Botnet Targets Web Sites With Junk SSL Connections

angry tapir writes "More than 300 Web sites are being pestered by infected computers that are part of the Pushdo botnet. The FBI, Twitter, and PayPal are among the sites being hit, although it doesn't appear the attacks are designed to knock the sites offline. Pushdo appears to have been recently updated to cause computers infected with it to make SSL connections to various Web sites — the bots start to create an SSL connection, disconnect, and then repeat." SecureWorks's Joe Stewart theorizes that this behavior is designed to obscure Pushdo's command and control in a flurry of bogus SSL traffic.

Comments

Re:SSL traffic

[drinkypoo]

Do they realise that SSL traffic causes a higher load on the server than a regular request? This would be an indication it is trying to bring the site down.

Requesting an SSL connection and then never making it takes a lot less load than actually retrieving a page. It doesn't really suggest a takedown attempt, for which there are superior strategies.

Up to something?

[toleshei]

"Site owners "would just see weird connections that don't seem to make sense," he said. "They look like they're trying to start an SSL handshake, but it comes in malformed and doesn't ever send anything after that first handshake attempt."" Is it possible that they've found a flaw in a specific Systems handling of SSL and are trying to see if the flaw exists elsewhere in an attempt to produce an exploit? I'm not really a security guy, but it seems like they're up to something specific. Otherwise why use SSL exclusively? wouldn't they want to diversify their requests?

Re:SSL traffic

[girlintraining]

Do they realise that SSL traffic causes a higher load on the server than a regular request? This would be an indication it is trying to bring the site down.

Yes, they do. They also don't care. Most botnet authors are self-taught, or only college educated, and are not experienced developers. They don't know how to obscure their creation's activity, because they lack a full understanding of network security. Which is understandable: That isn't in the SDK documentation and example code. Because they lack the skillset necessary to create a protocol resistant to traffic analysis, they go the other way: Flood all the connections and hope those analyzing the logs decide it's not worth the effort to find the needle in the haystack. They know it can be tracked -- they just don't feel its worth the effort to learn how to do it right, when doing it wrong gets them to payday faster and with only a minute amount of additional risk.

Re:nginx to the rescue?

[JWSmythe]

    Not really.

    I've had to parse logs for similar things. Thousands of requests hit a particular exploitable web page, but only one or two IP's are sending further information. It's easy to trim it down the list of candidates, and find who the real problem is.

    That's what the feds do in any investigation. They have a broad list of suspects. They eliminate folks until they have their persons of interest, and then down to the guy who they'll be convicting.

Re:How to stop bot nets

[Anonymous Coward]

is that because the antivirus program makes the computer crawl to a halt so the bot program has no CPU resources left to run?

Re:From TFA

[scdeimos]

I tend to agree with you that this sort of thing should still be relatively easy to pickup in logs - on proxies as well as the border routers. A lot of people are probably forgetting that SSL through proxies still needs a CONNECT originserver:443 HTTP/1.x request, which gets logged, even if all of the traffic is encrypted on the tunnel after that.

Entropy depletion

[xenocide2]

SSL/TLS at it's core generates "session keys" for communication; a string of random characters. It's possible they're trying to deplete the SSL servers of true entropy for some undisclosed attack; PRNG, for example.

Re:Entropy depletion

[bobstreo]

Don't think it's that complex. From June 2009:
http://isc.sans.org/diary.html?storyid=6601

Yesterday an interesting HTTP DoS tool has been released. The tool performs a Denial of Service attack on Apache (and some other, see below) servers by exhausting available connections. While there are a lot of DoS tools available today, this one is particularly interesting because it holds the connection open while sending incomplete HTTP requests to the server.

In this case, 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. Of course, this all can be changed so if you plan to create IDS signatures keep that in mind.

According to the web site where the tool was posted, Apache 1.x and 2.x are affected as well as Squid, so the potential impact of this tool could be quite high considering that it doesn't need to send a lot of traffic to exhaust available connections on a server (meaning, even a user on a slower line could possibly attack a fast server). Good news for Microsoft users is that IIS 6.0 or 7.0 are not affected.

At the moment I'm not sure what can be done in Apache's configuration to prevent this attack – increasing MaxClients will just increase requirements for the attacker as well but will not protect the server completely. One of our readers, Tomasz Miklas said that he was able to prevent the attack by using a reverse proxy called Perlbal in front of an Apache server.

We'll keep an eye on this, of course, and will post future diaries or update this one depending on what's happening. It will be interesting to see how/if other web servers as well as load balancers are resistant to this attack.

Re:From TFA

[fm6]

Some of the malware I've encountered lately (I've got one system unusable until I get around to reinstalling the OS) is very sophisticated indeed. I would admire the designers, if I didn't so badly want them dead.

Does anybody else miss script kiddies?