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 [lcamtufat_private] [security] [http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};: =-=> Did you know that clones never use mirrors? <=-=
This archive was generated by hypermail 2b30 : Wed Aug 01 2001 - 22:51:47 PDT