Fragroute and ISS (NetworkICE) products: a brief analysisFrom: Chris Deibler (email@example.com)
- Previous message: KF: "ecartis / listar PoC"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 25 Apr 2002 18:35:58 -0400 From: "Chris Deibler" <firstname.lastname@example.org> To: <email@example.com>, <firstname.lastname@example.org>
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.
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.
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 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.