How vigilance saved a startup from a sophisticated robbery

Bitcoin and security tend to go hand in hand. The wallets are mostly electronic; there are no charge backs; and, done correctly, it can be impossible to track who stole what funds.

That makes businesses that operate with Bitcoin prime targets for criminals and also means these businesses have to be pretty savvy if they want to survive.

Case in point is Bitcoin Video Poker, an retro-style online gambling house where players use Bitcoin to purchase credits. It recently launched and had enjoyed its 100 percent uptime for a while, until what seemed like a network issue knocked it offline for several hours until its server restarted.

As one of the company's employees explains on Reddit, the outage was actually an attack on its infrastructure, likely going after the Bitcoin wallet that the site uses to store funds.

It doesn't have to be a Bitcoin wallet that makes a business an interesting target for criminals. It can be intellectual property, a list of clients, personal information (Anonymous trying to prove a point, anyone?), or credit card information. Bearing this in mind, there are two things in particular that this startup did that any business could learn from.

The first was a high level of vigilance on server logs and tracing back over what had changed in its infrastructure.

Admins from the startup took a look at the running processes on the server, finding a foreign script in /etc called bitcoin.sh, and a scheduled task in crontab to restart it. This phoned home to the attacker's machine, presumably to allow for remote access.

This activity was also correlated in logs as occurring during the time that the server was meant to be inaccessible, raising more red flags.

The second was the use of encrypted partitions. The gaming services, along with wallet information, were contained within a protected partition that does not automatically mount in the event of a reboot. While this meant that the startup couldn't return to business immediately, it also meant that the attacker was unable to compromise the system any further.

But how did the attacker even get that far?

If the server's filesystem is relatively standard, writing to /etc implies root credentials were used to access the system. While the startup's credentials weren't compromised, it turns out that the server itself physically was, in a way.

The startup's admins had noted that its server had an open login on /dev/tty1, but this should almost never happen in a datacentre unless someone is in the racks.

After talking to the hosting provider, it was revealed that yes, someone had been in the racks, but the person had been authorised to install a remote keyboard, video, mouse (KVM) console. This would allow for the remote administration of a machine as if the operator was there.

But the startup never authorised the installation of such a device. This is where its attackers took a different angle to their attack. Using a vulnerability in the host's HostBill software, the attackers ordered and authorised for the remote KVM to be installed. The webhost none-the-wiser, complied, not knowing it was physically installing a backdoor for its customer.

Once installed, the attacker rebooted the machine to get into single user mode, effectively bypassing the server's login procedures, and enabling them to write to the filesystem and grant themselves root privileges. This is where the attackers hit a wall as, without the key to remount the encrypted partition (and not storing this key on the server is an important practice), they were unable to steal anything valuable.

The final twist is that the script that the attackers left running pre-empted this. Its purpose was to wait for the startup to restart its services and unlock the encrypted partition. Which takes us again back to the first point of always being vigilant about what is happening on your server.

There are so many places where this could have ended badly. A lack of encryption would have spelled disaster, an oversight of what was going on would have seen them open themselves up to theft, and sheer laziness could have seen them store the keys on the server. The startup has said, perhaps modestly, that encryption saved the day, but had it not been for a keen set of eyes, it might have all turned out very differently.