Exhausting known Ethereum addresses and thus preventing ETH-SONs usage #529

New issue

Open

opened 2023-04-20 11:00:55 +00:00 by bobinson · 4 comments

bobinson commented

2023-04-20 11:00:55 +00:00

(Migrated from gitlab.com)

Step 1:

Assume that the following is done by one individual (Alice).

setup Eth SONs in the local testnet
In the local Etherenum network, there must be total of 2 known addresses (assume that this is all the addresses available in the universe and each must have balances, the accounts can be 0x1.. 0x2..)
The accounts 0x1.. and 0x2.. belongs to Alice
A Peerplays account alice is created but it will not have any sidechain accounts at this point

Step 2:

Assume that this done by an attacker (Bob).

The attacker creates Peerplays accounts 'bob1' & bob2
He then adds 0x1.. as deposit and withdraw address to 'bob1'
Adds 0x2.. as deposit and withdraw addresses to bob2
Similarly if Alice or anyone creates any new addresses Bob will first learnt the same and repeat the process and all the Ethereum addresses will be added as sidechain addresses to various Peerplays accounts controlled by Bob

Step 3:

Alice tries to add 0x1 or 0x2 as sidechain address to peerplays account alice
Alice will not able add deposit address as its occupied by Attacker.

-------—

On the mainnet of both Peerplays and Ethreum, this can be extended as:

Bob fetches all known Ethereum addresses and adds them as deposit addresses for new Peerplays accounts. Then Bob continuously monitors Ethereum network for any new trascation initiated to a new address and instantaneously provisions a new Peerplays addresses and adds the newly identified Ethereum address as a deposit address. The process continues and acts as a denial of service against ETH-SONs.

Step 1: Assume that the following is done by one individual (Alice). - setup Eth SONs in the local testnet - In the local Etherenum network, there must be total of 2 known addresses (assume that this is all the addresses available in the universe and each must have balances, the accounts can be 0x1.. 0x2..) - The accounts 0x1.. and 0x2.. belongs to Alice - A Peerplays account `alice` is created but it will not have any sidechain accounts at this point - Step 2: Assume that this done by an attacker (Bob). - The attacker creates Peerplays accounts 'bob1' & bob2 - He then adds 0x1.. as deposit and withdraw address to 'bob1' - Adds 0x2.. as deposit and withdraw addresses to `bob2` - Similarly if Alice or anyone creates any new addresses Bob will first learnt the same and repeat the process and all the Ethereum addresses will be added as sidechain addresses to various Peerplays accounts controlled by Bob Step 3: - Alice tries to add 0x1 or 0x2 as sidechain address to peerplays account `alice` - Alice will not able add deposit address as its occupied by Attacker. -------— On the mainnet of both Peerplays and Ethreum, this can be extended as: Bob fetches all known Ethereum addresses and adds them as deposit addresses for new Peerplays accounts. Then Bob continuously monitors Ethereum network for any new trascation initiated to a new address and instantaneously provisions a new Peerplays addresses and adds the newly identified Ethereum address as a deposit address. The process continues and acts as a denial of service against ETH-SONs.

bobinson commented

2023-04-20 11:05:35 +00:00

(Migrated from gitlab.com)

changed the description

bobinson commented

2023-04-20 11:06:14 +00:00

(Migrated from gitlab.com)

changed the description

prandnum commented

2023-04-20 20:18:31 +00:00

(Migrated from gitlab.com)

changed the description