Fragroute and ISS (NetworkICE) products: a brief analysis

["Chris Deibler" <chris.deibler () vigilantminds com>]

        The new Fragroute and its interactions with Snort and related
software pieces has been getting a lot of exposure over on Bugtraq.
This is great -- Snort is a fantastic tool, but there is also a rather
large installed base of ISS products, and thus far (to my knowledge) ISS
has not released any significant official documentation regarding the
interaction of the new fragroute and the various sentries and agents
that comprise a defacto ICECap setup other than a brief statement in an
article or two circulating currently.  I have clients asking me if this
is an issue, so I thought I'd do a little research and share it with the
community.  I'll try and make my assumptions clear, but please feel free
to poke holes in my work.

Basic facts
---

The Sentry used for event detection for the course of this document is
running version 3.1eal.
The Sentry is running the NI daemon at about 5% CPU utilization
pre-test.
The Sentry is not running Response Rulesets, nor does it have custom
.ini fields in its IDS policy element.
The ICEcap server used for this test is running 3.0eat.


Assumptions
---

NI workstation agents are going to detect events in this scenario better
than a sentry , as it only has one IP to worry about decoding data for.
Individual box performance aside, this should also hold true for server
agents.  Thus, I consider the sentry the "worst case scenario".


Our first set of tests is using a fragroute.conf comprised of:

ip_frag 8 old
order random
print

I don't think the 'print' statement is going to impose too much of a
performance hit on our testing, and I would like the confidence of
seeing the fragmentation actually taking place.

The first test is a before and after snapshot of a pingflood-style
event.  The ping in question:

ping xxx.xxx.xxx.xxx -s 40000 -f

Without fragroute:
60 second storm (2003 packets)
Events detected:
ECHO STORM, count 100

With fragroute:
60 second storm (1998 packets)
Events detected:
Too much IP fragmentation, count 94
ECHO STORM, count 97

All ECHOs experienced 100% packet loss (the host did not want to play
fair).

This behavior continues when we decrease the fragment size (in
fragroute.conf) from 16 bytes to 8.  Another ~100 echo storm counts and
~100 too much IP fragmentation counts.

Interestingly enough, when reducing the size of the packets to 15000
bytes, allowing for only 69% packet loss (and indeed, parsing of the
responses from the host and not just the attack pings), we get two
additional events:

IP microfragment, count 24, length 8, protocol 1
IP fragment data changed, count 802, expected (list of expected data),
offset (list of offset data), length 8
The 94 ECHO storm events are unchanged.

This is a minimalist event type to try this kind of testing with, but I
think it establishes that BlackICE is at least reassembling the packets.
On a side note, adding ip_chaff and delay random 50 to the .conf file
caused my fragroute process to core dump when it received its first
packet.

Moving on to a more meaningful test, let's take something that has
become somewhat defacto in the last two years, the IIS traversal.  We
have whipped up a script ("just add perl!") to execute a large number of
different traversals in short order for this test.  This has the nice
side effect of showing us a few different types of events.  Your stock
Nimda hit will generate the following 3 events (with varying counts,
depending on version and coalescence settings) under BlackICE:

HTTP URL scan, count 6
HTTP UTF8 backtick, count 4
IIS system32 command, count 6

The following fragroute.conf was in use for this event:

ip_frag 8 new
tcp_chaff cksum
order random
print

> From my reading, this seems a little more likely to throw off the
Sentry.  With our script running against an IIS web server (not local,
in this case), the following events were returned:

Without fragroute:
IIS system 32 command, count 5
IIS system 32 command, count 4
HTTP UTF8 backtick, count 36
HTTP URL scan, count 40

With fragroute:
IIS system 32 command, count 1
IIS system 32 command, count 7
HTTP UTF8 backtick, count 36
HTTP URL scan, count 40
IP fragment data changed, count 1627

To be honest, the result set was more consistent than I had guessed it
would be.  We seem to have lost an IIS system32 command somewhere in the
fray, however, we can't necessarily pin that on the fragmentation, as
ICEcap's event coalescence and correlation can be a bit flaky on its own
sometimes.  I encourage others to test similar circumstances.

> From here I decided to get really silly and start throwing in some
hellish fragmentation options, with frequent core dumps on the poor
system selected to bear the burden of our fragmentation efforts.  My
most successful run was a manual IIS traversal that almost completed
transmitting before the core dumped.  The .conf settings for that run:

tcp_chaff cksum
drop random 15
tcp_seg 8 new
dup random 5
order random
print

More experimentation is needed to determine whether I'm just killing the
stack or there's a few bugs in the fragroute code (or one of the
requisite libraries).  Fragroute itself is a really fun toy that could
have a lot of potential in the attack & penetration biz, provided the
options can be worked out to dodge various IDS pieces.  Granted, ping
floods and traversals aren't the only bad things going on out there, but
I think they are fairly useful common denomintaors.

If I recall, the BlackICE suite had no real problems with the original
fragrouter, and I think that my data shows that there's no reason to
panic as an ISS customer or affiliate.  My gut feeling is that the
blackICE engine is robust enough to handle anything the new fragroute
can throw at it, but that's a strong statement to make on only a few
hours of data.  In a way, I'd really love to see if someone can come up
with an option package that will mask an IIS traversal to a sentry.
After all, I spend half my time on the other side of the
managed/professional services line.  Thanks to some of our clients for
donating some time on a few external dev boxes for a few trial runs, and
thanks to the ISS team for their continuing efforts with the ICECap
suite.

--Chris



********************************************
Chris Deibler, CISSP
Senior Security Consultant
VigilantMinds Inc.
Office 412-661-5700 ext.205
Fax 412-661-5684
www.vigilantminds.com
********************************************

This e-mail and any files transmitted with it is copyright VigilantMinds
Inc., 2002.  Unauthorized reproduction of this information is prohibited
without express permission.  All ISS/NetworkICE products are Copyright
ISS, Inc.

********************************************