Re: Variations of firewall ruleset bypass via FTP

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

Cut-n-paste responding; first Paul, then Darren:

"Paul D. Robertson" wrote:
> > First, just a client side attack scenario as I imagine it:
> >
> > We plant a link or IMG SRC somewhere, or mail it to them.
> > <img src="PORT 1,2,3,4,5,6/bogus.txt">
>
> I admit to being a little confused at the first <IMG SRC> tag- do you 
> expect that in an FTP URI's content somewhere (i.e. ftp://something.html), 
> an HTTP URI with and FTP port spec, or is that a valid HTML reference?  

Snafu. I meant:
<img src="ftp://evilserver.int/PORT 1,2,3,4,5,6/bogus.txt">


> Also, don't most HTML clients do PASV only?

- Netscape will fall back to active mode.
- IE does active by default these days ("FTP folder view" turned on).
  However, if this is changed, it only understands passive and refuses
  to fall back to active.
- The Squid proxy will fall back to active mode.
  (Yummy. Attacker gets to connect to proxy port and bounce attacks to
   intranet servers.)

- I can't get opera to fall back to active mode.
  However, this could be because I suck at FTP response codes. Opera is
  _very_ picky about the codes it receives, in stark contrast to
  most other FTP clients.


> At the risk of re-ranting over FTP, we *really* need to be moving folks
> away from FTP as a protocol.  HTTP and SCP both at least get rid of the
> whole data/command channel issue.

Amen.

Of course, then there's H.323 as well as "The Return Of the H.323 
from hell": SIP.  But that's for another day.


Paul Robertson wrote:
> [3] Which kind of begs the question should firewalls alert on attempts to
> do partial acks if they're able to detect it?

Darren Reed wrote:
> That aside, my view on this is "funky ACKing" may be within the
> bounds of legal TCP operation, but it's not what any "nornmal"
> FTP client is going to do so throw those packets away.

I've been asking myself this question. It applies to IDSes too.
(Indeed, I was pondering IDS evasion techniques when I came up with this.)
There _is_ in fact a valid use for partial acknowledgments.

- Receiving end checks pool of receive window buffers and comes to 
  the conclusion that there's plenty free. Sends out RWIN=8192
- Sender sees RWIN=8192 and fires off several full-length segments.
- Receiver receives segments, but, ACK(tm)! Other sockets snarfed all
  the buffers! All we can get our hands on is a measly 512 byte one!

At this point, the receiver can either just drop all segments, _OR_
grab hold of the 512 first bytes of the first segment, and send out
an ACK that only partially acknowledges the first segment.


Darren Reed wrote: 
> But if the attacker has got access to the local filesystem in order
> to create [file names with CRLFs in them], then there is little a 
> firewall of any sort is going to be able to do to stop them.

Yes, if an attacker can create file names with CRLFs in them, we're
most likely screwed no matter what we're running.

However, IMHO, the same _shouldn't_ have to be true for an attacker that 
simply creates file names (without CRLFs in them) via FTP and issues 
STAT commands.  I'm thinking that f.i. the latest version of ipf stops 
this, but not the version currently shipping with NetBSD?


-- 
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
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards