SANS has posted that they’ve heard grumblings on the Internets of a new OpenSSH exploit in the wild. They haven’t gotten their hands on it yet, but they’ve had several reports and a console log of the supposed exploit in action.
More info after the jump. SANS Diary on the Exploit
A new tool exploiting a quite-clever and very tricky to fix issue with ALL versions of Apache Web Server and Squid as well has been published into the wild yesterday. There’s no paper outlining the exact exploit, but there doesn’t really need to be one. As described by Bojan Zdrnja of SANS ISC, the DoS is carried out basically by telling the server to “hold on, I’m sending more header data,” yet never does:
…the server will open the connection and wait for the complete header to be received. However, the client (the DoS tool) will not send it and will instead keep sending bogus header lines which will keep the connection allocated.
The initial part of the HTTP request is completely legitimate:GET / HTTP/1.1\r\n
Host: host\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n
Content-Length: 42\r\n
After sending this the client waits for certain time – notice that it is missing one CRLF to finish the header which is otherwise completely legitimate. The bogus header line the tools sends is currently:X-a: b\r\n
Which obviously doesn’t mean anything to the server so it keeps waiting for the rest of the header to arrive
Essentially the attacker sends a partial legitimate browser UA string, albeit incomplete with intentions to send the rest of the data to complete the string, yet never does. This in turn holds the session open on the server end, quickly maxing the server’s connection table waiting for “clients” to complete the request.
This attack requires a very small amount of bandwidth to bring a server to its knees. There is no known workaround or patch yet, but can be stopped by including the signature for this type of attack in your IDS (if you have one in front of the web server.)
I recall Check Point VPN-1 R65 introducing a DoS protection technique that could possibly reduce the impact of such type of DoS attack. To keep the firewall’s connections table from becoming saturated in the event of a Denial-of-Service attack, a three-way session verification would take place. When a connection request it is initiated, the firewall would send back an acknowledgment to go ahead and start sending traffic (if the specific connection was allowed in the rulebase), but only keep the connection record in memory, not committing it to the actual connections table on the firewall. If no traffic was returned by the requestor, then the connection would be ignored and purged from memory. This kept the connections table clean of any “dummy” connections and thus would not become saturated and cause traffic-flow to come to a grinding halt. Maybe the fix could be to do something on an HTTP session scale with Apache.
