Re: FireWall-1 FTP Server Vulnerability

[monti () USHOST COM (monti)]

On Wed, 16 Feb 2000, Borbely Zoltan wrote:

> On Mon, Feb 14, 2000 at 07:32:54PM -0600, monti wrote:
> [...snip...]
>
> > First watch for:
> > client -> ftp-server "PASV"
> >
> > which triggers the firewall to look for this immediately afterwards:
> > client <- ftp-server "227 Entering Passive Mode (xxx,xxx,xxx,xxx,prt,prt)
> >
> > If any other statement is seen from client or server, before the presence
> > of the 227 port declaration, the attempt is ignored.
>
> This solution can't block the exploit. In the following case:
>
> C -> S "STAT -1"
> S -> C "."
> S -> C ".."
> C -> S "PASV"
> S -> C "227 Entering..."
>
> I know, this is against the RFC, but the SPF firewalls can misinterpret
> the whole situation.
>
> The time frame of the successful attack is very small, but maybe you can
> try to close the send window of the server. Maybe it works, but this is just
> theory.

Yes good points. As I said, I figured it could probably still be
manipulated. My real concern in my reply to checkpoint was that they were
putting out a 'patch' that barely fixed the exploit originally posted. And
only one incarnation of it at that.

I was (as I'm sure most bugtraq readers were) astounded at the weakness of
the checkpoint 'fix', and just simply had to point it out. For all I know,
they may have planned on a more comprehensive one to follow when they got
around to it, but I really just wanted to make sure that this was being
brought up.

I agree that proper FTP server implementation is extremely important, but
the unfortunate and frustrating trend that admins and security people face
these days is that 'the firewall' has taken on a role in many minds of
being able to cover all the deficiencies of un-patched/un-secured
internal/dmz systems. (I'm definitely not advocating this view, I just see
it with almost every client I work with to some degree. Bugtraq readers
ofcourse know better... right? <cough>).

With that in mind, it's a scary (but perhaps encouraging in the long term)
thing to see that most people will be cought with their pants down with
this sort of vulnerability since the solution is actually the reverse. The
end-node has to cover for deficiencies in the firewall. Back to basics
(yay!), but how long will it take to get there for some people?

.endrant

Based on your theoretical attack above (as well as the response from other
bugtraq'rs) I get the feeling that maybe an app-proxy --implementing
some of the techniques mentioned so far-- might be alot safer for this
overall.(?)

It seems that the above technique wouldnt be successful if the firewall
kept closer track of the order that packets/ftp control messages were sent
and arrived. (i.e. actually being an active part in the tcp session) or am
I missing something else in this specific instance?

(My disclaimer of this still being really hard to truly fix still applies
ofcourse).

Eric Monti
Denmac Systems
ericm () denmac com
monti () ushost com