Computer Journal

Botnets

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.