Payback on Web Attackers: Web Honeypots (OWASP AppSecUSA Presentation Review)

honeypotPayback on Web Attackers: Web Honeypots

As a web application scanning tool developer and architect at NT OBJECTives, I’m always thinking about how website are evolving and how we can automate more of applications scans. So, how will the evolution of honeypots influence web application scanning?

This talk at AppSecUSA, by Simon Roses Femerling (@simonroses) the Founder & CEO of VULNEX, was as you can imagine about honeypots. Apparently, most are rather immature technologically insofar as they are too focused. Honeypots are widely deployed but are mostly about simply distracting the hacker and forcing the hacker to waste time on the honeypot but most of them actually squander the opportunity to gather and log information on the hacker.

Several specific honeypots were enumerated and most of these run on top of the server.  Desirable features of a honeypot are low CPU impact and the ability to do more than just analyze attack patterns. Some honeypots generate cookies and some are basic authentication while others are CGI or are a simulation of well-known servers.

The latter one is rather what one pictures when presented with the concept of a honeypot.  Though probably that honeypot just simulates server behaviour to the extent of banner grabs and the like, it provokes imagination in me of having some juicy looking authentication link that then grants the attacker access to vast areas of the website topology that are fake (stealth bomber plans, user account id and passwords, configuration screens, who knows what). I do not actually know if anyone is doing anything this elaborate but it is cool to think about. The artistic challenge to composing such a thing is that the further one probes into the false part of the topology, the exponentially more difficult it likely is to keep it from being obvious that it is just bait.

Some effective honeypots to which that does not apply include brute force ad infinitum. It looks like an authentication page to something interesting but it just infinite loops a password bruteforcer. Specific attacks like server fingerprinting, session id collecting, directory indexing, the aforementioned brute force, XSS, and PHP CGI can be faked easily to yield credible but false information.

So, how might the evolution of honeypots impact application scanning tools?

We normally presume that the functionality in a web application is in good faith, but honeypots are there confounding an attacker, thus honeypots could confound an application scanning tool. If honeypots get more sophisticated and more of websites topology is fake, IT security teams wouldn’t want their scanners to scan the fake part of the application. Application scanning tools would need to identify and avoid the honeypots.

This could be achieved through training or heuristics. If the heuristic successfully identifies a honeypot, then that would be a vulnerability of sorts unto itself as it would indicate that the honeypot is easily and automatically detectable as such. If this speaker’s vision of more effective honeypots should be realized, then scanning tools should address this and perhaps even now it may be a good idea.



About M. J. Power 22 Articles
Connect with Mike on Google+

2 Comments on Payback on Web Attackers: Web Honeypots (OWASP AppSecUSA Presentation Review)

Leave a Reply

Your email address will not be published.