The recent surge in botnet activity around the Internet has led researchers to look at some unusual—and potentially...
troublesome—tactics to disrupt the botnets' operations and disable the bots on infected machines.
Kraken, the botnet of the moment, has infected tens of thousands of PCs and is showing no signs of slowing down. Researchers studying the malicious code noticed that machines controlled by the Kraken author run through a pre-seeded list of domains on start-up as they search for a functioning command-and-control server to communicate with. If a C&C server is disabled or is otherwise unavailable, the author will go and register the next domain on the list and set up a new command server. The bots in the network will then run through the list until they come to the new domain and simply begin taking commands from that machine.
Researchers at TippingPoint Inc.'s DVLabs saw this function as a potential opening and recently began registering some of the sub-domains in the Kraken list and emulating a C&C server. The phony server immediately began receiving connection requests from Kraken-infected PCs around the Internet, adding up to nearly 2 million in a one-week period, the researchers said in a blog post on their infiltration of Kraken . The researchers now had the ability to issue whatever commands they chose to the thousands of bots in the Kraken army.
The question is: What orders should they give? Are they justified in feeding the infected PCs new binaries that would disable the Kraken bots? The researchers wrestled with the problem and eventually came to the decision not to disable the bots, but not before a lot of back-and-forth on the matter.
"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. Is it wrong to do so?" one of the researchers, Pedram Amini, wrote in an analysis of the operation. "Although this discussion is similar to that of writing 'good worms' that roam the Internet patching vulnerable servers, there is a key difference in that a good worm can't be stopped. Once it has been released it is a self spreading uncontrollable entity. In our specific case however we have the ability to cease at any point. It is simply a one to one relationship. An infected system connects to us, we supply a simple binary to kill the target process, we never hear from the infected system again and neither can the actual botnet owners command and control servers."
The idea of writing code to automatically patch machines against a specific vulnerability or to disable existing malware is by no means a new one. Security specialists and researchers have been toying with the notion for years, and it has produced almost as much inflamed rhetoric as the arguments for and against full disclosure. There have been a few actual examples of so-called good worms in the wild, with the most famous being the Welchia worm of 2003 that attempted to patch the flaw in Windows that the infamous Blaster worm exploited.
And earlier this month a group of German researchers released a paper detailing their work digging into the botnet set up by the Storm Trojan and their ability to poison the Storm network by publishing a large amount of fake key material for the Storm-infected machines to consume. The Storm bots use the keys to communicate with their peers and the researchers were able to overwhelm the bots' search capabilities.
Many security experts have argued that regardless of the good intentions people have when releasing code such as Welchia, the idea of issuing commands to PCs owned by other people is not a good one. Cody Pierce, the TippingPoint researcher who did most of the reverse engineering and analysis of the Kraken code, said he can see why people re skittish about the idea, but thinks the benefits outweigh the drawbacks.
"There are two obvious sides to it. This thing is using resources that don't belong to it, sending out spam and doing denial-of-service attacks, and we can shut that down and do people a favor," he said. "But [the infected machines] are not our property and it's not up to us to police the Internet. I can see both sides. But I'd do it if I could."
From their unique vantage point inside the Kraken botnet, Pierce and Amini were able to scrutinize the behavior of a subset of the bots on the network and also were able to get a fairly good idea of how many machines were on their section of the network. During their seven days of observation they identified about 20,000 unique IP addresses that were sending connection requests to their fake C&C server.
"If you extrapolate that out to the rest of the network, that's a huge number," Pierce said.
Other researchers who have studied Kraken and similar botnets say that the temptation to disinfect compromised machines is always there, but there are too many legal, ethical and technical issues to make it worthwhile.
"When you start making the same changes the botmaster might make, it blurs to a point where I wouldn't feel comfortable doing anything like that," said Paul Royal, principal researcher at Damballa Inc., an Atlanta-based security vendor specializing in botnets, which discovered the Kraken botnet. "A lot of botmasters will disable other bots and will even patch vulnerabilities that they came in through, and if you're doing that, at that point you're the botmaster. And you may inadvertently do things to the machine that could cause more damage."