Wednesday, April 11, 2012

Web is vulnerable to hashing denial-of-service attack ( #hashdos ) with Demo

Researchers have shown how a flaw that is common to most popular Web programming languages can be used to launch denial-of-service attacks by exploiting hash table as reported by Jon from Ars Technica. Researchers presented information on a long standing vulnerability in most web application frameworks at 28th Chaos Communication Congress security conference in Berlin, Germany, Earth, Milky Way. Alexander “alech” Klink and Julian “zeri” Wälde delivered a demonstration and lecture titled "Efficient Denial of Service Attacks on Web Application Platforms". In their lecture they explained in detail how most web programming languages utilize hashes and manage collisions.

The flaw affects a long list of technologies, including PHP, ASP.NET, Java, Python, Ruby, Apache Tomcat, Apache Geronimo, Jetty, and Glassfish, as well as Google's open source JavaScript engine V8. The vendors and developers behind these technologies are working to close the vulnerability, with Microsoft warning of "imminent public release of exploit code" for what is known as a hash collision attack.

Klink and Wälde showed that "PHP 5, Java, ASP.NET as well as V8 are fully vulnerable to this issue and PHP 4, Python and Ruby are partially vulnerable, depending on version or whether the server running the code is a 32-bit or 64-bit machine."

"This attack is mostly independent of the underlying Web application and just relies on a common fact of how Web application servers typically work," the team wrote, noting that such attacks would force Web application servers to use 99% of CPU for several minutes to hours for a single HTTP request. "Hash tables are a commonly used data structure in most programming languages," they explained. "Web application servers or platforms commonly parse attacker-controlled POST form data into hash tables automatically, so that they can be accessed by application developers. If the language does not provide a randomized hash function or the application server does not recognize attacks using multi-collisions, an attacker can degenerate the hash table by sending lots of colliding keys. The algorithmic complexity of inserting n elements into the table then goes to O(n**2), making it possible to exhaust hours of CPU time using a single HTTP request."

Microsoft has released a workaround for an ASP.NET vulnerability to help protect Websites against potential denial-of-service (DoS) attacks, according to a security advisory.

The vulnerability is considered serious because an attacker could take down a site by consuming all CPU resources on a Web server, or cluster of servers, using a series of specially crafted, 100KB HTTP requests. Just one such request could consume 100 percent of one CPU core for between 90 and 110 seconds.

"An attacker could potentially repeatedly issue such requests, causing performance to degrade significantly enough to cause a denial of service condition for even multi-core servers or cluster of servers," Suha and Jonathan Ness, engineers with Microsoft Security Response Center said. Microsoft was unaware of any DoS attacks exploiting the vulnerability. Nevertheless, Microsoft decided to release a workaround, because detailed information on the flaw is publicly available.

Andrew Storms, director of security operations for nCircle said: "This isn’t your average DoS attack because it doesn’t take a botnet or a lot of coordination to take a web server down. Most DoS attacks rely on a huge number of small requests targeted at a specific web server to overwhelm it. In this case, a single request can consume a single core for 90 seconds. Queue up a few of these requests every few minutes and the site will be essentially knocked offline."

Demonstration
You can download the Video Demo from here and Hash collisions in POST Denial-of-service exploit online demo or Script source code is Here.

Available Countermeasures :
1.) Limiting the number of different HTTP request parameters (PHP, Tomcat) : PHP has added a new configuration variable max_input_vars, that can limit the number of parameters. This is similar to the first solution, except that here, not the total length of the request is limited, instead the number of different parameters that can be submitted in a single request is limited.
2.) Limiting HTTP POST and GET request lengths (Microsoft ASP.NET) : Microsoft suggests to limit the HTTP request length. Most applications don’t require very long HTTP requests, except for file uploads.


    <configuration>

     <system.web>
     <httpRuntime maxRequestLength="200”/>
     </system.web>
    </configuration>

As long as you don’t process data in a hash table from any other sources, except from the HTTP request (like external URLs), this should prevent the basic form of the attack.

Also , oCERT has a good summary about affected and fixed software versions & There is an advisory on full disclosure that describes the attack in det

SOURCE: www.thehackernews.com

No comments:

Post a Comment