OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Extending the FTP "ALG" vulnerability to any FTP client
From: Darren Reed (avalonCOOMBS.ANU.EDU.AU)
Date: Tue Mar 14 2000 - 18:31:35 CST

In some mail from Mitchell Blank Jr, sie said:
>
> Mikael Olsson wrote:
> > * 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.
>
> It would be nice if the browsers had a "disallow FTP to non-
> standard ports" checkbox.
>
> > 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"
>
> Actually, on some firewalls you might be able to skip
> all the aaaaaaa's then, since PORT is now legitamately another
> command.

If ftp.rooted.com is an evil ftp server, your options are very limited.

You can dump all ports < 1024, but what about 2049/tcp and 6000/tcp ?
And what about others, such a oracle, etc ?

I don't need to use a bad hyperlink in HTML to do the above, I can
equally use Java.

In this case, it does not matter if an application proxy or packet
filter job. By the time the web browser sends "CWD /aaaaaaa", it
has done a login already so sending "PORT" next is as one would
expect from the ftp proxy.

The worst case scenario that I'm aware of, in so far as ftp clients
to proxy, is "links" which packs USER/PASS/CWD/PORT/GET all into
one long string to send to the ftp server.

In comparison, I don't see nearly as many problems with passive ftp.

Darren