There is an ongoing attack against users where servers raise exceptions when a client broadcasts a transaction; in this case the error text is displayed as is in the client GUI. The attacker has spawned lots of servers on different /16 IPv4s to increase his chances of being connected to. The error messages are trying to get the user to download and install malware (disguised as updated versions of electrum).
Always remember to verify pgp / gpg signatures of bitcoin software you install.
In relation to #4953, we were privately sent a screenshot that was apparently floating around a German chat room (on 2018-12-21).
There wasn’t really any extra information given, however most likely the following happened:
- user was using legitimate electrum client
- connected to an electrum server operated by the attacker
- user tried to broadcast a txn
- server replied with an error containing the above rich text message
To make the attack more effective, the attacker is creating lots of servers (sybils), hence increasing the chance a client would connect to him. See this graph on the number of servers hsmiths shared re the peers found by his server:
At the very least, the message should not be displayed as rich text. It is untrusted input afterall…
We should also show some additional explanatory text at the beginning (prepend something).
For context, this mechanism of the server returning error message text to txn broadcasts is used to display error messages originating from bitcoind, such as low incremental fee or missing inputs, etc.
Maybe the server should return error codes (ints) instead, and we could have our own decoding table, but then this would need to be kept in sync with bitcoind…
Hours after we were sent the screenshot, we silently made mitigations in 5248613 and 5dc240d; and released 3.3.2. This is not a true fix, but the more proper fix of using error codes would entail upgrading the whole federated server ecosystem out there…
We did not publicly disclose this until now, as around the time of the 3.3.2 release, the attacker stopped; however they now started the attack again.
This is how the attack, live as writing this now, looks on 3.3.2:
This is on server
plmimservice.bitcoinplug.website on mainnet.
My current server peers on bitcoin mainnet
Notice there are 7
There are 6
There are 9
There are 7
There are 4
(EDIT: noticed at 2018-12-27 14:48 UTC that these domains are no longer DNS resolving)