On IDS Evasion, Vulnerabilities, and Vendor Hype

From: Eric Hacker (hackerat_private)
Date: Thu Oct 04 2001 - 10:04:14 PDT

  • Next message: Lamont Granquist: "RE: OpenUNIX 8 & Unixware possible local root"

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    
    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 (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 (http://www.securityfocus.com/advisories/3546) and ISS
    (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
    (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
    (http://www.securityfocus.com/cgi-bin/infocus.pl?head=IDS:IDS%20Evasio
    n&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.
    
    Peace,
    Eric Hacker, CISSP, GCIA, MCSE, CCSE
    Network Security Consultant
    Email: hackerat_private
    PGP key:
    hackerat_private">http://keyserver.pgp.com/pks/lookup?op=get&search=hackerat_private
    PGP Fingerprint: FADB 793E E98A 97BB 04D6  5973 7864 93A1 222B E0C7
    
    "Long gone are the days when one's surname referred to the role
    one had in the community."
    
    -----BEGIN PGP SIGNATURE-----
    Version: PGP 7.0.1
    
    iQA/AwUBO7yUX1npCOWDRQZ1EQK9MwCg47VENXVJ6txOtxIEUIvZd7YuywMAoK8e
    n9LEEAB6tOAtvjRCxhGVYGWS
    =5+q5
    -----END PGP SIGNATURE-----
    



    This archive was generated by hypermail 2b30 : Thu Oct 04 2001 - 14:52:49 PDT