Re: Active to Passive FTP translator?

[Mikael Olsson <mikael.olsson () clavister com>]

Scott, David,

[Whoops, I sent the last copy by mistake. 
 Here's the complete mail.]

"Scott, Richard" wrote:
> I am just curious at the real threat of allowing non passive 
> FTP connections from clients.

The threat is that the firewall protecting the client needs to allow
inbound connections on "random" ports.  This can either be done through
poking big static holes through the firewall (unless you're doing 
dynamic NAT), or having the firewall look at the control channel and
obey what it says.

The problem is that you can't really TRUST the control channel.

If an attacker can get a client to send "let outside people connect to 
me on port 1433", and there's an sql server running on port 1433, well,
all of a sudden, the attacker is allowed to connect to the sql server.

For firewalls that do not reassemble the ftp control channel TCP stream,
I've demonstrated TWICE that this can be bypassed. I fully expect that
there are more tricks to play on layers 2 (IP) and 3 (TCP), and perhaps
also tricks to be played on the client software itself.

However, there's more ...


David Pick wrote:
> Active FTP with a firewall that is sensitive to the content
> of the FTP control connection is as safe as you can readily
> get. In fact, in these circumstances, it makes little
> difference if you use active or passive FTP.

I've personally punched through several proxy firewalls that do this.
I remember Gauntlet and Raptor (Symantec Enterprise Firewall) off 
the top of my head, but it really doesn't matter. If they allow
clients to speak active mode, they're basically screwed.

I didn't do it through TCP/IP games, since full proxies aren't 
vulnerable to that kind of stuff, but the problems do not end there.

Consider this:
- Attacker writes a java applet that speaks 100% RFC compatible 
  active mode FTP
- Attacker gets an internal user to load this java applet (through
  HTML mail, DNS poisoning, cross-site-scripting, whatever... there's
  plenty of ways to get this to happen)
- The java applet connects out through the firewall, to a fake FTP
  server under the attacker's control, and sends 
  "PASV 192,168,0,1,5,153" (connect to me on port 1433)
  and then
  "RETR whatever.bin" (i want to receive data)

This opens up a channel from the attacker's "FTP server" through
which he can send whatever data he wants to.  If the FTP ALG is
_properly_ written, he shouldn't be getting any data back, but
that is seldom a requirement for successful exploitation; especially
in the case of attacks against intranet HTTP servers.


This active/passive mode horridity needs to obsoleted, and, 
fortunately, there is work underway to do just that.

Of course, all the new cool multimedia protocols make FTP transfer 
modes seem like nothing in comparison  Expect more fun in the 
dynamic data channel area.


Regards,
/Mikael Olsson

-- 
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com

"Senex semper diu dormit"
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards