Sunday, September 12, 2010

How to Deal with Botnets

A Botnet is a collection of software agents, or robots, that run autonomously and automatically. The term is most commonly associated with malicious software and is derived from a Czech author’s word “robot” that was featured in a 1932 science fiction novel http://www.gutenberg.org/etext/13083 .

Botnets are operated by a “Botnet Herder” who acquires bot-creation software from one of many commercially advertised sources as well as from clandestinely developed proprietary sources, such as from http://www.newfreedownloads.com/find/bot.html . Bots are often ‘rented’ as a service to third parties for sending out spam messages or for attacking computers for theft of passwords or credit card information.

To be successful a botnet attack starts with the “botnet launch” phase, which is always based on the deployment of a zero-day virus (the virus signature is not contained in any of the virus detection software or in firewalls screens). The attack target is always either the Microsoft Operating system or usually the Microsoft Browser, although increasingly the Firefox are also targeted. Lately, the attack mode has shifted t the exploitation of less robust social computing applications such as FaceBook and particularly Twitter, which are propagation vectors of infected messages. It used to be true that replacing the Microsoft OS with Linux reduced risks from botnets, but that is not the case any more because of the proliferation of social media as a malware carrier.

For instance, on September 10, 2010 ealert@gmu.edu reported that an e-mail message would contain the 32.Imsolk.B@MM malware, The recipient of this e-mail would be then asked to download a document (“Here you have, just for you”) alleged to be a PDF file, but is in fact a disguised attack.

An attack can be launched from anywhere in the world and will persist for not more than a few days and often only a few hours, which is sufficient time before countermeasures are found and anti-virus fixes can be installed. Any attack will consist of multiple (hundreds) of variants of bot attack version because the attackers can be never sure which version will be successful.

We can assume that NSA will (or can) attempt to intercept the botnet launch server by attacking it through jamming or with other counter measures. I have no idea how successful that can be, though I am skeptical whether that can work because the attacker can instantly change the herder’s site. The herder can also use “anonymous remailers” or similar camouflage to disguise its origin. In the case of DoD I would certainly not relay on any NSA intercepts of botnet sources as a defensive measure.

After the “botnet launch” phase succeeds, and the attacker has created a bot that self-replicates or is triggered by an unsuspecting user to launch itself, the herder can proceed with triggering the bots to perform their missions, though herder intervention is not needed in the case of denial of service attacks. Often the time between the “botnet launch” phase and the “botnet actuation” phase can be hours or days.  A successful botnet launch may succeed in planting itself few hundred thousands of computers. There are over 500 million computers connected to the Internet. It takes less than 0.1% of machines to be initially infected for a very successful attack.

From a DoD standpoint you should be aware that you already could have embedded in your systems “sleeping” bots, ready to be triggered by a herder, particularly if this creates a tactical advantage. Particularly damaging can be a sleeping bot that has implanted spyware that generates only a few transactions, which cannot be detected. How to ferret out such dormant cases is a lengthy subject, do be discussed when we have time. The source of the “sleepers” can be insiders (accidental or otherwise). As long as you do not have a complete forensic record of all transactions, including those of contractors, you will be always exposed to an insider risk. This is another situation that warrants further discussion.

After the “botnet launch” phase is done, the most frequent use of botnets is to distribute spam, mostly in the form of spammed e-mail (70% of e-mail now is spam). Spam can drive advertising but I would not discount the likelihood that it is used in cyber warfare as a probe to collect intelligence. I would always take the appearance of any spam whatsoever inside my secure systems as evidence that I have been compromised. Furthermore, I would mandate that every single spam case inside the secure network would have to be reported and then forensically analyzed.

The greatest danger from bots arises from their ability to receive commands from a herder to launch denial of service attack against a designated remote target, such as DoD routers, switches or servers with an IP address that can be detected (that is easy). Since bots can infect ten thousands of machines, thus creating a specific “botnet”, they can induce the bots to generate huge volumes of traffic, such is flooding DoD with spam, email or denial of service data transactions.

For instance, there were an estimated number of 12 million infected computers with the “Conficker” botnet in 2008, with a capacity to generate up to 10 billion transactions/day. Since its detection, “Conficker” has modified itself into several hard to detect variants http://www.microsoft.com/security/worms/conficker.aspx . “Conficker” variations are already inside DoD and pop us more often than anyone is ready to admit. I have a long list of table of successful bots, each with a unique name and unique signature (Mariposa – 12 million bots, Kraken – 9 billion/day capacity, etc.).

Preventive Measures
When I was in NASA I received a botnet attack on one of the thirteen Internet root servers (this is one of the most guarded servers in the entire global Internet) housed by NASA as a most trusted custodian. All we could do was shut down the root server for an hour and reboot back to an assured configuration. The botnet attack stopped and went elsewhere looking for other targets. My only concern was that even a failure of an attack could have been nothing but an intelligence- gathering op.

If a machine receives a denial-of-service attack from a botnet, there are few choices what can be done. Given the general geographic dispersal of botnets and their spread over millions of Internet sites, it is impossible to identify a pattern of offending machines. The sheer volume of IP addresses does not lend itself to the filtering of individual cases. Administrators can configure newer firewall equipment to take protective actions against a botnet attack by using information obtained from passive fingerprinting. The problem is that the number of virus signatures against which firewalls can guard is enormous. Symantec and McAfee are reported as tracking close to a million intrusion-detection signatures and update them daily http://securityresponse.symantec.com/business/resources/articles/article.jsp?aid=20090511_symc_malicious_code_activity_spiked_in_2008 . There are preventive measures utilizing attack rate-based intrusion prevention systems implemented with specialized hardware. You will be besieged with vendors offering you all sorts of hardware and software fixed.

Botnets often use free DNS hosting services such as DynDns.org http://www.dyndns.com/ , No-IP.com, and Afraid.org to point traffic to a to sub-domains that will then harbor the bots. Some large Internet companies (such as AT&T, Verizon, etc.) purge their domains of these sub-domains, but that is not helpful because a military cyber-attacker will bypass all that.

Several security companies such as Afferent Security Labs, Symantec, Trend Micro, FireEye, Simplicita and Damballa have announced offerings to stop botnets. While some, like Norton AntiBot are aimed at consumers, most are aimed to protect enterprises and the ISPs and not the users http://en.wikipedia.org/wiki/Botnet . So far as I am concerned, such measures are band-aids and inadequate for protect DoD sensitive operations.

Meanwhile Sandia National Laboratories is working on ho to control botnets by running huge penetration simulations. When I worked on your task force almost two years ago the key person from Sandia had by far the best grasp of the bot situation, but I have no idea what they have done with it.

An Approach
Since botnet infections come from the Internet, you must keep most of DoD completely isolated from the Internet.  There is no other choice. I do not know of a safe filter that would assure you that no bot would ever get through.

However, you can manage access to the Internet from DoD by setting up separate and completely isolated links for Internet access and particularly for social systems, as I discussed with you before.

One way of assuring security against the inevitable botnets is to allow access to internal network IP addresses to be accessible only through a limited number of router access points. This would force all incoming Internet traffic to obtain its Border Gateway Protocol (BGP) rout addresses exclusively from a DoD owned and operated computer, which would be under 24/7 surveillance. If a bot gets somehow through (it will, inevitably), your manned surveillance combined with investments in expensive tools, which are affordable to MDA for only a limited number of routers, should reduce this threat. Since your Internet connections will be all controlled, you can always resort to occasional “fumigation” of your systems, such as dictating a reboot with a secure system, even if this means losing transactions. I also favor using Linux instead of Microsoft OS as well as browsers, such as Chrome to reduce the attack surface offered to the most popular bot attacks. Of course, if a large share of your Internet connected population is in the form of thin clients, your “fumigation” efforts will be less and less fragile.

Forcing access to DoD exclusively through managed routing tables in at your Internet access entry points represents a challenge and would call for reconfiguration of your network topology.  But the result would be an increase in controls over the handling of every bit of incoming traffic, including bots. If you are forced to offer “social computing” and Internet access to Google and similar sources, you have no choice but to protect these channels by enforcing isolation.

Of course all of the other necessary precautions must be already in place for your operations. You cannot trust anyone to follow policy not to ever use a thumb drive on a secure machine. Your USB ports must be sealed, or continually monitored. The same applies to any removable drives. Altering any part of the removable memory, including swapping of changing configuration can take place only under 100% independently verified surveillance. If your people wish to telecommute or work from home, they would have to use only approved devices that have been fully protected and encrypted. Under no circumstances can you allow the use of any private devices to conduct any DoD business. For instance, contractors should not be allowed to use their firm’s computers to touch any of DoD communication points.

Summary
Consider the above a preliminary answer. I would need to know more before recommending to you to set up a path to the Internet, which is under surveillance by the network control center. Such a path must be completely separate from DoD secure communications. As long as you have even the slightest connection to the Internet, regardless how small, the enemy will ultimately find it and implant bots.

I am also concerned whether your security policies are adequate. I have read most of the DoD security policies, but they are generic and not articulated in plain English as to what is prohibited and what individuals can do. The existing policies were written for lawyers and contract officers, not of people who can spend only a limited amount of time on practicing secure behavior. A simple checklist of do’s and do-not’s that someone can check off and sign every quarter would go a long way to improve resistance to bot attacks.

You cannot stop bots. You can only control them by means of separate networks where you can afford accepting failures that you contain by more reliable human behavior.

No comments:

Post a Comment

For comments please e-mail pstrassm@gmu.edu