Ding, Dong, the Witch is Dead …
Well, one of them is, at least in theory. I am pleased to report that someone seems to have figured out how to kill a botnet. And not just any botnet, but the Storm botnet, a wicked system alleged to have infected more than 1 million computers during its existence.
A team of researchers from Bonn and RWTH Aachen universities analyzed the notorious Storm botnet and developed an application that links itself into the peer-to-peer (P2P) structure of a Storm worm network. Once there, it can divert drones to a new server controlled by the cleanup crew which can then issue commands to the Storm drones.
The server would direct the drones to download a special cleaning program that would remove Storm from the computer. Researchers think that their system will be able to dismantle a network of more than 100,000 drones without any danger of the central cleaning server collapsing under the load or suffering distributed denial of service attacks from botnet operators.
There is, however, one slight catch: employing this system might violate various national laws against unauthorized access to third-party computers or data tampering. In Germany, the home of the research team, they could face two years of imprisonment for unlawfully deleting, suppressing, making unusable or changing third-party data.
Other nations, including the United States, have similar provisions. In addition to criminal charges, you have to consider civil liability in case the cleanup application accidentally turns the computers into large, polycarbonate silicon boat anchors.
But all is not lost, even if the cleanup application is never deployed. In September 2008, a California-based Internet service provider (ISP), Atrivo/Intercage, long alleged to be associated with the equally infamous "Russian Business Group" cyber crime collective, was disconnected from the Internet by its upstream provider. Some declared this the final nail in the coffin for the Storm worms because Atrivo allegedly hosted Storm's control servers.
However, despite concerted efforts to clean it up, Storm is still thought to have 100,000 or so zombies still at large, albeit without much in the way of a command and control (C2) structure. And even if someone wipes Storm completely off the face of the Internet tomorrow, there are other botnets waiting to try and fill 95 percent of our inboxes with spam. But at least security researchers are working to combat them.
Brave New Botnets
Shortly after Atrivo was turned off, hosting provider McColo — a network that allegedly absorbed many of the cyber roaches fleeing Atrivo's shutdown — was also unplugged by its upstream providers in November. That stung, among others, the Srizbi botnet, another massive spam-producing operation with an estimated 450,000 infected computers. Organizations that monitor Internet traffic noted anywhere from a 50 to 75 percent reduction in e-mail spam on the day McColo was taken down.
Another less sophisticated but virulent botnet that ran into trouble in 2008 was Bobax (aka Kraken), which has been around since 2004. In April 2008, SecureWorks, a network security provider, reported that Bobax was the largest spam botnet with 185,000 active bots. Unfortunately for Bobax, it relied on a single hosting provider for its connectivity. In December 2008, that provider killed all of Bobax's control servers.
However, much like cockroaches, you can never really be completely sure that a botnet is dead, so it remains to be seen if Bobax is dead or merely waiting for new masters.
Unfortunately, that is pretty much where the good news ends. The reductions in spam from disconnecting Atrivo and McColo were temporary because other, more sophisticated botnets using encrypted or custom communication protocols, which are not dependent on a single host provider for C2, have moved in to fill the gaps. Botnets named Cutwail, Rustock, Donbot and Ozdok, each reportedly controlling more than 100,000 compromised clients, will be sending spam as fast as they can generate it.
And there are more waiting in line behind them, including a botnet called Waledac that seems to be a rewrite of Storm. Much as we like to kill off botnets, they not only seem to have the resilience of cockroaches; they breed like them too. As quickly as security and legal teams find and eliminate botnets, botnet owners develop more sophisticated systems.
Instead of using a single host for C2, they distribute over many hosts. Bot herders are hardening their systems with encryption both for communications and botnet clients.
They are also programming their zombie clients to send traffic to many Web addresses, in addition to their C2 servers, to make finding the actual control servers more difficult.
So, though there has been some progress fighting botnets, overall, we still don't have a pretty picture. For more on the botnet outlook for 2009, allow me to recommend an article, "Spam Botnets to Watch in 2009" on the SecureWorks Web site at: www.secureworks.com.
The Top 25
In addition to trying to kill botnets outright, another strategy is to deny them new zombies. With that in mind, computer security experts from 35 international, academic, corporate and government organizations released a list in January of the 25 most dangerous programming errors that create security vulnerabilities and how to avoid or fix them.
The U.S. federal government was represented by members of the National Security Agency's Information Assurance Division and the Department of Homeland Security‘s National Cyber Security Division.
The group divided the vulnerabilities into three main categories: insecure interaction between components, risky resource management and porous defenses. Let's look at a few of them.
The most common insecure interaction between components is called invalid input validation. A simple example of this is when an identifier that you expect to be numeric contains letters. If the system is not designed to reject improper input, it may become confused when attacked by input modified in unexpected ways.
Another potential avenue for insecure interactions uses Structured Query Language. An SQL injection attack occurs when an attacker tries to modify the SQL code that is used to communicate with databases.
For example, if a system uses SQL queries in authentication security controls, an attacker can attempt to alter the logic of those queries to bypass security. Other uses for SQL injection include modifying queries to steal, corrupt or otherwise change data.
The No. 1 risky resource management vulnerability is the "Failure to Constrain Operations within the Bounds of a Memory Buffer," or buffer overflow, for short. A buffer overflow happens when a program attempts to put more data in a buffer than it can hold or attempts to put data in a memory area outside of the boundaries of a buffer. This can, as with other attacks, confuse the system enough so that the attacker can then do other nefarious things.
When malware permits read or write operations on memory located outside of an allocated range, an attacker may be able to access/modify sensitive information, cause the system to crash, alter the intended control flow, or execute arbitrary code.
For porous defenses, the three top vulnerabilities are: improper access controls, secret hard-coded accounts and client-side security enforcement. Poor access controls essentially allow users to do things they shouldn't, like viewing complete folder directories. An analogy to this disaster waiting to happen is like inviting people to your house and having a few bad-mannered guests peek into your medicine cabinet or wander into your study and snoop in your checkbook.
Standard system passwords are not new, though most of them are also not particularly secret. Most systems come with a default administrator account, and you can bet any hacker worth his salt will either have a list of default passwords for popular systems or will have purchased (or stolen) a copy of the system to figure out the default account.
Smart system administrators change these defaults as soon as a system is installed. However, some developers have been known to write secret accounts into their systems, thus leaving a somewhat permanent vulnerability available to any hacker who can find it.
Client-side security enforcement problems occur when you trust client software to perform security checks on behalf of your server. Unfortunately, it leaves the keys to system access in the client software — an open invitation for hackers to reverse-engineer the client and write their own version — which, of course, will omit the security controls.
Combined with some of the previously mentioned authentication, authorization and input validation issues, this can be quite dangerous. While client-side validation may be convenient at some level, it is not a good security practice.
These are just general descriptions of only a few of the common weaknesses described in the report. For a complete report on the conference, more detailed descriptions of all 25 vulnerabilities, and discussion of how to avoid them, please see the conference report on the Sans Institute Web site at www.sans.org.
My Top Six List
So, where does cyber security go from here? Based on what we have been discussing for the last year and what we are seeing in cyberspace, here are my "Top Six" cyber security predictions for the next few years.
Stealthier Attack Methods. Given the evolution in botnet technology toward decentralization and encryption, the bot herders that survive the current worldwide purge will be those who fly under the radar. Early botnets thrived because people either did not know they existed — or did not believe they existed.
Dedicated security professionals, many of them working together, amassed enough evidence to start the gradually increasing avalanche of cyber security and legal activity that is burying the less agile botnets.
However, like using an antibiotic that kills only 99 percent of virulent germs, the remaining 1 percent may remain resistant to what worked the first time and transform into something even more predatory. The next generation of botnets may not be as easy to detect.
Smarter Attacks. Brute force attacks, a method of defeating a cryptographic scheme by systematically trying a large number of possibilities, which can include a dictionary attack, while still possible, are being supplanted by more intelligent attack methods, like collecting publicly available documents and files from a target and analyzing their metadata to develop attack profiles.
You can see a basic example of this by opening any common document format, going to the "File" menu and clicking on "Properties." This will reveal what the file knows about itself, including the software version used to prepare it and possibly the author's name and organization.
This can help a hacker on two levels: (1) He now knows the software the organization uses, which gives him a potential technical attack vector if that software has vulnerabilities, and (2) It may give him names and other organizational information to plan a social engineering attack.
Autonomous Evolution. Military troops prefer fire-and-forget weapons because they can launch an attack without being exposed to enemy fire. They can just pull the trigger and a smart weapon takes care of the rest.
Hackers like this paradigm too. I offer as an example the recent attacks by a worm known as Downadup or Conficker. This rapidly spreading worm may be a tool for building a huge new botnet, according to security researchers. It spreads itself, and then it prevents infected PCs from being cleaned up.
Once implanted, the worm searches out nearby servers and executes a brute force password-breaking program. It also spreads itself to any shared hard drives. What's more, it makes a copy of itself on any device plugged into a USB port, such as any thumb drives, music players or digital cameras. When that infected device is later plugged into another PC, it infects that machine, which then begins to similarly spread more infections.
Big Bulls-Eyes. Mark Twain once commented that if you put all your eggs in one basket you should watch that basket very carefully.
With the centralization of data stores over the last decade, much of our important financial, corporate and government information is migrating to fewer and larger network and storage systems.
However, as we discovered with banks and the Wild West, when you gather together large sums of money in one place, you attract thieves. News stories these days are full of reported breaches into centralized credit card databases and other sensitive information repositories.
It is a bit like the situation that confronted Lt. Gen. Walter Short, the Army Air Corps commander responsible for the defense of U.S. military installations in Hawaii at the time of the Japanese attack on Pearl Harbor Dec. 7, 1941.
Based on prevailing belief that local Japanese sympathizers were a greater threat than a Japanese air attack, Short made, what was arguably a reasonable decision. Short rationalized that clustering parked aircraft would be easier to protect against saboteurs than dispersing the aircraft.
Unfortunately, his strategy turned out to be tragically wrong. On Short's orders, the Army parked planes in such a way as to make them more vulnerable to aerial attack.
Compartmentalizing information protects it at the expense of making it less convenient to use. Centralizing information makes it easier to use, but at the potential risk of giving away the entire store if someone gains unauthorized access.
We should not limit ourselves to thinking in three-dimensional terms, as Short strategized in positioning Army aircraft, because in cyberspace, it does not matter where things are physically located.
The people who will make a lot of money in the next decade will be the ones who figure out how to give compartmentalized information the same ease of use as centralized information, so that authorized users will still have access — without compromising security.
If hackers can decentralize their botnets to defend against detection and elimination while still maintaining centralized command and control, then we should be able to do the same to defend our information resources.
System Lockdowns. On the positive side, it appears that network administrators and security professionals are making progress in securing systems. Internet service providers are now looking at security less as an inconvenience and as more of a way to protect their customers.
In one example reported by Spamhaus, a major ISP, allegedly home to 25 percent of e-mail spam that originated inside the United States, moved its Web-based e-mail traffic from Port 25, which does not require authentication, to Port 587, which requires an account ID and password to send e-mail.
Port 25 was a traditional channel for large organization e-mail communications, but because of its lack of authentication it is a favorite target for junk e-mail relays once a computer is infected.
While moving to Port 587 will not stop a zombie from sending spam, it will require that zombie to identify itself to the system, which helps in tracking and cleanup.
Yes, We Can. This last prediction is less a trend than a hope. The last thing most users want to see is one more computer security control that disables or locks down what they consider useful functionality on their PC or network.
Granted, there have been good reasons to clamp down because lots of bad people really are out to get us and get into our systems. But the "fortress network" mentality is almost totally defensive, and you do not win football games, or wars, with only defensive maneuvers.
With that in mind, I am seeing, in some circles, a move toward positive security, where people can try things on their computers using a balanced approach to security and flexibility. As we get better at protecting our networks, I hope to see more flexibility achieved through innovative security measures.
The Internet is much like a human body: a large organism with a huge number of interdependent component parts, including hardware and software, networks and users, control mechanisms and communications links. It is, thanks to its basic design, mostly self-healing, routing around damage and regulating the flow of data.
Computer security, in the endgame, will not depend on securing individual systems, but in securing all systems. It will not depend solely on technical measures, but also on diplomatic, legislative, judicial and political change at home and abroad.
As long as viruses, bacteria, cockroaches and bot herders have a place to hide, we will get colds, staph, bugs in the kitchen and junk e-mail.
While we, personally, may not be able to effect all the global technical, political, diplomatic, legislative and legal changes required, we can still do our best to help shine lights into dark corners and make the world a little less safe for the roaches in the system.
Until next time, Happy Networking and Good Hunting!
Long is a retired Air Force communications officer who has written regularly for CHIPS since 1993. He holds a master of science degree in information resources management from the Air Force Institute of Technology. He currently serves as a telecommunications manager in the Department of Homeland Security.
The views expressed here are solely those of the author, and do not necessarily reflect those of the Department of the Navy, Department of Defense or the United States government.