Command and Control
Regardless of the fact that P2P technologies are starting to be used for communication between bots, it is still useful to understand how the less evolved bots function. The new P2P-enabled bots have the same functionality at their core, so the concept is the same.
A bot herder who controls a bot server (or multiple servers) has at his disposal a number of interesting tools. We briefly talked about what botnets are used for in the introduction to this series, but now let's take a more detailed look at the actual commands a server can send to bot clients.
Botnets have various capabilities, including denial of service attacks, spam relays, and theft of personal information. They even start Web servers on infected computers to aid in phishing attacks. Here's a brief list of a few of the more interesting things bots can be instructed do:
- Start flooding a specific IP or network using TCP, UDP, or ICMP
- Add/delete Windows services from the registry
- Test the Internet connection speed of the infected computer
- Start the following services: http proxy, TCP port redirector, and various socks proxies
- Run their own IRC server, becoming a master for other bots to connect to
- Capture or "harvest": CD Keys from the Windows registry, AOL traffic including passwords, and the entire Windows registry itself
- Scan and infect other computers on the local network
- Send spam
- Download and execute a file from a given FTP site
Moreover, if that was not horrific enough for you, consider the following: all of the IRC bots have modular capabilities. Therefore, if someone programs a new module to extend the bots' capabilities, the owner of the botnet simply runs a single command to install and use the new module on every bot.
Web Exploitation Kits
These kits allow the attacker to gain control of a client machine when it visits a malicious Web page. The most common avenue of attack is via browser vulnerabilities. The attacking code will instruct the Web browser to download and execute malicious code without the user even knowing. It isn't always a matter of "stupid user that clicked yes," which is why it is so important to install patches as soon as they are released.
It is extremely rare for attack code to be part of the initial exploit. Instead, it generally instructs the victim browser to download the exploit from another server. A malicious Web page doesn't generally host the exploit, probably because it'd be reported even more quickly. The server hosting the actual exploit is generally a Web server that was running some piece of PHP (or other) code that allowed someone to secretly upload whatever they wanted. This is caused by mistakes in server configuration, Web application programming errors, or sometimes just plain old security holes in the underlying technologies used.
Of course, attackers need to be able to keep track of which IPs they have compromised. MPack and IcePack are the two most popular kits available. They both provide the user with a Web interface and configuration options to set up a "downloader." The downloader is the program that gets run on exploited machines after an attack has succeeded. The downloader will fetch and execute malware from wherever it's configured to do so, and it can use encryption to avoid network-based detection.
These Web kits provide attackers with a neat Web page to view statistics about their attack progress. It provides information about how successful the attack is, as well as lists of already-compromised IP addresses. This excellent honeynet.org paper describes the process in more detail, but suffice it to say, this is extremely trivial stuff. Anyone who gets a hold of IcePack, for example, can quickly begin compromising their Web site visitors' computers. No skill, and no knowledge of the actual exploits is required.
Compromised Web servers, regardless of color or race, pose a great threat to overall Internet safety. Vulnerable applications exist on every type of Web server, and the underlying OS does nothing to prevent simple exploits from taking place.
Simple exploits, like inserting a little text into a site, used to be pretty innocent. Script kiddies, as they were called, would run other peoples' exploits and deface sites with obscene text or their groups' markings. Every once in a while they would try running some code to open a backdoor into a Unix server, which allowed them access as the user the Web server ran as. But now, with botnets and automated attacks, a simple exploit like this is pretty serious.
Web servers play a huge role in the initial infection, re-infection, and maintenance of botnets. Very often the "downloader" provided by the Web exploitation kits will be used to install bot client software. This is likely an extremely effective method of expanding a botnet, since network-based attacks can be blocked and are more likely to be patched.
Fixing all Web server holes won't stop users from getting infected by any means, but understanding the role of exploited Web servers in the malware ecosystem helps us learn how to fight it.