Chapter 12 Responding to Botnets
Introduction
In this chapter, we talk about how we got ourselves into this mess, and brainstorm a bit about how we might get out. We first discuss the problem and talk a bit about how it is fueled by money and identity theft. We also talk about why it is a hard problem. Then, we present various ways we might respond to the challenge of botnets, including basic sane security practices for hosts and networks, and measures aimed at reaching out to more aggressively grapple with the beast. One thing for sure, the problem is real and it is fueled by money. We also are going to brainstorm a bit in this chapter. Not of all our solutions or suggestions will be doable by everyone, especially those with limited resources and time. To quote from the State of Kansas: “ad astra per aspera” (to the stars through difficulties). We hope to provide food for thought.
The $64,000 question with botnets is what to do with them when you find them. Blocking the inbound and outbound traffic related to the botnet and eliminating clients you find in your environment is a natural first inclination, and in many organizations, this may appear to be your only option.
Your organization’s response to botnets should begin long before you discover a botclient or botserver on your network. Many actions can be taken that are preventative, proactive, and should be considered. We will examine the issues and concerns in many areas to search for potential opportunities for improvement to discover as many tools and weapons against botnets as possible.
Giving Up Is Not an Option
Recently, some botnet pundits have opined that the traditional way to get rid of a botnet may not work as well anymore as distributed botnet software continues to evolve. We have traditionally relied on botnets having a known head (a few botnet server IPs at a DNS name as mentioned in Chapter 3) and have tried to take down the botnet server itself. In a few cases (not enough), we have tried to lock the botnet herder in jail. Chapter 3 presented botnets that may use the Web (http) or P2P technologies for connectivity. P2P in particular looks worrisome because it could mean the snake now has multiple heads.
The problem with cutting off the head is that it leaves a sea of infected hosts behind. If a botnet client host is vulnerable to exploitation and not fixed, it is still vulnerable and can probably be infected with a new bug, controlled by a different master, and added to a new, stealthier botnet for new forms of misuse. We can’t be sure we actually cut off enough of the head, either. Alternate head #2 may be primed and ready to take over. The host and all its data are still in peril. Ultimately, we still have to address host security and do a better job of it.
Botnets certainly represent a new, more evolved form of malware. Malware used to be one virus and maybe one remote controlled host, not an entire assemblage of exploited hosts remotely controlled. The big differences now are in the numbers of controlled hosts and the use of exploited hosts for money, possibly with organized crime behind it all. Systems are used for various forms of identity theft (phishing, more later) and other forms of fraud, including bogus mouse clicks on Web pages, spam generation, and the use of denial of service as a form of extortion.
Computers are hacked in different ways—some traditional, some new, and as of yet possibly unknown. Botnets represent a rapid sphere of evolution in some sense in attacks, but most of the attacks are old and represent nothing new. These attacks include traditional password guessing and Microsoft file share attacks. Password-guessing attacks could be dealt with by known strong authentication techniques or even such simple techniques as making sure accounts have passwords. Microsoft file share attacks often succeed simply because people for whatever reason (bad reasons, typically like “it is not convenient”) don’t update their computers.
So, possibly to misquote John Paul Jones: “we have not yet begun to fight.” We do not know if the situation is worse than it was a few years ago (attacks often go unreported). We might simply be more aware of what is happening in the black-hat world. Even if botnet technology changes, though, the arms race between white-hats trying to protect computers and black-hats trying to exploit computers has been going on for awhile. That particular arms race is not new, either. There will be new advances in both white-hat and black-hat technologies. At times, white-hat technologies may discover a way to more easily discern botnet traffic or practices. At times, the black-hat hackers may create a new technology and deploy it in their botnet malware. This doesn’t mean the white-hats should give up and call it a day.
In the meantime, we would do well to pay attention to the usual suspects:
1. We need more education about security in general and botnets in particular.
2. We need more white-hat organization and communication between security professionals.
3. If you practice good security practices, odds are you won’t be joining a botnet.
Education about keeping computers safe has always been a problem in security, and we would like to see more done there. One obvious challenge is the world of home computers hooked up to broadband DLS and cable connections (see the spamhaus site at www.spamhaus.org/statistics/networks.lasso for grim statistics). We aren’t going to say much more about that here, but of course this book is part of the solution as it should help educate the IT public about the botnet threat. It would not hurt if IT managers would emphasize training for IT professionals in security.
Organization and communication between security professionals is crucial. There is not enough communication about botnets in many spheres, including academia, professional groups, security-related businesses, and the white-hats actually fighting botnets. Informal and formal discussion venues are needed. Basic meta-problems exist, like who is authorized to know certain kinds of data. Another problem is that academics often cannot get relevant and useful data for study simply because of security or privacy concerns. Often, there is a very real problem that security people may need data but are “simply not be in the loop,” because they don’t now how to get in the loop.
Our point is simple. Yes, botnets may evolve, but so will defensive measures. This doesn’t mean we should give up. Our defensive measures and practices are well known. We can probably stop the average Microsoft host from being infected. We simply must put our defensive measures into practice and at the same time do a better job of communication about problems.
Why Do We Have This Problem?
Let’s back up a moment and talk about why we have this problem in the first place. One basic reason is that botnets are a means of making money. Another aspect to consider is the software engineering background where hard problems in software engineering contribute to the problem. However, if engineering is the problem, then possibly engineering is also the solution. We also find that we make mistakes not due to technical wonders inherent in “exploits,” but because our processes and practices are flawed. Simple attention to IT process can work wonders in the enterprise and possibly in the home if we can ever figure out how to do tackle that particular arena.
Why are botnets spreading everywhere? Are there environmental conditions or factors that make it easier or harder for botnets to exist and proliferate? If they exist, then companies, universities, and organizations can affect the desirability of their site for botnet colonization. In industry, are there behaviors and practices that encourage the creation and use of botnets? Could these behaviors and practices be changed? This section attempts to describe environmental aspects that are useful to botnets. While we won’t be able to cover all possible environmental aspects, we’ll address as many as time permits.
Fueling the Demand: Money, Spam, and Phishing
As in most things, the primary motivation for the creation and use of botnets is money. The headlines tell us that organized crime has gotten into the sponsorship of botnets in a big way. Recently, the news media reported a Russian Mafia group operating a 73,000-bot network for sending spam. Their products included pornography, pump and dump stocks, and Viagra. As long as there are lucrative opportunities like these, there will be botnets. We know that only a small percentage of recipients need to respond to make the operation profitable. The rationale for using mass mailing to individuals who do not ask for or consent to the e-mails, is either that the population of potential customers is difficult to discern, or the fear that most potential customers would say no if asked if they would like advertisements of this nature. For botnets to be useful in this kind of venture, the botherder must gather a large number of computers for the generation of spam. Some of these computers need to have high-speed connections and significant processing power to serve as spam relays. Alternately, the botherder can locate and use other (not part of the botnet) mail servers configured to act as relays or open proxies. Botnet clients need to live on networks that permit the command and control protocol through their firewalls and IDS/IPS, or the command and control must be flexible and designed to operate using multiple protocols and applications. In a recent R-bot infestation, we found copies of Dameware, Carbon Copy, and VNC, all useful as remote administration tools, on different botnet clients within the botnet.
The products chosen need a large and reachable customer population. It is, after all, a numbers game. The spammers count on getting a certain number of customers out of every run. In the case cited previously, the spammers only needed one sale out of every 30,000 to make a good profit. The customers must want to buy the products via this unusual medium. In this case, the motivation could be embarrassment or cost. In the case of pump and dump stocks, the motivation is greed. Note, too, that the spam needs to get by many (but not all) of the anti-spam filtering techniques.
Ironically, some large ISPs have begun to provide anti-spam software or services due to the demand of their customer base. This is a case where the spammers may have been their own worst enemy. By not exercising constraint (which is not in their nature), they have caused ISPs to respond to keep customers from changing to other ISPs.
Spammers prefer to find an organization that permits individual computers to send SMTP outbound as opposed to sending it through a local SMTP server where it might be checked for spam. They also prefer organizations that do not keep statistics, such as top outbound mail senders, and so forth. Organizations that permit inactive accounts to stay open are also targets for spam sending botnets. Botnet herders can pound away at these inactive accounts trying to guess their passwords since there is no one using the account to notice. Large organizations with many inactive accounts and large amounts of user rollover, like universities, are a prime target. These accounts can be on both UNIX and PC systems, since mail is ubiquitous.
For phishing and pharming attacks, the target is personal information, financial information, credit card numbers, and access to financial Web accounts (for piggybacking). There are three components to the phishing attack. First, you have to herd the victims to your collection sites. For this, the phisherman could use a botnet in much the same fashion as the spammers. This spam would look like e-mails from banks or other financial institutions. You could also use pharming techniques. For pharming, the botherder targets local DNS, either on a PC host directly or by a targeted attack on the local DNS servers. Taking over DNS in toto is an awesome venue for man-in-the-middle attacks. Now the phishing site needs to masquerade as the real site. Many do this by using images that were extracted from a real financial or business site. The herding activities discussed are all technical elements of a social engineering attack. The attack depends on the user being unable to easily distinguish between a real e-mail or Web site and the phishing version. It also depends on the user to react to the emotional appeal of the fictitious issue raised by the phisherman. Finally, to set the hook, the phisherman needs the victim to react in the manner prescribed in the e-mail—that is, to click on the provided link. Click here to avoid this unpleasant disaster. For this to happen, the user must be uninformed, emotional, and unsuspecting of the convenience of the embedded link.
Law Enforcement Issues
As a side note on this phenomenon, the phisherman can locate sites in different countries for the actual phishing Web site. These sites are in existence for less than seven days. Why? International requests in Europe for law enforcement assistance take seven days to process.
Using International Sites to Delay Law Enforcement
A May 19 Information Week article by Thomas Claburn described the case of Jayson Harris, an MSN phisher, who was convicted in Microsoft’s first civil phishing case (www.informationweek.com/news/showArticle.jhtml?articleID=188100721). Dave Aucsmith, senior director at Microsoft’s Institute for Advanced Technology in Governments described the path of the investigation to CRIME, a Portland Oregon group of law enforcement and information security professionals. Microsoft filed a John Doe lawsuit in the state of Washington. Following the e-mail path, the trail dead-ended in India. Then, law enforcement issued subpoenas to Web hosting sites in California. The information gathered in these subpoenas pointed to an ISP in Austria. A February 14 article, “How to Hook the Elusive Phisher” by Steven Levy in online Newsweek, revealed that Microsoft had no legal grounds to compel the Austrian ISP into revealing what they knew about the attacker. However, according to Levy, the operator, Andreas Griesser, hates phishers and voluntarily identified a Qwest IP address in the United States. The subpoena to Qwest and further investigations revealed Jayson Harris of Iowa as the culprit. Harris was using his grandfather’s MSN account to run the operation. Jayson was sentenced to 21 months and restitution of $57,000.
Of course, the individual has no chance of being able to take independent actions that would catch the phisherman. A number of consortiums, like the CastleCops.com/PIRT team and the Anti-Phishing.org Web site, have sprung up to provide a channel for individuals and corporations to have a chance of contributing to the taking down and eventual capture of phishing site operators.
Even in the same country, the process of getting information from the ISPs involves a significant bureaucracy. Both the law enforcement community and the judicial community must be involved in the process of developing and approving a subpoena, which most ISPs require to protect themselves from lawsuits. Just a few years ago, the ISP operators would have given the information voluntarily once they were convinced that “terms of service” had been violated or a suspected crime had been committed. In today’s litigious world, this rarely happens.
For the botherder, the final component of the phishing/pharming attacks is the final site where the data is aggregated and exploited. This may be a site owned and secured by the botherder, but it may also be a neutral site controlled or specified by an individual or group known as cashers. The main technique for converting credentialed information into cash is to use the information to create ATM cards (called tracking) and then use the cards to withdraw the individual’s maximum daily funds. Christopher Abad, in his report “The Economy of Phishing” (www.firstmonday.org/issues/issue10_9/abad/), notes that the reason tracking has become popular is because of measures taken to make it more difficult to ship purchased goods to countries where credit card fraud is a significant problem.
Studies of institutions targeted for phishing in Abad’s report show that financial institutions that use weak measures to protect ATM mechanisms from tracking are the most frequent target. The demand for Bank of America credential information is almost nonexistent due to the fact that their ATM card encoding algorithm is difficult to obtain or crack. According to Abad, phishers interviewed believe it may be encrypted with Triple-DES. When his report was written, in September 2005, Washington Mutual, Sun Trust Bank, Citibank, and Citizens Bank were the top four targets of credential theft. Abad speculates the reason these banks are in such demand is because their tracking algorithm is easy to obtain from other phishers. This demand, he concludes, is created by the ability of the casher to cash out a given financial institution; thus, restricting the ability of the casher to cash out reduces demand.
Hard Problems in Software Engineering
From the traditional computer science point of view, a couple of points need to be made. One is that our problem is indeed hard. For example, one of the founding fathers of computer science, Alan Turing, showed that we could not write a program that could decide if another program was going to halt the computer. (For example, see http://en.wikipedia.org/wiki/Halting_problem).
This was called the halting problem. A poor student of computer science might decide that this problem only applies to programs looking for halt instructions in other programs. After all, Turing mathematically proved that the program searching for the flaw cannot find all instances of it. The more astute student understands the general implications. In practical terms, we can’t get all the bugs out of a software program or system. For example, in security terms, consider a virus checker looking for “signatures” (patterns) in random files on your Windows box. Turing told us that by definition this program cannot be perfect. A virus may exist that the program cannot detect. This is a fundamental result in computer science.
Furthermore, we know that our systems only seem to get more complicated. We now have dynamic link libraries and loadable device drivers and it isn’t clear where the operating system ends and applications begin. Microsoft may have a lot of software, but they also have created a large market for third-party applications. It is not reasonable to expect them to have absolute control over the quality of those third-party applications. The bad news here is that the odds of your host system having been tested for security bugs in any meaningful way is darned near zero. IT workers have the daunting task of taking miscellaneous hardware, an operating system, random drivers, a different set of applications per host, and the pile of patches needed to keep those systems “up to date” and somehow make it all work with other systems over the network. Put another way, the combinatorics of testing of any sort is a very difficult problem. Couple the complexity of software with the fact that the hacker needs one bug that works and the “anti-hacker” needs to know all the possible bugs. This is a very tough nut, indeed.
In the botnet world, we seem to have some tough problems, too. One of them is the ever-increasing amount of spam we discussed in the previous section on the phishing phenomenon. Another is that we lack effective means of dealing with large-scale DoS attacks. These are both hard problems.
Lack of Effective Security Policies or Process
To be owned, each botnet client has to have at least one security issue. In some cases, the issue is technical, but in many, many cases, the fundamental local enterprise security policies or the lack thereof may be the problem. To quote from our hero, Bruce Schneier, security wizard: “security is a process, not a product” (www.schneier.com/crypto-gram-0005.html). In other words, a new shiny firewall won’t solve the problem unless it somehow is part of a process of incremental improvement with some brainpower and policy thinking behind it. IT process and wise implementation is fundamental. To illustrate this problem, let’s tell a little story before we go on.
One fundamental problem with PCs is that most software applications can require local admin to install software. Many companies and institutions grant users local administrator access, either by putting their domain account in the local administrators group on the workstation or by creating a local account and putting the account in the local (workstation) administrator group for them. This account is different from the institution’s local administrator account. Giving the user’s Domain account local admin privileges means that every time the user goes to a site that downloads and executes malicious code, it will execute with local administrator privileges. This is not good. Giving the user a separate local account with local administrator privileges is better from this perspective, but then you have to ensure that the account is properly protected and the users understand that they are to use this account only when they have to have (not want) admin rights. Many IT organizations split the Windows administration tasks between two groups. One team administers the group policy and enterprise level aspects. The other team maintains the local policy and workstation level aspects. Windows does not by default carry over the domain security policy regarding password complexity, strength, and expiration into the local policy unless you explicitly tell it to do so. In addition, the limitation on the number of guesses you can make when trying to log in to a local account across the network does not match the limits placed on the domain accounts. For local accounts, the default for auto-lockout is none. Guess what? The result is open season on most local accounts! This is the vulnerability Rbot relies on to spread from computer to computer.
The fundamental problem here is that users want to be able to install software without having to wait for IT or have IT install it for them. Companies with real concerns about security use group security policy to prohibit users from installing their own software. Each piece of software installed by a user is one more opportunity for hackers to exploit. None of these applications will be protected by the corporate patch management system (if such a thing exists). Some companies grant local admin to everyone who asks for it. Some grant the user local admin by default to eliminate the work associated with these requests. Very few organizations teach users to use one account with a very strong password for installing software and other tasks requiring privilege, and another account for daily use.
One security conscious (but 0wned) user had an amazing array of firewalls (yes, plural), anti-virus, spyware, intrusion detection, process and network monitoring tools, all of which showed nothing. Rbot penetrated his system using a local admin account because the local admin password had been made trivial. Rbot came in as a legitimate local admin, and turned off the security tools long enough so it could execute its applications using a stealth hook program (hidden32.exe, hideapp.exe, or hiderun.exe). The result was that these monitoring tools either showed nothing or attributed the activity to common applications. In some instances, the FTP server, SERV-U, was modified so that it appears, in Task Manager and System Internals process explorer, as the Internet Explorer. If you look closer, it says that it is a security alert mechanism to protect against hacker attacks. Instead, it opened an FTP server on port 1119.
The use of local administrator accounts by users also leads to the phenomenon of local admin account creep. Each time a new user is assigned the computer, a new local admin account is created. Soon, no one remembers what the other accounts were for and whether any dependencies exist related to them. To play it “safe,” they are left on the system, forever. Coupled with the fact that the passwords never expire, there is no complexity policy, and there is no account lockout, these accounts are a target that cannot be passed up.
At Portland State University, we have seen the following phenomenon play out far too many times:
1. A Windows system remains unpatched, because the user in charge doesn’t turn on Microsoft updates. Guess what happens eventually?
2. A Windows or UNIX system (likely Windows, though) is compromised because of a password-guessing attack. This may be due to the most stupid possible reason: it has an account with no password, or the password is “sue”.
3. A UNIX Web server is compromised because it has a piece of trash PHP code on it that allows a remote user to execute arbitrary code on the server. This is not a new paradigm. It is simply a modern variation on having a backdoor in the server known to the hackers but not to the administrators. Ultimately, this occurs because users (or professors) are allowed to have Web software and servers. Compound that with a policy that says every user is given a Web site that lasts forever and is never updated.
These problems should be dealt with by policy and process.
Implementation of process is tricky, of course, because as is often the case, human failure can be the source of the problem. Still, a good password policy and removal of user accounts as goals are crucial components. Third-party Web-based software is also a problem, and measures including checking the software in various ways need to be part of the process.
Operations Challenges
The emphasis in most IT organizations is to do whatever it takes to return to operations. In the case of botnet infestations, this is a losing proposition. Without knowing the attack vector and ensuring you have closed it, you will re-image the system only to have it get re-infected soon after it is back on the network. A/V vendors tag the files they find with names unique to that vendor. The naming convention has become increasingly a function tag rather than a unique name. More importantly, the A/V product treats all the files associated with the found file the same. That is, if the executable is deleted, all the associated configuration files are also deleted. In our most recent botnet infestation, we identified the vast majority of the botnet clients by mining the infected clients for information. Our clearest picture of the architecture of this botnet came from the detail found in the malware’s ini and text files. We’re suggesting that A/V tools could provide a tremendous intelligence value to enterprise security if they would collect the intel in these files and report them to the information security organization. Gathering and analyzing the security event, firewall, and anti-virus logs told us who was attacking the infected client before it joined the botnet and where the payload might be hidden. The firewall log also told us which computers connected directly to this workstation. In most organizations, it is rare for workstations to connect to one another—workstation to server, yes, but workstation to workstation not very often. Note that none of this intelligence is possible unless operations permit you to collect this small set of forensic data before scanning or re-imaging.
One could probably stop here and argue as to whether the cup is half full or half empty. Half full because any security professional can come up with techniques for fixing the aforementioned problems (turn on updates, use better authentication techniques, check the crufty PHP software with web-checkers (check out nikto, which is open source at www.cirt.net/code/nikto.shtml). From the half-empty point of view, we can despair of ordinary users. Can we ever educate them? That is a very good question. Perhaps the vendors could help, and instead of pitting security versus usability, help make security more useable. The bottom line, though, for botnets is that a lot of the exploits are used over and over again. If you saw an attack against X yesterday and it worked, why should they bother to develop a new attack? We may have hard engineering problems, but we feel that security engineering in terms of process and policy are a key answer to the problem. We strongly suspect that simple policy measures can pay off.
What Is to Be Done?
We mentioned before that known practices apply. Security professionals and network engineers need to do what needs to be done to make their networks more secure. Management needs to support this effort with training, time, and cash. Business, Academia, and IT professionals need to communicate about these problems and look for approaches that deal with the problem, not just “market share.” In this section, we briefly mention some rules that should be obvious but perhaps are not. We also talk a bit about how to more aggressively pursue the botnets and botnet herders.
Effective Practices
So, what are some effective practices? There are so many ideas in the previous chapters that we don’t have the room to list them all. However, we do want to briefly list some ideas we think are fundamental.
Practices for Individual Computer Users
Here are several effective practices for individual computer users to consider.
If it’s spam, delete it and don’t respond to it. Don’t buy their product. If no one bought products from spam, there would be no spam problem.
With e-mail or Web surfing, be careful. You should not execute unknown e-mail attachments, because you may be installing malware on your box. Think before you download. If a confinement mechanism exists for doing a download, use it. It seems like it would be a wonderful idea to have virtual machines for download and test-installation of programs, and then be able to throw out the virtual machine if it goes south. Think of the problems your Mom could avoid if her e-mail product only executed attachments in a virtual machine instead of on the real-world computer.
Many exploits in recent times have been aimed at Internet Explorer. If you use IE, be careful with it. You should strongly consider installing another browser and using it (Firefox). Outlook is also on the short list of programs that have been infected far too many times. Consider using another e-mail client (note that you can use a Web browser as an e-mail client with some ISPs). Alternatively, use Thunderbird at www.mozilla.com/en-US/thunderbird/.
Be careful about downloading and executing programs from the Web. Another case where virtual systems would be useful if they could be easy to use. Perhaps the download option of the Web browser could offer it as an option “Open Virtual” instead of just Open or Save.
Make sure your system has auto-updates on. You have to stay patched. This applies to Microsoft in particular.
Ensure local accounts, particularly those with administrator privileges, have strong passwords.
Install a host firewall. Windows XP has one, so use it even if you do not intend to manage the ruleset. The firewall log provides valuable information for botnet detection and analysis. If you are in an enterprise setting, the Windows firewall can be turned on by group policy. If you are an individual, the firewall can be turned on in the Control Panel |Windows Firewall menu item. On the General tab, click the On option button. In addition, click on the Advanced tab. In the section labeled Security Logging, click on Settings. On the Log Settings page, check the boxes Log dropped packets and Log successful connections.
Zone alarm has a nifty product (with a free version) that alerts you in an active way if programs on your Windows host try to contact the network or the network tries to contact you. Enterprise firewalls are necessary, but in the modern mobile world, you may be at a coffee shop and your organization might not have configured your laptop so that all outbound traffic travels via VPN to the enterprise firewall before going to the Internet. Thus, without a host firewall there would be nothing between you and the Internet. Or, you might be at the office and the host “next to you” on the same IP subnet is sick and decides to attack you. Every ordinary operating system has a firewall capability at this point. People need to learn to use them.
Ensure that your security log is on and that it records both Successful and Unsuccessful login attempts. In your local security policy, under Audit Policies, ensure that the Security Setting for the following policies is set to Success, Failure:
This, coupled with the Internet firewall logs and network monitoring logs, will permit you or investigators to determine where attacks came from, which other machines might be part of the botnet, and which accounts have been compromised. If you are in an enterprise or organization, consider software that will centrally collect and protect the local event logs from your workstations. This would enable monitoring of brute force and password-guessing attacks in near real time.
Run a virus checker, especially on Windows. Your virus checker needs to be patched. We have nothing against commercial vendors, but free virus checkers do exist (here’s a hint: search Google for “free virus checker”). There is no reason to run unprotected.
Virus checkers may not do a good job checking for so-called spyware or adware. Adware checkers exist, too. Use one.
Rename the Administrator account and disable the Guest account. Every password-guessing tool in the hacker inventory knows about these accounts and tries to break them. Don’t use account names like Track_Cash or others that beg to be owned.
Enterprise Practices
Here are some effective practices for users in enterprise environments to consider.
Use an intrusion detection system (IDS), as you need something watching your network. As two examples, ourmon as an anomaly detection system watches for attacks that have unfortunately succeeded. Snort watches for known attacks that will be repeated. Ourmon and snort are complementary.
Any organization that does not have a firewall today is asking to be tagged with negligence damages related to many information technology losses. They are in the same position that the tugboat operator was in when the principle of “due care” was introduced. Firewalls of all shapes, sizes, and performance capabilities exist, and most organizations have them in place. Attack logs can be useful as long as they are reviewed and analyzed. A firewall is better if it denies everything and only allows exactly what you need. However, in the days of mobile systems and VPNs, firewalls are less perfect than ever. Network access to files, printers, and network instrumentation gear (and SQL servers) should be minimized.
Network-based monitoring systems such as Ourmon, cricket, and netflow provide graphical or log-based histories of what happened on your network. These can be invaluable for forensic examination of network attacks.
For outbound spam, block port 25 access to the Internet for hosts using dynamic IP. Hosts that show up in the logs trying to get out to the Internet on port 25 are candidates for “bothood.” Open mail relays are not the problem they once were, but open proxy “Web” servers are a real possibility.
Monitor suspicious sources of e-mail (you should know and closely control e-mail servers in the enterprise). Use an application or service.
If you have a mail server, it should have some way to check e-mail for viruses. We hope this point is obvious, but it needs repeating. Open source virus checkers exist (for example, see www.clamav.net).
Layer 2 measures can help minimize internal post-exploit fan-out. For example, Cisco’s recent switch mechanisms (port security) for detecting DHCP, IP address, and ARP spoofing can all help.
Work with networking managers, sys admins, and facilities management to ensure the infrastructure (maps of building and data jack locations, data jack to switch mappings, DHCP historical logs, Mac to IP address mappings, and IP address to NetBIOS names) will permit you to track down the physical locations of botnet clients
Require that all remote authorized users’ access to internal systems be via encrypted VPNs.
Develop and use a network quarantine for use whenever a botnet client is detected.
Work with operations to ensure security is permitted time to gather intelligence from victims’ computers before they are re-imaged and returned to service.
Security policy and process is crucial. This applies in particular to user account management (minimize privilege), password policy (use them, the stronger the authentication the better), and installation of third-party network accessible software (check it and isolate it, insist on a responsible party for any instances of it).
Ensure that your OS and A/V are updated in a timely manner. Don’t just run the patch job. Run reports after every update to determine which systems have and have not been updated. Determine why they didn’t update and find a way to reach all systems.
So, given that set of guidelines aimed at local sanity, what else might we do?
How Might We Respond to Botnets?
Obviously, one very basic response to botnets is to stomp out the malware. Consider these suggestions:
Clean up any infected hosts, whether they are clients or server. Be prepared to re-image or reinstall from scratch, as some sorts of malware are very complicated these days. Trying to remove a bit here and there is not likely to work. It can be very hard to find all the parts of a rootkit. Of course, this situation may be made more complex if you have any thoughts of working with law enforcement and you need to worry about preserving evidence. You can at least replace the user’s drive with a new shiny, up-to-date pile of software and cart the infected drive off for forensic analysis. At some point, you need to get the infected system off the air, so it doesn’t infect others.
Consider monitoring the infected host to see who else talks to it. See Chapter 5 for mention of sniffers. You should analyze the local firewall and network monitoring historical data for this same data. You should analyze the local security event logs to see who attacked this computer prior to its assimilation. Submitting malware found during the quick forensics process to a malware analysis sandbox can identify the initial C&C server, channel names, and passwords.
Contact other network domains to tell them about the remote contacts discovered in the monitoring phase or analysis phase. Join the industry intelligence sharing groups for your industry, like REN-ISAC for higher education. See the ISAC Council at www.isaccouncil.org. Consider other organizations like www.shadowserver.org for botnets, www.castlecops.com/PIRT for phishing, and mailing lists like Gadi Evron’s Botnet Digest (www.whitestar.linuxbox.org/mailman/listinfo/botnets).
It’s a good idea to watch an infected host with a sniffer of some sort, as you may see that a remote controller is talking to more than one host. Given constraints on time, this may be all an IT organization is able to do. In Chapter 5, we talked about abuse e-mail lists and ways to find out whom to contact for attacks from remote network domains. Politely ask the remote party to stop scanning you, sending spam your way, or inform them that they have a botnet C&C on their premises. This may be an act of compassion for some poor user (or 100,000 poor users) you have never met, as now his or her box might get cleaned up and further acts of identity theft might be prevented. This act may be useful or useless. However, it is worth a shot, as communication channels need to be part of the overall solution to the botnet problem.
Taken together, the previous set of measures might be regarded as fundamental, but that raises an interesting question. What else might we do? In the remainder of this section, we are going to talk about a few other things you could try that are more proactive and may not be for everyone. If you have time and possibly security credentials, you can consider getting involved by communicating and working with others about botnets. You can consider setting up your own darknet or honeynets, or feeding any captured malware to a sandbox system as described in Chapter 10. You might also contact law enforcement. Certainly, there are difficulties with the latter approach. However, sometimes hackers do go to jail, and if they were all in jail, we might not have such a problem.
Reporting Botnets
A public channel for reporting botnets is located at [email protected]. The e-mail address is managed by Gadi Evron, a former information security manager for the Israel CERT, now with Beyond Security. Gadi distributes a monthly command and control report listing the top 20 ASNs by total suspect domains mapping to a host in the ASN, and the top 20 ASNs by number of active suspect command and controls (see the sidebar, Notes from the Underground).
Evron also runs a mailing list for people who are interested in discussions about botnets, located at www.whitestar.linuxbox.org/mailman/listinfo/botnets.
If you joined or participate in one of the organizations mentioned earlier that track botnets or other forms of intrusion detection, you should be a good netizen and report the events from your organization to them. Dshield at dshield.org takes firewall log data from the Internet at large and is a useful Web site to visit for many reasons, including information about what is going on planet-wide in malware. REN-ISAC is a security group for universities that focuses on collecting and disseminating information about security incidents including botnets, and other forms of malware. It is a closed group, but you might consider joining it if you are the security officer for a university, teaching hospital, or government research organization. They can be found at www.ren-isac.net. Check out www.isaccouncil.org for ISACs that cover other industries or interest groups.
Botnet Command and Control Servers Report
A report of botnet C&Cs (however defined) as counted in various network routing domains (Autonomous Systems) is available at www.isotf.org. The report is also published publicly on the North American Network Operators Group, located at www.merit.edu/mail.archives/nanog/. The report ranks ISP routing domains in various ways, including active C&Cs and C&Cs taken down. The report is sorted various ways. The version here is sorted according to the ASN with the most active C&Cs and is dated 30 Dec 2006.
Top 20 ASNs by number of active suspect C&Cs:
ASN Responsible Party Total Open Resolved
13301 UNITEDCOLO-AS Autonomous System of 107 27 75
174 Cogent Communications 30 25 17
19318 NJIIX-AS-1 - NEW JERSEY INTERN 132 25 81
25761 STAMIN-2 Staminus Communications 31 18 42
30058 FDCSE FDCservers.net LLC 51 15 71
29737 WideOpenWest LLC 14 7 50
7132 SBC Internet Services 33 6 82
1781 KAIST-DAEJEON-AS-KR Korea Advanced 9 6 33
21050 FAST-TELCO kw.fast-telco Autnomous 11 6 45
13213 UK2NET-AS UK-2 Ltd Autonomous Syste 32 6 81
Fighting Back
No chapter on responses to botnets would be complete without a mention of Blue Security and Blue Frog.
WARNINGIf you decide to actively pursue a botnet, be aware that you might get hit with a tremendous DDoS attack.
The Saga of Blue Security
Blue Security, an anti-spam vendor, developed a unique response to spam. The company offered a subscription service for a Do Not Intrude Registry service. Users would subscribe to the service. Then, when a user received spam, the Blue Frog agent would search the spam Web site to find the opt out form and submit one opt out form (Figure 12.1) for every e-mail received. All of these actions are legal and above board, despite a disinformation campaign to characterize the Blue Frog response as spam.
The campaign appeared to be designed to disarm those who would come to Blue Security’s defense. In April 2006, five major spam groups agreed to stop spamming Blue Frog’s customers. The Blue Frog approach must have been working, for it evoked a deadly response from the spammers.
According to a post on castle.com by tembow, a member of the Blue Security profile, the following was the spammers’ attack plan.
1. Gain access to over 70% of the Do Not Intrude Register (DNIR).
2. Mount a massive 20-fold spam attack increase on Blue Security members.
3. Shut down the Blue Security primary site with a massive DDoS.
4. Shut down all the other Blue Security sites the same way.
5. Subvert the Blue Frog application itself and make it launch spam and DDoS attacks.
Several sources speculate that the spammers were able to determine the contents of the Blue Security DNIR database by using the filtering software provided by Blue Security to produce a list of the e-mail addresses that were permitted by the filter. They then compared the pre-filtered list. Anyone not on both lists had to be a Blue Security customer. The spammers then carried out step 2 by sending the spam e-mail you find in the sidebar “E-Mail Sent to Blue Security Customers.” The following transcript contains conversations of the spammers discussing the database and how they would use it.
The transcript is archived at http://slashdot.org/comments.pl?sid=184656&threshold=1&commentsort=0&mode=thread&cid=15249882. The quote is reported to come from the postings of the alleged planners of the Blue Frog attacks on www.specialham.com.
“You BlueFrog faggots, you think this is the only community that has your whole database? You honestly think a community of people you are trying to take down are going to REMOVE you from their lists? Look, killthem is not an anti, I know him personally, so let that whole bullsh*t idea go to rest. Second, by running that database as froms or mailing them on a dedicated box will not result in any “fed” coming to your door, more so you’ll just be p****ng off another bullshit internet-lamer who can’t understand how to filter a simple spam message, so they join some bullshit community called “BlueFrog” and think they can run this sh*t. BF, newsflash: do you realize how many resources this community as a whole controls? Do you honestly think you stand a chance? Your domain is down, it’s a matter of time before more nets are mounted to bring down your members area and it’ll be held down continuously until BF userbase has gotten to the point they can’t perform their equally illegal DDoS attacks. Guys, download the DB, spam it, compile your lists with it and trade it around. Use them as froms, mail your anti DB with them, do whatever you want. Let this database leak to the point all these stupid a** f**ks have to get new e-mail addresses. Adios bluefreaks”
E-mail Sent to Blue Frog Customers
Name Removed Mon, May 1, 2006 at 5:30 PM
Hey, You are receieving this email because you are a member of BlueSecurity (http://www.bluesecurity.com). You signed up because you were expecting to recieve a lesser amount of spam, unfortunately, due to the tactics used by BlueSecurity, you will end up recieving this message, or other nonsensical spams 20–40 times more than you would normally.
Simple, in 48 hours, and every 48 hours thereafter, we will run our current list of BlueSecurity subscribers through BlueSecurity’s database, if you arent there.. you won’t get this again.
We have devised a method to retrieve your address from their database, so by signing up and remaining a BlueSecurity user not only are you opening yourself up for this, you are also potentially verifying your email address through them to even more spammers, and will end up getting up even more spam as an end-result.
By signing up for bluesecurity, you are doing the exact opposite of what you want, so delete your account, and you will stop recieving this.
Its simple, we dont want to, but BlueSecurity is forcing us. We would much rather not waste our resources and send you these useless mails.
It’s simple, we dont want to, but BlueSecurity is forcing us. We would much rather not waste our resources and send you these useless mails, but do not believe for one second that we will stop this tirade of emails if you choose to stay with BlueSecurity.
Just remember one thing when you read this, we didnt do this to you, BlueSecurity did.
If BlueSecurity decides to play fair, we will do the same.
Just remove yourself from BlueSecurity, and make it easier on you.
I think maybe he was saying “Let me the hell out of here!” When he let the coverlet fall into a smoking heap at the baseboard, there was a big smoking bald spot in the middle of the wall, but the paper was out. “Colter,” he said. What would she think, he wondered, of that man as he looked now, forty pounds lighter and ten years older, his legs a pair of crooked useless horrors?.
On May 2, the spammers began a DDoS attack on the main Blue Security Web site. During the course of the attack, the spammers would take out Blue Security’s Web site. When Blue Security re-directed the traffic for its main Web page to its blog server to make the Blue Frog service available to its customers again, the blog server was not able to handle the load either. Only when it went down it took all of Six Part, the blog serving company, including high-profile customers Live Journal and Typepad. At that point, their domain name service provider, Tucows, fired them, revealing yet another hole on the good guy’s side. Blue Security then worked with Prolexic Technologies, a company known as a specialist in DDoS protection. Prolexic was bombarded by defamatory spam e-mails about Prolexic, multi-gigabit DDoS attacks, and mail bombs. They were taken down for eight hours when the attack shifted to their DNS provider. When the spammers began targeting the paying customers of Blue Security with intense spam, the people who turned to Blue Security—that is, had paid Blue Security for protection—suddenly found themselves a target because of that action. On May 16, Blue Security closed its doors.
The Register of Known Spam Operations (ROKSO, www.spamhaus.org/rokso/index.lasso), operated by The Spamhaus Project (www.spamhaus.org/index.lasso), believes the planners of the attacks are:
Leo Kuvayev (AKA BadCow), speculated to be Pharmamaster, the spammer who DDoS’ed Blue Frog. Kuvayev made the news in May 2005, being prosecuted by the state of Massachusetts to the tune of $37M and the forced closure of dozens of Web sites. The state suspects that he fled to Russia where there were no laws against spamming. A law was passed in 2006, but is believed to be ineffective.
Christopher J. Brown / Swank AKA Dollar
Joshua Burch (AKA “zMACk,” “pitboss,” and maybe “Digihax,” “Nathan Allen” & “Gene Heu”)
Alex Blood / Alexander Mosh / AlekseyB / Alex Polyakov—Some believe he could be Pharmamaster. Alex Polyakov is a Russian spy in John LeCarre’s spy novel, Tinker, Tailor, Soldier, Spy.
An open source project called Black Frog (www.okopipi.org/) hopes to continue to work on the concept.
Some Observations about the Blue Frog Affair
This incident closely resembles the gang warfare of the 1920s, 1950s, and 1960s. Perhaps we should look at how communities reclaimed their neighborhoods for ideas. It also resembles the Wild West when people entered an area devoid of the infrastructures of civilization. The good news is that in each of these cases, time eventually brought an end to the conditions that permitted this immoral behavior to prevail. In each case, a few brave souls stood their ground and said, “this has got to change.” And it did. Blue Frog was effective at what it did. Six of the world’s top 10 spammers had agreed to use their filtering. This was an incredible feat. What brought Blue Security down was the lack of infrastructure to protect our DNS services, the lack of an ability to respond to this kind of law enforcement challenge, the lack of effective laws in all countries covering this problem, and the lack of any requirements for DNS and ISPs to support their customers in these situations. That and the fact that Blue Security never envisioned that someone would be able to figure out who its customers were and go after them.
Graham Cluley, a Sophos senior technology consultant, made this observation in a Technology News article (Blue Security Shutters After Brutal Spam Attack, by Keith Regan 5/18/06) after the Blue Frog fiasco. “This is truly an international problem now, and that means old-fashioned law enforcement efforts aren’t going to get the job done. It’s going to take a combination of technology, law enforcement, and cultural shifts from users to make a difference.” This change won’t happen by accident, and it won’t happen without the right people meeting to plan it and make it happen.
Later in the spammer’s transcript, one of the spammers known as ebulker says, “Let’s work as a team destroying their business and protect our interests together!” That’s some advice we should be following.
Law Enforcement
If you choose, you can report a botnet to either the FBI or the Secret Service. Reporting a botnet to the IC3 (www.IC3.gov) lets the IC3 determine the agency with jurisdiction, but does not give you the option of following progress on the case. If you need to be able to report the outcome, they will need to report it to the FBI or the Secret Service. The Secret Service is usually responsible for cases involving credit cards and some other financial crimes. The FTC can also be involved in cases of phishing or identity theft.
Use law enforcement to identify and track the botherder for prosecution or civil suits. You can ask your prosecuting attorney’s office to issue a subpoena to obtain customer information or connection information. Sometimes, an ISP will require a court order for connection information. To gain access to content, it is usually necessary for law enforcement to obtain a warrant for search or seizure of any local infected host. Onsite, the target host should be disconnected from the network. Image the host’s hard drive using tools capable of making a forensically sound image. Ask the system administrators to assist in obtaining information about the following:
The botnet channel and its moderator (identity information; when the user account, if there is one, was created). Note that IRC does not require the user to have an account on the system.
Other channels the botherder moderated or used.
When the channel(s) were created.
Whether the botherder connects locally or remotely, and if remotely, using which IP addresses.
Any useful system logs or other file traces associated with the attack.
You may need to repeat this process for systems the botherder used to access your system. You should try to confirm that the system had no Remote Access Trojan (RAT) through which the botherder could have entered. The ISP for this system may have valuable logs about the activities of the botherder that can alert you that this next system may be the actual botherder’s system.
The law enforcement and judicial system interface is another place for improvements. With spam in the millions and botnets of multi-thousand computers spread across the globe, the current process of having to speak to and gain permission from a person in the court system is no longer viable. A means of electronic submission and approval of these kinds of requests is needed.
Darknets, Honeynets, and Botnet Subversion
Darknets, honeynets, and the like, including tools like sandboxes (Chapter 11), are an important and valuable resource for fighting botnets. Many researchers and white-hat crime fighters are using them to learn more about botnets and eliminate them when possible. Darknets and honeynets run by various entities provide valuable information about how botnets work both from the host and network point of view. For instance, Shadowserver (www.shadowserver.org/) is an all-volunteer group that tracks and reports on botnets and other malware. Much of their information comes from such tools, and their Web site explicitly promotes a tool called Nepenthes for collection of malware (see http://nepenthes.mwcollect.org). Shadowserver’s Web site also has some great statistics on botnets. Another Web site and group of interest is the Cymru group (www.cymru.com), which has information about how to set up a darknet.
Setting up a darknet or honeynet isn’t for everyone, as you might not have the time or resources required. However, if you do, you should consider joining one or more crime-fighting groups and then report on information learned about local attacks.
One can note that some consider more “interesting” techniques that might include trying to actively subvert the botnet itself in some way. Perhaps you might log in to an IRC botnet server and issue commands to release the botnet clients, or perhaps actively try to take over the C&C and somehow shut the botnet system down. We aren’t going to recommend such practices, as they may be harmful to your network’s health.
Even though we do not recommend such practices (at least for novices), one highly intriguing idea comes from Kapil Kumar Singh of Georgia Institute of Technology. Kapil recommends using a Karstnet (Figure 12.2). The Karstnet approach leverages the fact that most bot clients can find the bot server (step 1 in Figure 12.2), because the server is set up using Dynamic DNS. In step 2, with the cooperation of a dynamic DNS provider, you can have the provider redirect the DNS entries to somewhere other than the bot server. In effect, this is a man-in-the-middle attack on the botnet herder. This entry will cause (step 3) botnet clients to send all bot client communication attempts to the fake C&C. At the fake C&C, various choices can be made, including simply studying the traffic as it passes by, or blocking the traffic to make the botnet itself ineffective. If something like this is attempted, it is probably a good idea to block any local botnet clients from talking to something other than the fake C&C, as they may have backdoor channels you did not know about beforehand. Another simple option is to simply remove the DNS entries altogether. In step 4, the botnet herder says a bad word. The Dynamic DNS provider should be prepared for a DDoS attack, if the botherder has more divisions of zombies to do his bidding. You can find more detail on the Karstnet approach at www.cc.gatech.edu/classes/AY2006/cs6262_spring/botnets.ppt.
A Call to Arms
So, let’s look in the crystal ball and predict the future. It’s not hard. Botnets represent a leading edge of computer crime in both technological and profit terms. Botnets will evolve to some extent because people will find holes in complex software systems, and some botnet herders will use different control mechanisms. They may use strong encryption. They may use P2P for command and control, or still use IRC because working software is useful and human beings are often averse to change, even hackers. Turing proved that holes are unavoidable, and common sense tells us that software systems tend to complexity. It doesn’t matter if you blame it on Microsoft or Linux; normal folks rarely buy a computer with less memory. The bottom line here is that botnets will get more complicated. And in response, vendors will create more complex systems for detecting malware, be it network gear like intrusion detection systems or anti-virus software, or “honeynets in a box.” So, botnets will change their stripes. However, IT professionals will analyze what the black-hats do and invent new countermeasures.
The following list includes general categories of concepts or things that could affect the existence and proliferation of botnets. The categories listed are a generalization of a taxonomy of phishing solutions developed by the Financial Services Technology Consortium. The original categories can be found in Appendix A and are used with the permission of the Financial Services Technology Consortium (FSTC). These categories were taken from Appendix B of “FSTC Counter Phishing Solutions Survey Summary,” published by FSTC on December 4, 2004.
Summary
We’ve covered a number of the preceding categories in this book, but not all. To successfully attack the problem of botnets, we need to have smart people breaking this problem in to manageable pieces. The preceding outline can begin to guide our efforts to apply resources to many aspects of this scourge.
It is hard to decide where to begin. There are so many opportunities to chose from that will make a difference in your organization. The important thing is that each of us picks something and begins. Most importantly, communicate with others about what is going on at your site. Tell each other about what works and what doesn’t in terms of processes and tools. If you have time and skill, get involved in the wider fight. Consider reporting your problems or discoveries to various relevant sites like dshield.org, the shadowserver site, the botnet digest, or one of the ISACs we mentioned previously.
There is that famous alleged old Chinese curse, “may you live in interesting times.” These are interesting times. On the other hand, there is an opportunity here for those concerned about the problem to find ways to band together. We think that this is a potentially very fruitful area simply because useful exchanges about botnets have had limited circulation in the past. There is hope there simply because books like this one may get people to work together to address these problems.
We sincerely believe that security and networking professionals of all walks need to band together and work harder (or smarter) to deal with the botnet threat Some of the techniques presented in this book (including, for example, the sandbox work in Chapter 10 or ourmon in Chapters 6 through 9 Chapter 6 Chapter 7 Chapter 8 Chapter 9) suggest new tools that can help. Basic security measures based on traditional rules like isolation and separation of privilege (and good password practice) will help, too. Serious consideration needs to be given to the problems of large-scale Windows administration in enterprises, and the problem of Windows on an end-user desk hooked up via a DSL connection. The single biggest gap in our ability to address the botnet threat is the lack of the ability to help the home user. When we described the efforts that are needed in the enterprise or institutional networks, they were wide reaching and complicated. Even our power users in this environment are not considered to have the tools and skills necessary to fight this issue alone. Yet, the home user—our moms and dads, grandmothers, and grandfathers, and small children—are essentially on their own in this battle. In our opinion, the ISPs serving the home market need to acknowledge that without a mandatory response by the ISPs, botherders will always have a new crop of easy victims. The mandatory response can be in the form of required compliance to new industry standards or compliance with new laws or regulations. As long as ISPs continue to believe that their only responsibility is to act as a pipeline, they will continue to stand idly by while our innocents are exposed to danger. Perhaps most important is that the white-hats need to get involved and communicate. Their management needs to encourage them to get involved.
Solutions Fast Track
Giving Up Is Not an Option
The despair over the loss of the “head of the snake” strategy was misplaced. Just as the loss of U.S. battleships in Pearl Harbor forced the U.S. Navy to move to a newer and in many ways better carrier-centric Navy, so too will the loss of the old botnet strategy force us to move to newer and better tools and techniques. Botnets may evolve, but so will our responses to them.?
Getting rid of a botserver C&C is a good thing, but damaged hosts still need to be repaired.
Many botnet clients are simply due to bad local security practices that can be easily remedied via education about good security policy and practice.
Why Do We Have This Problem?
Money is the root of all evil, and botnets. Who is fueling the demand for botnets? Find and eliminate the conditions that cause the demand, and botnets will diminish. Improve the security of ATM card encoding, and botnets won’t be nearly as lucrative a business proposition for cashers.
Phishing attacks based on social engineering via fake Web pages, and pharming attacks based on rewiring the DNS to send naïve users to new fake Web sites, are an important part of the botnet scene.
The complexity of software and distributed systems is a hard problem. This means it is easy for a hacker to find an exploit, and hard for defenders to defend against all possible exploits.
Fundamental security policies are often ignored. For example, passwords may be weak or nonexistent on highly privileged accounts. Many attacks include password guessing as one of the threat elements. Software that requires a user to have local admin privileges to operate, giving out local admin accounts to anyone who wants one, and using local admin accounts for day-to-day use increase the odds that a computer will become a botnet.
Many attacks are old and simply rely on the existence of unpatched (Windows) systems. Windows is not the only guilty party, though, as other systems can go unpatched as well.
Policies that allow anyone to create Web pages without any requirement for security, security standards compliance, or even security review threaten both Windows- and UNIX-based systems. Creating Web pages for all users, even if they never intend to use them, creates piles of treasure for the new phisher. The hosting platform of choice for phishers today is overwhelmingly UNIX-based systems running Apache.
What Is to Be Done?
Improve local security policy authentication practices to help prevent password-guessing attacks. This includes sane account management practices.
Use firewalls and other containment technologies (even NAT!) to limit the scope of attacks.
Windows systems need to be updated. All other systems need to be updated, too. Beware turning off auto updates. Remember from Microsoft Patch Tuesday to the first exploit is down to three days as of December 2006. Don’t forget to verify that all systems have accepted and installed the patches.
Every Windows host needs a virus checker and possibly a spyware or adware checker.
Every host should have a firewall. User host firewalls that can actively warn you about host network perimeter trespasses seem like a very good idea indeed.
Obviously, malware should be taken off the Net and cleaned up. However, you may want to first consider putting tcpview or a sniffer on it and learning if other local hosts are involved. You may also be able to learn about remote hosts that may be the botnet C&C. Send a copy of malware that is found on infected systems to one of the CWSandbox sites to learn what it does and who it talks to upon installation.
Send abuse e-mail about remote attacks. You may be doing some poor remote user a great favor (or you may be ignored).
Law enforcement may be invoked, especially if the incident is considered very serious for legal or financial reasons.
Darknets, honeynets, honeypot tools, and sandboxes are all useful for determining what is going on in botnet-land.
Shadowserver (www.shadowserver.org) is an all-volunteer group that tracks and reports on botnets and other malware. They recommend Nepenthes for collection of malware (see http://nepenthes.mwcollect.org).
Require all outbound mail to go through official mail servers to prevent botclients from spamming directly to the Internet.
Use networking equipment that supports port security to detect DHCP, IP address, and ARP spoofing.
Develop your sources of internal intelligence. Work with operations to ensure that you have the time to gather intelligence from infected machines before they are re-imaged and put back in service.
Plan the steps you will take if a botherder decides to target your company for retribution for all of the above actions. Remember the Blue Frog!
A Call to Arms
Fundamental security rules apply: focus on good security policy and process.
We need effective communication channels between all white-hat elements involved in this problem, including government, law enforcement, academics, and IT professionals.
Education for everyone in security is essential.
Try the new tools discussed in this chapter, find a new technique, join a new organization. It doesn’t matter which one. It is important to take that first step.
The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form.
Q: So, should we give up all hope and cower under the table?
A: No. Cowering under the table gets old, especially when you are hopeless. Sane security policies and practices need to be learned, thought about, and implemented. Expect to make mistakes, but be willing to learn from
Q: Are there any particular security practices or lack thereof you find disconcerting?
A: Yes, we think there needs to be at least a one order of magnitude increase in communication among security professionals. Different people know different parts of the problem, and in general, not enough information is shared on the subject. One very real problem is that organizations do not want to talk about security problems for reasons of fear of liability or simple embarrassment about looking stupid. We need more open communication and better ways for those who know what is happening to inform those who need to know what is happening.
Q: Doesn’t P2P mean the game is over?
A: Hardly. One need only pay attention to the ever-unfolding saga of P2P protocol development. On the one hand, we have youngsters trying to “share” media, and on the other, we have Hollywood trying to stop them from disseminating unlicensed IP of various forms. As a result, we may end up with P2P encrypted with AES and using port 80 to hide among the Web traffic (just like botnets). The problem is that you still have to have some way for the set of P2P hosts to rendezvous, and the rendezvous may always include an unwanted third party (read informer). This phenomenon is similar to the darknet/honeynet phenomenon. If you attack strangers, it may turn out that some strangers will invite you in, feed you, and note everything you do. From another point of view entirely, those who send spam and engage in DDoS attacks commit unnatural acts on the Internet. Various tools like netflow and ourmon can spot those attacks. Once we know a local box is infected, we can see who is talking to it, even if we can’t decode the traffic. Honeypots and the like mean that at some point the malware loses its encrypted communication channel. This offers the white-hats the ability to tap into the software and figure out what is going on. The game is not over.