Re: [fw-wiz] Variations of firewall ruleset bypass via FTP
From: Paul D. Robertson (proberts@patriot.net)
Date: 10/10/02
- Next message: Carson Gaspar: "Re: [fw-wiz] Variations of firewall ruleset bypass via FTP"
- Previous message: Darren Reed: "Re: [fw-wiz] Variations of firewall ruleset bypass via FTP"
- In reply to: Mikael Olsson: "[fw-wiz] Variations of firewall ruleset bypass via FTP"
- Next in thread: Carson Gaspar: "Re: [fw-wiz] Variations of firewall ruleset bypass via FTP"
- Reply: Carson Gaspar: "Re: [fw-wiz] Variations of firewall ruleset bypass via FTP"
- Reply: Mikael Olsson: "Re: [fw-wiz] Variations of firewall ruleset bypass via FTP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Paul D. Robertson" <proberts@patriot.net> To: Mikael Olsson <mikael.olsson@clavister.com> Date: Thu Oct 10 22:27:01 2002
On Thu, 10 Oct 2002, Mikael Olsson wrote:
> 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 :)
I'd like to point out, in case it's not obvious, or for folks who've
missed the earlier thread and haven't yet read the archives[1], "class of
attack" isn't limited to "class of attack against FTP." Any protocol that
echoes some sort of user-provided input (file name, credentials...) and
dynamically opens ports can have issues like this. I know it's been
mentioned before, but we've had a pretty good chunk of new subscribers
today and late yesterday, so I want to be sure it's mentioned again.
> 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]
At the risk of re-ranting over FTP, we *really* need to be moving folks
away from FTP as a protocl. HTTP and SCP both at least get rid of the
whole data/command channel issue.
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?
Also, don't most HTML clients do PASV only?
[snip]
One of the things that makes FTP such a bad case is that protecting the
server means going to active FTP and protecting the clients means going to
PASV mode. So there's not a natural protection point that allows both to
be satisfied.
Personally, I can't think of anything that would make me want to let my
desktop clients do active FTP out from my network. If I had a real need
for active FTP, I'd probably spend my time on an HTTP-based FTP gateway.
For the few applications that wanted to do their own active FTP client
stuff, I'd be putting major pressure on the application vendor.
If you've got public FTP servers, and they're behind some sort of stateful
filter, you're sort of part of the problem[2], and I have less sympathy.
As should have been painfully obvious in 2000, FTP has serious issues for
stateful filtering. People who fixed a particular issue still may not
have all the issues rounded out, and if they do, the level of code
complexity goes up significantly[3]. Prudence therefore would dictate
that firewall administrators "fix" this problem the "better" way by not passing
it *through* firewalls (browsers have seperate FTP proxy settings, so it's
possible to pass it *to* a firewall, then in, rather than *through* it.)
Paul
[1] http://honor.icsalabs.com/pipermail/firewall-wizards/2002-October/thread.html
[2] I almost said "port of the problem," but the bad humo[u]r is reserved
for folks who read footnotes ;)
[3] Which kind of begs the question should firewalls alert on attempts to
do partial acks if they're able to detect it?
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
proberts@patriot.net which may have no basis whatsoever in fact."
probertson@trusecure.com Director of Risk Assessment TruSecure Corporation
- Next message: Carson Gaspar: "Re: [fw-wiz] Variations of firewall ruleset bypass via FTP"
- Previous message: Darren Reed: "Re: [fw-wiz] Variations of firewall ruleset bypass via FTP"
- In reply to: Mikael Olsson: "[fw-wiz] Variations of firewall ruleset bypass via FTP"
- Next in thread: Carson Gaspar: "Re: [fw-wiz] Variations of firewall ruleset bypass via FTP"
- Reply: Carson Gaspar: "Re: [fw-wiz] Variations of firewall ruleset bypass via FTP"
- Reply: Mikael Olsson: "Re: [fw-wiz] Variations of firewall ruleset bypass via FTP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|