CSE 484 Botnet Lab (lab 3)


You are highly encouraged to work in groups of up to 3 for this lab. You should form your group within the first week of this being assigned. Please use the grouper tool.


Curteously of http://en.wikipedia.org/wiki/Botnet

As an attacker compromises more and more computers, it becomes harder and harder to control all of them -- especially in some coordinated and purposeful manner. These compromised computers are called bots and the collection of them is called a botnet. Why do attackers run botnets? Some of them are used as part of spam campaigns in order to send spam; others are used as a weapon of DDOS (Distributed Denial Of Service) in order to take down a website for money or ideology, or even disable a country's critical communication infrastructure during times of conflict. If you're interested, consider reading about the economics of botnets for spam here: Spamalytics

Your job will consist of performing all of the necessary steps in order to create and operate a secure and successful botnet. You will then write a report discussing how you did this, what design decisions you made, and how secure your design is against different kinds of attacks. This process will give you deeper insights into pragmatic computer security and give you the chance to design and implement a cryptographically secure system, work with common crypto APIs, and understand how botnets operate.

The process of creating a botnet consists of 2 distinct parts:

  1. Finding and exploiting some program on the target hosts and installing your control program -- the bot -- onto the hosts.
  2. Creating a CC (Command and Control) structure to control the hosts.
We'll discuss both of these parts in detail below.

1. Compromising a Host

Often, hosts get compromised by visiting a malicious site that uses an exploit against the user's browser to install and run malicious code. This is indeed what you'll be doing.

Given the trend towards new and beefier browsers, we have decided to start anew with a slim and faster browser -- we're sure that this will finally make us money. We've written a program (similar to wget) called cgethttp. cgethttp simply fetches HTML from any URL and prints it to the screen. Your job will be to (1) find a vulnerability in cgethttp and 2) create a webpage that, when visited by cgethttp, will download and install your malicious bot onto the client machine. You will be given a virtual machine (similar to the one you used for lab1) with cgethttp installed in /root/. Get the VM here: box-lab3.tar.gz.

A botnet usually involves more than one bot! You should test your botnet with at least two bots. Because each VM is fairly large, we've set up course space here: /projects/instr/10wi/cse484. Make sure to correctly set up the folder permissions. We can create unix groups for your team upon request. We ask that each team store no more than 2 VMs in course space (it's shared between all the courses). If it's possible for you to use your own machines to store the VMs, please do that in order to save space.

Remember the exploits you did for lab 1? Well, you'll get to use your knowledge of them here! For lab 1 you were given shellcode to execute; you altered the control flow of the target program so that it found and executed the shell code. For this project, you'll again alter the control flow and make it execute your own exploit code -- except now, instead of simply launching a shell, you'll make the compromised host download and execute your bot code (see further down for explanations of what your bot must do) from your web server.

You'll want the exploit code to be included as part of the HTML document that the vulnerable program downloads. If this all sounds confusing, don't worry, we'll walk through what you need to do in section. Meanwhile, you can start playing around with cgethttp and seeing if you can successfully hijack the control flow.

2. Command and Control Structure

Once a computer is successfully infected with a bot, it needs to communicate with the botmaster -- that's you! One of the classical ways to commands a botnet is through an IRC server. We've conveniently set one up for you on eve.cs.washington.edu. Wikepedia has some good background materials about IRC. In this structure, exploited clients connect to a prespecified channel on the IRC server, announce their presence, and wait for commands from the botmaster. The botmaster then issues commands to one, some, or all of the bots instructing them to perform some action.

You'll want to create your own random channel(s) for communicating with your bots. Make sure to make your room(s) secret -- /mode #channelName +s -- this will prevent others from seeing, visiting, and attacking your bot communications. Note, that as operators of the server, we can still snoop on your progress :) Please don't abuse or DOS the IRC server. Also, compromising other teams is not a part of this project.

We will leave the architecture of the Botnet largely up to you, but here are some requirements and helpful suggestions to get you started:

You will want to ensure that the communication between you and your bots is secure against most kinds of attacks. This means that an eavesdropper watching the network traffic between the infected machine and the IRC server should not be able to gain useful information or hijack your bots. For example, the communications to your bots should be encrypted, and an eavesdropper should not be able to learn the key being used. Furthermore if a single bot is compromised and an attacker somehow learns the private information stored with the bot (e.g. private keys), this should not help him or her gain additional information about the rest of the botnet. Be sure to discuss what design decisions you made and how they affect the security of your botnet in your written report. You may use Java's Cryptography APIs for your design. You should aim to make your bot as secure as possible, within reason. There are certain attacks, suck as Sybil attacks, that are not easy to defend against (and, in fact, are active subjects of research). We will discuss these types of attacks in more detail in class. However, for the purpose of this assignment, you should define your threat model, figure what you can and should defend against (and what you can't), and then build your bot to meet your threat model.

Your bots should support a set of commands to allow you - the botnet operator - to use your botnet. Below is a list of a minimum set of commands you must support. Feel free to be creative and add to this list if you think of other useful things that your bots can do; we reserve the right to give extra credit for useful, creative, and interesting new features.

Minimal Required features (besides secure communications):

We recommend that you do your development in Java. Here is skeleton code that demonstrates how to use the PircBot library to write a Java IRC bot. You can name your bot Anna if you want.

3. Written Report and Demo

Write a report that documents your botnet architecture, describes how it works, and justify the decisions you made from a security perspective. In your report, be sure to discuss your threat model, and then justify why your design and implementation meets that threat model. What attacks does your botnet prevent? What attacks is it still vulnerable to?

In your report you should also include a description of how the exploit in part 1 functions.

If you implemented any of the bells and whistles below, or any other features that were not required, be sure to describe them as well.

We will also schedule a time with your group outside of class for you to give us a 10 to 20 minute demo of your botnet. In your demo you will need to show off all of the required features as well as any bells and whistles you've implemented. Be prepared to answer questions about the design and security decisions you have made when building your implementation.

4. Bells and Whistles

There is no limit to extensions and improvements that you can make to your botnet. Below are some suggestions from us on what you can add to generally enhance your botnet and receive extra ctedit. Each of the following suggestions is rated in terms of "Bells" and "Whistles." A "Bell" is worth more than a "Whistle," and a "Monster Bell" is the equivalent of several "Bells."

Remember that in order for us to know and appreciate the extensions that you wrote you have to clearly document them in your writeup and in your code.

Camouflage Your Exploit - As part of your exploit, make it even harder for the user to detect, make CGETHTTP exit normally (not segfault) after running the exploit code.

Camouflage Your Bot - Make the bot run as a part of something that usually runs on the system, so that it is very difficult to detect and kill without killing a critical component.

Small Footprint - Try and make the executable loaded on the infected machine have as small a footprint as possible. This includes the size of the program, as well as its memory and CPU footprint. Document what improvement you've made, what steps you took to improve the footprint, and how much better this is over the naive implementation.

Create a Point-Of-Distribution - Point-of-distribution sites (ones that serve up the exploits) are, if there are few of them, easy to identify and shut down. Therefore, attackers actively and continuously search for vulnerable websites in order to host their malicious code. As an alternative, attackers often make comprimised bots become points-of-distribution. That means, the bot starts a web server and begins to host the attacker code. Have your bots do exactly this -- start a web server that hosts your exploit code. Note that your bots should now send spam with a link to the exploit code being hosted by its own server.

Proxy - Attackers like to hide behind proxies so that they're hard to find. Add in the ability to use your bots as proxies for generic traffic (HTTP, torrents, etc...).

Keylogging - Have your bot install a real keylogger that captures all keystrokes from the keyboard, as well as SSH sessions.

Code Obfuscation - To make reverse engineering of your code harder by security companies, use one of the public code obfuscation tools. Document in your report how it works and how it has made your code harder to reverse engineer. Provide specific examples if possible.

Load-Balanced Updating - Add functionality to your bots to securely update the bot code. However, do this in such a way that the nodes in the botnet do not fetch all the code simultaneously (otherwise it will give away the botnet's existance and will put a lot of load on your update server), and all at the same time. That is, create staggered updates that slowly roll through your botnet. For an extra bell, in order to further reduce server load and mask the botnet existance, make the nodes get update code from neighboring nodes in your botnet. In your report, document what it means for your update mechanism to be "secure". What is the threat model? What attacks does your secure software update mechanism protect against? How is it still vulnerable (if at all)?

Photo and Location Spying/Blackmail - add code to the exploit to install a script to check if the the compromised bot has a webcam. If it does, take pictures every-so-often (maybe every 15 minutes) and upload them to your server.

Fully Distributed Command & Control - As international and government organizations crack down on botnet operators it becomes more and more necessary to hide and distribute the command and control structure so that the botnet cannot be taken down by taking a single server offline. Implement a robust distributed command & control protocol that will tolerate multinode failure and obscure the origin of botnet control commands.

Hide with Steganography - Some nodes may be added to your botnet from network environments where the traffic may be monitored, eg from within companies or universities. To make sure that the compromised node is harder to dectect you may want to obscure the traffic being sent to and from the node by the botnet. Use steganography for this purpose.

Self Morphing - In order to make your bot harder to detect by anti-virus utilities, make your bot be self-mophing. That is, it should change in such a way that the hash of its code should be different after every run. For an extra bell, make the hash change every several minutes.

Detect Virtualization - In order to make your bot harder to analyze by anti-virus companies, detect if your bot is being run on a VM. If so, refuse to run.

Embedded Languages - Write your binary in an embedded language. This would make a potential reverse-engineer decipher your embedded language first. Talk to us if you plan to do this.

We reserve the right to add more bells and whistles spontaneously

5. Evaluation and Grading