+- Sinisterly (https://sinister.ly)
+-- Forum: Hacking (https://sinister.ly/Forum-Hacking)
+--- Forum: Remote Administration & Stress Testing (https://sinister.ly/Forum-Remote-Administration-Stress-Testing)
+--- Thread: [Theory] P2P botnet (/Thread-Theory-P2P-botnet)
[Theory] P2P botnet - 3SidedSquare - 06-27-2014
Alright, before I go balls deep and actually write this monster, I want to ask you guys if you see any flaws in it. I suggest taking several breaks. I can be wordy.
Intro-
A peer to peer network is a computer network where all computers connect to each other, there is no central server, only many many client/server connections between all the computers of the network. I want to build a Peer-to-peer virus, and I'll try to explain it below.
Stuff it should do-
- Send commands and recive data from all slaves
- Have most computers connected to only one other, but with a list of backups it can use if the one it is currently connected to goes down.
- Use insecure computers as the nodes for secured computers
- Scan the system before downloading a specialized build of the client
- Be resilient
Establishing connection-
Given 3 infected, unsecure computers (Alice, Bob, Charlie). Charlie's client sees a spreading opportunity. The bot from Charlie carries the addresses of Alice, Bob, and Charlie. When it gets installed on the fourth computer (Doug) It attempts to connect to Alice, Bob, or Charlie, and enter the network. If it fails, it retries hourly. If it has been unable to establish connection for more than 2 weeks, it uninstalls itself.
Connecting the network-
There are 2 "kinds" of computers in this network, "secure" peers, and "unsecured" peers. Unsecured peers are peers that do not stop a NAT punchthough, and these act as the nodes in the network. Secure clients cannot be connected to, and therefore act as clients to the nodes.
Insecure peers (nodes)-
When a secure peer wants to connect to a node, it pings the node with a malformed ping packet. When the packet is detected, the node preforms a NAT punchthrough to connect to the client.Each node has a list of a variable number of other nodes it uses to permutate combinations to give to the secure peers. Insecure peers are connected to 5 other insecure peers and a variable number secure peers. Insecure peers each generate a privatekey/publickey pair, and distribute the public key to other nodes. Nodes communicate by "broadcasting". Ex: "Give Alice this encrypted message:AkdlakjAjdkfjlIKDLBBiklSjfoOi"
Secure peers-
Each secure peer has a different set of 3 nodes to use in case the one it is connected to goes down. Additionally, insecure peers may request a new set of nodes each time that start from any of the nodes they have had before. I hope this reduces the possibility of peer poisoning. Secure peers generate a privatekye/publickey pair, and give the public key to the node they are currently connected to. Secure peers ONLY receive commands from one peer at a time (the one they gave their public key to) Nodes do not store public keys, and are given a new one upon connection from a secure peer.
Issuing commands-
The botnet admin must be one of the nodes in the network. All nodes are built with a hardcoded private key (I don't care who can decrypt the commands, only I want to be able to encrypt the commands). The botnet admin's node (admin peer) gives it's command to 5 of his connected nodes, which in turn tell connected nodes. If a node receives a duplicate broadcast(and many will) it ignores it. (to this end, i'm giving each command a "command id" so I can use the same command more than once). Some commands can be issued with a public key if they require a response. Ex: command#21:Tell everyone to ddos 127.0.0.1
Receiving data-
If the command requires a response, it is given by the secure peer to the node, which gives the information back to the computer it FIRST received the broadcast from, and so on until it reaches the botnet admin, who has the private key to decode the information.
Gosh that's a lot. If you have any questions, or see a flaw, drop a reply below. Thanks for reading.
RE: [Theory] P2P botnet - joeroot - 07-10-2014
hmmm nice post brother ,,
RE: [Theory] P2P botnet - Eclipse - 07-10-2014
This is an interesting concept. I'm looking forward to seeing your attempt to make it a reality. Might I ask what language you'll be coding in?
RE: [Theory] P2P botnet - 3SidedSquare - 07-10-2014
C++, I've made a simple rat (just key logging functionality) to make sure it works. Server node will probably be written in Python, C++ networking is a pain.
RE: [Theory] P2P botnet - havoc-parasite - 07-10-2014
Wow great Idea Brother !!!, I love it
RE: [Theory] P2P botnet - Null_Byte - 07-10-2014
The python side will be easy but why not go for a challenge
push yourself and try to make it all in one language. It's a good idea but don't just reinvent the wheel, try to add new functionality other than key loggers, DoS functions, or other things. Try to create a new function for it.
RE: [Theory] P2P botnet - Merkuri - 07-21-2014
I'm curious what happened with this?
RE: [Theory] P2P botnet - 3SidedSquare - 07-21-2014
(07-21-2014, 06:04 PM)Merkuri Wrote: I'm curious what happened with this?
Still working on it, I'm haveing a little trouble getting NAT punchthrough to work reliably though :/
RE: [Theory] P2P botnet - w00t - 07-22-2014
Then don't implement NAT punchthrough until later, using the scripting interface I'm sure you have.
A few things.
1) Your node structure leaks too much information to each secure peer trying to get into the network. Instead of broadcasting all known nodes to the secure peer, only a handful should be broadcast, keeping it so totalNodes - n >= n whenever possible. This prevents an adversary from downing your entire network off of one infected client.
2) If you ever have to do weird things like distribute a private key, you're likely doing something wrong. Instead, you should have mandatory sign AND encrypt for inter-node comms. When a node receives a command that successfully decrypts, and is signed with the admin key, it redistributes the signed and encrypted message as it was originally received.
3) You should ALWAYS verify receipt of comms, especially of a command, whenever possible. To verify that a node received a command, the admin node would only need be configured to have a list of what nodes have broadcast the command to the admin node, while determining if the endpoints had received the command would be more complicated.
RE: [Theory] P2P botnet - 3SidedSquare - 07-22-2014
(07-22-2014, 08:40 AM)w00t Wrote: Then don't implement NAT punchthrough until later, using the scripting interface I'm sure you have.Let me see if I undersatand you correctly;
A few things.
1) Your node structure leaks too much information to each secure peer trying to get into the network. Instead of broadcasting all known nodes to the secure peer, only a handful should be broadcast, keeping it so totalNodes - n >= n whenever possible. This prevents an adversary from downing your entire network off of one infected client.
You're thinking of a situation where a secure node repeatedly asks for a new set of 3 unsecured nodes, until they get the entire network.
(07-22-2014, 08:40 AM)w00t Wrote: 2) If you ever have to do weird things like distribute a private key, you're likely doing something wrong. Instead, you should have mandatory sign AND encrypt for inter-node comms. When a node receives a command that successfully decrypts, and is signed with the admin key, it redistributes the signed and encrypted message as it was originally received.I called it a private key, really it's just asymmetrical encryption where the nodes can decrypt commands, but not encrypt them. Nodes should be able to encrypt/decrypt traffic to and from the other nodes. You bring up a good point about checking messages coming from the admin node though.
(07-22-2014, 08:40 AM)w00t Wrote: 3) You should ALWAYS verify receipt of comms, especially of a command, whenever possible. To verify that a node received a command, the admin node would only need be configured to have a list of what nodes have broadcast the command to the admin node, while determining if the endpoints had received the command would be more complicated.I'm a little confused here. Why does the admin node need to know what peers have broadcast to it? It's still part of the network, so it should get a broadcast from all 5 of the unsecured peers it is connected to. To determin if an endpoint has received the command, I'm envisioning something like this:
Sending message:
Code:
code tags r broke
->_secured node
->_unsecured node->_secured node
/ |\` ->_secured node <- target for command
Admin node < \ ->_unsecured node->_secured node
\->_unsecured node->_secured nodeGetting feedback:
Code:
code tags r broke
<-_secured node <- target for command
Admin node <-_unsecured node
<-_unsecured node