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.
The network security guys at T-Mobile USA probably breached their underpants after some black hat or group of black hats named “Pwnmobile” posted on seclists.org a sizeable list of internal hostnames, OSes, partial descriptions, internal IP addresses, and facilities relating to the back-end of T-Mobile’s customer management and services network.
At first, T-Mobile tried to say it was just a list pulled from a corporate document; but now the company is admitting that it was, in fact a major security breach according to a USA Today Blog and are not disclosing how much data was taken. Odds are, if whoever managed to get this far, a very sizeable amount of data was captured. The person who made the posting mentioned that they had tried to sell the information to competitors, but they were not taken seriously.
On a slightly related note, the posting related the T-Mobile hack with Check Point. Does this mean a perimeter Check Point firewall was either hacked or exploited to gain access to this network? Only further elaboration from Pwnmobile, T-Mobile, or an insider can say. There have been several recently published high-visibility Check Point exploits and perhaps they were used in the hack.
Interesting article about how the US is planning on handling the aging security infrastructure in the US. The issue has become more pressing lately because of high-profile breaches that have garnered peoples’ attention towards how safe not only the government is; but their personal data on government computers as well. More here:
