Go to content Go to navigation Go to search

05/06/08 03:13 PM

A Good Samaritan Botnet

Posted in by Nick Staples

I’ve recently heard talks of security researchers using the distributed nature of a botnet to remove existing malware. More specifically, the issue was raised after researchers over at TippingPoint Technologies managed to isolate and reverse engineer a client of the Kraken trojan botnet.

According to Pedram Amini (one of the researchers):

“By reverse-engineering the list of names and successfully registering some of the subdomains Kraken is looking for, we can emulate a server and begin to infiltrate the network zombie by zombie. Stated simply, Kraken-infected systems worldwide start to connect to a server we control.
...
We have the ability to successfully redirect infected systems. We have the ability to provide an ‘update’ through the existing Kraken protocol that can simply remove the Kraken zombie.”

This presents an interesting ethical issue— is it or is it not a good idea? From a professional standpoint, I can certainly see how it would be wrong; executing unrequested code on someone else’s computer, no matter what the reason, is a violation of their privacy. It’s technically no different from the malware itself, so there is definitely a liability issue to take into consideration.

On the other hand, for people who are unaware that they have an infected computer (or who don’t know how to fix the problem themselves), using the botnet to clean infected computers might be appreciated. It could be good in a vigilante sort of way.

But then there’s the argument that a good number of those computers that would be “cleaned” by the modified botnet would just get reinfected by the next wave of malware anyway. Maybe it’s really not even worth the risk…

1 Comments for A Good Samaritan Botnet

Violation of privacy aside, I don’t trust anyone other than the software vendor to patch their own product. The “good samaritan” approach, while it sounds good in theory, is really dangerous. The biggest problem is that it’s really, really hard to write bug-free code…especially when updating a program that you didn’t write in the first place.

What would happen when the “fix” contains a new bug? Something along these lines could easily happen, which would just compound the problem. On a distributed network, where you can’t be sure of which computer is running what versions of what software, do you trust yourself to write a patch that is 100% bulletproof? I’ve got a big head, but I don’t think my ego is inflated enough to think that I could.

Closing up security holes is important, but this seems like a really bad way to go about it. The risk/reward ratio is insanely skewed towards the risk side. I think it would be better if we, as an industry, make education and self-sufficience more accessible to end users rather than surreptitiously try to save them from themselves.


— Walt    05/06/08 04:26 PM    #