Researchers Infiltrate and 'Pollute' Storm Botnet

ancientribe writes "Dark Reading reports that a group of European researchers has found a way to disrupt the massive Storm botnet by infiltrating it and injecting "polluted" content into it to disrupt communication among the bots and their controlling hosts. Other researchers have historically shied way from this controversial method because they don't "want to mess with other peoples' PCs by injecting commands," said one botnet expert quoted in the article.

Fair Play

[FurtiveGlancer]

I submit that it's inherently fair and perfectly ethical to disrupt those who invade and steal from others. Even if the theft is one of compute cycles. Usually, we call those who disrupt invaders and thieves "heroes."

Who is liable in the event of retaliation?

[Tanman]

Ok, so here's a fun question: Lets say the botnet creators get pissed off and send out a code change that makes one of the standard commands change to be something like, oh, "wipe hard drive." The botnet creators then use different commands, but the researchers come along and issue the old command, thus wiping the users' hard drives.

Are the researchers liable since they technically issued the offending command while logged in as a remote user without the owner's permission?

Re:It's not Really...

[el_flynn]

Unless there's a problem with the command you send out and it completely wipes the end users hard drive and all their personal data or does something else destructive to the infected user.

True, but who's to say the resident malware isn't already doing that? Although I'm sure the bot manufacturer will take quite strong measures to stop this from happening, as it would really result in a non-productive bot. So the anti-bot programmer would just have to take similar steps I suppose.

It would be far better to monitor the botnet, find the computers involved and then help them clean their computer and prevent another infection.

TFA says the researchers "saw between 5,000 and 40,000 machines online at a time."
Who, other than a NATO-type international task force, would have the resources to reach out to those 40k users and help them clean their machines? All you IT admins and helpdesk staff are already cringing at the thought of handling tens or hundreds of users -- can you even begin to imagine trying to explain to thousands of clueless users what's happened to their PC, and what steps to take to clean it?

Re:It's not Really...

[hilather]

You know, wiping out a bot infected computer of any personal information or even all information might actually be doing that person a favour. It is better then having that information falling into the wrong hands. I could go either way on this, its the computer equivalent of vigilantes. But what happens when bot net controllers star to realize identity theft is a pretty lucrative business too?

How active is storm currently?

[damn_registrars]

I've seen previous allegations that Leo Kuvayev [wikipedia.org] has ties to the storm botnet. It of course is known that Mr. Kuvayev is a prolific spammer.

However, there hasn't been as much spam from Mr. Kuvayev - either in my own boxes, or mentioned recently on line. This leaves me to wonder if perhaps he isn't utilizing it as much as he used to?

While certainly the botnet has been used for more than just spam propagation, and Kuvayev has sent spam to a lot more people that just me, I still can't help but wonder if it either isn't as large or as active as it once was.

Re:It's not Really...

[graphicsguy]

Who, other than a NATO-type international task force, would have the resources to reach out to those 40k users and help them clean their machines?

If it's easy to detect the traffic to/from a botnet computer, they should be cut off by their ISP. The ISP can then offer them both instructions and to sell them PC cleaning as a service before allowing them to re-activate their connection.

Re:How active is storm currently?

[ahabswhale]

It's a shadow of its former self. Microsoft actually took them out, believe it or not. The Msft malicious software removal tool has taken care of it and the maintainers of the storm botnet got tired of dealing with it and let it go. See here for more info: http://blogs.technet.com/antimalware/archive/2007/09/20/storm-drain.aspx [technet.com]

So it's great that they came up with this but too bad it's pointless, at least for Storm. However, I'm sure they'll continue patting themselves on the back for fixing something that was already fixed.

Re:It's not Really...

[Moridineas]

Well, if you agree, you probably feel that point is "+1 Insightful" or "+1 Interesting" whatever.

I do agree that the system of moderating on slashdot is HIGHLY overused by those who use them for their opinions. I've been guilty of this at times too, though I try not to.

Maybe we do need a "+1 I agree, good thinking!" and a "-1 I disagree, that's stupid!" that count as a different class of points. Dunno.

Re:Public Key Cryptography and Message Signing.

[querist]

For your first point (1), there are some issues:

The encryption itself will only be partly effective, since the bot needs to have the decryption key available, it would simply be a matter of analysis to locate the key. This would allow researchers to intercept messages headed to the bots.

Messages to the Command and Control will still be protected if public-key crypto is used.

The signatures will not be able to be faked, so your approach is correct in that it would prevent the researchers from injecting commands.

And for point (2):

The bots can use PKI to talk among themselves, but because each bot will have its own keys (and how will they negotiate keys to encrypt?) the process should be at least observable at a much deeper level unless the programmers are very careful to have considered a man-in-the-middle attack and, for example, used signed keys. This would prevent forgery of signatures, but would still allow the researchers to intercept any communications for a bot which the researchers can control. A small percentage, but in a lab this could allow the researchers to decode at least some of the "Secret Handshakes" used, those being the ones for bot to bot communication.

Communication TO the Command and Control, however, would remain inaccessible.

However, public key encryption is notoriously hard on the CPU, requiring many more cycles when compared to a similar (equal protection from brute force attack) symmetric algorithm.

I guess your approach will work partially, but enough to make life difficult for "the good guys".

Re:It's not Really...

[ruin20]

We typically consider distributed loss less harmful than concentrated loss. We call means for turning concentrated loss into distributed loss insurance. You run the same calculation on that and I'm pretty sure you'll find that if favors scrapping insurance rather than keeping it.

Oh and you could say the same with crime and taxes for law enforcement. Or social security.

There's a price paid in human or emotional capital associated with concentrated loss. People usually are willing to pay to prevent that.

Re:It's not Really...

[Ethanol-fueled]

Note that you said unprotected gun. I'll assume that you meant to imply that if you give your gun to some schmo and he uses it for evil then you should be responsible.

What the bad guys are doing(to use your gun analogy) is breaking into your house, finding your firearm and picking its trigger lock, then loading it with their own magazine and ammo and then using it for evil. Would that be your fault? No. Now envision the same scenario except that you left your door open and the perp walked right through it. It still wouldn't be your fault, and you wouldn't be criminally charged as long as you had no idea that the perp was going to use your gun. You may, however, be sued for negligence.

Re:It's not Really...

[khallow]

You're comparing a concentrated loss to a distributed loss.

One ugly thing malicious software can do is a "retaliation" strategy (a cooler name is welcome). If you try to destroy or render it ineffective, then it attempts to do the same to the computer that it's on. If I can't have your computer, then you can't have it either. Maybe tit for tat. So if the user stops trying to fix things, then the bot stops retaliating. This would be interesting on a collective level since the bot network might start destroying data, if it detects poisoning attempts.

Re:Public Key Cryptography and Message Signing.

[CodeBuster]

it would simply be a matter of analysis to locate the key.

Allow me to be more clear: the key stored in the bot code would be the public key of the botnet operator so even if the researches found it it would not help them to sign false messages. For that they would need the private key which, of course, would be retained by the botnet operator and never distributed. If the correct signature cannot be forged without the private key then the command messages would be safe, even if analysis recovered the public key from the bot binary.

Messages to the Command and Control will still be protected if public-key crypto is used...The signatures will not be able to be faked, so your approach is correct in that it would prevent the researchers from injecting commands.

Right and right again. I should have been more clear about the public key issue in the message signing part of the original post.

The bots can use PKI to talk among themselves, but because each bot will have its own keys (and how will they negotiate keys to encrypt?)

The diffie-hellman key exchange [wikipedia.org] algorithm does not require PKI to work, although the addition of PKI can make it more secure. If PKI is not employed as part of the key exchange then it is vulnerable to man-in-the-middle (MITM is usually difficult to do in practice over TCP/IP due to timing and network latency issues among other difficulties).

the process should be at least observable at a much deeper level unless the programmers are very careful to have considered a man-in-the-middle attack and, for example, used signed keys

PKI between bot instances is impractical. There are too many instances (on the order of hundreds of thousands at least) and how would they securely store their individual private keys and distribute and forward all of their public keys? They could use naive Diffie-Hellman, but not PKI for inter bot communications. I agree that this would be vulnerable to analysis in a controlled environment.

This would prevent forgery of signatures, but would still allow the researchers to intercept any communications for a bot which the researchers can control. A small percentage, but in a lab this could allow the researchers to decode at least some of the "Secret Handshakes" used, those being the ones for bot to bot communication.

Right, I agree. Although it might be somewhat cumbersome to set up the controlled environment. You would need at least two (2) bots in the sandbox network that can be induced to communicate with each other with a third host performing the MITM and analyzing the secret handshakes (which occur after the secure connection is established via Diffie-Hellman).

Communication TO the Command and Control, however, would remain inaccessible.

Right, and this probably how the really important operations are executed anyway, under the command and control of the botnet operator.

However, public key encryption is notoriously hard on the CPU, requiring many more cycles when compared to a similar (equal protection from brute force attack) symmetric algorithm.

Right and the PKI for the command and control protocol would have to use big keys because if they are cracked then the entire command and control network is cracked (probably 2048 bit RSA would be used). The private key for message signing on the command and control protocol would be an attractive target to say the least. As for slowing down the machine that probably wouldn't tip of f the naive user/owner since they will probably chalk it up to "their computer is old" or "well, that is Windows for you".

I guess your approach will work partially, but enough to make life difficult for "the good guys".

That is all that the botnet author really needs to do, make it hard enough so that people don't want to bother with attempting to disrupt the bot network.

Re:It's not Really...

[Sancho]

If you think about the terms used:
Informative means providing information. In the context of Slashdot, it should be information pertaining to the topic. This is not highly subjective, until you start talking about tangents.

Interesting is highly subjective. What's interesting to one person may be flat out boring to another. It's probably a bad moderation, but it's always going to be biased.

Insightful is somewhere between the two. Realistically, it ought to be reserved for times when a poster comes up with new and unique information--an insight, if you will--into the current thread.

I don't think there's really a place for "I agree" or "I disagree" moderation. If you disagree, rebut the post. If you agree, post an agreement that adds to the discussion or just keep on reading. Leave agreement and disagreement to the slums of Digg.

legal angle

[habusnake]

http://www.yjolt.org/7/ [yjolt.org] A little old, but this is an article I wrote on related legal issues-- legality of striking back including at zombies.

Re:It's not Really...

[logicpaw]

Do you think the Confederate states would have been better liberated, on under control of the U.S.? That's the point.