Bitcoin Forum

The MITM attack is one of the most effective ways to hack today because with this attack we can easily filter logins from users on almost any website and the sad part is it doesn't care if you use Linux, Mac, Windows, or a phone. The only problem about this attack is the network, it only runs on a local network. The attack is now specialized in web browsers, even while people feel secure behind https connections the attacker can avoid that encryption with a tool called sslstrip (https://github.com/moxie0/sslstrip).

Now, the question is, what can a MITM attack do on a Bitcoin Core?

Let's suppose we are on the same network and we start spoofing all data from the Core machine, since the transactions are signed on the computer and then broadcasted to the network the information the attacker could get is the signed transaction, so, in that part, there is no risk at all. But what happens if the node is connected with rpc, when we connect bitcoin node with some language like JS we need a user and password to make rpc calls, if someone spoof that data and gets that username and password, he could get access to bitcoin-cli calls and steal all the balance.

So, this was just theory, what do you think guys, is possible to affect bitcoin with this kind of attack?

Yes attacks similar to this are (correct me if i'm wrong) possible which is why i think there is a warning displayed when you're trying to use RPC with Bitcoin core;

You are supposed to sign tx's on offline devices which are airgapped, and whose access it's blocked, this way even physical access isn't a problem. The node runs separately on another device. The tx is to be transported in a safe medium, namely a QR code reader. Pretty hard to compromise that... MITM doesn't apply there.

That's dangerous sciolism.

You can either
1) Strip off https completely, which is visible because you are connected via http then. And not every website allows http access. Any half-way attentive user should notice that or
2) Use a faked certificate. Your browser will show a warning in this case. The only way to do that without a warning is by installing a new CA on the targets machine (with access to a targets machine you have more trouble than just a fake certificate)




Yes.
RPC calls are not encrypted, afaik.

Don't use RPC in an untrusted network or build something around it (e.g. simple encryption).

Don't use RPC in an untrusted network. Period. Set up a VPN tunnel between your node and the client accessing the RPC interface, if you must.

"Building something around it" may only provide you with a false sense of security rather than offering actual protection.

I was referring to situations where the communications has to go via a network you are not in full control of (e.g. internet).
If 2 server have to communicate with each other via the internet, not using it is not an option.

'Building something around it' can be using TLS certificates, VPN, own encryption implementation, or anything..


Of course you have to use proven concepts / algorithms and not create your own crypto protocol  ::)
But i thought this was obvious.

Please note that most crypto systems fail due to a flaw in the implementation rather than its formal specification.

So for all intents and purposes, that:


...is pretty much as bad as that:


Just sayin' :)

I think we both have a different understand of the term 'implementation'.

If i write python code which uses a well known libary to implement AES encryption before sending it via the internet and the server receives it and uses the same libary to decrypt it... that's my 'own' implementation (in my terms).

This doesn't make it unsecure.


I did not intend to talk about implementing the encryption process itself from scratch.
But about implementing encryption at all (e.g. in an own small application).



By the way.. if you follow the specification properly, your cipher text won't be vulnerable to attacks.
Own implementation of the encryption process often leads to side effects which can be abused.

But in a MITM scenario, those side effects (e.g. CPU time) won't have any effect and therefore won't be an attack surface at all.

If you actually can read and actually can type, you should be able to create your own encryption algorithm (based on a given specification) without being vulnerable to MITM (only talking about MITM here).


P.s. Note that AES is just an example. Pure AES is not suitable for this case (missing replay protection etc.)

Thanks for the reply guys, especially to the HeRetiK and bob123 answers, i think about this attack because i was reading the Jetcash thread about sync the node on public places (https://bitcointalk.org/index.php?topic=5163058.0).

So, is good to know that can be secure on a public network only if we don't have RPC calls configured with any wrapper.

Ah, gotcha. Fair enough.



Except even the most competent developers make mistakes and even the most trusted implementation can have vulnerabilities (see Heartbleed for example -- not exactly a MITM attack but I think you get my point). We're all just human after all (presumably).