+- 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)
RE: [Theory] P2P botnet - w00t - 07-22-2014
1. Yes, the worry is that a peer can just request over and over until they have a map of the entire network.
2. But the public key is derived FROM the private key, so its only asymmetric to someone not willing to compute the public key from the private key. By encrypting a message to the node, but signing it with an admin key, you authenticate that the command came from the holder of the admin private key, and the command is secure from outside eyes.
3. I was merely proposing a way to verify that the command is propagating through the network, it seems you already have a way.
RE: [Theory] P2P botnet - 3SidedSquare - 07-23-2014
(07-22-2014, 08:22 PM)w00t Wrote: 1. Yes, the worry is that a peer can just request over and over until they have a map of the entire network.
I'm sitting here racking my brain, and I've thought up a few solutions
Solution 1:
Spoiler:
Unsecured nodes keep track of all clients they have had. When a secure peer tries to enter the network, the unsecured peer they connect to broadcasts a message checking if anyone has the secure peer on their "list of secure peers that have connected to me". That way secure nodes only get new unsecured nodes when 'their' old node(s) go down.
Very susceptible to peer poisoning
A computer running 24/7 can probably get a chunk of the network anyway
Very susceptible to peer poisoning
A computer running 24/7 can probably get a chunk of the network anyway
Solution 2:
Spoiler:
When the bot spreads, only give it 5 or so unsecured nodes. If they all go down, the bot is dropped.
Lots of bots will drop over time
Lots of bots will drop over time
Solution 3:
Spoiler:
Have a list of secure peers that have requested some new unsecure peers recently, if one peer is requesting more than once a hour/day/week/month, don't give him any new peers.
May take up a lot of space on the unsecure peers
May take up a lot of space on the unsecure peers
I'm thinking about going with option 1, opinions?
(07-22-2014, 08:22 PM)w00t Wrote: 2. But the public key is derived FROM the private key, so its only asymmetric to someone not willing to compute the public key from the private key. By encrypting a message to the node, but signing it with an admin key, you authenticate that the command came from the holder of the admin private key, and the command is secure from outside eyes.
I don't think this is always the case, but anyway I've found an algorithm that I think will satisfy,
http://en.wikipedia.org/wiki/ElGamal_encryption
RE: [Theory] P2P botnet - w00t - 07-23-2014
Assign each peer to a "master" node( each node could have the ability to function both as a regular node and a master node )
On initial connection, the node sends 5 other nodes to the peer for connection
If one node goes down, the peer can "tell" its master node.
The master node will then verify that that node is down, and if it is send another node's information.
As for your command auth, yes, in any PKC system having the private key would make it relatively simple to derive the public key. Why not just encrypt the message to the node, with a signature on the decrypted message that one can check against a hardcoded admin public key?
RE: [Theory] P2P botnet - Cake - 07-23-2014
in theory this is stupid.
RE: [Theory] P2P botnet - Oni - 07-23-2014
(07-23-2014, 04:44 AM)Cake Wrote: in theory this is stupid.
It's been done before, actually.
RE: [Theory] P2P botnet - 3SidedSquare - 07-23-2014
(07-23-2014, 04:00 AM)w00t Wrote: Assign each peer to a "master" node( each node could have the ability to function both as a regular node and a master node )
On initial connection, the node sends 5 other nodes to the peer for connection
If one node goes down, the peer can "tell" its master node.
The master node will then verify that that node is down, and if it is send another node's information.
*words*
But this is a botnet, people's computers turn off, so each node would need to have multiple master nodes in case one goes down. They would also need the ability to "transfer" the master node-status.
Additionally, now a security researcher just needs 2 nodes instead of one to collect the entire network (one to pretend to be a master node, another to pretend to be a node).
(07-23-2014, 04:44 AM)Cake Wrote: in theory this is stupid.
Care to elaborate?
RE: [Theory] P2P botnet - Cake - 07-23-2014
(07-23-2014, 05:10 AM)3SidedSquare Wrote: Care to elaborate?
no
RE: [Theory] P2P botnet - Null_Byte - 08-25-2014
(07-23-2014, 04:51 AM)Oni Wrote: It's been done before, actually.
It has and boy was it good
RE: [Theory] P2P botnet - sykerz - 08-27-2014
(08-25-2014, 09:40 AM)Null_Byte Wrote: It has and boy was it goodWas it? :O
RE: [Theory] P2P botnet - 3SidedSquare - 08-28-2014
(08-27-2014, 12:01 PM)sykerz Wrote: Was it? :O
Yep, here's the article that inspired me to start this project (which is on hold for now btw until I get some time off from school)
http://www.secureworks.com/cyber-threat-intelligence/threats/The_Lifecycle_of_Peer_to_Peer_Gameover_ZeuS/