Seriously? No POC till now...

[sankalpsingha]

I am starting to wonder if Drupal was trolling all of us.

[Leksat]

Really low chances that this was a trolling.

They implemented request sanitization instead of fixing the real problem

• to make it harder to create an exploit,
• to make it possible to mitigate the issue on the server level.

Because there still will be lots and lots of websites running on an outdated Drupal version.

(That's only my guesses)

[RicterZ]

But there are so many security researchers cannot find the way to exploit Drupal, it's weird :(

[xuxuedong]

@sankalpsingha what's meaning of "trolling all of us" ?

[SpoiltNX]

I find it so hard to believe nobody has figured this out yet. I had a big deadline sucking up all my time, so when the news came out I did not spend any time trying to figure it out. Now that my deadline is over I spent 30min on my phone scrolling through the drupal bootstrap process in D6 and D7 and I think I found what the exploit is related to.

I dont know how you would deliver the payload but it makes sense to me. I am not going to point out the actual code her, I think people should work for their lunch but hear is a tip.

Its a remote code execution vulnerability, so we talking callbacks and the patch removes anything stating with a '#'.

$function = $_POST['#own_me'];
$result = $function($_POST['value']);

The patch is very clever on Drupals part because they fix the problem without directly drawing attention to it.

[sankalpsingha]

@SpoiltNX : There are people who are trying to figure out the vulnerability for a long time, and what you have suggested has already been known, if you feel that is the correct exploit ( highly doubtful ), please create a POC.

[Eyal-Shalev]

After research done by me, Rotem Reiss and Eran Vaknin we were able to uncover what was the vulnerability in the latest security patch.

Read more in the white-paper that was published in Check Point: https://research.checkpoint.com/uncovering-drupalgeddon-2/

[3kings0xFF]

Just got done reading your research online about 4 minutes before this email came out. Great job with the write-up! I expect a script to be made within the next hour.

…

On Thu, Apr 12, 2018 at 11:22 AM, Eyal Shalev ***@***.***> wrote: After research done by me, Rotem Reiss and Eran Vaknin we were able to uncover what was the vulnerability in the latest security patch. Read more in the white-paper that was published in Check Point: https://research.checkpoint.com/uncovering-drupalgeddon-2/ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGLSwnxAvVrKlbYgkyncgz0K8cUqI36Lks5tn39jgaJpZM4TGr7U> .

[AlbinoDrought]

Thanks @Eyal-Shalev

Barebones exec PoC: https://gist.github.com/AlbinoDrought/626c07ee96bae21cb174003c9c710384
Netcat reverse shell: https://gist.github.com/AlbinoDrought/2854ca1b2a9a4f33ca87581cf1e1fdd4

Testing can be done with docker4drupal - just grab a version before the RequestSanitizer patch.

Demo steps:

1. Clone the docker4drupal repo: git clone https://github.com/wodby/docker4drupal.git .
2. Change the DRUPAL_TAG in .env to a vulnerable version (8-7.1-4.2.3): sed -i -e 's/^DRUPAL_TAG=.*/DRUPAL_TAG=8-7.1-4.2.3/g' .env
3. Start docker4drupal: docker-compose up
4. Setup your hosts file: https://wodby.com/stacks/drupal/docs/local/domains/
5. Setup Drupal: http://drupal.docker.localhost:8000/
6. Run the PoC

[SpoiltNX]

@sankalpsingha So now that all the details are out in the open, exploit and all, the code I was alluding to that I found was the drupal_render() function in D6 & D7. A little more difficult to find the offending code in D8 but still present and specifically the #pre_render attribute, confirmed to be one several attackable attributes by the latest findings and now exploit.

CVE-2018-7600 In a nutshell

  if (isset($elements['#pre_render'])) {
    foreach ($elements['#pre_render'] as $function) {
      if (function_exists($function)) {
        $elements = $function($elements);
      }
    }
  }

@Eyal-Shalev Nice work guys really enjoyed the paper. The Drupal FAPI is one the aspects of Drupal that makes it so flexible but at the same time has contributed to its slowness over the years with multiple passes on very large nested multi-dimensional arrays and a big part of this flexibility is the callbacks hooks system and white papers like yours are a good thing for any dev to read to create awareness around security and consequences of good ideas. Going forward, whenever I developer any dynamic callback method I will be stopping and thinking about the source of callback and arguments. For me it is the same as the first time I learnt about SQL injection. After that point I changed the way I looked at DB queries.

Thanks to all involved. Including the Drupal Security Team, the patch was very clever to not draw attention to the offending code, giving time for people to patch and update and making this easter-egg hunt to find the exploit even more interesting, like a real Drama building tension and intrigue, with some even questioning the validity of the original announcement.

Even with all this I know of more than one company with hundreds of un-patched sites even with me warning them and providing instructions to patch D6 sites. Now they must suffer the consequences.