HTTP POST - Layer 7 DOS - No Websites can escape

Well first of all, congratz to hackers (whitehat maybe) who discovered this fundamental flaw in HTTP implementation. I was wondering why in this world anyone thought about this prior to late 2010 

The Story goes like this...

Wong Onn Chee (Researcher), who discovered this attack in 2009 with a team of researchers in Singapore, says

HTTP is "broken" and leaves all Web-based servers or systems with a Web interface vulnerable to this form of attack.

"We believe that the fix is in the actual protocol as it is broken by design and affects everyone globally and anything using a Web application. This talk is very sensitive and should be highlighted for U.S. critical infrastructure,"

"If it has a Web interface, we can knock it down [with this attack]: think SSL VPN and other critical systems accessed with a Web browser that you need to connect to by posting information."

 

As we all know DOS (denial of service) attacks traditionally works at Layer 4, but Onn chee say that the HTTP Layer 7-type attack is much more difficult to stop because it's tough to distinguish between real HTTP traffic and malicious HTTP traffic

How does this attack work?

The attacker sends POST headers with a legitimate "content-length" field that lets the Web server know how much data is arriving. Once the headers are sent, the POST message body is transmitted at a slow speed to gridlock the connection and use server resources. This attack can DDoS a Web server with just tens of thousands of slow HTTP POST connections and take it down within minutes.

The attack in some ways resembles the Slowloris HTTP DDoS attack tool created by RSnake that keeps connections open by sending partial HTTP requests and sends headers at regular intervals to prevent the sockets from closing. But the slow HTTP POST DDoS can't be mitigated by load-balancers like with Slowloris

For People who wants to know more about this attack: http://www.owasp.org/images/4/43/Layer_7_DDOS.pdf

Potential countermeasures

Apache

• (Experimental) mod_reqtimeout
• LimitRequestBody directive

IIS

• No reply from Microsoft on the availability of the
• Proposed controls in the latest service pack for IIS.

XML INJECTION

XML Injection is an attack technique used to manipulate or compromise the logic of an XML application or service. The injection of unintended XML content and/or structures into an XML message can alter the intend logic of the application. Further, XML injection can cause the insertion of malicious content into the resulting message/document.

An example of XML injection to include insertion of full XML structures:

Consider this example XML document:

<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<uname>sant1</uname>
<pwd>r3g</pwd>
<uid>0<uid/>
<mail>sant1@example1.com</mail>
</user>
<user>
<uname>sant2</uname>
<pwd>an00n</pwd>
<uid>500<uid/>
<mail>sant2@example2.com</mail>
</user>
</users>

If the attacker were to inject the following values for a new user 'Henry':

Username: Henry123
Password: iluvbob
E-mail: Henry123@example3.com</mail></user><user><uname>Hacker</uname><pwd>l33tist</pwd><uid>0</uid><mail>hacker@exmaple_evil.net</mail>

Then the resulting XML document would be:

<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<uname>sant1</uname>
<pwd>r3g</pwd>
<uid>0<uid/>
<mail>sant1@example1.com</mail>
</user>
<user>
<uname>sant2</uname>
<pwd>an00n</pwd>
<uid>500<uid/>
<mail>sant2@example2.com</mail>
</user>
<user>
<uname>henry123</uname>
<pwd>iluvbob</pwd>
<uid>500</uid>
<mail>henry123@exmaple3.com</mail></user><user><uname>Hacker</uname><pwd>l33tist</pwd><uid>0</uid>
<mail>hacker@exmaple_evil.net</mail>
</user>
</users>

In this example a new user (Hacker) will be inserted into the table with user ID 0. In many cases with XML applications, the second user ID instance will override the first. This results in the injected new user 'Hacker' being logged in with userid=0 (which often is used as the administrator uid).

Another type of XML injection is where CDATA elements are used to insert malicious content. One example of this is where XML message payloads that contain a CDATA field can be used to inject illegal characters/content that are ignored by the XML parser.

<HTML>
<![CDATA[<IMG SRC=http://www.exmaple.com/logo.gif onmouseover=javascript:alert('Attack');>]]>
</HTML>

In this example an XML/HTML application can be exposed to an XSS vulnerability. This state is achieved because the CDATA content is unparsed and therefore will be missed by schema validation based input validation filters.