mailing list archives
Re: Extending the FTP "ALG" vulnerability to any FTP client
From: solar () FALSE COM (Solar Designer)
Date: Sun, 12 Mar 2000 05:41:55 +0300
* 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">
I was playing with that recently as well. Yes, this works. Some
browsers add an extra "/" to such requests (at least on the first
check, for a directory), so one might want to add %0d%0a to the end.
It's also important that this is either an ftp URL, or some other
text-based protocol directed to 21/tcp (such as, http://server:21).
* 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.
This is not always necessary. Linux's ip_masq_ftp module is happy to
detect PORT anywhere in packets travelling to 21/tcp.
* 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 (126.96.36.199 in this case)
It will also translate the PORT command, so that ftp.rooted.com sees
the firewall's IP address and port number that's currently redirected
* 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.
There's a partial workaround: only allow access to non-privileged
ports. Yes, there can still be vulnerable services on those. :-(
I haven't tested if this would work with real-world FTP clients on
Win32 -- are there any that would use privileged ports?
* 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
That doesn't help against the http://...:21 trick.