Peer-to-Peer Botnets for Beginners

Usr6 · December 22, 2013

Traditional Botnets

With tradition botnets (Be it HTTP, IRC or some other protocol), the structure remains the same. The bots all connect to one or more servers through one or more domains. Although the network structure can differ from very basic to very complex, the botnet can easily be disabled with enough cooperation.

seizing control of an active domain or sever associated with the botnet can usually be all that is needed in order to disband it, however if for some reason it isn't possible to send commands to the bots, a different approach is needed. Attempting to shut down the control sever is usually a waste of time as it would not take long for the botmaster to set up another and redirect the domain to it, which only leaves the option of going after the domain.

A botnet that isn't run by beginners will likely use multiple domains, if a single domain is shut down, the bots will connect to the next. To take down such a botnet: it would be required for researchers to either suspend all domains associated with the botnet (in a time frame that doesn't allow the botmaster to update the bots with new domains), or to seize the domain the botnet is currently using and point it to a functional server (known as a sinkhole), designed to keep the bots away from the legitimate control server and out of the botmaster's reach.

Peer to Peer

Peer to Peer (P2P) botnets try to solve the problem of security researchers and authorities targeting domains or servers, by creating a decentralized network. The idea of P2P is that all the bots connect & communicate with to each-other in order to remove the need for a centralized server, however it's not as straight forward as that.

CommandsIf bots are communicating with each-other, then the botmaster needs to make sure only he can command the bots, this is usually done using digital signing. Signing is performed by using asymmetric encryption, a special type of encryption that required two keys (public and private). if one key is used to encrypt a message, it can only be decrypted with the other key. If the botmaster keep one key secret (private key) and embed the other key in the bot (public key), he can use his key to encrypt commands and then the bots can decrypt them using the public key: without the botmaster's private key, no one can encrypt the commands.

Most people's idea of a peer to peer botnet is similar to Figure 1, the bots all connect to each-other via IP address, forwarding commands to each-other, removing the need for a central server or domain, this representation however is incorrect.

Computers that are behind NAT, Firewalls, or use a proxy server to access the internet: cannot accept incoming connection, but can make outgoing connection. This is a bit of a problem as it would prevent the majority of bots being connected to by other bots. In traditional botnets, this obviously isn't a problem as the bots connect to the server, so a peer to peer network still requires servers in a way.

Bots that are capable of accepting incoming connections (not behind Proxy / NAT / Firewall) act as servers (usually referred to as nodes or peers), the bots that are not capable of accepting connections (usually referred to as workers) will then connect to one or more nodes in order to receive commands (Figure 2). Although the nodes are technically servers, they are used in a way that prevents take down, that is: the workers are distributed between many nodes, allowing them to shift to another node if one is taken down. P2P botnets only work if there are enough nodes that it is impractical to take them all down, the bad news is because the nodes are legitimate computers, they can't simply be seized like a server would be.

Each node maintains a list of IP addresses of other nodes which it shares with the workers, the workers then store the lists, allowing them to switch nodes if the current one were to die. At this stage the botnet would just be many small groups of bots connected to many different nodes, which would be impossible to command. For commands to circulate the entire network, either: The bots will connect to multiple nodes and pass any commands received to the other nodes; The nodes connect to other nodes and pass commands between themselves; or a combination of the two.

Bootstrapping

In order for a bot to join the network: it would need the IP address of at least one node, this is where bootstrapping comes in. The bot is hard-coded with a list of bootstrap servers, which it connects to when it is first run on the infected computer. the job of a bootstrap server is to maintain a huge list of node IP addresses, providing new bots with a smaller list of node IPs (introducing it to the network). Generally bootstrap servers provide some sort of signing, which prevents them from being hijacked by security researchers and used to give new bots invalid node IPs.

Obviously the bootstrap servers are a central points, like with traditional botnets, they could be taken down, however this isn't a huge issue. If all of the bootstrap servers were to be seized at once, it would not effect the bots that are already on the botnet, however it would prevent new infections from joining. The botmaster can simply cease infecting new systems until they can set up new bootstrap servers,this would be only a temporary hold back so it is fairly pointless to attack the bootstrap system.

Dismantling the botnet

Attacking the bootstrap system only temporarily prevents new bots joining the network, digitally signed commands prevent anyone other than the botmaster commanding the bots, and there are far too many nodes to take down at once, so what can be done?

Peer Poisoning

Nearly all peer to peer botnets is existence have a vulnerability in the peer sharing mechanism. As explained earlier, the nodes are required to maintain and share a list of other nodes with the workers, to distribute the workers among the vast number of nodes. It would be incredibly time consuming or even impossible for the botmaster to manually provide each node with a list of other nodes, so the nodes do it automatically. When a new bot is identified as being capable of accepting connections, the node it is connected to adds it to the node list and shares it with the other nodes.

So what if you were to introduce a malicious computer to the network, one that would be identified as capable of becoming a node, the from there you provided the workers and other nodes with a list of invalid ips? Probably not a lot. It's likely that the nodes would verify each new node IP address to make sure it's real, but with that in mind there's another way!

Security researchers could introduce many malicious nodes to the network, but instead of providing workers and other nodes with false IP addresses, they would only share a list of other malicious nodes. With enough resources, the malicious nodes can become a significant part of the botnet and separate the workers from the legitimate nodes. By only issuing the IP addresses of other malicious nodes, it increases the chance that the workers will only be aware of malicious nodes and significantly decreases the chance of them rejoining the network. At a given date the malicious nodes can stop forwarding commands from legitimate nodes: leaving all the workers which are connected to malicious nodes unable to receive commands, and leaving the botmaster no time to react. Such an attack would be unlikely to separate all the workers from the network, but could cripple a significant part of the botnet. Malicious nodes can be left running to commandeer more bots and attempt to keep hold of any bots which may have stored IP addresses of legitimate nodes.

Sursa: MalwareTech: Peer-to-Peer Botnets for Beginners