Fighting spam and other botnet recruitment efforts requires constant vigilance. We might not be able to eliminate the bad guys, but we can certainly raise the level of effort necessary for them to use our networks for financial gain.
Active bots (a.k.a. zombies) continue to grow in number, even after the 4th quarter 2008 takedown of McColo, at the time the world’s largest botnet controller, at a rate of about 300,000 per day. This is according to a recent internet.com article by Richard Adhikari. He writes that the reason for the continued increase is the incremental improvements both in bot software and in bot recruitment methods. In this article, I focus on two ways bots are recruited, mounting a defense, and dealing with bots already working on your network.
Scanning through Adhikari’s article, I found two primary attack vectors described:
- Improvements in Pharming result in more successful recruitment.
- Recruiting email is still getting to users who still insist on clicking the included link.
Let’s take a look at what these mean to a business network administrator, what can be done to defend against having an organization’s desktops recruited for botnet duty, and how to detect bots which have slipped through our defenses.
Two popular pharming techniques
Pharming is the redirection of a Web site’s actual or intended traffic to a malicious site. Redirection is often accomplished in one of two ways: modification of host files or by taking advantage of weaknesses in DNS services.
The Hosts file is an old method of resolving domain names to IP addresses when DNS services are either not available or when slight adjustments to resolved addresses are required. The Hosts file, residing by default on every Microsoft Windows system, contains domain/IP address information which overrides DNS name resolution. So all an attacker has to do is drop a small script on a desktop, modify the Hosts file, and abracadabra, the user is thenceforth directed to one or more sites of the attacker’s choice. Let’s step through an example on a Windows XP SP2 system.
The hosts file is located in the same place on all current versions of Windows, shown in Figure 1. Hosts is a text file WITHOUT an extension. Adding an extension causes Windows to ignore the file on bootup.
Hosts ships with content designed to assist administrators, as shown in Figure 2. Note the entries are similar to host address resource records in DNS.
To demonstrate how this works, I chose to redirect my Web site name, adventuresinsecurity.com, to google.com. I started by pinging Google and entering the IP address returned into the hosts file along with my domain name, as shown in Figure 3.
After I saved the file (with no extension), I flushed the resolver cache by entering ipconfig /flushdns at a command prompt. This performed two tasks. First, it removed all cached name resolution records from my test machine. Second, it loaded the contents of the hosts file into the resolver cache. Since the resolver cache is checked before a Windows system sends a DNS query, adventuresinsecurity.com will always resolve to the Google IP address. (For detailed information on DNS and resolver cache operation, see DNS resource record integrity is still a big, big problem.)
To test, I closed and reloaded Microsoft IE7 and entered adventuresinsecurity.com in the address space. As you can see in Figure 4, I was directed to google.com instead of my Web site. If an attacker placed this entry, he or she would likely redirect me to a page which looked exactly like the actual site. Applications at the substitute site could then perform various tasks, including enlisting the redirected system into a botnet.
Default access to the Hosts file is read/execute for all users except local admin. As long as your users are not logging in and browsing the Web as local administrators, this type of attack will be troublesome for black hat hackers. But there is another way.
Black hats do not have to gain access to the local Hosts file to redirect users to malicious sites. Recent discoveries about DNS vulnerabilities make resolver cache poisoning at the server level a real possibility, especially if DNS service providers have not patched or properly configured their servers. Poisoned cache entries can potentially redirect all systems requesting name resolution to malicious servers. For more information about DNS security issues, see:
- An Illustrated Guide to the Kaminsky DNS Vulnerability
- DNS Cache Poisoning
- DNS resource record integrity is still a big, big problem
Name resolution redirection, in any form, is growing as an insidious method of attracting new recruits into spam botnets. Although outside the scope of this article, it’s important to understand that redirection also increases data and identity theft risk.
Spam growth and metamorphosis
Spam and pharming for bots feed each other. Bots send spam and many spam messages help recruit. And spam is on the rise as a percentage of the global message total. According to Adhikari’s article, the percentage of email messages identified as spam has grown from 72 percent in the fourth quarter of 2008 to 85 percent in January (about 150 billion messages), with no signs of slowing.
So much of this spam is intended to increase the size of botnets, which increases the amount of spam, which increases the size of botnets, ad infinitum.
Blocking all spam without blocking a sizable number of valid messages is not possible. In addition, spam filter vendors are always playing catch-up as spammers adapt to filtering technology. So organizations must allow some spam to get through, relying on user behavior—not clicking links in spam messages—to protect the network and sensitive data. Since relying on humans to do the right thing is never really good way to ensure security, security professionals must take additional steps to detect and eliminate bots and other bothersome malicious code which have already found they way into the enterprise.
Preventive measures are well known but often not implemented, including:
- DO NOT allow users to log in as local administrators. At the very least, limit their system access when accessing the Internet. (See Use DropMyRights to protect systems from admin users.)
- Filter Web site access. If you don’t have the budget to pay for this, OpenDNS is a great way to provide this function.
- Ensure your DNS services are patched and security configured. If you don’t host your own service, check for vulnerabilities with free services like the DNS Nameserver Spoofability Test. If vulnerabilities exist, work with your vendor to fix them. If necessary, switch to a service more attentive to your network’s security.
No matter what you do, bots will likely find their way onto your network. Two primary detection, intervention, and eradication methods can help rid you of them. The first is blocking spam coming from the bots and the infected machine’s ability to accept new commands from botnet HQ. Blocking outgoing spam is possible if the right monitoring systems are in place. Not only can an IPS device, for example, block the spam. It can also alert staff that a bot is in the house.
Second, extrusion/intrusion detection methods, also found on IPS devices, can detect or block bot attempts to connect to unrecognized or non-business related external servers.
Finally, and most obvious, is the implementation and daily management of an antivirus solution. I know, I know. This is getting a little old, but you’d be surprised by organizations that still "don’t get it."
The final word
Fighting spam and other botnet recruitment efforts requires constant vigilance and frequent adjustments to administrative and technical controls. We might not be able to eliminate the bad guys, but we can certainly raise the level of effort necessary for them to use our networks for financial gain.