Curteously of http://en.wikipedia.org/wiki/Botnet
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:
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.
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):
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 embarassing, you should probably get it taken down. Here is the link: YYY -ZZZYour bot should fill XXX, YYY, and ZZZ in appropriately.
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.
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.
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
[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.txtownage.txt with your message in it.