Do C&C through a blockchain? C’mon, you could do better Interpol!

On a recent Forbes article one can read Interpol claiming that Bitcoin’s blockchain offers a safe heaven for malware and child abuse. Sure it proved to be nothing more than propaganda.

First of all the article’s title is mostly unrelated to its contents. The article deals with using a blockchain to command and control (C&C) botnets, that is, inserting commands into the blockchain for bots to execute. Such has little to do with malware and child abuse. This alone tells us loads about the author’s motives and journalistic accuracy and about Forbes’ editorial guidelines.

Then, inserting commands into a blockchain seems nothing more than a plain stupid idea. As said on the article itself it would:

  • become expensive due to transaction fees, actually 0.0001 BTC for each 1000 bytes if done on Bitcoin;
  • turn the blockchain into a permanent record of the botnet’s administrator crimes.

Besides this, the botnet’s admin would also be crippled by the small amount of space available on blocks. Currently most Bitcoin miners discard transactions larger than 100 KB. and the maximum block size is 1 MB. Thus the admin can only insert simple commands into the blockchain. However, virtually all contemporary botnets are prepared to receive large payloads with new executable code. Those won’t fit easily inside blocks and require another communication channel. Nowadays botnets use Tor hidden services for that purpose. Therefore, if some other communication channel must be in place, why make things harder and more expensive, using a blockchain?

All this makes little sense both in terms of monetary costs and development effort.

Interpol is spending tax-payer’s money on Kaspersky researchers to find evil applications for blockchain technology and this is the best they can come up with?

Well, we will see if someone stupid enough comes around and explores this. If it ever happens my first suspect will be Interpol.


Hackers: lets hoard Zooz tokens!

La’Zooz is building a decentralized real-time ridesharing app mixed with cryptocurrency concepts. They are distributing Zooz tokens through proof-of-movement in order to bootstrap their app and get the necessary critical mass. While in theory this would provide a nice and fair token distribution, in practice it is not feasible to implement a “hacker proof” proof-of-movement algorithm.

La’Zooz developers are pretty aware that GPS data is easy to fake. Thus their Android app gathers a whole bunch of data, from phone contacts to nearby Wi-Fi networks and accelerometer data. They hope to use all this data on a “cocktail of algorithms” built to prevent proof spoofing. The truth is such data gathering sounds more menacing than some NSA projects while the cocktail of algorithms overcomplicates the system and adds little protection:

1. Proof-of-social-being algorithms — which […] looks at […] all users and the links between them, to filter out most faked users (bots).

Thus they send the entire contact list to their server, all that for a little reward, because, as they say:

it’s pretty easy to identify millions of bots, but it won’t reach easily a single or a few bots.

As a La’Zooz user I would be concerned about “a few bots” accumulating Zooz tokens with fake trips. That’s unfair for all other players.

2. Proof-of-location algorithms — which basically cross refer real-time-location data between different users, and between users and external data. […] we can ask the phone what is the temperature it sees.  If two people located at the same point report different answers, we may know one of them is cheating

First of all, that means we can only mine with an active internet connection. Thus La’Zooz may deplete our data plans.
Second, applying this in practice would get them a super high false negative rate. As Waldschrat2 pointed out:

other App users may be in a location with A/C (e.g. car, bus, office… – less than 25°C) – while the usual motobike drivers will have temperatures of 35°C+…

Similar problems happen if you compare available Wi-Fi networks: my smartphone’s antenna may be worse than that of other users, a bus might be blocking the signal, the Wi-Fi network may be temporarily offline or have changed name, etc.

Lastly, what about routes crossed only by a single user? There will be no data to cross reference there. Will they discard those? … Not fair.

3. Proof-of-movement algorithms — analysing the signals of movement [from the accelerometer] in a way that differentiate an authentic movement from an artificially created one. Of course, one can “record” his movement data, but then we’ll see multiplication of such data all over the place (assuming it’s used for many faked users).

What prevents an hacker from doing some little data permutations (tilt to the right instead of tilt to the left or whatever) to fool them?

These proof-of-movement heuristics are akin to Google’s PageRank cat-and-mouse game, but way harder. There will always be ways to fool them. Also, La’Zooz will never be able to release the full heuristics out in public… so much for transparency and getting community feedback. It’s doomed to security by obscurity.

Post scriptum

La’Zooz tried to mitigate this problem by giving non-tradeable tokens to road miners. These tokens can only be used inside their app to pay for rides. This brings little improvement, the system is still unfair for those who drive for miles in order to mine their tokens.

Furthermore, these tokens “become tradeable upon use”. Which appears to mean that a driver receiving them can trade them for a currency (e.g. BTC). Thus, imagine John the Hacker who controls two bots, A and B. Bot A can ride a fake ride with bot B (fakeable as explained above): voilá, B (aka John the Hacker) gets tokens which are exchangeable for BTC. In the end, if many hackers keep exploiting this vulnerability, Zooz tokens will devalue until their are worth nothing.