Hi there all... Probably just problem with the way RealSecure is/was (I'm sure this doesn't happen in newer versions) looking for that particular string. I would imagine they are not making decisions based on user-supplied HTTP versions. (Then again, this is begins to tread on the 'ol debate of how protocol decoding should be used in ID. False Positives vs. False Negatives and the inverse relationship between reducing one and increasing the other...) Not the point of this thread or list though, so I'll shut-up there before the holy war freedom fighters get all excited... Could the second two tests not trigger the same event the first two do (but still trigger a event that is not configured to send resets?). Just a thought - I'm not familar with RealSecure... Anyway, verified with Dragon: [g@none ]# nc 10.100.100.111 80 GET /cgi-bin/phf HTTP/0.9 HTTP/1.1 404 Not Found Date: Fri, 15 Feb 2002 20:02:38 GMT Server: Apache/1.3.19 (Unix) (Red-Hat/Linux) mod_ssl/2.8.1 OpenSSL/0.9.6 DAV/1.0.2 PHP/4.0.4pl1 mod_perl/1.24_01 Connection: close Content-Type: text/html; charset=iso-8859-1 and, [g@none ]# nc 10.100.100.111 80 GET /cgi-bin/phf HTTP/12.0 HTTP/1.1 400 Bad Request Date: Fri, 15 Feb 2002 20:21:48 GMT Server: Apache/1.3.19 (Unix) (Red-Hat/Linux) mod_ssl/2.8.1 OpenSSL/0.9.6 DAV/1.0.2 PHP/4.0.4pl1 mod_perl/1.24_01 Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 [g@none ]# /usr/dragon/tools/mklog -e WEB:CGI-PHF -l -f /usr/dragon/DB/2002Feb15/dragon.db 15:33:36 [T] x.x.x.x 10.100.100.111 [WEB:CGI-PHF] (tcp,dp=80,sp=32895) (test1-nids) 15:52:46 [T] x.x.x.x 10.100.100.111 [WEB:CGI-PHF] (tcp,dp=80,sp=32951) (test1-nids) -----Original Message----- From: Alla Bezroutchko To: vuln-devat_private Sent: 2/15/02 12:20 PM Subject: Possible IDS-evasion technique I've accidently found a way to bypass IDS detection for HTTP requests. I've seen this behaviour on some older version of IIS RealSecure network IDS and I wonder if this works on any other IDSes. That particular IDS was set up to reset connections that match attack signatures, so I could see immediately if it was detected or not: Request: GET /cgi-bin/phf HTTP/1.0 Connection reset Request: GET /cgi-bin/phf Connection reset Request: GET /cgi-bin/phf HTTP/12.0 Connection not reset, HTTP server replies "version not supported" Request: GET /cgi-bin/phf HTTP/0.9 Connection not reset, HTTP server replies "file not found" Apparently the last form of request allows to get a meaningful reply from HTTP server while IDS does not mind it. Apache and Netscape Entriprise will happily reply to the last form of request, didn't try it on other web servers. Alla. __________________________________________________ Do You Yahoo!? Got something to say? Say it better with Yahoo! Video Mail http://mail.yahoo.com
This archive was generated by hypermail 2b30 : Fri Feb 15 2002 - 18:29:04 PST