Bitcoin robberies

Apparently, another bitcoin platform got robbed: Bitcoin, call the police

Don’t use something like WordPress for your bitcoin platform

I specialize in the security of bitcoin marketplaces and bitcoin exchange platforms. Having sat through multiple attack attempts myself, contrary to common perception, my experience says that it is possible to run a bitcoin platform on the internet or even on the tor network without getting robbed, but first you must forget everything you think you know about software engineering or about security, because all of it is wrong.

Pick whatever framework in whatever programming language, and out of the box it will go wrong. The stories about hot/cold wallets? It does not work and it will go wrong.

You will also not get anywhere by carrying out just a cargo cult of installing so-called “security modules” without knowing why exactly you are doing what precisely.

Security is the prime architectural concern of a bitcoin platform. In something like WordPress, security is not the prime concern at all.

If the architecture and the source code of your platform looks too much like WordPress, you know that the shit will hit the fan someday soon. At the same time, most sites on the internet and on the tor network look like WordPress. Most frameworks do too. Django? Lavarel? Name it. These are all variations on what goes wrong if you deploy something like WordPress.

The config.ini problem

One example. If all that the attacker needs to do, is to obtain read access to some kind of config.ini file sitting on the very server on which the public accesses your system, reading that file, which contains database user and password, is usually enough for the attacker to have full control over your database.

This is just one of the long list of examples of what is wrong with the typical architecture.

For WordPress-style architectures, the attacker just overruns the defenses you have put up around the www-data user (webserver system user) andit is game over; and all the bitcoins will be stolen.

It may not be possible to prevent the attacker from overrunning www-data. However, you can drastically reduce the damage by a collapse in your first line of defense. It should not be game over. You can also detect such intrusion and even automatically address it.

Running bitcoind on your public-facing server

Imagine your site is mybitcoinplace.com and exactly on that server you have a bitcoind process running with full access to the site’s private bitcoin keys. How could that ever go right? This is just an open invitation to attack! A bitcoin platform running on just one server image, is always an accident waiting to happen. What can the attacker discover when taking control of the mybitcoinplace.com server? Always way too much.

Pick the locus of control correctly

Another example of how security imposes different solutions. Imagine you have the following two servers: one live server and one backup server. Will you run the backup process on the live server and make it access the backup server, or will you implement it the other way around?

At first glance, both solutions are equivalent, but from a security point of view, they are not.

If you run the backup process on a live server, the attacker who has managed to take control of your live server will also know where the backup server is located. He will find enough credentials on the live server to at least make backups, but very often he will find even more credentials than that. He may even have enough privileges to destroy your history of backups.

If you run the backup process on the backup server, the attacker who has taken control of your live server will not even know of the existence of the backup server. It will take him a hell of a lot of effort to discover that there is a remote machine trying to access the live server every few hours in order to copy a few things. Furthermore, even if the attacker figures that out, he still does not have access to any credentials that would allow him to control such remote backup server.

Compartimentalize the live process

A general principle is that the bitcoin platform must be compartimentalized into a large number of smaller subsystems. For each subsystem, the question then becomes: What would be the damage if the attacker manages to get control over it, and how can we detect that he did so?

For servers, who do not store original data, but only carry out computations, it should be a press of the button to back up the forensics of the attack and to put back a virgin image of the software.

The heaviest defensive lines should surround the machines that store original data. But then again, the attacker will not discover their existence first. The attacker will first see the front end machine images which are serving the main domain (mybitcoinplace.com). Even then, in the case of a successful attack, the backup strategy, every few hours, should also be able to mitigate its effects.

In terms of security, MVC is totally wrong

In terms of software development, Ruby on Rails, Django, Lavarel, or similar frameworks assume more or less that you will be using an MVC architecture: Model – View – Controller. The Model will access the database, the View will produce the HTML, the Controller will do some kind of routing of urls to picking the right Model and View.

Their MVC model assume that the HTML will be served from the same machine as the machine that accesses the database. In other words, putting the config.ini file with database credentials on the machine serving the platform’s domain (mybitcoinplace.com) to the users and therefore perfectly well known by the attackers, is built in from the get-go.

In other words, it is MVC that creates the config.ini security problem. This kind of architecture will automatically suffer maximum damage, if the attacker overruns the www-data defenses. If it ever goes wrong, and it will, it will go badly wrong.

MVC is totally incorrect. Never build your system like that.

You have two mixers. One mixer is the backend mixer. It emits SQL to the back and JSON messages to the front. A second mixer is the frontend mixer. It reads JSON messages at the back and emits HTML at the front. It is possible to put both mixers on different machine images.

Triangulating over JSON has other advantages. With a few minor tweaks in preprocessing the JSON messages, you can also make it somewhat harder to perform a successful SQLI attack. But then again SQLI primarily remains an issue of escaping and quoting correctly. Fundamentally, it should be solved by code reviewing things.

If the attacker overruns the frontend mixer and gains control over its www-data system user, he has achieved not particularly much. He still needs to overrun the www-data user of the second machine. So, now he needs to intelligently craft JSON messages that will acquire control over the second machine. There is, however, a problem in doing so. The frontend mixer does not store any data. The frontend mixer is also a readonly image. No way to permanently install anything. Therefore, it gets reinstalled every 4 hours or so. So, that does not give the attacker much time to figure out how to attack the backend mixer.

Furthermore, and as needed, the backend mixer can be split up across different machines. So, gaining access to the first backend mixer may still be nothing particularly useful to the attacker.

Put sensitive servers on the tor network

Concerning the bitcoin private keys, it is obvious that the machine containing them, should access the remainder of the platform and not the other way around. In other words, the remainder of the platform should simply not know where these private keys could be. Once in a while the key machine may access the platform to figure out with payments it should do, but that still does not reveal to the platform what machine exactly is doing that.

If the platform does not know where these private keys could possibly be, the attacker cannot either.

An additional complication to impose onto the attacker is to put sensitive machines, such as the private key machine, on the tor network. Even if the attacker ever figures out on what domain the machine is located, it will be a tor domain. But then again, that tor address is a secret too. It only takes a minute to change the tor address of a server.

So, if you detect that an intrusion is taking place, run the script that rotates all tor domains, without informing the servers under attack of the new addresses. The upstream mixers under attack will no longer be able to reach the downstream mixers. This security measure will shut in the attacker. If you have redundant server images still up and running, it should not affect the live process. Furthermore, shut down the payment process for the time to reinstall compromised server images.

Conclusion

Contemporary software engineering of server platforms revolves around MVC. In terms of security, such development method is completely wrong. It forcibly introduces security issues that you may otherwise not have.

MVC is an ideological belief quite similar to the belief in the communism. People do not believe things like MVC because they would be able to axiomatically and exclusively reduce its untruth to the untruth in particular stated axioms (math) or because they are backed by repeatable experiments in which we could find counterexamples (science) or because they can corroborate numerous written witness depositions (history). He does not believe this because he has used the methods that allows us to harness the laws of nature, but because the average developer is just like the average person in general: an incorrigible pagan.

Security has nothing to do with calling the police (it will be too late) or with regulations (they are ineffective and probably unwanted). It is purely a technical problem. You either solve it or else your platform gets robbed.