CSE 484 Botnet Lab (lab 3)

Groups

Background

Courtesy 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 C&C (Command and Control) structure to control the hosts.

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 VMware image (with an environment similar to the VM used in lab 1, except that you will be running the VM yourself) with cgethttp installed in /root/. Get the VM here: box-lab3.tar.gz. Note that the root password is root, and to bring up the network, run dhclient.

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/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, port 6667. Wikipedia 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):

• Initialize on startup - Your bot should start every time the machine is restarted.
• Remote root shell - Open a remote root terminal through IRC (for example as a direct chat) to any of the compromised machines. It should enable you type arbitrary commands into the terminal and see the server replies. Note that you should not worry about handling complex user interface interfaces (like curses or ncurses) which make visual modes of vi and emacs work.
• Patch the exploit code - After you take over a machine, you'd like to have exclusive control over it. Thus to prevent others from doing what you just did, you should patch the hole you used to get in.
• Templated Spam - Send spam email from a single machine or a set of machines you control to create spam email. You should be able to upload an e-mail template and a list of target e-mails or a specify that recipients should be random. Below is an example template (feel free to come up with something you think will get more clicks). Your template must be PG (not R rated).
  

  Hi XXX!
  
  I know we haven't talked in a while, and you might not even remember me, but I
  think I accidentally found this picture of you on-line.  It's pretty
  embarrassing, you should probably get it taken down.  
  
  Here is the link: YYY
  
  -ZZZ
  

  Your bot should fill XXX, YYY, and ZZZ in appropriately.
• DDoS - Repeatedly request a URL from a single machine or a set of machines you control to mount Distributed Denial of Service (DDoS) attacks. You should be able to specify how often and for how long the bot requests the given URL (for example: request the URL every second for 15 minutes). Try to minimize the non-network resources of the bot (CPU and RAM) used -- you should not fire up Firefox every time you request a URL (or the user might notice and wipe his system clean... or just throw the computer against a wall).
• Leasing - Be able to lease a machine to a different botnet. That is, someone may request to use the bot's resources for a certain period of time (for example: for the purpose of sending spam or a DDOS attack). This means the following -- a machine should join another botnet (you may assume that it uses the same protocol), but should disconnect itself and return to your botnet after a certain time. The other botnet should NOT be able to compromise the leased machine to steal it away from you. Think about what implications this last requirement has for your design. To give you a hint: you may want to restrict some functionalities of the bot (like the ability to open a root shell), but you must still allow the bot to perform all "safe" operations. Make sure to document which options you left in and which you took out and why. Note that the more options your "leasable" bot supports, the more attractive it it is for potential customers.

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.

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, let the researchers know (researchers often use VMs to study bots) you're on to them with a snarky comment.

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 compromised 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.

Super Persistence - Add functionality to your bots to check if they've been deleted and reinstantiate themselves. One way of doing this is to install the bot and have the in-memory version of the bot check (every minute or so) to make sure that the binary for the bot still exists. If the in-memory bot detects that its binary has been deleted, it could write itself back to disk.

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 existence 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 existence, 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 detect 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-morphing. 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.

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

• Part 1 of the project (the exploit) will be due on Feb. 28 at 5:00pm. It is worth 20% of the final grade. After the due date, we will reveal the exploit so you can use it with the rest of your lab.
  As part of the grading for part 1, it will be your job to convince us through an email to follow your link. You must craft a creative e-mail (a Nigerian spammer, promises of money, food, a free PhD...) and send it to cse484-tas@cs.washington.edu. The subject of your e-mail MUST be

  [PART 1] submission

  We will then follow your link with cgethttp using the same VM we gave you. The link should exploit our machine and, since your bot (part 2) will likely not be done yet, your exploit for part 1 should download, install, and execute a bash script from a location you control (e.g. abstract). The bash script should have the following command:

  echo "MESSAGE" > ownage.txt

  Where MESSAGE is your own custom message (in can be a joke or a comment or anything you'd like). That is, after visiting your link we should have 2 files in our directory: 1) a bash script and 2) a file ownage.txt with your message in it.
  
  ******PART 1 SUBMISSIONS CANNOT BE TURNED IN LATE!!!*******
  
  Make sure that your exploit for Part 1 works on the original VM. Depending on how you solve it, it can be EXTREMELY sensitive to installs of new libraries. For the required parts of the projects, you should not need to install any new libraries. The VM comes with java6, sendmail, and mutt pre-installed.
  
  
• Part 2 (Botnet) will be due on March 15, at 11:50pm, it is worth 50% of the grade.
  Please submit to Catalyst:
  • Gunzipped tarball of your code
  • README containing:
    • A paragraph summarizing how your botnet works -- really only a paragraph
    • Anything we should know about building and running your code.
    • Anything that doesn't work.
    • Also include the name, CSE NetID, and UW NetID of every group member.
    • md5 of your code -- we will ask you to verify this for us during the demo
  
  
  
• Part 3 (Report and Demo) will be worth 30% of the grade. The report is due on March 15, at 11:50pm. Please submit the report to Catalyst. The demo should run the same code that you have submitted or will submit via the Catalyst system (we will ask you to show us that the md5 hashes match if your demo is on 3.17). Please sign up on the paper posted to Yoshi's door for your demo time slot. Each demo should be no more than 20 minutes long.
  
  Please note the following:
  • We'll be running on an extremely tight schedule, so please be on time and ready to go.
  • Practice your demo from start to finish on several machines on the CSE wireless network. If there are issues setting up, handle them BEFORE you come in to show us the demo. When you show up to the demo, you should be READY TO GO.
  • You will have exactly 17 minutes to convince us that your project works and fulfills the requirements
  • After 17 minutes, we will cut you off and begin asking questions about your design.
  • The demo is the main way for us to understand what works and what doesn't. If we don't see it in the demo or it doesn't work in the demo, we will probably not go digging through your code to find it.
  • You should not be debugging, getting the correct version, compiling, recompiling, or otherwise editing your code during the demo. Please do multiple dry runs before you come of installing and running your bot on clean VMs. Please be ready to go. If your setup takes more than 3 minutes, we will prematurely cancel your demo.
  • Ideally your setup should involve just wget and running a shell script on the VMs
  • Your demo will start by you showing us how you download and run your setup shell script.
  • You should easily be able to send spam to an address we provide during the demo
  • You should easily be able to modify your spam template during your demo
  • You should easily be able to demonstrate leasing.
  • Please make sure your bots run on laptops running VMs. If something doesn't work that way, you must figure out why before you come.
  • We will supply you with 3 laptops each running a clean version of the VM -- you can, however, bring your own computers. The VMs will have public IPs.