Can it be a problem for Bitcoin network ?

[Delta_Freak]

I am not a technical specialist.

I was just imagining how theoretically to attack the network.
Is it real in real life ?

Step 1:
We are searching for all Bitcoin nodes by port 8383.

Step 2:
We will find out on which hardware (cpu architecture ) and operating system the nodes running on.

Step 3:
Using Zero-days exploit for arbitrary code execution on each nodes we find.

Step 4:
Changing the consensus rules. (something like "if you're translate transaction which transfer n BTC to bc1adwHq....3q (The attacker's address ) , it does not require signing this transaction with Private key or whatever
 Its Something like forced Hardfork.


Since we have more computing power than anyone else, these rules will be valid in the longest chain

What do you think about it ? Is it real ?

[1714726071]

1714726071

[1714726071]

1714726071

[1714726071]

1714726071

[mocacinno]

I guess... But this attack vector is valid for many different scenario's: if you attack all banks and change your records so they reflect you have 1 billion you'll be rich aswell... If you hack the complete supply chain of toyota so they think you bought (and payed for) a new car, you'll have a new car. If you hack all IRS databases you won't have to pay taxes this year...

In reality, nodes are run on about every modern OS available... I used to run mine on bsd, now i'm running it on CentOS (have to switch so SLES pretty soon). I know people running them on Mac, i know people running them on Windows, i'm pretty sure you'll find people running them on AIX, HP-UX,... All different OS's behind different firewalls, running different thread mitigation methods, sometimes only available as tor hidden service...
Hacking 50% of the nodes seems harder than hacking all banks, or all irs databases, or all toyota backend servers...

[NeuroticFish]

Is it real ?

No. By scanning a port you will know it's open, but not what OS and hardware you have there (in order to get more the system has to be overly vulnerable and in most cases it's not).
Then an exploit will work only on a very small set of unprotected computers. And most computers having Bitcoin Core are Linux system (and afaik there are no known such exploits as you imply for Linux) and the rest do have protection installed, hence you won't touch them.

So making an exploit to take over the consensus is - by far - unrealistic.

Keep in mind that although there is a huge number of computers going online, way less than 1% is usually hit by a malware. I'd go by this numbers also in your scenario. And 1% won't change any consensus.

[NotATether]

Step 1 is not applicable because most data centers where you'd run a server ban port scanning, but then again there are lists of nodes on Bitnodes.

Step 3 would only work if there's no firewall running and someone finds a vulnerability in Bitcoin Core's implementation of the protocol before some dev does.

Step 4 requires that you have a special version of Bitcoin Core with different consensus rules already compiled for these systems; but this would be a hardfork by then, and at worst those nodes will be orphaned from the network.

Consensus rules are hardcoded and so invalid blocks will not be accepted even if it's in the longest chain.

[jackg]

As well as what's said above, most miners will have their nodes configured to use different ports and places where port 8333 is taken might also do the same.

Most simple firewalls start at a point of:
Block all connections I don't initiate (for client based-non server environments)
Or
Block all connections that look different to what my others do (for servers)

And I think the second point here is what's going to cause your problem. Most firewalls (if they accept bitcoin core) are able for peer discovery because most nodes send the same types of information and the same style of packets (a message telling you the current block height from two nodes should look almost identical if the protocol is the same - such as if both are using bitcoin core).

Step 1 is not applicable because most data centers where you'd run a server ban port scanning, but then again there are lists of nodes on Bitnodes.

Even if you can run port scanning on a datacentre, you'll probably find most will run vpns to forward their traffic so they'll just change their ports and IP addresses (they probably do this dynamically quite often too - saves an old machine you don't want to connect to your machine trying to connect back).

[seoincorporation]

Step 1:
We are searching for all Bitcoin nodes by port 8383.

How would you do this? Scanning all the possible ip address is really complex for IPv4 and Impossible for IPv6.

Step 2:
We will find out on which hardware (cpu architecture ) and operating system the nodes running on.

For what? i don't think the CPU architecture is a relevant information, you only need to know the OS to perform the attack.

Step 3:
Using Zero-days exploit for arbitrary code execution on each nodes we find.

If you do this, then why don't only stole the coins you find? and even better, if you have a Zero day why don't you sell it? some Zero days are worth millions.

Step 4:
Changing the consensus rules. (something like "if you're translate transaction which transfer n BTC to bc1adwHq....3q (The attacker's address ) , it does not require signing this transaction with Private key or whatever
 Its Something like forced Hardfork.

If you change the consensus rules that will wake up the alarms, and the bug will be fixed before you can make the attack.

[odolvlobo]

I suppose it is possible in theory. but step 3 is a problem because the exploit would have to be in Bitcoin's messaging protocol, which does not have a very big attack surface.

[pooya87]

There are a bunch of problems here.

First it is very hard to find the operating system of the nodes since the information is not provided through the defined P2P message protocols so you'll have to find an alternative way to figure that out.

Secondly the only exploit you can hope for is in the operating system not in the full node implementation because they don't leave any room for "remote code execution" to be exploited. That means you are now facing multiple OS versions and types that all have to have an exploit which is not possible.

Finally you can't change consensus rules since it is the compiled code that is enforcing those rules (the code) and you can't change the code at run time. You first have to close the application, change the rules, compile the code again and (re)start running the node. That adds more challenge.

Assuming this attack is successful the scale is going to be small so now you are basically creating a fork where you have a minority chain that is working on an altcoin that is rejected by the rest of the network.
There is also the additional problem of getting a miner to mine said altcoin blocks.

[DannyHamilton]

Step 1:
We are searching for all Bitcoin nodes by port 8383.

This won't find my node (or a whole lot of others). I have nodes that are not running on port 8383, and nodes that are not directly accessible from the internet.

Step 2:
We will find out on which hardware (cpu architecture ) and operating system the nodes running on.

If you haven't accomplished step 3 yet, how are you going to find this out?  Are you going to sneak into all the buildings and look at all the equipment to see what they are running?  If so, then you didn't need step 1, did you?  Instead, step one should say "sneak into every building on earth and see if they are running any equipment that might be capable of running a Bitcoin Node. LOL.

Step 3:
Using Zero-days exploit for arbitrary code execution on each nodes we find.

What if there isn't a zero-day exploit available for the system that you are attempting to attack? If you can find a node, and if you can determine that it has an exploit available, sure you'll be able to attack that one node. You aren't going to gain access to all of them though. If you can't access ALL nodes, then you can ONLY attack the people whose nodes you do gain access to, not anybody else.

Step 4:
Changing the consensus rules. (something like "if you're translate transaction which transfer n BTC to bc1adwHq....3q (The attacker's address ) , it does not require signing this transaction with Private key or whatever
 Its Something like forced Hardfork.

You might be able to confuse a few people by tricking THEIR nodes to split off temporarily onto your hard fork. However, those people will quickly see that their nodes are incorrect and they will clean out the malware, fix the zero-day, and reinstall Bitcoin Core. Now they are right back on the main Bitcoin Network and you haven't accomplished anything.

Since we have more computing power than anyone else, these rules will be valid in the longest chain

Nope.  That's not how Bitcoin works.  You've misunderstood.  If you have ALL of the nodes in the ENTIRE WORLD (except mine), including ALL the miners and mining pools, and you try to change the consensus rules, my nodes still won't accept your invalid blocks.  Amount of computing power does not make it possible to turn invalid blocks into valid blocks. This is why we call them CONSENSUS rules, and not MAJORITY rules. majority hashpower ONLY decides which VALID blocks are accepted when two different VALID blocks are competing for the next position in the blockchain. A hard fork requires EVERYONE (miners, pools, merchants, consumers, node-running hobbyists, wallet software creators, etc) to ALL agree on the new rules. Otherwise, anyone still running the old rules will simply reject any invliad block no matter how much hash power it was created with.


What do you think about it ? Is it real ?
[/quote]