Preventing ServerSide CryptoJacking

Intro

Bitcoin and associated cryptocurrencies have brought a lot of greed along with their meteroic rise - not of which the criminal element is amongst. Cryptojacking is the act of placing software on end-user computers or servers to mine cryptocurrency.

Compared to ransomware the big difference from a financial point of view through the attackers eyes is that cryptojacking starts to generate revenue as soon as it infects a machine while ransomware depends on the organization paying out the ransom.

What a lot of people don’t know is that cryptojacking is not regulated to the armies of unsecured windows boxes laying scattered throughout large enterprises.

There are three distinct types of attacks. One is targeted for servers, one for end-user devices and one through the web such as your company’s website.

Slow computer performance can be an indicator of cryptojacking activity as well as complaints that the site is slow.

Web

Cryptojacking is becoming such a large concern that there are now coinblocking lists to block malicious javascript being ran on various sites - much like adblocking software.

So one of the popular forms of attack uses this site called coinhive. Coinhive is this site that allows people to mine monero, a cryptocurrency, with a javascript based miner.

One humorous yet sad case of a coinhive based attack was that it infected a federal agency’s website but it didn’t actually load cause the site had a bad ssl cert. I guess that’s one way of protecting your infrastructure but not advised.

Attacks using this are actually particularly dangerous since it’s javascript. Modern day websites can’t escape javascript - it’s going to be used, however, current javascript development trends involve utilizing plenty of 3rd party software. This is particularly dangerous as it becomes much easier to accidently include cryptojacking code into it.

At first blush the javascript attack doesn’t make much sense but when you start to realize that javascript runs on end-user computers each site it infects immediately commandeers that entire website’s audience.

So that’s web facing cryptojacking. Let’s talk about server crypto-jacking.

WebLogic

Earlier this year attackers made over $200,000 mining monero on weblogic servers.

The "exploit" here was simply POSTing a small SOAP message to the poor server. Soap is this older REST like protocol based on xml.

In fact around here some developers consider REST itself to be old so this tells you something.

The exploit literally calls this class called java.lang.ProcessBuilder and passes an argument of /bin/sh.

This type of stuff is just disgusting. There is no good reason in 2018 that this should be a thing but it is.

Drupal

Next up we have DrupalGeddon. Drupal hosts up to 1M websites around the world including government and financial institutions.

Recently there was an input sanitization problem on the form builder.

As it seems to be always the root case (pun intended) - the ability to execute shell commands is when the attacker wins and you lose.

Through a simple single curl command attackers could force the drupal application to download new software and spawn a shell.

One of the parameters here would locate the part of the form but in this case it would download a malicious payload using wget.

Listen, programmers create bugs like this all the time - it’s just a part of the process of writing code, however, we don’t have to make it so easy for attackers to launch their attacks against us. We don’t have to deploy software this way.

What’s crazy is this actually happened months ago - what’s new?

What’s new is that it’s *still* being used for a cryptojacking attack. Over a 100k sites are still vulnerable to this attack.

While this exploit wasn’t as trivial as the weblogic craziness it still boils down to the same style of attack - that is using remote code execution via the shell. This is precisely the type of attack that unikernels help prevent.

Unikernels stop attacks like this because they only run one program and there is no way to “shell out” and run other programs. It’s a foreign concept to unikernels. There are no users and there is no way to login to the host.

So we know upgrading from version to version and keeping track of every new CVE out there is difficult for many organizations but what if you could start with a more secure substrate that this software lives on? That’s the promise of unikernels.