Simple demo

[Rik Farrow <rik () spirit com>]

John McDermott <jjm () jkintl com> may have written:

> I agree here, too, which prompts a question: is there some (simple) attack
> I can use to demonstrate that SPFs in their current form(s) are
> (inherently) less secure than proxies?  IOW I would like to set up a simple
> demo to show that the internal systems can be successfully attacked even
> with an SPF firewall in place.

You can do a nice demo using buffer overflow attacks.  I tried this
about a year ago, with the IMAP daemon running under Linux.  It was
possible to add a new root account by connecting to the IMAP daemon
and sending it an overly long (about 1500 bytes) of a carefully
crafted string as the login name/password.  You can simulate this
by using netcat to connect to port 143 of a vulnerable Linux system
(these have all been patched, right?), and sending it about 2k of
random data preceded by the string "* login ".  If the IMAP
daemon crashes, it was vulnerable.

Now for the test.  Set up Checkpoint FW-1 (I tested V3.0) and Gauntlet
(v 3.2), with the target host behind the firewall, and the firewall
permitting access to the target hosts vulnerable IMAP server.  Gauntlet,
the AG, truncates the long login string, but Checkpoint, being SPF, does
not.  IMAP core dumps (buffer overflows) when protected by Checkpoint.

The key thing here is that a properly written AG will guard against
buffer overflow exploits by counting and only passing a 'reasonable'
number of bytes to a server.  SPF firewalls don't implement the
application protocol, so are unaware of any potential buffer overflow.
Of course, if all of your servers are correctly written, this is
not a problem...

You can also do things such as setup netcat in server mode, listening
to port 53 TCP, behind Checkpoint configured to permit all DNS
traffic through.  Using Netcat in client mode outside the firewall,
connect to the internal netcat server.  PF, SPF, SMLI, and circuit
relays such as SOCKS ignore the content and merrily pass along the
packets.  AGs 'notice' that the content is not DNS requests/responses
and prevent this activity.

Food for thought.

Regards,
Rik