Jan 242012
 

There has been wide coverage of the naming and shaming of the supposedly perpetrators behind the Koobface botnet that has affected Facebook and other social sites for a few years.

The gang leader was first named on Dancho Danchev’s blog, then the Facebook’s security team threaten and did reveal the gang’s real identity, the New York times even ran an article on it and finally Sophos published another in-depth look at how they also discovered their identity. In between, many other sites jumped in to share that information.

I am slightly uncomfortable with this approach.

It appeared to have worked in this instance as the bonnet Command & Centre has been turned off, and it also appears they named the right persons; but what if all those blogs/researchers made a mistake!? It would have been nothing more than a smear campaign that could have affected the lives of some innocent internet users.

This tactic is used by the police in some countries, so they can catch “real” criminals on the run. They name and shame, appealing for help from the public and thus making it more difficult for them to cary on with their illegal activities.
By “real” I mean criminals in the traditional sense of the term, who have broken the law physically as opposed to virtually. But as our lives become more and more entangled with the virtual world, criminal activities “there” can and do have an impact “here”.

Where I think there is a difference, is that the police conducts a thorough investigation before naming and shaming, more importantly they follow an established, documented and legally sound process to conduct such investigation. Although those security researchers are experts in their own right (pun intended), it is a dangerous game to become a vigilante…

To conclude, I am not fundamentally against this practise but I am concern it could spiral out of control. It also highlights how difficult it is to bring hackers to stop their activities as, this, is some kind of last resort solution.

Jan 032012
 

By websites, I should really have said Web Applications, but the end result is the same: A server which is serving pages on the Internet could see its CPU usage increasing to a level making that server unusable for a few minutes or more. All that from a relatively small specially crafted malicious HTTP request.

This vulnerability exists in most languages used to develop web applications: PHP, ASP.Net, Java, Python, Ruby, etc. And it has been known to exist in theory since 2003!

Last week, Alexander Klink and Julian Wälde explained at the 28th Chaos Communication Congress in Germany how exactly the theory became reality and the impact on the different web application languages were affected.

The core of the issue is the way hash lists have been implemented in those languages. By “Hash” they both refer to a specific type of data structure and the cryptographic function. A Hash list is a type of data structure that is very popular because it stores and accesses data in a list very quickly. Before an object is inserted into a hash list, it is first hashed using a hash function to provide a “unique” hash reference which is then used to access and store the object in the list. To simplify, it replaces the usual [i] of a standard list with a [hash reference]. (“i” being an integer).

In reality those hash references are not so unique and collisions do occur. When it happens the objects with the same hash reference are daisy chained. The longer the chain and the least efficient hash lists become. Under normal operation it does not happen often and this is not a problem.

But as first highlighted by Scott Crosby and Dan Wallach in 2003, data/object stored into hash lists can be manipulated so collisions do happen more often. So much more in fact, it can degenerate the hash list resulting into the server’s CPU going overdrive and bringing the server to its knee in the process.

Alexander and Julian explained at 28c3, as shown in this video, that for Perl the issue was located in how the DJBX33A (PHP5) and DJBX33X (PHP4) functions were generating hashes. Other languages were also vulnerable because they were using very similar functions to generate their hashes.

With the help of CERT they communicated an advanced advisory to the relevant vendors and organisations in early November 2011, after they successfully implemented an attack for most of the languages used by Web Applications. They received different responses, some more satisfactory than others…

Ruby reacted very quickly and has a patch ready, Microsoft has issued a temporary work around for ASP.Net by limiting the number of parameters, PHP and Python needs more time and Oracle, although they have provided a patch for Tomcat and will in a near future do the same for Glassfish, stated that it isn’t an issue for Java. If you watch the 28c3 video you can easily understand they are wrong (clue for Oracle, go to the 32d minute or so). Therefore we should expect a Java patch for the HashTable and HashMap functions soon, albeit too late.

To conclude, this is a serious issue that has now a practical and known way to exploit it, with a global scope and high performance impact. Microsoft in a Technet article has provided a snort signature to detect this type of attack against ASP.Net, it should be fairly easy to adapt for other languages.

The recommendation is to both monitor for a patch related to your web applications (and implement it quickly when available) and to also monitor your network for such attacks (and try to block its source IP if not coming from a distributed attack). You should be reviewing what are the versions of the languages used by your Internet facing web applications and probably also ask your 3rd party partners what they plan to do about it!

A nice summary is also available on Arstechnica.

PS: Thanks to Thierry for pointing the story to me in the first place!