In some mail from Michal Zalewski, sie said: [...] > This does not really give that much. As discussed in our advisory, it is > possible to generate 'good loking' USER and NICK sequence, and 'good > looking' IRC server response. Two things here - first of all, most of web > browsers ignore first line sent by remote host - the banner - and accept > it even if it does not start with valid ftp protocol numeric code. Also, > response fragmentation (newlines in the middle of TCP packets, and so on), > can be used to make HTTP client think it sees FTP messages and the > firewall to think it sees IRC conversation. Sample conversation might > look like that: > > > ":server 255 user :Hello\r\n331 Username OK" > (ignored by web browser) Say what? What do FTP numeric responses have to do with IRC and an IRC proxy? Also, IRC servers generally don't send anything unless an error is generated, a PING is sent or registration is complete. There is no "you have connected to me" banner (or is this a recent bastardisation?). > < "USER user +iw user user\r\nNICK user\r\n" > (as a result of ftp://USER%20user%20...@server:6667/...) > > > ":server 255 user :You are welcome\r\n210 Something" > (client will usually join this together with remaining > 331 Username OK from previous message; firewall would > probably parse it as-is, as IRC message) > > ...and so on, and so on. Upto this point you've not shown me anything that a well written proxy cannot detect and reject. 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. Likewise the irc proxy should be doing the same. Given that this is for IRC and IRC uses TCP, it can simply drop things which are out of order (if a server is trying to play nasty and attack). The proxy should work when it is interfacing between an IRC client and an IRC server under normal circumstances (i.e ignore things going through byte at a time, etc) but whether or not it does when talking to an FTP server is not important, although you would generally prefer it didn't. So where was I going with that...oh, that's right, your look-alike ":server 255 user :You are welcome" should just be ignored and given the FTP server is never going to respond in a fashion that is recognised by the IRC proxy, you'll go nowhere, fast. > Not to mention using Java applets for this purpose. Very tight protocol > validation makes the attack somewhat more complicated, but does not solve > the question of sender's intentions =) 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). For most netizens that use Windows, so long as the < 1024 ports are just ignored, life is not likely to be too hard. 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#. Darren * - well, it's _meant_ to work that way :*)
