8299163 2002-04-16 20:07 -0700 /26 rader/ <0xcafebabe@hushmail.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-17 08:30 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern mottagare: pen-test@securityfocus.com
Extern kopiemottagare: snort-devel@snort.org
Mottagare: Bugtraq (import) <21879>
Ärende: Snort exploits
------------------------------------------------------------
From: 0xcafebabe@hushmail.com
To: bugtraq@securityfocus.com, pen-test@securityfocus.com
Cc: snort-devel@snort.org
Message-ID: <200204170307.g3H37CD00821@mailserver2.hushmail.com>
I didn't see it posted to these lists, but yesterday Dug Song quietly released a tool on the focus-ids list which totally blindsides Snort - http://www.monkey.org/~dugsong/fragroute/index.html. His README.snort file contains several fragroute scripts which blindside even the current Snort version in CVS, tested on RedHat 7.2. For example, the latest wu-ftpd exploits run through the one line "tcp_seg 1 new" don't trigger any Snort alerts at all.
:( :(
Fragroute is a very powerful new tool. Has anyone found other attacks
against Snort with it, or tried it against any other IDS for that
matter?
-=+ 0xCafeBabe +=-
Hush provide the worlds most secure, easy to use online applications
- which solution is right for you? HushMail Secure Email
http://www.hushmail.com/ HushDrive Secure Online Storage
http://www.hushmail.com/hushdrive/ Hush Business - security for your
Business http://www.hush.com/ Hush Enterprise - Secure Solutions for
your Enterprise http://www.hush.com/
Looking for a good deal on a domain name?
http://www.hush.com/partners/offers.cgi?id=domainpeople
(8299163) / <0xcafebabe@hushmail.com>/----(Ombruten)
Kommentar i text 8304905 av Dragos Ruiu <dr@kyx.net>
8304905 2002-04-17 04:07 +0000 /100 rader/ Dragos Ruiu <dr@kyx.net>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-18 02:50 av Brevbäraren
Extern mottagare: 0xcafebabe@hushmail.com
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: pen-test@securityfocus.com
Extern kopiemottagare: snort-devel@snort.org
Extern kopiemottagare: roesch@sourcefire.com
Extern kopiemottagare: natasha@snort.org
Mottagare: Bugtraq (import) <21907>
Kommentar till text 8299163 av <0xcafebabe@hushmail.com>
Ärende: Re: Snort exploits
------------------------------------------------------------
From: Dragos Ruiu <dr@kyx.net>
To: 0xcafebabe@hushmail.com
Cc: bugtraq@securityfocus.com, pen-test@securityfocus.com,
snort-devel@snort.org, roesch@sourcefire.com, natasha@snort.org
Message-ID: <20020417040731.21e188af.dr@kyx.net>
Heh, well... first... don't panic. :-)
First of all I would like to commend Dug on his responsible
disclosure stance. He has given the IDS vendors several months heads
up that this stuff is in the pipe... I think everyone who needed to
know knew this was coming down the pipe, so this is in _no_ way
critical of him.
I was actually expecting him to release fragroute on the CanSecWest
conference CD, for his talk on it there and am preparing some
appropriate counter measures for the variant of snort I was going to
put on there. Been kinda swamped with conference preparations so
please do not ask me for any of this in advance of the conference.
Odds are now that this info has gone out snort cvs will have fixes
for this in a matter of hours or days...
The TCP evasions are fairly easily detectable as overlaps should not
normally occur. I'm sure Marty or Andrew will be releasing some
tweaks to stream4 shortly to address this. It is just a matter of
slightly more rigorous alerting and an occasional little bit of extra
noise.
Similarly the IP fragmentation detection just needs slightly more
rigorous overlap detection and alerting, as these overlaps will not
be occurring in normal situations. For now as a workaround you can
just alert on small fragments (resurrect minfrag... heh) which should
be indicative of games being played. Note that some of these
overlaps were successful in snort 1.8.x because the teardrop
detection had a bug in it which was recently found and was only fixed
again in snort 1.8.4. The moral of the story is that it pays to keep
your copy of snort current. :-)
Basically all the chaffing at the IP and TCP level is detectable as
those should not be normal conditions. Look to snort cvs over the
next few days for solutions to these issues...
To Dug:
As far as playing timing games in the future, well the solution for
this and some other problems will be target based reassembly which
varies reassembly timing and overlap behaviour based on destination
to mimic host specifics. And though the current frag2 snort
defragger features deterministic timeout behaviour the earlier defrag
reassembler had non-deterministic timeout behaviours on purpose to
specifically avoid timeout games and this kind of behaviour will
likely be resurrected on future defraggers. I have had a defragger
in the works for, oh, a long time... :) that fixes this and some
other issues. Guess Marty, I, and the other snort developers have to
get off our lazy asses (since snort development proceeds so slowly
:-) and fix that now. Heh... I'm being sarcastic for those that
didn't note.
The same logic and procedures can be applied at the TCP level as well
as at the IP fragmentation layer BTW.
To everyone else:
The game of evasion and coutermeasures is the snake eating its tail
and you shouldn't be naive and assume that there aren't other
evasions out there because there are _always_ other obfuscations and
countermeasures, and then detectors for those. That's why you pay us
snort developers the big bucks, and you should keep your ids builds
current fairly often... to keep you safe from that. :-)
But using fairly loaded terms like "blindside" is just excessively
alarmist imho.
cheers,
--dr
On Tue, 16 Apr 2002 20:07:12 -0700
0xcafebabe@hushmail.com wrote:
>
> I didn't see it posted to these lists, but yesterday Dug Song quietly released a tool on the focus-ids list which totally blindsides Snort - http://www.monkey.org/~dugsong/fragroute/index.html. His README.snort file contains several fragroute scripts which blindside even the current Snort version in CVS, tested on RedHat 7.2. For example, the latest wu-ftpd exploits run through the one line "tcp_seg 1 new" don't trigger any Snort alerts at all.
> :( :(
>
> Fragroute is a very powerful new tool. Has anyone found other attacks against Snort with it, or tried it against any other IDS for that matter?
>
>
> -=+ 0xCafeBabe +=-
>
>
>
>
> Hush provide the worlds most secure, easy to use online applications - which solution is right for you?
> HushMail Secure Email http://www.hushmail.com/
> HushDrive Secure Online Storage http://www.hushmail.com/hushdrive/
> Hush Business - security for your Business http://www.hush.com/
> Hush Enterprise - Secure Solutions for your Enterprise http://www.hush.com/
>
> Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople
>
>
--
--dr pgpkey: http://dragos.com/dr-dursec.asc
CanSecWest/core02 - May 1-3 2002 - Vancouver B.C. - http://cansecwest.com
(8304905) /Dragos Ruiu <dr@kyx.net>/------(Ombruten)
8304964 2002-04-17 18:07 -0400 /82 rader/ Grimes, Roger <RogerG@GoldKeyresorts.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-18 03:55 av Brevbäraren
Extern mottagare: 'Dave Ahmad' <da@securityfocus.com>
Extern kopiemottagare: 'bugtraq@securityfocus.com' <bugtraq@securityfocus.com>
Mottagare: Bugtraq (import) <21918>
Ärende: RE: Snort exploits
------------------------------------------------------------
From: "Grimes, Roger" <RogerG@GoldKeyresorts.com>
To: 'Dave Ahmad' <da@securityfocus.com>
Cc: "'bugtraq@securityfocus.com'" <bugtraq@securityfocus.com>
Message-ID: <B7C0314C9765D511BEB200E018C4638EB7E3DF@mail.phr.com>
Not to get even further off topic...but I will...to support Draqos.
The whole IDS evasion thing mimics the scanners vs. virus writers
war. I've been doing antivirus work since 1989 and I have heard that
virus writers were going to polymorph, encrypt, oli-this, poly-that
since before there were 100 viruses. Nobody, not even the AV vendors
thought that scanners would still be fighting the good fight (and
winning 99.999% of the time) when 30,000+ viruses and worms appeared.
Virus scanners would run out of memory, wouldn't be able to keep up
with the signatures, would end up with too many false-positives,
would run so slow nobody would use them, etc. But the truth is
fingerprint scanning (no matter how flawed) still works and I hear
less about AV scanner deaths every year...and when I do hear it's
from the vendors themselves...and guess what they have the new
solution sitting in the wings ready to go. I see the same pattern in
IDS...heck, yeah, the black hatters will develop more sophisticated
hacks...and the white hatters will fight back...SUCCESSFULLY.
With that said, there are some viruses today that scare the mess out
of the good AV guys...ones that scare them and keep them up at night.
And DDoS "Reflection" attacks???...if you're not scared you don't
understand the problem. But the good guys will respond and life will
go on as usual.
Just my one cent.
Roger A. Grimes
***************************************************************************
*Roger A. Grimes, VP of IT for GK/PHR Holding Company *Gold Key
Resorts and Professional Hospitality Resources *email:
rogerg@goldkeyresorts.com *ph: 757-491-2101 x403 *fax:757-491-6550
*932 Laskin Road, Virginia Beach, VA 23451 *Author of Malicious
Mobile Code: Virus Protection for Windows by O'Reilly
*http://www.oreilly.com/catalog/malmobcode/
***************************************************************************
;-----Original Message-----
;From: Dragos Ruiu [mailto:dr@kyx.net]
;Sent: Wednesday, April 17, 2002 12:08 AM
;To: 0xcafebabe@hushmail.com
;Cc: bugtraq@securityfocus.com; pen-test@securityfocus.com;
;snort-devel@snort.org; roesch@sourcefire.com; natasha@snort.org
;Subject: Re: Snort exploits
;Heh, well... first... don't panic. :-)
;I was actually expecting him to release fragroute on the CanSecWest
conference CD,
;for his talk on it there and am preparing some appropriate counter measures
for the
;variant of snort I was going to put on there. Been kinda swamped with
conference
;preparations so please do not ask me for any of this in advance of the
conference.
;Odds are now that this info has gone out snort cvs will have fixes for this
;in a matter of hours or days...
;The TCP evasions are fairly easily detectable as overlaps should not
normally occur.
;I'm sure Marty or Andrew will be releasing some tweaks to stream4 shortly
to
;address this. It is just a matter of slightly more rigorous alerting and
;To everyone else:
;The game of evasion and coutermeasures is the snake eating its tail and you
;shouldn't be naive and assume that there aren't other evasions out there
because
;there are _always_ other obfuscations and countermeasures, and then
detectors for
;--dr
(8304964) /Grimes, Roger <RogerG@GoldKeyresorts.com>/(Ombruten)
8309705 2002-04-18 10:34 -0400 /57 rader/ Dug Song <dugsong@monkey.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-18 21:18 av Brevbäraren
Extern mottagare: Dragos Ruiu <dr@dursec.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: snort-users@lists.sourceforge.net
Extern kopiemottagare: pen-test@securityfocus.com
Extern kopiemottagare: roesch@sourcefire.com
Extern kopiemottagare: 0xcafebabe@hushmail.com
Mottagare: Bugtraq (import) <21922>
Kommentar till text 8310921 av Dragos Ruiu <dr@dursec.com>
Sänt: 2002-04-19 02:29
Ärende: Re: fragroute vs. snort: the tempest in a teacup
------------------------------------------------------------
From: Dug Song <dugsong@monkey.org>
To: Dragos Ruiu <dr@dursec.com>
Cc: bugtraq@securityfocus.com, snort-users@lists.sourceforge.net,
pen-test@securityfocus.com, roesch@sourcefire.com,
0xcafebabe@hushmail.com
Message-ID: <20020418143408.GV29490@naughty.monkey.org>
On Wed, Apr 17, 2002 at 11:11:54PM +0000, Dragos Ruiu wrote:
> First, this is not a snort-only issue, as I would wager other idses
> have as many if not more evasion modes as well as sharing these with
> Snort...
absolutely correct. Snort, i'd wager, does much better than most.
most stateful inspection firewalls and "intrusion prevention" or other
application-layer content filtering devices (e.g. Cisco NBAR) have
similar vulnerabilities that may be tested with fragroute.
> Most firewalls these days (especially Linux and OpenBSD ones)
> actually do reassembly inbound.
this isn't quite true. most stateful inspection firewalls do "virtual
reassembly" for IP fragments, and a few do basic window tracking for
TCP connections, but will still allow most fragroute-style attacks
through (e.g. duplicate overwriting TCP segments with older TCP
timestamp options for PAWS elimination, short TTLs, etc.).
your best bet (for the truly paranoid) is an application-layer
firewall, but we all knew that already. :-)
TCP scrubbers, as proposed by Malan, Paxson, et al. [1] [2] and
implemented by Provos, Paxson, et al. [3] [4] are a good intermediate
solution, but haven't found widespread deployment.
> This was an interesting point discovered recently when it was
> realized that the snort defragger was actually never getting touched
> at all in some installations.
IP fragmentation is rare to begin with [5], so i wouldn't chalk this
up to firewall magic - especially when all major firewalls still pass
fragments in their default configuration, and ONLY OpenBSD pf and
Linux netfilter can actually be configured to reassemble. even fewer
track TCP windows, options, etc...
-d.
[1]
http://www.eecs.umich.edu/~rmalan/publications/mwjhInfocomm2000.ps.gz
[2] http://www.icir.org/vern/papers/norm-usenix-sec-01.ps.gz [3]
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_norm.c [4]
http://www.mirrors.wiretapped.net/security/network-intrusion-detection/norm/
[5] http://www.caida.org/outreach/papers/2001/Frag/
---
http://www.monkey.org/~dugsong/
(8309705) /Dug Song <dugsong@monkey.org>/-(Ombruten)
Kommentar i text 8311044 av Darren Reed <avalon@coombs.anu.edu.au>
8311044 2002-04-19 08:10 +1000 /47 rader/ Darren Reed <avalon@coombs.anu.edu.au>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-19 04:21 av Brevbäraren
Extern mottagare: Dug Song <dugsong@monkey.org>
Extern kopiemottagare: Dragos Ruiu <dr@dursec.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: snort-users@lists.sourceforge.net
Extern kopiemottagare: pen-test@securityfocus.com
Extern kopiemottagare: roesch@sourcefire.com
Extern kopiemottagare: 0xcafebabe@hushmail.com
Mottagare: Bugtraq (import) <21945>
Kommentar till text 8309705 av Dug Song <dugsong@monkey.org>
Ärende: Re: fragroute vs. snort: the tempest in a teacup
------------------------------------------------------------
From: Darren Reed <avalon@coombs.anu.edu.au>
To: dugsong@monkey.org (Dug Song)
Cc: dr@dursec.com (Dragos Ruiu), bugtraq@securityfocus.com,
snort-users@lists.sourceforge.net, pen-test@securityfocus.com,
roesch@sourcefire.com, 0xcafebabe@hushmail.com
Message-ID: <200204182210.IAA10429@caligula.anu.edu.au>
In some mail from Dug Song, sie said:
>
> > Most firewalls these days (especially Linux and OpenBSD ones)
> > actually do reassembly inbound.
>
> this isn't quite true. most stateful inspection firewalls do "virtual
> reassembly" for IP fragments, and a few do basic window tracking for
> TCP connections, but will still allow most fragroute-style attacks
> through (e.g. duplicate overwriting TCP segments with older TCP
> timestamp options for PAWS elimination, short TTLs, etc.).
Well then IDS software needs to be smarter. IMHO it makes little
sense for an IDS to be *behind* a firewall as it's going to miss out
on lots of useful data points. Maybe this means telling your IDS
software how big your network is so it can make intelligent decisions
about how far a packet will go based on its TTL.
> > This was an interesting point discovered recently when it was
> > realized that the snort defragger was actually never getting touched
> > at all in some installations.
>
> IP fragmentation is rare to begin with [5], so i wouldn't chalk this
> up to firewall magic - especially when all major firewalls still pass
> fragments in their default configuration, and ONLY OpenBSD pf and
> Linux netfilter can actually be configured to reassemble. even fewer
> track TCP windows, options, etc...
IP Fragmentation is rare across the WAN, maybe, but anyone who's used
NFSv2 knows how common it is on the LAN.
There are good reasons NOT to do reassembly and I imagine those that
do not do so because they understand this better than the desire to
simply add yet another feature which some consider "cool".
Mind you, if you don't configure OpenBSD pf to reassemble packets then
you cannot make pf drop them, either.
Darren
(8311044) /Darren Reed <avalon@coombs.anu.edu.au>/(Ombruten)
8309790 2002-04-18 10:37 -0400 /104 rader/ Martin Roesch <roesch@sourcefire.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-18 21:32 av Brevbäraren
Extern mottagare: Vern Paxson <vern@icir.org>
Extern mottagare: Dragos Ruiu <dr@kyx.net>
Extern kopiemottagare: 0xcafebabe@hushmail.com
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: pen-test@securityfocus.com
Extern kopiemottagare: 'snort-devel@lists.sourceforge.net' <snort-devel@lists.sourceforge.net>
Extern kopiemottagare: natasha@snort.org
Mottagare: Bugtraq (import) <21923>
Kommentar till text 8310885 av Vern Paxson <vern@icir.org>
Sänt: 2002-04-19 02:11
Ärende: Re: Snort exploits
------------------------------------------------------------
From: Martin Roesch <roesch@sourcefire.com>
To: Vern Paxson <vern@icir.org>, Dragos Ruiu <dr@kyx.net>
Cc: <0xcafebabe@hushmail.com>, <bugtraq@securityfocus.com>,
<pen-test@securityfocus.com>,
"'snort-devel@lists.sourceforge.net'" <snort-devel@lists.sourceforge.net>,
<natasha@snort.org>
Message-ID: <B8E45269.6795%roesch@sourcefire.com>
On 4/17/02 9:49 PM, "Vern Paxson" <vern@icir.org> wrote:
>> The TCP evasions are fairly easily detectable as overlaps should not
>> normally occur.
>
> See the Bro paper - Bro has detected this possible evasion for many years
> now, and in fact we do see overlaps operationally, and unfortunately they're
> just about always innocuous (busted TCPs, not attacks), so alerting on them
> has a high false positive ratio.
Snort is capable of detecting a variety of TCP foolishness as well,
it's just turned off by default because people complain about the
"noise". To enable Snort's TCP stream protocol violation alerts,
configure the stream4 preprocessor the following way:
preprocessor stream4: detect_scans, detect_state_problems
>> Similarly the IP fragmentation detection just needs slightly more rigorous
>> overlap detection and alerting, as these overlaps will not be occurring
>> in normal situations.
>
> Also discussed in the Bro paper - we do see these in practice, both innocuous
> and as evasion attempts.
Snort has overlap detection and mitigation built into its frag2
preprocessor, I fixed it when Dug told me it was broken back in
January.
>> For now as a workaround you can just alert on small
>> fragments (resurrect minfrag... heh) which should be indicative of games
>> being played.
>
> (same - you see tiny fragments for innocuous reasons, sigh)
From misc.rules:
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"MISC Tiny
Fragments"; fragbits:M; dsize: < 25; classtype:bad-unknown; sid:522;
rev:1;)
This has existed for a while and is the reason that we dumped the
minfrag preprocessor (as a historical note). Tiny frags do happen,
but I've rarely see them outside of live attacks. Then again, I
don't hang on .edu networks very much... ;)
>> Basically all the chaffing at the IP and TCP level is detectable as those
>> should not be normal conditions.
>
> Per the above, this is unfortunately not true, if you're watching a large
> traffic stream. For small traffic streams (e.g., a hundred local hosts),
> yes, my experience has been that these don't normally occur.
Snort has both TCP and IP forward overlap detection and mitigation in
its stream and defrag preprocessors, something might not be working
right currently (we've been doing lots of dev work lately, it's not
inconceivable that something may have been broken). When Dug sent me
the message about the problems back in January I took the time to fix
the overlap conditions and we worked out minimum TTL drops as well.
The chaffing conditions should be defeated since then, we're doing
some testing over here to see what's going on and seeing if the
readme.snort with fragroute needs some updating.
So, for the record:
1. older TCP retransmission chaff - FIXED in January
2. forward TCP segmentation overlap, favoring newer data - FIXED in
January
3. chaff TCP segments with older TCP timestamp options forcing PAWS
elimination - NOT FIXED
4. older IP fragment duplicates - FIXED in January
5. IP duplicate fragment chaff with bad options - NOT FIXED
6. either TCP or IP chaffing with short TTLs - FIXED in January
We currently *do not* have the following:
PAWS detection/bad packet drops
IP frags with bad options drops
I'll see about adding them this weekend.
As a side note, it might be nice if we could test the commercial
systems out there to see how they fare, the damn media is having a
field day with this one.
-Marty
-- Martin Roesch - Founder/CEO, Sourcefire Inc. - (410)290-1616
Sourcefire: Professional Snort Sensor and Management Console
appliances roesch@sourcefire.com - http://www.sourcefire.com Snort:
Open Source Network IDS - http://www.snort.org
(8309790) /Martin Roesch <roesch@sourcefire.com>/(Ombruten)
Kommentar i text 8311045 av der Mouse <mouse@Rodents.Montreal.QC.CA>
8311045 2002-04-18 14:14 -0400 /19 rader/ der Mouse <mouse@Rodents.Montreal.QC.CA>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-19 04:23 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <21946>
Kommentar till text 8309790 av Martin Roesch <roesch@sourcefire.com>
Ärende: Re: Snort exploits
------------------------------------------------------------
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
To: bugtraq@securityfocus.com
Message-ID: <200204181814.OAA27643@Sparkle.Rodents.Montreal.QC.CA>
> Tiny frags do happen, but I've rarely see them outside of live
> attacks. Then again, I don't hang on .edu networks very much... ;)
I was, until very recently (<24hrs ago), behind a link with MTU 1400.
I regularly saw tiny fragments; they happened whenever anyone who
wasn't trying to do PMTU-D tried to talk to me.
Just for what it may be worth.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
(8311045) /der Mouse <mouse@Rodents.Montreal.QC.CA>/
8310852 2002-04-18 15:10 +0700 /45 rader/ Fyodor <fygrave@tigerteam.net>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-19 01:52 av Brevbäraren
Extern mottagare: 0xcafebabe@hushmail.com
Extern kopiemottagare: Dragos Ruiu <dr@kyx.net>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: pen-test@securityfocus.com
Extern kopiemottagare: snort-devel@lists.sourceforge.net
Mottagare: Bugtraq (import) <21931>
Ärende: Re: [Snort-devel] Re: Re: Snort exploits
------------------------------------------------------------
From: Fyodor <fygrave@tigerteam.net>
To: 0xcafebabe@hushmail.com
Cc: Dragos Ruiu <dr@kyx.net>, bugtraq@securityfocus.com,
pen-test@securityfocus.com, snort-devel@lists.sourceforge.net
Message-ID: <20020418151018.E897@tigerteam.net>
0xcafebabe@hushmail.com <0xcafebabe@hushmail.com> spoke:
>
> On Wed, 17 Apr 2002 04:07:31 +0000, Dragos Ruiu <dr@kyx.net> wrote:
>
> >Basically all the chaffing at the IP and TCP level is detectable as those
> >should not be normal conditions. Look to snort cvs over the next few days
> >for solutions to these issues...
>
> That's good to know. But why has it taken 3 months to fix? I wonder what I've been missing during those 3 months. :(
You still are missing the stuff. A Network based IDS concept is by
design not capable of capturing %100 of all potential threats. The
place of NIDS should be made clear in your network security defence
scheme: it will alert you in most of the cases if kiddies poke around
your network, but may not even notice someone who is seriously trying
to get in unnoticed. At the end of the day the burglar alarms keep
away only amateurs.
There are heaps of things which a dedicated intruder could play
with: application specific bugs, encrypted channels (ssl, ssh, vpn,
..), various tcp/ip stack specific issues (tcp stack overlaps which
are handled differently by each TCP/IP stack, frags, transmission
timeouts, corrupted datagrams, ttl games), you never know how broken
a TCP/IP stack or an application is. Even a perfect NIDS would not be
able to handle all these things real time according to each of the
protected systems specifics. If you were not aware of that, it's time
to stop whinning and do some research before complaining. Traffic
normalizers, ssl accelerators and other kind of similar stuff is what
you may be looking into for help. After all, an IDS would just tell
you that they 0wn you, but they still 0wn you, if they can!
Hope it makes things a bit more clear.
-FY
--
http://www.notlsd.net
PGP fingerprint = 56DD 1511 DDDA 56D7 99C7 B288 5CE5 A713 0969 A4D1
(8310852) /Fyodor <fygrave@tigerteam.net>/(Ombruten)
8310885 2002-04-17 18:49 -0700 /45 rader/ Vern Paxson <vern@icir.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-19 02:11 av Brevbäraren
Extern mottagare: Dragos Ruiu <dr@kyx.net>
Extern kopiemottagare: 0xcafebabe@hushmail.com
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: pen-test@securityfocus.com
Extern kopiemottagare: snort-devel@snort.org
Extern kopiemottagare: roesch@sourcefire.com
Extern kopiemottagare: natasha@snort.org
Mottagare: Bugtraq (import) <21932>
Ärende: Re: Snort exploits
------------------------------------------------------------
From: Vern Paxson <vern@icir.org>
To: Dragos Ruiu <dr@kyx.net>
Cc: 0xcafebabe@hushmail.com, bugtraq@securityfocus.com,
pen-test@securityfocus.com, snort-devel@snort.org,
roesch@sourcefire.com, natasha@snort.org
Message-ID: <200204180149.g3I1nfO30770@yak.icir.org>
> First of all I would like to commend Dug on his responsible disclosure
> stance. He has given the IDS vendors several months heads up that this
> stuff is in the pipe...
(Months? My copy of fragrouter, which I got off the net, is more than
two years old.)
> The TCP evasions are fairly easily detectable as overlaps should not
> normally occur.
See the Bro paper - Bro has detected this possible evasion for many
years now, and in fact we do see overlaps operationally, and
unfortunately they're just about always innocuous (busted TCPs, not
attacks), so alerting on them has a high false positive ratio.
> Similarly the IP fragmentation detection just needs slightly more rigorous
> overlap detection and alerting, as these overlaps will not be occurring
> in normal situations.
Also discussed in the Bro paper - we do see these in practice, both
innocuous and as evasion attempts.
> For now as a workaround you can just alert on small
> fragments (resurrect minfrag... heh) which should be indicative of games
> being played.
(same - you see tiny fragments for innocuous reasons, sigh)
> Basically all the chaffing at the IP and TCP level is detectable as those
> should not be normal conditions.
Per the above, this is unfortunately not true, if you're watching a
large traffic stream. For small traffic streams (e.g., a hundred
local hosts), yes, my experience has been that these don't normally
occur.
Vern
(8310885) /Vern Paxson <vern@icir.org>/---(Ombruten)
Kommentar i text 8309790 av Martin Roesch <roesch@sourcefire.com>
8310921 2002-04-17 23:11 +0000 /45 rader/ Dragos Ruiu <dr@dursec.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-19 02:29 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern mottagare: snort-users@lists.sourceforge.net
Extern mottagare: pen-test@securityfocus.com
Extern kopiemottagare: dugsong@monkey.org
Extern kopiemottagare: roesch@sourcefire.com
Extern kopiemottagare: 0xcafebabe@hushmail.com
Mottagare: Bugtraq (import) <21934>
Ärende: fragroute vs. snort: the tempest in a teacup
------------------------------------------------------------
From: Dragos Ruiu <dr@dursec.com>
To: bugtraq@securityfocus.com, snort-users@lists.sourceforge.net,
pen-test@securityfocus.com
Cc: dugsong@monkey.org, roesch@sourcefire.com,
0xcafebabe@hushmail.com
Message-ID: <20020417231154.18b08cf0.dr@dursec.com>
Just a quick follow-up to the fragroute alarmism (which I see has
prompted Mr. James Middleton at vnunet to write a news story
"Evasion tool put's Snort's nose out of joint" :-). First, this
is not a snort-only issue, as I would wager other idses have as
many if not more evasion modes as well as sharing these with Snort...
But upon further analysis, this issue is a bit of a tempest in a
teacup, as a vast majority of these attack obfuscations, particularly
the IP fragmentation ones are not a real threat in practice, because
they are not actually useable in real networks except on vulnerable
bastion hosts. Most firewalls these days (especially Linux and
OpenBSD ones) actually do reassembly inbound. This was an
interesting point discovered recently when it was realized that the
snort defragger was actually never getting touched at all in some
installations. So in reality these fragroute obfuscations are
actually obfuscating things from the firewall rather than from
internal snort sensors. Which is just fine, as snort will see the
same traffic as a system being attacked... and therefore operate
properly.
Theo DeRaadt coined the best answer for fragrouter in this procedure,
a single word: scrub.
So in practice, the fragment level obfuscations are usually
hidden/scrubbed from internal snort sensors by the firewalls... but
that's ok because they are also hidden from most of the target
systems too... ;) and therefore the attack is of not much value or
cause for alarm as it will either be stripped of obfuscation or
broken and not be a concern or significant threat.
cheers,
--dr
--
--dr pgpkey: http://dragos.com/dr-dursec.asc
CanSecWest/core02 - May 1-3 2002 - Vancouver B.C. - http://cansecwest.com
(8310921) /Dragos Ruiu <dr@dursec.com>/---(Ombruten)
Kommentar i text 8309705 av Dug Song <dugsong@monkey.org>
8311062 2002-04-18 18:08 +1000 /40 rader/ Darren Reed <avalon@coombs.anu.edu.au>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-19 04:49 av Brevbäraren
Extern mottagare: Grimes, Roger <RogerG@GoldKeyresorts.com>
Extern kopiemottagare: 'Dave Ahmad' <da@securityfocus.com>
Extern kopiemottagare: 'bugtraq@securityfocus.com' <bugtraq@securityfocus.com>
Mottagare: Bugtraq (import) <21947>
Kommentar till text 8304964 av Grimes, Roger <RogerG@GoldKeyresorts.com>
Ärende: Re: Snort exploits
------------------------------------------------------------
From: Darren Reed <avalon@coombs.anu.edu.au>
To: RogerG@GoldKeyresorts.com (Grimes, Roger)
Cc: da@securityfocus.com ('Dave Ahmad'),
bugtraq@securityfocus.com ('bugtraq@securityfocus.com')
Message-ID: <200204180808.SAA25010@caligula.anu.edu.au>
Given your history in "the industry", what is your impression of the
average lag time between a virus being released into the wild and a
fingerprint update being available from a vendor ? Is it days, weeks
or months ? Also, what's the average interval in updates for anti-
virus software users ?
Lets say I map out all the web servers on the net, next month.
The next day a new vulnerability in IIS is released. Within a
day I should be able to "0wn" a number of web servers I know
to be vulnerable. Unlike a virus, me exploiting them is not
dependant upon them doing anything (ie. reading their email)
except having IIS up and running. Also, it is "always rush hour
somewhere on the 'net".
Another difference is in what it takes for a virus to work. It
has to propogate from system to system and will eventually make
itself known. Once released, it is out of control of the writer
(more or less).
The IDS vs hackers battle is different. A hacker may develop an
exploit and use it successfully through IDSs for some time, maybe
even years. The IDS provides a defence against known scripts and
known exploits but there is no reason to believe that this knowledge
is anywhere near the 99% level an anti-virus program will achieve.
If IDS vendors construct good honeypots, there is a chance that they
may pick up otherwise unknown attack signatures. You might even
venture to say that any IDS vendor that doesn't have a number of
sophisticated honeypots for this purpose is on the road to nowhere.
Darren
(8311062) /Darren Reed <avalon@coombs.anu.edu.au>/--
8315218 2002-04-19 08:58 -0700 /57 rader/ Brad Powell <Brad.Powell@Sun.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-19 21:50 av Brevbäraren
Extern mottagare: dugsong@monkey.org
Extern mottagare: avalon@coombs.anu.edu.au
Extern kopiemottagare: dr@dursec.com
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: snort-users@lists.sourceforge.net
Extern kopiemottagare: pen-test@securityfocus.com
Extern kopiemottagare: roesch@sourcefire.com
Extern kopiemottagare: 0xcafebabe@hushmail.com
Externa svar till: Brad.Powell@Sun.COM
Mottagare: Bugtraq (import) <21960>
Ärende: Re: fragroute vs. snort: the tempest in a teacup
------------------------------------------------------------
From: Brad Powell <Brad.Powell@Sun.COM>
To: dugsong@monkey.org, avalon@coombs.anu.edu.au
Cc: dr@dursec.com, bugtraq@securityfocus.com,
snort-users@lists.sourceforge.net, pen-test@securityfocus.com,
roesch@sourcefire.com, 0xcafebabe@hushmail.com
Message-ID: <200204191558.g3JFweh18383@olympics.Eng.Sun.COM>
Darren writes:
>
> Well then IDS software needs to be smarter. IMHO it makes little sense
> for an IDS to be *behind* a firewall as it's going to miss out on lots
> of useful data points. Maybe this means telling your IDS software how
> big your network is so it can make intelligent decisions about how far
> a packet will go based on its TTL.
actually it depends. Behind the firewall and you can set the red
flags to be very sensative. Packets that should -never- be there
send up big red flags, and page people because the FW failed.
In front of the FW give you more info to be sure, but also a lot of
noise that your FW would block anyway.
Depends on if you want to heare the door rattlers (millions of them)
or not.
> IP Fragmentation is rare across the WAN, maybe, but anyone who's used
> NFSv2 knows how common it is on the LAN.
actually with load ballancing gear frags are more and more prevelent
even on the WAN.
>
> There are good reasons NOT to do reassembly and I imagine those that do
> not do so because they understand this better than the desire to simply
> add yet another feature which some consider "cool".
true, except if you can't guarentee that you will see the whole
packet through the SAME interface. We tripped over this a few times
with SunScreen doing stateful inspection (a good thing most of the
time). Anywhere from 1/2 to more of the traffic was going through a
different router and the Firewall was sitting there holding 1/2 of
the packet in a memory buffer that would never get freed. Eventually
you get enough of these that the network slows down or the FW runs
out of memory.
HPux was nortorius for opening a buffer for frags, and never freeing
the buffer. The easy way to bring HP's to their knees :-)
Brad Powell : HOME: brad@fish.com WORK: brad.powell@Sun.COM
-------------------------------------------------------------------------
The views expressed are those of the author and may not reflect the views
of Sun Microsystems Inc.
(8315218) /Brad Powell <Brad.Powell@Sun.COM>/(Ombruten)
8315733 2002-04-19 16:01 -0400 /30 rader/ Steven M. Bellovin <smb@research.att.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-20 00:48 av Brevbäraren
Extern mottagare: Darren Reed <avalon@coombs.anu.edu.au>
Extern kopiemottagare: Dug Song <dugsong@monkey.org>
Extern kopiemottagare: Dragos Ruiu <dr@dursec.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: snort-users@lists.sourceforge.net
Extern kopiemottagare: pen-test@securityfocus.com
Extern kopiemottagare: roesch@sourcefire.com
Extern kopiemottagare: 0xcafebabe@hushmail.com
Mottagare: Bugtraq (import) <21971>
Ärende: Re: fragroute vs. snort: the tempest in a teacup
------------------------------------------------------------
From: "Steven M. Bellovin" <smb@research.att.com>
To: Darren Reed <avalon@coombs.anu.edu.au>
Cc: dugsong@monkey.org (Dug Song), dr@dursec.com (Dragos Ruiu),
bugtraq@securityfocus.com, snort-users@lists.sourceforge.net,
pen-test@securityfocus.com, roesch@sourcefire.com,
0xcafebabe@hushmail.com
Message-ID: <20020419200122.F21737B4B@berkshire.research.att.com>
In message <200204182210.IAA10429@caligula.anu.edu.au>, Darren Reed writes:
> IMHO it makes little sense
>for an IDS to be *behind* a firewall as it's going to miss out on lots
>of useful data points.
The question to answer is what the purpose is of your IDS. If you're
a researcher on intrusion techniques, you should indeed have your
IDS on the outside. If you're a good citizen and have lots of free
time, by all means have one, so you can tell all the rooted sites
that are probing you that they're owned. But if you want to find
out if you're under attack, don't bother -- you are under attack,
more or less continuously.
An IDS on the inside will have many fewer false alarms, and will tell
you what you really want to know -- that someone has gotten through
your (other) defenses.
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at
http://www.wilyhacker.com
(8315733) /Steven M. Bellovin <smb@research.att.com>/(Ombruten)
8318645 2002-04-19 07:33 -0500 /57 rader/ Ron DuFresne <dufresne@winternet.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-20 22:12 av Brevbäraren
Extern mottagare: Darren Reed <avalon@coombs.anu.edu.au>
Extern kopiemottagare: Dug Song <dugsong@monkey.org>
Extern kopiemottagare: Dragos Ruiu <dr@dursec.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: snort-users@lists.sourceforge.net
Extern kopiemottagare: pen-test@securityfocus.com
Extern kopiemottagare: roesch@sourcefire.com
Extern kopiemottagare: 0xcafebabe@hushmail.com
Mottagare: Bugtraq (import) <21983>
Kommentar till text 8311044 av Darren Reed <avalon@coombs.anu.edu.au>
Ärende: Re: fragroute vs. snort: the tempest in a teacup
------------------------------------------------------------
From: Ron DuFresne <dufresne@winternet.com>
To: Darren Reed <avalon@coombs.anu.edu.au>
Cc: Dug Song <dugsong@monkey.org>, Dragos Ruiu <dr@dursec.com>,
<bugtraq@securityfocus.com>, <snort-users@lists.sourceforge.net>,
<pen-test@securityfocus.com>, <roesch@sourcefire.com>,
<0xcafebabe@hushmail.com>
Message-ID: <Pine.GSO.4.43.0204190728160.5124-100000@tundra.winternet.com>
On Fri, 19 Apr 2002, Darren Reed wrote:
> In some mail from Dug Song, sie said:
> >
> > > Most firewalls these days (especially Linux and OpenBSD ones)
> > > actually do reassembly inbound.
> >
> > this isn't quite true. most stateful inspection firewalls do "virtual
> > reassembly" for IP fragments, and a few do basic window tracking for
> > TCP connections, but will still allow most fragroute-style attacks
> > through (e.g. duplicate overwriting TCP segments with older TCP
> > timestamp options for PAWS elimination, short TTLs, etc.).
>
> Well then IDS software needs to be smarter. IMHO it makes little sense
> for an IDS to be *behind* a firewall as it's going to miss out on lots
> of useful data points. Maybe this means telling your IDS software how
> big your network is so it can make intelligent decisions about how far
> a packet will go based on its TTL.
>
But, was not this what IDS' were originally designed for; behind the
firewall placement to detect what the firewall policies might not be
catching? And as thus a warning/alert being sounded for action?
I see the additional placement of looking inwards as having merit.
to detect machines that are trojaned and or viri infected and trying
to scan other networks or phone home.
Being that the IDS' in present use are lke a abti-viri product and
requiring lots of special care and feeding, and thus very reactionary
to signatures and the known common attack vectors, I see they are
only useful at present as policy verifiers, behind the firewal as a
last catchall. Especially in light of comments by others about the
'scrubbing' charateristics of some firewalls.
Thanks,
Ron DuFresne
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***
OK, so you're a Ph.D. Just don't touch anything.
(8318645) /Ron DuFresne <dufresne@winternet.com>/(Ombruten)
8318659 2002-04-19 10:20 +0800 /55 rader/ <jan@nil.si>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-20 22:17 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <21984>
Ärende: Re: fragroute vs. snort: the tempest in a teacup
------------------------------------------------------------
From: jan@nil.si
To: bugtraq@securityfocus.com
Message-ID: <OF0A2ED078.7C229840-ON48256BA0.0005E758@nil.si>
>bastion hosts. Most firewalls these days (especially Linux and OpenBSD
>ones) actually do reassembly inbound. This was an interesting point
...
>So in practice, the fragment level obfuscations are usually
hidden/scrubbed
>from internal snort sensors by the firewalls..
This is NOT true. At least the Cisco PIX and (correct me if I am
wrong) Checkpoint FW-1, which together represent MOST firewalls out
there, do not perform true reassembly. The PIX, for example, collects
all the fragments, checks them for some basic overlaps (like TCP
header overwrite) and then pass them on as they were originally
fragmented. According to Lance's paper, if Checkpoint has not
modified their code in FW-1 NG, roughly the same thing will happen
Also, you focus on an IDS as always being behind the firewall, which
is often not the case. Perhaps there are no firewalls around at all.
Here are some references on FW-1:
http://www.enteract.com/~lspitz/fwtable.html
http://www.phoneboy.com/faq/0420.html
The real issue has always been about HOW does the IDS try to
reassemble frags, when it has no idea how the target would reassemble
them. In every possible way? For me, it is often enough for an IDS to
alarm about suspicious fragmentation events, which can be
investigated by a human if enough forensics are available.
But from this point, let's not go into the debate whether folks who
use PIX or FW-1 also commonly use Snort ;)
Regards,
Jan
Jan Bervar
Specialist za podatkovne komunikacije, CCIE #2527
Consulting Engineer
NIL Data Communications, Einspielerjeva 6, 1000 Ljubljana, Slovenia
Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
(8318659) / <jan@nil.si>/-----------------(Ombruten)
8340879 2002-04-24 15:41 -0400 /137 rader/ Chris Green <cmg@sourcefire.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-04-25 06:55 av Brevbäraren
Extern mottagare: 0xcafebabe@hushmail.com
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: pen-test@securityfocus.com
Extern kopiemottagare: snort-users@lists.sourceforge.net
Mottagare: Bugtraq (import) <22047>
Kommentar till text 8299163 av <0xcafebabe@hushmail.com>
Ärende: Re: Snort exploits
------------------------------------------------------------
From: Chris Green <cmg@sourcefire.com>
To: 0xcafebabe@hushmail.com
Cc: bugtraq@securityfocus.com, pen-test@securityfocus.com,
snort-users@lists.sourceforge.net
Message-ID: <m2adrskhpm.fsf@mail.sourcefire.com>
I've just made Snort 1.8.7beta1 available at
http://www.snort.org/dl/beta/snort-1.8.7beta1.tar.gz.
This should correct the issues that fragroute induces.
I want to thank Andrea Barisani, Joe McAlerney, and Peter Johnson for
feedback on on the commits I've done over the past few days. I'm also
glad Dug Song wrote fragroute as I'd been talking to Andrea about the
fragmentation attacks I'd like to see in ftester
One of the problems snort was having is with getting fragments out of
order on the network and then sending them through the detection
engine. We still do that but also alert on overlapping fragments.
TTL Limits have been added to both frag2 and pointed out in stream4 to
be used in conjunction with min_ttl options.
Here my post to the snort user lists from Monday:
I just committed a lot of changes today to snort's HEAD branch in CVS
to deal with the test cases iterated in fragroute.
To get the full benefit of these changes:
preprocessor frag2: detect_state_problems
processessor stream4: detect_state_problems
If you find a new set of options that evade snort, drop me a line and
I'll work to fix and/or detect them and give you full credit.
The bugtraq post was the first I'd seen the README.snort so let me
just say that I spent a lot of Thursday superlate-> Today thinking
about the problems while trying to get work done.
Anyway, fragroute is a neat tool and does a lot of the stuff that has
been on the todo list to check. Ahh only hours in the day.
>
> 1. older TCP retransmission chaff (snort's TCP segment reassembly
> seems to always favor newer data, even for properlby sequenced
> received data):
>
> tcp_seg 1
> tcp_chaff rexmit
> order random
Should be fixed and if we see retransmissions of older data that
differs from what we already have, we generate an alert and throw away
the packet
>
> 2. forward TCP segmentation overlap, favoring newer data (both Windows
> and Unix operate this way, in contrast to Ptacek and Newsham's
> results):
>
> tcp_seg 1 new
Fixed and generates alerts on packets that are part of a stream that
has already been reassembled.
> 3. chaff TCP segments with older TCP timestamp options forcing PAWS
> elimination:
>
> tcp_seg 1
> tcp_chaff paws
> order random
This should be relooked at but after making the first two changes,
this one was picked up very loudly.
>
> 4. older IP fragment duplicates (snort's IP fragment reassembly seems
> to always favor newer data, even for properly sequenced received
> data):
>
> ip_frag 8
> ip_chaff dup
> order random
>
Alert on frags with option data and suck them all away.
Philosophical question: Should we ignore frags we didn't see the
first fragment of?
[ Answered later: We cope with out of order fragments but will alert
on a fragment we've recieved multiple times ]
>
> 5. IP duplicate fragment chaff with bad options:
>
> ip_frag 8
> ip_chaff opt
> order random
>
We alert on ip fragments with ip options.
>
> 6. either TCP or IP chaffing with short TTLs (that expire before
> reaching the end host, but pass by the monitor):
>
> ip_frag 8
> ip_ttl 11
> ip_chaff 10
> order random
>
> tcp_seg 1
> ip_ttl 11
> tcp_chaff 10
> order random
>
TCP stream stuff already had the min_ttl option to detect this attack
so that it will throw away anything underneath that.
I added this option to frag2
Also, there is a ttl_limit option to both. Basically, this will alert
on anything that is different by more than a certain limit
The default is 5 picked off the cuff. Know of any papers that measure
the avg and std deviation of TTLs on normal internet traffic across a
large sample and I'll be your buddy.
--
Chris Green <cmg@sourcefire.com>
"Yeah, but you're taking the universe out of context."
(8340879) /Chris Green <cmg@sourcefire.com>/--------