Archive: http://msgs.securepoint.com/ids FAQ IDS: http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm FAQ NIDS: http://www.ticm.com/kb/faq/idsfaq.html IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html HELP: Having problems... email questions to ids-ownerat_private NOTE: Remove this section from reply msgs otherwise the msg will bounce. SPAM: DO NOT send unsolicted mail to this list. UNSUBSCRIBE: email "unsubscribe ids" to majordomoat_private ----------------------------------------------------------------------------- Eric, I'm with you on the inability for large companies to act quickly with their technology, but uber fast on the marketing and spin... but the following passage form your email seems to miss its mark with me: "There is no simple pattern matching facility that will work for UTF-8 encoding, unlike %u encoding." My question is, and forgive me if i'm being over simplistic here, but if "there is no simple pattern matching facility", then how exactly does it get decoded at the destination. It seems to me that if IIS can do it on the fly, that somewhere in the packet toss algorithms of IDS such a thing could be flagged or ruled out. Now obviously the location at which this check either gets performed, or does not, needs to be well qualified. -blue0ne On Wed, 3 Oct 2001, Eric Hacker wrote: > > -----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/AwUBO7vHp1npCOWDRQZ1EQKECwCfSq1vQ9z5XwDCyxk6UpiiY4ePVbcAn3vN > fvsOkTaHgBT+kPIHK423i9vE > =O+eO > -----END PGP SIGNATURE----- > -- -blue0ne http://www.digitz.org "The great bulk of my wealthy and educated friends regard me as a dangerous crank." - Theodore Roosevelt
This archive was generated by hypermail 2b30 : Fri Oct 05 2001 - 06:04:07 PDT