Botnets

by Javantea aka. Joel R. Voss
Sept. 7, 2006
Slideshow format
Botnets Neg9 Hands-On Tutorial

Introduction

Botnets are groups of computers running malicious software that group together to achieve a common goal. Botnets are possible because of rampant security flaws in commonly used operating systems and programs. While software developers release patches, there isn't a perfect system of updating in place and there is evidence that there never will be. Lack of patching leaves programs open to exploitation. However, many exploits could be prevented by using simple security software (firewall, anti-virus) or by simple design of the operating system (no ports open). Some exploits, however, are in programs that are required for business (eg. web servers). I plan to discuss the methods and motivations for botnets and the methods for discovery and destruction of Botnets. I don't have perfect solutions, but I have some good ideas that can be put into use today to affect the number of botnets.

History of Botnets

Botnets are a quite recent addition to security literature. They have appeared mainly as a result of obvious security vulnerabilities. Most botnets are targeted at the Win32 OS because of the number of vulnerabilities [1] and the massive number of unpatched machines available (250,000-1.5M+ Sasser infections, 200M update downloads) [2]. However, botnets have targeted many platforms. The first Linux/Apache worm was quite recent (Dec 20  2004), targetting a vulnerability in phpBB which was caused by PHP. The worm used Perl, Google, and left an obvious trace [3]. Although it did not become a botnet, it easily could have. More recently I have detected a botnet gathering using the AWStats and Mambo vulnerabilities [4]. In response to increased patching and firewalls in remote services of Microsoft Windows, botnets have targetted IE6, which is often unpatched.

Methods of Botnets

Sasser is a good example of a recent botnet victim using push technology (service). Microsoft Windows has a service called LSASS running on port 445. This unnecessary service has many vulnerabilities, including one on Aug 10, 2006 of which the Department of Homeland Security (DHS) said "if exploited could enable an attacker to remotely take control of an affected system," [5]. Thank you Captain Obvious. On May 1, 2004, Sasser attacked a vulnerability in LSASS which resulted in massive infection (including myself) [6]. While Sasser is not generally accepted as a botnet because it did not do anything by itself, it did open shell and file transfer services, which qualify as botnet properties. Unpatched and unfirewalled Windows machines are easily exploited by worms.

Since botnets have massive computing power, the normal limits on intrusion do not apply: they can tcpdump poorly encrypted net traffic and crack the password. They can brute force SSH. They can brute force any commonly used password scheme that doesn't use secure techniques. These become more efficient attack vectors for botnets than for manual attacks even though manual attacks work also [7].

IE6 is a pull technology (client), which is quite different from push technology (server). In order to exploit a vulnerability in IE6, a botnet must gain control over HTTP servers. However, due to NAT or open firewalls, a client can become an HTTP server in many cases. Once a server is setup, links can be posted by bots to popular forums with titles like "Nude Celebrities" or "Pokemon" depending on the audience. Any person searching for such terms in the wrong places will find a spammed server with links to strange addresses. They can also use cross-site scripting (XSS) vulnerabilites in websites as well to attack their audiences. A recent talk at Defcon revealed that nearly all recent botnet victims are IE6 users [8].

Since we have at least a dozen examples of botnets, but not more, we can learn two things about the authors of botnets. First of all, by this time, they're thinking about your plans before you are. They have control over every angle. But since there are not more, we can assume that botnets are handwritten by extremely skilled hackers. By examining the code and the cases, we can note that they are usually young programmers who come from various poor or not poor backgrounds from developed or non-developed countries. This is a wide range of authors. It can be noted that any hacker with any motive can write a botnet and most can execute it successfully. Many people make note that the how to below is so easy that it could be successfully pulled off by a script kiddie, a person who only knows how to execute scripts and modify settings. Since most of the tools are available, but not all, at least some knowledge of security coding is required. Certain tools that qualify as botnets can be used and modified by script kiddies, but are not very sophisticated.

Now we can look at the general how to. First, start with a motive: profit, theft, power, curiosity, harm, or espionage. From this, design a payload: spam, keylogger, shell/ftp, hello world, delete files, search for files, encrypt files, and DDoS. Since you often have no limit on size, any number of payloads can be added. With shell/ftp, you can dynamically choose or upload a payload. Now, design a communication/control method: port binding, reverse shell, IRC, port knocking, etc. Now try to make this much more difficult for those other than yourself. This can involve Blowfish encryption, Diffie-Hellman, or anything. Diffie-Hellman works well for botnets because the traffic cannot be sniffed by a third party. Decentralized systems allow for amazing amounts of privacy by the botnet creator. Next, setup the vulnerability to exploit. Next, setup a virus delivery mechanism: reverse shell + uudecode, wget, stand-alone, etc. Next, setup a propagation system: random scan, e-mail, Google, websites, etc. When all this is developed, testing can begin on a small network. Once the botnet is successfully debugged, it can be shipped via Tor, a friend, wifi, an exploited box, or at random.

Since there's no reason that a virus can't be multi-platform, it is likely that botnet software in the near future will nmap a target, and try every exploit on every open port. Since the botnet is large in numbers and not actively attacked, it has no fear of giving away it's address to a target by way of logs.

Tracking Botnets

Tracking botnets is more than an academic exercise, but a business opportunity and fits into generic security practice. You may not have Dan K's network access, but any network access can spot attackers that are sufficiently broad in their attack vector. If the propagation system is a random scan, you will find botnets attacking by opening your ports and setting up a honeypot. I did this on May 1, 2004, during Sasser, so you can get an idea of what the traffic looks like [6]. I tested the LSASS exploit on my laptop and sure enough it worked. Sadly my desktop's motherboard died during Sasser, so I switched to using my laptop that was running Windows XP and got infected myself. My modem (MSN Arescom) DMZ'd the computer it was connected to, so instead of giving protection like a NAT router does, it opens the user up to worms. Remember that Sasser and LSASS exploit rebooted the target machine 60 seconds after disconnect. It took me 5 minutes to get infected and 5 hours to patch my laptop. These days, most modems are NAT and not DMZ, but many people still open up unnecessary ports to the outside world. Sadly, I didn't know how to use tcpdump at the time, so I was unable to capture Sasser traffic. I should have written a data capturing honeypot, but I was not able to.

The next way to track botnets is by running an actual server. In your server logs, you'll notice long strings. Some of those are Code Red, Nimda, and so on. More interesting are the quite new exploits based on AWStats and Mambo [4]. Note the simple system: exploit the vulnerability using an 0wned box, grab the payload from the 0wned box, execute the payload. From this, you can see not only what is going on in the botnet, but also who is infected. (This will be used later on).

The next way to track botnets is by looking at the output of a botnet. If we assume a profit motive, we can look at the various illegitimate profiters on the internet: Spam, DDoS, user-paid advertising, identity theft, and extortion are the most popular. If you have a mail account, you probably have spam. Do you delete your spam? You're throwing away data samples if you are. I have collected all my spam, tarred it, and designed methods of tracking the sender. [9] In the past I have told friends often that I didn't get enough spam. In 2004, I got 5 spams per day. I get 2314 per month now (I have to glimpse at/click on 607 of these), which is plenty although I'm interested in seeing other people's spam still. You should know why. Since legit mail servers track who sent the e-mail to them with the Received: header, I was able to write a simple Perl script to grab a list of spam servers. From this, I can check to see whether the spam server is an open relay, a proxy, a legitimate business, or an exploited machine. The question then becomes how do you tell a legit machine from an exploited machine? Exploited machines usually look strange, although they don't have to be. But sadly, spam servers look strange, too. So really a person can only guess looking at the raw data. There are advanced techniques, but I don't want to buy any software for something so braindead as that.

If you are the victim of a DDoS attack, send me your logs because I'd really like a list of IPs of these botnet bastards. You'll find out why later.

Honeypots that are actually infected with botnet software provides invaluable information. If the botnet is controlled via IRC and the bots are not using Tor to connect, they will allow you to get their IP from the server. They might be using an anonymizing IRC server, but more likely they will not. If the botnet command and control ever connects directly to the honeypot, it gives away its address. Friends have suggested infecting a virtual machine of unpatched Windows and capturing the data that occurs. This is an excellent honeypot and is quite cheap even though a Windows license is not free. A very low resource *nix honeypot could be created by using chroot jails, but the possibility of a smart virus breaking the chroot jail is fairly high. Obviously, actually getting 0wned is not the goal when tracking botnets.

Since Tor is an excellent resource for anonymous hacking (with caveat), I expect that analyzing traffic from a Tor end node would possibly give away the IPs of many malicious boxes. However, since filtering for known exploits and such is a privacy violation and could make you liable under CFAA or various other inane computer and telecom laws, I only suggest this for the most evil of botnet attackers.

Destroying Botnets

So now we move on to the discussion of destroying a botnet. Since destroying anything, legal or not, is prohibited by CFAA and a dozen other laws, I suggest only doing the analysis, utility writing, handwaving, and incentive-giving parts of this section. As far as I'm concerned, analysis and utility writing are completely benign white hat activities which ought to be done for the security of our networks. If you really must destroy a botnet, do it from wifi with your MAC address changed, through Tor so that it cannot be traced back to you. Even then you should be ready to fight criminal charges filed against you. It's only common fucking sense. ---No Warranty---

You compiled a list of suspect IPs in the previous chapter. Nmap this list to find out what type of computers, services, and such are running. If there is no response from ping, the box may be down or may have picked a new dynamic IP. This happens often in botnets. If you get obvious exploit ports open, record them. The next step is to attack the protocol. If the protocol is trivial (flat shell/ftp), you can just bash the hell out of it. Hackers have suggested that the Windows firewall can be turned on remotely. It might also be able to be patched remotely. Given root, nearly all boxes can be remotely administered to perfect health or perfect destruction, whichever is more appealing. Assuming a sophisticated botnet, there may be tools that exist already to exploit the protocol that the bots use. If there are no tools, you can reverse engineer the protocol either by using a honeypot or by elegant attacks.

A 4-hacker brainstorm on the way back from Defcon 14 provided the conclusion that a proper botnet could use a mesh configuration or a star configuration, strong authentication, obsfucation, and so on to avoid attacks. A non-communicating botnet could have all ports closed. However, for communicating botnets at some point, there must be a box with an open port. The virus could patch the holes and firewall the ports. This simply means that it is possible that a botnet could survive all attempts to destroy it. While this is sad, it is a fact that if we can lock down our boxes, so can anyone, even a botnet.

However, that is not yet the case. Most botnets are flawed and can be re-exploited by anyone who is interested enough.

Hands-on Tutorial? Yes.

Future of Botnets

As firewalls, program update utilities, and secure programming techniques advance, exploits could be dramatically reduced. This is to say that in the future, botnets will be extinct. In their place will be very specialized exploits on cutting edge software which are not in common use. For example, I could list 10 vulnerabilities in SOAP and only 5 were discussed in a Defcon 13 talk [10].

A respected security researcher said off the record that he felt that currently undeveloped countries will write insecure code and new exploits that will push botnets, viruses, exploits, and such well into the next decade. Other hackers are not so sure. While all parties agree that Russians are insane (in a joking manner), we disagree on whether we can protect against the threat. If Linux, BSD, OSX, or Vista are widely accepted and actually provide the security that they have developed, reactive security against malware may finally become a thing of the past.

Operating systems such as Linux, OpenBSD, NetBSD, and Mac OSX all use many obvious secure coding practices to reduce the number of possible remote vulnerabilites. The Linux 2.6.12 kernel added 8k of stack randomization. I have written a preliminary analysis of this and I have concluded that it will not deter any but the most limited attacks. However, the GR Security patch offers many preventitive security measures for the Linux kernel that are absolutely absurdly useful against exploits in vulnerable code. OpenBSD also has a kernel and admin systems designed to protect against vulnerable code being exploited. Windows XP has added a firewall to close the gaping holes in it's security, but it is extremely flawed. Currently vaporware, Windows Vista is planned to have Address Space Layout Randomization (ASLR) which will attempt to curb exploitation of vulnerable code [11].

Exploits that cannot be prevented are quantifiable: Web, mail, p2p, and other servers will continue to provide remote vulnerabilites, but can be improved with secure coding practices and vulnerability assessment. Custom web software will have file permission vulnerabilities, shell injection, SQL injection, weak passwords, and various other problems. Users can be tricked into running malicious software. Each of these can be improved, but never solved by education and improvements in software development methods.

Philosophy of Botnets

Finally, the why of botnets, botnet defense, and reactive security needs to be discussed. Obviously Microsoft who has a vested interest in blaming hackers will say that prosecution and updates is the solution to botnets. As I have discussed, prosecution and updates are both flawed. Better security practices and updates will eventually solve the problem. However, prosecution does not benefit anyone except the black hat who will get a high salary job.

Without black hats, we would still need security because we do not want _anyone_ to have control over our machines. The truth is that everyone is a black hat. To blame black hats for security problems is like blaming dancers at a disco that burns down. The lack of black hats makes software developers lazy on security. The truth to the matter is that only massive harm is a valid motivation for software developers to fix their software. This means that "criminals" are doing customers a valid service even by the very harm that they are doing to them. This point will never be accepted by mainstream software developers because they are by definition quite stubborn and resistant to logic that requires them to work for free (their bottom line is always more important than security).

Is there anything we can do at the current time to destroy botnets? Yes, develop the utilities described above to detect, analyze, and destroy botnets. Release these utilites with appropriate switches to allow a person to do anything. These utilities are as legit as the exploits released to attack vulnerabilities in legitimate code.

Works Cited

1) Ou, George. "Vulnerability statistics for Mac and Windows." URL: http://blogs.zdnet.com/Ou/?p=165 February 28, 2006
2) Sullivan, Bob. "'Sasser' infections begin to subside." URL: http://www.msnbc.msn.com/id/4890780 May 5, 2004
3) Voss, Joel R. "phpBB Vulnerability Analysis." URL: http://www.altsci.com/concepts/phpbb1.html Dec 20, 2004
4) Voss, Joel R. "AWStats and Mambo Vulnerability Analysis." URL: http://www.altsci.com/concepts/mambo1.html Jun 16, 2006
5) Department of Homeland Security. "DHS Recommends Security Patch to Protect Against a Vulnerability Found In Windows Operating Systems." URL: http://www.dhs.gov/dhspublic/display?content=5789 August 9, 2006
6) Voss, Joel R. "LSASS Vulnerability Analysis." URL: http://www.altsci.com/concepts/lsass1.html May 1, 2004
7) aorth @ mac.com. "Hacking the Hackers." URL: http://pancakebunny.org/dedicaticon/ December 17th, 2005
8) Wesson, Rick. "Abuse and the Global Infection Rate." Defcon 14. Aug 2006.
9) Voss, Joel R. "Spam Server Analysis." URL: http://www.altsci.com/concepts/spam1.html Jan 9-Aug 26, 2006
10) Stamos and Stender. "Attacking Web Services: The Next Generation of Vulnerable Apps." Defcon 13. July, 2005
11) Lemos, Robert. "Microsoft defends Vista by mixing up memory." URL: http://www.securityfocus.com/brief/222 2006-06-02

Permalink

Comments: 0

Leave a reply »

 
  • Leave a Reply
    Your gravatar
    Your Name