Slashdot Mirror


'Drupalgeddon2' Touches Off Arms Race To Mass-Exploit Powerful Web Servers (arstechnica.com)

Researchers with Netlab 360 warn that attackers are mass-exploiting "Drupalgeddon2," the name of an extremely critical vulnerability Drupal maintainers patched in late March. The exploit allows them to take control of powerful website servers. Ars Technica reports: Formally indexed as CVE- 2018-7600, Drupalgeddon2 makes it easy for anyone on the Internet to take complete control of vulnerable servers simply by accessing a URL and injecting publicly available exploit code. Exploits allow attackers to run code of their choice without having to have an account of any type on a vulnerable website. The remote-code vulnerability harkens back to a 2014 Drupal vulnerability that also made it easy to commandeer vulnerable servers.

Drupalgeddon2 "is under active attack, and every Drupal site behind our network is being probed constantly from multiple IP addresses," Daniel Cid, CTO and founder of security firm Sucuri, told Ars. "Anyone that has not patched is hacked already at this point. Since the first public exploit was released, we are seeing this arms race between the criminals as they all try to hack as many sites as they can." China-based Netlab 360, meanwhile, said at least three competing attack groups are exploiting the vulnerability. The most active group, Netlab 360 researchers said in a blog post published Friday, is using it to install multiple malicious payloads, including cryptocurrency miners and software for performing distributed denial-of-service attacks on other domains. The group, dubbed Muhstik after a keyword that pops up in its code, relies on 11 separate command-and-control domains and IP addresses, presumably for redundancy in the event one gets taken down.

30 of 60 comments (clear)

  1. Powerful servers by manu0601 · · Score: 5, Funny

    The exploit allows them to take control of powerful website servers

    Powerful indeed, since you need huge resources to run Drupal decently.

    1. Re:Powerful servers by PeopleAquarium · · Score: 1

      Is there anyone left on the internet who doesn't work for Russia?

    2. Re: Powerful servers by Anonymous Coward · · Score: 1

      The intelligent people left this site long ago.

  2. Drupal Consultants by Anonymous Coward · · Score: 2, Interesting

    Big part of the reason there are so many un-patched Drupal sites is the cost of Drupal consultants. Hourly rates in the $200+ range are a big risk vector to consider for small to medium sized sites.

    1. Re: Drupal Consultants by Z00L00K · · Score: 3, Interesting

      I was running drupal and got hit by a monero miner so I scrapped Drupal and php.

      I see this problem as something rooted in php.

      I did a small analysis of what had happened and the exploit created a miner executable file in /tmp that was then moved to /dev/shm and executed there by some action. It had been active for just a few hours as a non-privileged process, so no big deal.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    2. Re:Drupal Consultants by Anonymous Coward · · Score: 2, Informative

      Developers don't get $200 an hour. The firms that employ them get $200+ an hour.

      The work gets farmed out to India, Eastern Europe or South America at a rate of around $25 an hour. Developers in Europe or North America get salaries that work out to between $50 and $75 an hour.

      The drupalgeddon patches are not hard to apply and push to production. I know because I patched the 16 Drupal sites my organization manages, which isn't even my job, I'm a sysadmin.

      The 3 agencies we work with were no help patching the sites. The lowest estimate we received was for 40 hours and it would take 2 weeks from the day the patch came out to complete the work. We could not get them to just apply the patch, we had to buy a sprint.

      Which meant the sites would have already been compromised and our servers probably would have been trashed. This was funny because our agency partners are the people who alerted us about the need to immediately patch our code.

      This isn't the first time we got a red alert about a vulnerability on short notice and were handed a huge bill to apply a patch. We got a budget last week to migrate the sites to other platforms and already know 10 of them are moving to Wordpress.

      The big difference between Wordpress and Drupal is my boss isn't putting her job at risk for choosing Wordpress.

    3. Re: Drupal Consultants by Anonymous Coward · · Score: 1

      The blame is shared between PHP and the Drupal team. Here's an explanation of the vulnerability:
      If you do a POST request to https://example.com/user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax, the PHP function uploadAjaxCallback gets called with its $request parameter containing the request including all the URL and POST parameters. The following line splits the element_parents URL parameter:
      $form_parents = explode('/', $request->query->get('element_parents'));
      Now $form_parents will be an array: ['account', 'mail', '#value'] This array will get fed to a utility function that extracts a value from a multilevel associative array:
      $form = NestedArray::getValue($form, $form_parents);
      The original value of $form is a complex structure, representing the current form including user-supplied data and metadata about fields and such. Why you'd want to give the end user the ability to index into any property somewhere inside that structure is beyond me. In case of the user registration form, the value of $form['account']['mail']['#value'] has been initialised with the value of the POST parameter named mail. This value, which is now considered to be a Drupal render array, is fed to Renderer::renderRoot in order to turn it into HTML. (A render array is an associative array kind of like a DOM structure wherein keys starting with # indicate properties.) This function does some bookkeeping and eventually calls doRender, which gives the render array several ways to specify to call any PHP function, using the following properties: #access_callback, #lazy_builder, #pre_- and #post_render.
      Think about that for a moment. Drupal's got a data structure that is meant to be passed to doRender and which by design can contain executable code. It lets the user pass such a structure to itself and then feeds it to doRender in order to execute it. It's like letting the user upload an executable and then executing it.
      So you could for example execute any shell command by supplying the following POST parameters:
      mail[#post_render][] = exec
      mail[#type] = markup
      mail[#markup] = any shell command

      I think the blame is shared between PHP and Drupal. On the one hand, Drupal should have never used PHP's capability to execute any PHP function. On the other hand PHP makes it much too easy to do this (just use call_user_func(_array) and supply it with a string specifying the function to call) and doing stuff like this is just part of the PHP culture which every native PHP developer lives and breathes. And PHP's sloppy type system also shares responsibility in this case, as does the way PHP is hooked up to the HTML form parameters.
      Every single step in the chain stinks. The generic callback. The way it lets the user index into a private data structure. The way it lets the user supply an executable data structure. The fact that this data structure was designed to be executable to begin with. The fact that the properties which make it executable weren't filtered out. And of course the fact that it's then executed.
      And you know how the Drupal team decided to fix this? By making render arrays non-executable by default, I hear you say? By putting the abovementioned properties in separate modules that are only included when you can be sure that an administrator approved the render array? By making sure that render arrays can only execute code that an administrator approved as being able to be run in the appropriate context? By making sure that the user cannot trick Drupal into believing things are render arrays when they aren't?
      Nope. They did it by recursively stripping out all keys from the POST parameter array that start with #. It's like painting a pile of poo.

  3. Greed is stupid by hyades1 · · Score: 5, Insightful

    Sensible people would briefly use the servers to install a lightweight, hard-to-find bitcoin miner that stayed out of the way until the victim's computer was doing nothing, but still had an internet connection. Don't get greedy. Don't thrash the hard drive or run the graphics card 'til it melts. Just take a little sip here and a little sip there, and rely on having a lot of places to go for that little sip.

    I bet something like that could stay under the radar for a long, long time.

    --
    I've calculated my velocity with such exquisite precision that I have no idea where I am.
    1. Re:Greed is stupid by DontBeAMoran · · Score: 2

      That's what I've been doing. I got scripts all over the planet mining Bitcoins since 1988.

      --
      #DeleteFacebook
    2. Re:Greed is stupid by Z00L00K · · Score: 1

      It's not possible to hide if the server admin runs tools like 'rkhunter'. That's how I saw that my server was impacted.

      And in my case it was a monero miner. I did dig through the stuff in the server and found out the hashed ID of the culprit as well and mailed the monero support with that ID. Haven't heard anything about it but if they cancel the mined stuff without notifying anyone then I'm good with that too.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    3. Re: Greed is stupid by phantomfive · · Score: 1

      If it's running on AWS your get a month at most before the server is shut down and replaced with a freshly running instance.

      --
      "First they came for the slanderers and i said nothing."
    4. Re:Greed is stupid by TheRaven64 · · Score: 1

      It's not possible to hide if the server admin runs tools like 'rkhunter'.

      I've not heard of rkhunter before, but from how it works I can think of a few ways to hide. It doesn't appear to scan the contents of kernel memory, so if you're able to inject running code into the kernel and masquerade as a low-priority kernel thread then it won't be noticed. It also isn't able to scan into SGX enclaves, or into any of the (now compromised) trusted firmware on AMD systems, the latter of which gives you a good way of persisting your malware across reboots.

      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.

      On the plus side, it would be rebuilt by the beginning of next week.

      --
      I am TheRaven on Soylent News
    5. Re:Greed is stupid by Bongo · · Score: 1

      I believe rkhunter made an appearance in Mr. Robot.

    6. Re:Greed is stupid by hyades1 · · Score: 1

      Thanks for that. If possible, I'd give you points for "Informative".

      --
      I've calculated my velocity with such exquisite precision that I have no idea where I am.
    7. Re:Greed is stupid by mikael · · Score: 1

      I've noticed on some Linux PC's that using lsmod will provide a list of modules and how many modules plus their names are depending on it. But in some cases the "Intel" module has about 5 other modules using, but they aren't listed.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
    8. Re:Greed is stupid by Z00L00K · · Score: 1

      Anything that would annoy the illegal miner is fine by me.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    9. Re: Greed is stupid by houghi · · Score: 1

      They do a shory con. So better to do 100% fir 1 hour. No idea how long they can do it. Could be that they need to close after 24 hours. Or sooner.

      If they wanted to do the long con, they would have started a bank.

      --
      Don't fight for your country, if your country does not fight for you.
  4. Probed constantly by ve3oat · · Score: 5, Interesting

    I don't run Drupal but in a six hour period Saturday morning even my little website was hit on from 147 different IP addresses, each using 4 or 5 requests in rapid succession. Made my logs hard to read.

    1. Re:Probed constantly by bobstreo · · Score: 1

      I don't run Drupal but in a six hour period Saturday morning even my little website was hit on from 147 different IP addresses, each using 4 or 5 requests in rapid succession. Made my logs hard to read.

      If they're hitting the same URL, just make sure the URL refers to a 2TB random file.

      Or you could start whitelisting/blacklisting or banning IP's trying to access resources that shouldn't be accessed.

    2. Re:Probed constantly by ve3oat · · Score: 1

      I didn't have a 2 TB file to give away but after all the activity the previous day (Friday), I made sure the URLs they were after would give them only a "403" response instead of the usual "404", just to make a point. There were only a few isolated probes after about 1230 UTC Saturday. I wonder if the attacks continued on other sites after they ended on mine.

    3. Re:Probed constantly by Xenna · · Score: 1

      What do these probes look like in the logs?

    4. Re:Probed constantly by ve3oat · · Score: 1

      Looked like this :
      "GET / HTTP/1.1" 301 226 "-"
      "POST /wls-wsat/CoordinatorPortType HTTP/1.1" 400 17 "-"
      "POST /user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax HTTP/1.1" 403 15 "-"
      "GET / HTTP/1.1" 301 226 "-"
      "GET / HTTP/1.1" 301 226 "-"
      "GET /rss.php?mode=recent HTTP/1.1" 403 15 "-"
      "GET /wp-login.php HTTP/1.1" 403 15 "-"
      Mostly in rapid succession but sometimes spaced out over several minutes. Requests for wp-login.php were sometimes omitted. UA was "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36" or very similar. All attacks were against my IP address, so requests for the home page got automatic redirects to the domain (which they ignored).

  5. Code of Conduct by Anonymous Coward · · Score: 1

    That's ok, Drupal's code of conduct specifically bans malicious hacking because it isn't nice. That, and any form of kink that doesn't have a parade and could be inconvenient for Dries's IPO.

    God bless the Drupal CoC.

  6. Drupal is awful by Anonymous Coward · · Score: 1

    It's worse than Wordpress. That's saying something.
    These garbage cms's that have an established base of "developers" with a lot of sunk costs becoming "experts" need to die. Maybe a good, easy to use cms will come along but it won't be Drupal or Wordpress.

    1. Re:Drupal is awful by Anonymous Coward · · Score: 1

      Concrete5, Statamic, and Pagekit. ExpressionEngine and maybe Joomla except for the ease of use condition...

  7. Great source article by scdeimos · · Score: 5, Informative

    Noice... TFA links back to the 2014 security advisory and completely misses a link to the current 2018 security advisory.

  8. Re:Windows or Linux servers? by Z00L00K · · Score: 3, Informative

    It's not really a Linux issue, it's a PHP / Drupal issue.

    PHP is as it's designed a potential security risk and any code written is "dirty" since it's hard to validate and is a mix of code, HTML and Javascript. So even a slight error in coding in PHP can lead to "interesting" side effects.

    --
    If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  9. why does anyone use it anymore? by gravewax · · Score: 1

    Why the fuck does anyone still use Drupal, it has proven time and time again to be a total clusterfuck when it comes to security and doesn't seem to be improving. It is like the turds MS churned out in the late 90's.

    1. Re:why does anyone use it anymore? by gravewax · · Score: 1

      yeah... there is just 2 in the last 4 years! I hope to hell you aren't a drupal server admin. https://www.drupal.org/securit...

  10. Drupal is WP in worse and without the userbase. by Qbertino · · Score: 4, Interesting

    Disclaimer: I've used and developed for both Drupal and WP professionally, for a living. A good living.

    Like most PHP systems Drupal is built by monkeys on crack with zero clue about proper software architecture. Unlike WordPress though it doesn't have a 140 million+ installbase and an army of people messing around with it every day and patching holes as they pop up just about instantly. This is a problem. Add to that the fact that while both WP and Drupal are built by people who didn't know squat what they were doing when they started out, WP actually makes it somewhat easy to code around it's mess, just using a few utility functions from WP core to latch on to the DB and the user management and stearing clear of the rest of the mess, getting to doing real work roughly 10 minutes in to your first WP plugin.
    Drupal OTOH is a mess through and through *and* forces you to follow along, making development much more difficult. Which is why the installbase is 'only' a few million which AFAICT isn't enough to compensate for crappy webapps built by n00bs in PHP. I expect Drupal holes like this one to be much more of a problem vis-a-vis WPs holes, simply because the userbase is orders of magnitude smaller than of WP.

    My 2 cents.

    --
    We suffer more in our imagination than in reality. - Seneca