Re: [RAZOR] Linux kernel IP masquerading vulnerability (_actual_

[Michal Zalewski <lcamtuf () gis net>]

On Thu, 2 Aug 2001, Darren Reed wrote:

> Say what?  What do FTP numeric responses have to do with IRC and an IRC
> proxy?

Firewall thinks this is IRC protocol connection, HTTP client thinks it is
FTP connection. That's it. Since HTTP clients like Netscape Navigator do
not really care about any standards, they tend to do things like ignoring
first line from the server no matter how it looks like. This can be used
to trick some proxies - and yes, this can be defeated, as well. Things
like this just make protocol tracking more tricky - since HTTP client
might send commands that 'look legitimate', and might consider received
responses valid FTP responses, even if they are not. It is pretty
difficult to predict how all 'major' HTTP browsers or HTML-capable MUAs
will behave - every single one of them is different, and usually has 
brain-damaged FTP implementation ;>

> Also, IRC servers generally don't send anything unless an error is
> generated, a PING is sent or registration is complete.

Untrue. Typical EFNet server:

$ nc 217.17.33.10 6667
NOTICE AUTH :*** Looking up your hostname...
NOTICE AUTH :*** Found your hostname, cached
NOTICE AUTH :*** Checking Ident
NOTICE AUTH :*** Got Ident response

> Upto this point you've not shown me anything that a well written proxy
> cannot detect and reject.

Actually, since HTTP client behavior vary, and is far from being
standarized or RFC-compliant, I believe it is at least difficult to
propose one, good way of handling stuff like that, in general. There are
some protocol-related checks you might apply and hope that would work
(e.g. dropping connection if commands like 'SYST' are sent to something we
believe is an IRC server, not FTP server), but it is protocol-dependent.
Or client dependent, in other cases.

Actually, much better way to handle it, as suggested by Matt Power, is for
the firewall to send PING with some secret value as a challenge to what we
believe is IRC client at the very beginning, and to expect PONG response
to assure we're talking to IRC client, not something blindly sending
IRC-alike commands. The problem is that it is protocol-specific, and does
not solve general problems of masquerading helpers (inability to determine
and verify user's will ;), nor does not defend against Java applets.

> At least the IPFilter ftp* proxy knows if it was in the middle of a
> string when it reached the end of the packet and junks following text
> upto the next \r\n in the next packet.

By 'junking' you mean discarding, or just not parsing it, but forwarding?
If discarding, I'm not really sure if that is reasonable - I can't use
char-by-char mode tools, like Windows telnet client, to chat with ftp
servers? If not parsing, ok. Next - what about long packets? HTTP client
input-parsing buffer might be smaller than received data, and it might
keep parsing one huge IRC protocol-alike response sent at the beginning
for whole session. It ignores first portion, no matter how it looks like,
and gets portions starting with '220 Ok...' or something like that... Of
course! You can defend, you can check packet size, as well. But keep in
mind what I was saying - I do not claim you _cannot_ do strict protocol
verification to assure communication protocol validity and to detect
attacks. I just think that's not the way, because it is neverending battle
- and yet, at the end, there's Java applet that can connect to its 'home
server', to port 6667 as well. So this is partial solution, hard to tell
how accurate - and how many ways to abuse HTTP client FTP protocol
implementation oddities are there - and I won't bet my life on it, even if
applied to IMG tags only, and if we do not care about Java applets.

> So where was I going with that...oh, that's right, your look-alike
> ":server 255 user :You are welcome" should just be ignored

Very interesting policy, since that's what many IRC servers send.

> If you want to go to that extreme, there is nothing safe you can do.
> The applet could sit there sending out PRIVMSG commands to a /dev/null
> style server for every port from 1024 - 65535 (there's no requirement
> on the part of DCC for the previous port to be connected before
> another "connect to me " announcement is sent out).

I don't see your point here. Why /dev/null-style server? The server might
respond correctly, and it is not a big deal to implement valid Java applet
IRC client. It can behave just like any IRC client, and the other end
might be a valid IRC server. The only difference is that, at some given
point, this IRC client sends evil DCC request. The only difference is that
it sends something without user's will. And welcome, no matter how careful
protocol inspection you perform, here we are, sending legitimate DCC
request to remote server from protected network.

Sad fact: 90% of people, if not more, have Java applets enabled. We
described HTML tag abuse just because it sounds better, and demonstrates
that "disabling Java" should not be the answer. But with careful protocol
inspection, even if you can bet your life on its accuracy, which I
wouldn't do, we are still vulnerable.

> Even the original problem needed a bit of work to exploit.  Whilst the
> target string is:
>
> <IMG SRC="http://server:6667/^ADCC stuff^A">
>
> you should at least have been required to get the correct IP address,
> which when using NAT and a web proxy may not even be available to the
> remote server.  Still, you can't use static HTML here, unless javascript
> can find out your IP#.

Hmm, why you "can't use" it? If you consider 'massive' attack against
vulnerable ip_masq_irc (or anything that buggy, w/o extact address
matching), not targeted attack, you can just put a bunch of IMG tags with
a bunch of possible addresses in private networks (usually 10.0.0.1 or
192.168.1.1 or something like that would work) - you'd have pretty neat
success ratio. If you consider targeted attack, you probably can obtain
this information one way or another (mail headers, or whatever - not
always, but often).

-- 
_____________________________________________________
Michal Zalewski [lcamtuf () bos bindview com] [security]
[http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};:
=-=> Did you know that clones never use mirrors? <=-=