[iwar] [fc:On.IDS.Evasion,.Vulnerabilities,.and.Vendor.Hype]

From: Fred Cohen (fc@all.net)
Date: 2001-10-04 20:25:20
Next message: Fred Cohen: "[iwar] [fc:Biochem.terror:.a.reality.check]"
Previous message: Fred Cohen: "[iwar] [fc:bin.Laden's.bank.accounts.hacked]"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Message-Id: <200110050325.UAA02898@big.all.net>
To: iwar@onelist.com (Information Warfare Mailing List)
Organization: I'm not allowed to say
From: Fred Cohen <fc@all.net>
Mailing-List: list iwar@yahoogroups.com; contact iwar-owner@yahoogroups.com
Precedence: bulk
Date: Thu, 4 Oct 2001 20:25:20 -0700 (PDT)
Reply-To: iwar@yahoogroups.com
Subject: [iwar] [fc:On.IDS.Evasion,.Vulnerabilities,.and.Vendor.Hype]
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit

On IDS Evasion, Vulnerabilities, and Vendor Hype

Recently a disturbing event played out in the IDS world.  A security
company released an advisory regarding the ability to bypass IDS
signatures.  This is disturbing because it conveys the impression that
otherwise, it was not possible to bypass IDS systems.  This is not true. 
IDS, especially Network IDS, is not mathematics.  It is more like
psychology; it is far from perfect. 

Historically, when NIDS evasion tactics have been uncovered, they have
been written about in papers and discussed in forums.  Everyone knows
that NIDS is an immature and evolving technology and that no vendor can
provide complete security.  Well, everyone _should_ know. 

A dependency on signatures will only go so far in detecting attacks. 
Protocol analysis goes one step further, but still will not provide
perfect detection for all types of attacks in all types of environments. 
Anomaly detection has its uses and issues.  Depending on the IDS vendor,
there are many ways to sneak some known attacks by signatures that are
supposed to detect those attacks.  To release all such methodologies as
advisories at this stage of maturity in the technology is pointless,
unless one is seeking publicity. 

IDS vendors sometimes must completely rewrite parts of their engines to
detect evasion methodologies.  How long was it before some vendors got
fragmentation reassembly? Vendors simply are not ready to offer perfect
detection, or even pretend to. 

Vendor Hype

Eeye cast the first stone with their advisory %u encoding IDS bypass
vulnerability (<a
href="http://www.securityfocus.com/advisories/3552">http://www.securityfocus.com/advisories/3552>). 
Certainly the issue that Eeye discovered is an important one and needed
to be made public.  The practice of marketing an organization’s name
through advisories is what is not necessary. 

Cisco (<a
href="http://www.securityfocus.com/advisories/3546">http://www.securityfocus.com/advisories/3546>)
and ISS (<a
href="http://www.securityfocus.com/advisories/3551">http://www.securityfocus.com/advisories/3551>)
followed with advisories of their own.  Cisco played it straight, and
merely announced that their own software was vulnerable.  The ISS
X-Force jumped in on the hype, announcing that many vendors could be
affected by this vulnerability and announcing a patch that protects
against it.  ISS even compared this new vulnerability to the IIS Unicode
Directory Traversal (IUDT) vulnerability from October of 2000 (<a
href="http://www.securityfocus.com/bid/1806">http://www.securityfocus.com/bid/1806>). 
The latter is different, however. 

The IUDT vulnerability actually uses UTF-8 encoding rather than the
nonstandard %u Unicode encoding found in the new vulnerability.  What is
the difference? Well UTF-8 is a _standard_ method of encoding Unicode,
albeit one that has been applied in non-standard ways by Microsoft.  %u
encoding was something completely invented by Microsoft.  One would
expect that IDS vendors might not know about a non-standard encoding
method developed by a particular vendor. 

UTF-8, being a standard method of encoding published in the open for the
world to use, should be detected or interpreted by IDS vendors. 
Unfortunately ISS RealSecure stands out as one of the IDS vendors that
completely misses UTF-8 encoded attacks.  The IDS industry was notified
by my article on UTF-8 evasion in January 2001 (<a
href="http://www.securityfocus.com/cgi-bin/infocus.pl?head=IDS:IDS%20Evasio">http://www.securityfocus.com/cgi-bin/infocus.pl?head=IDS:IDS%20Evasio>
n&amp;id=1232) but by then many vendors had already begun working on the
issue.  One would think that if ISS was seriously interested in not
being evaded rather than just cashing in on some hype, that there would
be a patch for UTF-8 by now.  Unfortunately the X-Force team has not
even acknowledged my emails to them on this issue. 

Admittedly, the UTF-8 encoding problem is much harder to solve than the
%u encoding.  It is no surprise that some vendors have yet to deal with
it adequately.  (How long did it take certain vendors to deal with
fragmentation?).  However, releasing advisories on similar evasion
techniques only serves to cloud the current state of IDS and make the
technology seem more mature than it is.  Such illusions do not improve
the state of security on the Internet. 

IDS Evasion

Just for the record, using the example from the X-Force advisory:

“The following is a standard HTML GET request without Unicode-escaped
characters:

GET /attack.html HTTP/1.0

The following shows the same request, using a valid, but escaped Unicode
character in place of the letter k:

GET /attac%u006b.html HTTP/1.0

This request uses a non-standard form of Unicode, referred to as "%u
encoding".  This type of encoding can be used to effectively bypass many
IDS signatures for IIS-specific vulnerabilities.”

The following are some, but quite possibly not all, of the variations on
“attack.html” using standard UTF-8 encoding on IIS5:

GET /attac%C1%8B.html HTTP/1.0
GET /attac%C4%B6.html HTTP/1.0
GET /attac%C7%A8.html HTTP/1.0
GET /attac%E2%84%AA.html HTTP/1.0
GET /attac%EF%BC%AB.html HTTP/1.0
GET /attac%C1%AB.html HTTP/1.0
GET /attac%C4%B7.html HTTP/1.0
GET /attac%C7%A9.html HTTP/1.0
GET /attac%EF%BD%8B.html HTTP/1.0

Both upper and lower case letters can be interchanged.

One can use the unescaped raw binary codes as well, where {0x41}
represents the byte for ‘A’:

GET /attac{0xC1}{0x8B}.html HTTP/1.0
GET /attac{0xC4}{0xB6}.html HTTP/1.0
and so on.

There is no simple pattern matching facility that will work for UTF-8
encoding, unlike %u encoding. 

Vulnerabilities

Customers who fall prey to vendor hype and believe that they have bought
security. 

The system of trust that vendors release advisories to promote full
disclosure and not to further their own interests. 

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Pinpoint the right security solution for your company- Learn how to add 128- bit encryption and to authenticate your web site with VeriSign's FREE guide!
http://us.click.yahoo.com/yQix2C/33_CAA/yigFAA/kgFolB/TM
---------------------------------------------------------------------~->

------------------
http://all.net/ 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Next message: Fred Cohen: "[iwar] [fc:Biochem.terror:.a.reality.check]"
Previous message: Fred Cohen: "[iwar] [fc:bin.Laden's.bank.accounts.hacked]"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
This archive was generated by hypermail 2.1.2 : 2001-12-31 20:59:54 PST