|
|
|
|
|
|
|
|
Last week, Cody Pierce and Pedram Amini (members of TippingPoint's security research group) released a detailed analysis of the Kraken botnet. The purpose of the analysis was to see whether the bot network could be infiltrated.
In order to test that possibility, Pierce and Amini had to take a very close look at the inner workings of the botnet code. With a sample in hand, they disassembled the code and dove into its inner workings to find an inroad into the botnet. The idea wasn't to become a bot in the network but to become a command and control server for the actual bots.
Amini explained, "The key to overtaking the botnet is understanding how the overall client-server architecture works. Kraken infected systems attempt to 'phone home' to a master command and control server by systematically generating sub-domains from various dynamic DNS resolver services such as dyndns.com. By reverse engineering the list of names and successfully registering some of the sub-domains Kraken is looking for, we can emulate a server and begin to infiltrate the network zombie by zombie. Stated simply, Kraken infected systems world wide start to connect to a server we control."
After reverse-engineering the bot, which of course included its encryption algorithm, Pierce and Amini were successful with their infiltration. After one week of running their rogue command and control server, they discovered that about 25,000 systems were infected with the Kraken bot. That is to say, about 25,000 unique computers connected to their rogue command and control server.
Apparently there's some debate about how big the Kraken botnet really is. The estimates range from roughly 185,000 bots to as many as 650,000 bots. Pierce and Amini said that since they were able to communicate with 25,000 bots, they effectively had control over anywhere from 4 to 14 percent of the entire botnet.
Then came the question of what to do with such control: sit back and watch, or on the other hand, possibly take action to remove the bot software from infected systems. That's an interesting question with no easy answer, although cleaning up the infected systems is very tempting.
First, there are issues that center around legalities. For example, is it legal to remove malware from people's systems without their permission? I'd guess that it's not. Even so, would authorities or individuals seek to press charges if unauthorized removal took place?
Then there are issues that center around potential damage to an infected system. Pierce and Amini point out that Dave Endler, who also works at TippingPoint, is against removal for these relatively solid reasons: What if a computer is damaged or crashes in the process of removal? And what if such a computer were in some way partially responsible for someone's life, as might be the case if a computer were located in a hospital, clinic, or doctor's office?
Clearly the only safe way to handle this kind of dilemma is to gather the IP addresses of infected computers, find out which companies manage those IP addresses, and contact those companies to let them know about the infected systems. Hopefully those companies would take steps to clean up the botnets and help the end users of those addresses get some adequate protection installed on their systems.
Of course, because cleaning up the infected systems through the use of a command and control server is incredibly tempting, there are those who would take such action regardless of the risks involved.
If you're interested in the details of the analysis or in sharing your perspective on how you think such an issue should be handled, head over to TippingPoint's Digital Vaccine Labs blog at the URL below. There you'll find detailed technical explanations of the analysis (including disassembled code snippets), links to related information regarding Kraken, and plenty of comments from readers who've commented on how they think the moral issue should be handled.
dvlabs.tippingpoint.com/blog/2008/04/28/kraken-botnet-infiltration
End of Article
|
|
|
|
Register
