Routers turned into zombie cryptojackers - is yours one of them?
- Users and sysadmins. Patch early, patch often.
- Vendors and programmers. Don’t store plaintext passwords.
Security researcher Simon Kenin at Trustwave pieced the story together, following reports that there seemed to be a surge of web-based cryptojacking in Brazil.
Kenin quickly realised that Brazil was something of a red herring in the story, because the attack was happening wherever the crooks could find unpatched Mikrotik routers.
Brazil just happened to be where the story broke – it is, after all, the fifth most populous country in the world, so there are a lot of Brazilian home and small business networks for crooks to find and attack.
Here’s how this cryptojacking attack seems to have gone down.
Back in April 2018, Mikrotik patched a remote access vulnerability in its products.
As far as we can tell, Mikrotik discovered the security flaw itself, describing it in basic terms as a vulnerability that “allowed a special tool to connect to the [administration] port, and request the system user database file.”
As it turned out, there was a bit more to it than that – the bug allowed any file to be read off the router, effectively giving crooks who knew the trick the opportunity to leech any data they wanted.
The user database file just happened to be the crown jewels, because Mikrotik had stored both usernames and passwords in plaintext.
As any regular Naked Security reader will know, you almost never [*] need to store passwords in a way that they can be recovered.
You can verify that a supplied password is correct by matching it against a database entry computed from the password using a cryptographic technique known colloquially as salt-hash-stretch.
Simply put, you hardly ever [*] need to store actual passwords in files on on disk, or even to store encrypted versions of passwords that can be unscrambled on demand.
That’s because you typically only need to check that a password was correct, not to record permanently what it was.
Sure, the crooks aren’t supposed to be able to steal your user database file in the first place, but there’s no point in making your username file into an instant password giveaway if it does get stolen.
How the bug was weaponised
Unfortunately, perhaps, a pair of security researchers going by @n0p and @yalpanian took Mikrotik’s patch and reverse-engineered it to recover the bug it was supposed to fix.
They subsequently published a proof-of-concept exploit, written in Python, that showed how to use the recovered flaw to extract the admin password from an unpatched Mikrotik router.
Exploits of this sort are sometimes considered to be “mostly harmless”, assuming that the exploit comes out after there’s been time to apply the patch.
In practice, of course, patches are often ignored for weeks or months, so that proof-of-concept exploits are also warmly welcomed by cybercrooks.
Anyway, the crooks in this cryptojacking saga seem to be using the Mikrotik admin-port attack vector (we have no idea if they actually started with n0p’s proof-of-concept or figured it out for themselves) to do their dirty work.
Sneakily, this particular router takeover didn’t require any code hacking or low-level network trickery.
According to Kenin, the crooks simply replaced a file called error.html, transmitted by Mikrotik’s built-in web proxy whenever there’s an HTTP error, with a web page that loads the CoinHive browser-based cryptomining software.
In other words, if you’re at a coffee shop where the owner has an unpatched Mikrotik router and has configured it to push all HTTP traffic through the web proxy, you’ll end up cryptomining on behalf of the crooks every time there’s a browsing problem.
Silently redirecting all web traffic in this way is known as transparent proxying. It’s not unusual on free shared networks such as coffee shops, trains, airports and so on. Often, the network operator isn’t trying to spy on you, or to censor your browsing. The goal is simply to block access to sites that eat a lot of bandwidth a lot of the time, such as video streaming or gaming servers. This helps to spread the available bandwidth a bit more fairly amongst all users.
Will the crooks get rich?
We doubt that the crooks will make much money here, so we’re hoping that their enthusiasm for the this sort of attack will wane pretty quickly.
You’ll only get cryptojacked if you are browsing via the Mikrotik proxy; the cryptojacking will only kick off when there’s an error to report; and the cryptomining will only last until you exit from the browser tab with the cryptomining code in it.
You’re very likely to notice the cryptojacking, not least because your computer will slow down as its processors dedicate themselves to cryptomining.
If you have a laptop with cooling fans, you’ll probably them kick in at full throttle to deal with the heat generated by the cryptojacking.
Also, Mikrotik’s proxy only supports HTTP, not HTTPS.
Transparent proxies can’t peek inside HTTPS traffic without your explicit agreement, because the data in an HTTPS session is encrypted by your browser and, by default, can only be decrypted when it reaches the web server at the other end of the link.
So if you stick to HTTPS you won’t be sending traffic through the router’s proxy anyway.
What to do?
If you have a Mikrotik router, you really do want to patch this hole.
Firstly, cryptojacking is bad in absolute terms, even if the crooks only do a tiny bit of it very occasionally.
Secondly, if cryptojackers can reconfigure your router this easily, other crooks could hack you, too, perhaps with more serious side-effects.
So, here are our two initial points again, with a bonus piece of advice for good measure:
- Users and sysadmins: patch early, patch often. For better or for worse, patches may end up being the public documentation of how a security hole works – it’s usually much easier to go backwards from a patch to an exploit than to figure out the exploit from first principles. In other words, the longer you leave it before patching, the longer you give the crooks to work back from the fix to a viable attack.
- Vendors and programmers: don’t store plaintext passwords. You almost never need to – you can store salted-hashed-and-stretched passwords instead so that a breach of your password database means the crooks still have plenty of work to do to figure out what passwords match which hashes. Users who change their passwords quickly will beat the crooks to it, and the old hashes will be useless.
- Everyone on the internet: stick to HTTPS as much as you can. Why use HTTP, which makes it really easy for crooks to intercept, spy on and tamper with your browsing, when you can use HTTPS, which makes all of those things very much harder?
By the way, even if you don’t have any Mikrotik hardware, why not check your own router for an update – and why not do it today?
via nakedsecurity
