Social Zombies - Aspects of Trojan Networks May, 2005 warlord warlord / nologin.org 1) Introduction While I'm sitting here and writing this article, my firewall is getting hammered by lots and lots of packets that I never asked for. How come? In the last couple of years we saw the internet grow into a dangerous place for the uninitiated, with worms and viruses looming almost everywhere, often times infecting systems without user interaction. This article will focus on the subclass of malware commonly referred to as worms, and introduce some new ideas to the concept of worm networks. 2) Worm Infection Vectors The worms around today can mostly be put into one the four categories discussed in the following sections. 2.1) Mail The mail worm is the simplest type of worm. It's primary mode of propagation is through social engineering. By sending large quantities of mail with content that deceives people and/or triggers their curiosity, recipients are tricked into running an attached program. Once executed, the program will send out copies of itself via email to recipients found in the victims address book. This type of worm is usually stopped quickly when antivirus companies update their signature files, and mail servers running those AV products start filtering the worm mails out. Users, in general, are becoming more and more aware of this type of malware, and many won't run attachments sent in mail anymore. Regardless, this method of infection still manages to be successful. 2.2) Browser Browser-based worms, which primarily work against Internet Explorer, make use of vulnerabilities that exist in web-browsers. What generally happens is that when a users visits a malicious website, an exploit will make Internet Explorer download and execute code. As there are well known vulnerabilities in Internet Explorer at all times that are not yet fixed, the bad guys usually have a couple of days or weeks to spread their code. Of course, the infection rate heavily depends on the number of visitors on the website hosting the exploit. One approach that has been used in the past to gain access to a wider 'audience' involved sending mail to thousands of users in an attempt to get the users to visit a malicious website. Another approach involved hacking advertisement companies and changing their content in order to make them serve exploits and malware on high profile sites. 2.3) Peer to Peer The peer to peer worm is quite similar to the mail worm; it's all about social engineering. Users hunting for the latest mp3s or pictures of their most beloved celebrity find similarly named programs and scripts, trying to deceive the user to download and execute them. Once active on the users system, the malcode will make sure it's being hosted by the users p2p application to spread further. Even if downloaded, host based anti-virus scanners with recent signatures will catch most of these programs before they can be run. 2.4) Active This one is the most dangerous worm, as it doesn't require any sort of user interaction at all. It also requires the highest level of skill to write. Active worms spread by scanning the internet for one or more types of vulnerabilities. Once a vulnerable target is found, an exploit attempt is made that, if successful, results in the uploading of the worm to the attacked site where propagation can continue in the same form. These worms are usually spotted first by an increasing number of hosts scanning the internet, most often scanning for a single port. These worms also usually exploit weaknesses that are well-known to the public for hours, days, weeks or months. Examples of this type of worm include the Wank worm, Code Red, Sadmind, SQL Slammer, Blaster, Sasser and others. As the use of firewalls and NAT routers increases, and as anti-exploit techniques like the one employed by Windows XP SP2 become more common, these worms will find less hosts to infect. To this point, from the time of this writing, it's been a while since the last big active worm hit the net. Other active infection vectors include code spreading via unset or weak passwords on CIFS Common Internet File System. The protocol used to exchange data between Windows hosts via network shares. shares, IRC and instant messaging networks, Usenet, and virtually every other data exchange protocol. 3) Motives 3.1) Ego Media attention often is a major motivation behind a worm. Coders bolstering their ego by seeing reports on their worm on major sites on the internet as well as tv news and newspapers with paniced warnings of the latest doomsday threat which may take down the planet and result in a 'Digital Pearl Harbor' seems to be quite often the case. Huge media attention usually also means huge law enforcement attention, and big efforts will be made to catch the perpetrator. Though especially wide open (public) WIFI networks can make it quite difficult to catch the perpetrator by technological means, people boasting on IRC and, as in the case of Sasser, bounties, can quickly result in the worm's author being taken into custody. 3.2) DDoS The reason for a DDoS botnet is usually either the wish to have enough firepower to virtually shoot people/sites/organizations off the net, or extortion, or a combination of both. The extortion of gambling websites before big sports events is just one example of many cases of extortion involving DDoS. The attacker usually takes the website down for a couple of hours to demonstrate his ability to do so whenever it pleases him, and sends a mail to the owner of the website, asking for money to keep the firepower away from his site. This sort of business model is well known for millenia, and merely found new applications online. 3.3) Spamming This one is also about money in the end. Infected machines are (ab)used as spam zombies. Each machine sends their master's unsolicited mail to lots and lots of unwilling recipients. The owners of these systems usually offer their services to the spam industry and thus make money of it. 3.4) Adware Yet another reason involving money. Just like on TV and Google, advertisements can be sold. The more people seeing the advertisement, the more money can be requested from the people that pay for their slogan to be displayed on some end users Windows. (Of course, it could be Linux and MacOS too, but, face it, no adware attacks those) 3.5) Hacking A worm that infects and backdoors a couple thousand hosts is a great way to quickly and easily obtain data from those systems. Examples of data that may be worth stealing includes accounts for online games, credit card numbers, personal information that can be used in identity theft scams, and more. There has even been a report that items of online games were being stolen to sell those later on E-bay. Already having compromised one machine, enhancing the influence into some network can be much easier of course. Take for example the case of a heavily firewalled company. A hacker can't get inside using an active approach, but notices that one of his malware serving websites infected a host within that network. Using a connect-back approach, where the infected node connects to the attacker, a can tunnel can be built through the firewall thereby allowing the attacker to reach the internal network. 4) Botnets While I did mention DDoS and spam as reasons for infection already, what I left out so far was the infrastructure of hundreds or thousands of compromised machines, which is usually called a botnet. Once a worm has infected lots of systems, an attacker needs some way to control his zombies. Most often the nodes are made to connect to an IRC server and join a (password protected) secret channel. Depending on the malware in use, the attacker can usually command single or all nodes sitting on the channel to, for example, DDoS a host into oblivion, look for game CD keys and dump those into the channel, install additional software on the infected machines, or do a whole lot of other operations. While such an approach may be quite effective, it has several shortcomings. - IRC is a plaintext protocol. Unless every node builds an SSL tunnel to an SSL-capable IRCD, everything that goes on in the channel will be sent from the IRCD to all nodes connected, which means that someone sniffing from an infected honeypot can see everything going on in the channel, including commands and passwords to control the botnet. Such a weakness allows botnets to be stolen or destroyed (f.ex. by issuing a command to make them connect to a new IRCD which is on IP 127.0.0.1). - It's a single point of failure. What if the IRCD goes down because some victim contacted the admin of the IRC server? On top of this, an IRC Op (a IRC administrator) could render the channel inaccessible. If an attacker is left without a way to communicate with all of the zombie hosts, they become useless. A way around this dilemma is to make use of dynamic DNS sites like www.dyndns.org. Instead of making the zombies connect to irc.somehost.com, the attacker can install a dyndns client which then allows drones to reference a hostname that can be directed to a new address by the attacker. This allows the attacker to migrate zombies from one IRC server to the next without issue. Though this solves the problem of reliability, IRC should not be considered secure enough to operate a botnet successfully. The question, then, is what is a better solution? It seems the author of the trojan Phatbot already tried to find a way around this problem. His approach was to include peer to peer functionality in his code. He ripped the code of the P2P project ``Waste'' and incorporated it into his creation. The problem was, though, that Waste itself didn't include an easy way to exchange cryptographic keys that are required to successfully operate the network, and, as such, neither did Phatbot. The author is not aware of any case where Phatbot's P2P functionality was actually used. Then again, considering people won't run around telling everyone about it (well, not all of them at least), it's possible that such a case is just not publicly known. To keep a botnet up and running, it requires reliability, authentication, secrecy, encryption and scalability. How can all of those goals be achieved? What would the basic functionality of a perfect botnet require? Consider the following points: - An easy way to quickly send commands to all nodes - Untraceability of the source IP address of a command - Impossibile to judge from an intercepted command packet which node it was addressed to - Authentication schemes to make sure only authorized personnel operate the zombie network - Encryption to conceal communication - Safe software upgrade mechanisms to allow for functionality enhancements - Containment; so that a single compromised node doesn't endanger the entire network - Reliability; to make sure the network is still up and running when most of its nodes have gone - Stealthiness on the infected host as well as on the network At this point one should distinguish between unlinked and linked, or passive, botnets. Unlinked means each node is on its own. The nodes poll some central resource for information. Information can include commands to download software updates, to execute a program at a certain time, or the order a DDoS on a given target machine. A linked botnet means the nodes don't do anything by themselves but wait for command packets instead. Both approaches have advantages and disadvantages. While a linked botnet can react faster and may be more stealthy considering the fact that it doesn't build up periodic network connections to look out for commands, it also won't work for infected nodes sitting behind firewalls. Those nodes may be able to reach a website to look for commands, which means an unlinked approach would work for them, but command packets like in the linked approach won't reach them, as the firewall will filter those out. Also, consider the case of trying to build up a botnet with the next Windows worm. Infected Windows machines are generally home users with dynamic IP addresses. End-user machines change IPs regularly or are turned off because the owner is at work or on a hunting weekend. Good luck trying to keep an up-to-date list of infected IPs. So basically, depending on the purpose of the botnet, one needs to decide which approach to use. A combination of both might be best. The nodes could, for example, poll a resource of information once a day, where commands that don't require immediate attention are waiting for them. On the other hand if there's something urgent, sending command packets to certain nodes could still be an option. Imagine a sort of unlinked botnet. No node knows about another node and nor does it ever contact one of its brothers, which perfectly achieves our goal of containment. These nodes periodically contact what the author has labeled a resource of information to retrieve their latest orders. What could such a resource look like? The following attributes are desirable: - It shouldn't be a single point for failure, like a single host that makes the whole system break down once it's removed. - It should be highly anonymous, meaning connecting there shouldn't be suspicious activity. To the contrary, the more people requesting information from it the better. This way the nodes' connections would vanish in the masses. - The system shouldn't be owned by the botnet master. Anonymity is one of the botnet's primary goals after all. - It should be easy to post messages there, so that commands to the botnet can be sent easily. There are several options to achieve these goals. It could be: - Usenet: Messages posted to a large newsgroup which contain steganographically hidden commands that are cryptographically signed achieves all of the above mentioned goals. - P2P networks: The nodes link to a server once in a while and, like hundreds of thousands of other people, search for a certain term (``xxx''), and find command files. File size could be an indicator for the nodes that a certain file may be a command file. - The Web itself: This one would potentially be slow, but of course it's also possible to setup a website that includes commands, and register that site with a search engine. To find said site, the zombies would connect to the search engine and submit a keyword. A special title of the website would make it possible to identify the right page between thousands of other hits on the keyword, without visiting each of them. Using those methods, it would be possible to administer even large botnets without even having to know the IP adresses of the nodes. The ``distance'' between botnet owner and botnet drone would be as large as possible since there would be no direct connection between the two. These approaches also face several problems, though: How would the botnet master determine the number of infected hosts that are up and running? Only in the case of the website would estimation of the number of nodes be possible by inspecting the access logs, even logging were to be enabled. In the case of the Usenet approach a command of ``DDoS Ebay/Yahoo/Amazon/CNN'' might just reach the last 5 remaining hosts, and the attacker would only be left with the knowledge that it somehow didn't work. The problem is, however, that the attacker would not know the number of zombies that would actually take part in the attack. The same problem occurs with the type and location of the infected hosts. Some might be high profile, such as those connecting from big corporations, game developers, or financial institutions. The attacker might be interested in abusing those for something other than Spam and DDoS, if he knew about them in particular. If the attacker wants to bounce his connections over 5 of his compromised nodes to make sure he can't be traced, then it is required that he be able to communicate with 5 nodes only and that he must know address information about the nodes. If the attacker doesn't have a clue which IP addresses his nodes have, how can he tell 5 of them where to connect to? Besides the obvious problem of timing, of course. If the nodes poll for a new command file once every 24 hours, he'd have to wait 24 hours in the worst case until the last node finds out it's supposed to bind a port and forward the connection to somewhere else. 4.1) The Linked Network Though I called this approach a passive network, as the nodes idle and wait for commands to come to them, this type of botnet is in fact quite active. The mechanisms described now will not (easily) work when most of the nodes are on dynamic IP addresses. It is thus more interesting for nodes installed after exploiting some kind of server software. Of course, while not solving the uptime problem, a rogue dyndns account can always give a dynamic IP a static hostname. This kind of network focuses on all of its nodes forming some kind of self-organizing peer to peer network. A node that infects some other host can send over the botnet program and make the new host link to itself, thus becoming that node's parent. This technique can make the infected hosts form a sort of tree structure over time, as each newly infected host tries to link to the infecting host. Updates, information, and commands can be transmitted using this worm network to reach each node, no matter which node it was sent from, as each node informs both child nodes as well as its parent nodes. In its early (or final) stages, a network of this type might look like this piece of ascii art: Level 0 N / \ 1 N N / \ / 2 N N N To make sure a 'successful' node that infects lots of hosts doesn't become the parent of all of those hosts, nodes must refuse link requests from child nodes after a certain number have been linked (say 5). The parent can instead in form the would-be child to link to one of its already established children instead. By keeping track of the number of nodes linked to each location in the tree, a parent can even try to keep the tree thats hierarchically below it well balanced. This way a certain node would know about its parent and up to 5 children, thus keeping the number of other hosts that someone who compromises a node rather low, while still making sure to have a network that's as effective as possible. Depending on the number of nodes in the entire network, the amount of children that may link to a parent node could be easily changed to make the network scale better. As each node may be some final link as well as a parent node, every host runs the same program. There's no need for special 'client' and 'server' nodes. Whats the problem with a tree structure? Well, what if a parent fails? Say a node has 3 children, each having 2 children of its own. Now this node fails because the owner decides to reinstall the host. Are we left with 3 networks that can't communicate with each other any more? Not necessarily. While possibly giving a forensics expert information on additional hosts, to increase reliability each node has to know about at least one more upstream node that it can try to link to if its parent is gone. An ideal candidate could be the parent's parent. In order to make sure that all nodes are still linked to the network, a periodic (once a day) sort of ``ping'' through the entire network has to happen in any case. By giving a child node the IP of its ``grandparent'', the direct parent of the child node always knows that the fail-over node, the one its kids will try to link to if it should fail, is still up and running. Though this may help to address the issue of parent death, another issue remains. If the topmost node fails, there are no more upstream nodes that the children could link to. Thats why in this case the children should have the ip of one(!) of its siblings as the fail-over address so that they can make this one the new top node in the case of a fail-over condition. Making use of the node-based ping, each node also knows how many of its children are still up and running. By including this number into the ping sent to the parent, the topmost node could always tell the number of linked hosts. In order to not have to rely on connecting to the topmost node to collect this type of information, a simple command can be implemented to make the topmost node report this info to any node on the network that asks for it. Using a public key stored into all the nodes, it's even possible to encrypt every piece of information thats destined for the botnet owner, making sure that no one besides the owner can decrypt the data. Although this type of botnet may give a forensics expert or someone with a sniffer information on other nodes that are part of the network, it also offers fast response times and more flexibility in the (ab)use of the network compared to the previous approach with the unlinked nodes. It's a sort of trade off between the biggest possible level of anonymity on one hand, and flexibility on the other. It is a huge step up compared to all of the zombies sitting on IRC servers right now, where a single channel contains the zombies of the entire botnet. By employing cryptography to store the IPs of the child and parent nodes, and keeping those IPs only in RAM mitigates the problem further. Once a drone network of this type has been established with several hundreds of hosts, there are lots of possibilities of putting it to use. To conceal the originating IP address of a connection, hopping over several nodes of the drone network to a target host can be easily accomplished. A command packet tells one node to bind a port. Once it receives a connection on it, it is told to command a second node to do the same, and from then on node 1 forwards all the traffic to node 2. Node 2 does the same, and forwards to node 3, then 4, maybe 5, until finally the last node connects to the intended destination IP. By encrypting the entire connection from the original source IP address up to the last node, a possible investigator sniffing node 2 will not see the commands (and thus the IP addresses) which tell node 3 to connect to node 4, node 4 to node 5, and of course especially not the destination host's address. An idle timeout makes sure that connections don't stay up forever. As manually updating several hundreds or thousands of hosts is tedious work, an easy updating system should be coded into the nodes. There are basically two possible ways to realize that. A command, distributed from node to node all over the network, could make each node replace itself with a newer version which it may download from a certain HTTP address. The other way is by updating the server software on one node, which in turn distributes this update to all the nodes it's linked to (children and parent), which do just the same. Cryptographic signatures are a must of course to make sure someone doesn't replace all of the precious nodes with SETI@home. Vlad902 suggested a simple and effective way to do that. Each node gets an MD5 hash hardcoded into it. Whenever someone offers a software update, it will download the first X bytes and see wether they hash to the hardcoded value. If they do, the update will be installed. Of course, a forensics expert may extract the hash out of an identified node. However, due to the nature of cryptographic hashes, he won't be able to tell which byte sequence generates that hash. This will prevent the forensics export from creating a malicious update to take down the network. As the value used to generate the hash has to be considered compromised after an update, each update has to supply a new hash value to look out for. Further security mechanisms could include making the network completely memory resident, and parents keeping track of kids, and reinfecting those if necessary. What never hit the hard-disk can obviously not be found by forensics. Also, commands should be time-stamped to make sure a certain command will only work once, and replay attacks (sending a sniffed command packet to trigger a response from a node) will fail. Using public key cryptography to sign and encrypt data and communication is always a nice idea too, but it also has 2 disadvantages: - It usually produces quite a big overhead to incorporate into the code. - Holding the one and only private key matching to a public key thats been found on hundreds of hacked hosts is quite incriminating evidence. An additional feature could be the incorporation of global unique identifiers into the network, providing each node with a unique ID that's set upon installation on each new victim. While the network master would have to keep track of host addresses and unique IDs, he could use this feature to his advantage. Imagine a sort of traceroute within the node network. The master wants to know where a certain host is linked to. Every node knows the IDs of all of the child nodes linked hierarchically below it. So he asks the topmost node to find out the path to the node he's interested in. The topmost node realizes it's linked somewhere under child 2, and in turn asks child 2. This node knows it's linked somewhere below child 4, and so on and so on. In the end, the master gets his information, a couple of IDs, while no node thats not directly linked to another gets to know the IPs of further hosts that are linked to the network. Since a portscan shouldn't reveal a compromised host, a raw socket must be used to sniff command packets off the wire. Also, command packets should be structured as unsuspicious as possible, to make it look like the host just got hit by yet another packet of ``internet background noise''. DNS replies or certain values in TCP SYN packets could do the trick. 4.2) The Hybrid There is a way to combine both the anonymity of an unlinked network with the quick response time of the linked approach. This can be done by employing a technique first envisioned in the description of a so-called ``Warhol Worm''. While no node knows anything about other nodes, the network master keeps track of the IPs of infected hosts. To distribute a command to a couple or maybe all of the nodes, he first of all prepares an encrypted file containing the IPs of all active nodes, and combines that with the command to execute. He then sends this commandfile to the first node on the list. This node executes the command, takes itself from the list, and goes top to bottom through the list, until it finds another active node, which it transmits the command file to. This way each node will only get to know about other nodes when receiving commandfiles, which are subsequently erased after the file has been successfully transmitted to another node. By calling certain nodes by their unique IDs, it's even possible to make certain nodes take different actions than all the others. By preparing different files and sending them to different nodes at start already, quite a fast distribution time can be achieved. Of course, should someone accomplish to not only sniff the commandfile, but also decrypt it, he has an entire list of infected hosts. Someone sniffing a node will still also see an incoming connection from somewhere, and an outgoing connection to somewhere else, and thus get to know about 2 more nodes. Thats just the same as depicted in the passive approach. Whats different is that a binary analysis of a node will not divulge information on another host of the network. As sniffing is probably more of a threat than binary analysis though, and considering a linked network offers way more flexibility, the Hybrid is most likely an inferior approach. 5) Conclusion When it comes to botnets, the malcode development is still in it's infancy, and while today's networks are very basic and easily detected, the reader should by now have realized that there are far better and stealthier ways to link compromised hosts into a network. And who knows, maybe one or more advanced networks are already in use nowadays, and even though some of their nodes have been spotted and removed already, the network itself has just not been identified as being one yet. Bibliography The Honeypot Project. Know Your Enemy: Tracking Botnets. http://www.honeynet.org/papers/bots/ Weaver, Nicholas C. Warhol Worms: The Potential for Very Fast Internet Plagues. http://www.cs.berkeley.edu/ nweaver/warhol.html Paxson, Vern, Stuart Staniford Nicholas Weaver. How to 0wn the Internet in Your Spare Time. http://www.icir.org/vern/papers/cdc-usenix-sec02/ Zalewski, Michael. Writing Internet Worms for Fun and Profit. http://www.securitymap.net/sdm/docs/virus/worm.txt