6831977 2001-08-01 22:57 -0400 /126 rader/ Michal Zalewski <lcamtuf@gis.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-02 08:17 av Brevbäraren
Extern mottagare: Darren Reed <avalon@coombs.anu.edu.au>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18588>
Kommentar till text 6831975 av Darren Reed <avalon@coombs.anu.edu.au>
Ärende: Re: [RAZOR] Linux kernel IP masquerading vulnerability (_actual_
------------------------------------------------------------
From: Michal Zalewski <lcamtuf@gis.net>
To: Darren Reed <avalon@coombs.anu.edu.au>
Cc: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.21.0108012225040.747-100000@nimue.bos.bindview.com>
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? <=-=
(6831977) /Michal Zalewski <lcamtuf@gis.net>/(Ombruten)