[Penetration Testing] Drupal RCE / Win32k.sys Kernel Exploit

TRY HARDER: A Blog About Discovery

Author: Brennan Turner @BLTSEC
Foothold: Drupal 7.x Services Module RCE
Escalation: Win32k.sys Elevation of Privilege (CVE-2014-4113)

Mission: Investigate the system named Bastard ( and determine if any vulnerabilities exist. If vulnerabilities do exist determine if they can be exploited. Finally help mitigate risk by suggesting security controls to implement.

Disclaimer: Let’s first answer a question that may already be on your mind, the server’s hostname is actually “Bastard”. I didn’t give it this name due to frustration! This is a test system and some of the below methods shouldn’t be done in a production environment. Use these techniques responsibly and ethically and always test every flag, switch, command, and exploit in your own test environment prior to running in a customer’s environment.

Engage: I began the enumeration process by scanning the system with nmap. I used the flags below to determine the operating system, perform a faster scan, gather details of the discovered ports and their associated services and finally output the results to a variety of formats.

Typically if I determine a web service is present I will investigate there first, this is due to the fact I enjoy writing web apps in various languages and frameworks and I’m a developer by trade. Yes…I even like developing Java applications! I fired up Burp’s proxy to capture my manual investigation and spidering of the site. I configured my browser to use the proxy and then I browsed to I was presented with a Drupal page without any content but there was a login form on the page. I then looked at the headers in the browser’s developer tools and found some interesting details pertaining to the versions of Drupal, PHP, and IIS as well as the HTTP Security Headers. I usually look at the headers first before using a tool because details can be gathered quickly and passively.

After reviewing the nmap scan and browsing the site and headers I wanted to check out the Drupal instance running on port 80 in greater detail, so I decided to check out CMSmap for further enumeration! I’ve been waiting for an opportunity to try out CMSmap for content management services like Drupal or Joomla since WPScan is pretty fantastic for WordPress instances.

Burp’s proxy is really nice to track all of the pages you’ve visited and spider directories further if needed.

The next thing I did was search Google for Drupal 7.54 exploits and discovered the one below: https://www.ambionics.io/blog/drupal-services-module-rce

Exploit: The exploitation of the Drupal vulnerability allowed for privilege escalation, SQL injection and, finally, remote code execution. Services is a “standardized solution for building API’s so that external clients can communicate with Drupal”. Based on the example shown in the article above I manually tried to find the endpoint path and after a couple of tries I found it. There are tools that can help with this process by fuzzing parameters and wfuzz is a fantastic one to use to accomplish this. The options below run the request through Burp’s proxy, color code the findings, loads the file payload with a specified wordlist, and finally only displays results with a response code of 200.

I browsed to which was the path of the rest api. The word “rest_endpoint” was the name given to identify the endpoint. I had to look at Drupal’s documentation to understand how to set a Services Endpoint up in Drupal since I wasn’t familiar with this cms.

When I browsed the site I noticed the path I accessed this endpoint using the rest api. which displayed a user friendly database lookup error on the page.

I then crafted a request in Burp’s Repeater tab using the rest url and /user/login endpoint and it was apparent I would need a valid account to access anything further in the site., I tried using a fake email account and I received an error message saying the email wasn’t sent. Since this was a test system I went to https://www.mailinator.com/ to use a temporary email account in hopes that the service just needed a valid email to relay a password to the user. I attempted to create an account and the email service still issued an error.

After investigating the authentication process briefly with the above methods I went on to read more about the exploitation process. One of the features of the module is that a client can control the input/output format by changing the Content-Type/Accept headers. This content type in particular “application/vnd.php.serialized” is given to PHP serialized data. The vulnerability occurs with the unserialize function. More Information ca be found here: http://php.net/manual/en/function.unserialize.php

Based on the details gathered from attempting to authenticate as admin with the POST request above and reading on Drupal’s Services documentation the endpoint is used to retrieve and compare stored credentials in the database. The endpoint being /user/login.

Breakdown: Drupal’s api allows users to not only submit queries using the string type but also submit objects in subqueries. During the serialization process the object’s string representation is used directly in the sql statement and this allows attackers to be able to call the object’s methods. Basically the exploit is possible because of a sql injection vulnerability which allows an object to be deserialized and the object’s methods to be called. The next step is to create the file on the web server that we can access in order to get a shell on the system. The Services module caches every endpoint and an attacker can modify the cache to call any php function. The DrupalCacheArray class specifically allows an attacker to modify the /user/login endpoint and cause the endpoint to create a malicious php file. An attacker could then access that url which would execute the malicious payload. For more details please read the article in it’s entirety.

I looked at the php exploit code and acknowledged I had all of the required values to make the exploit execute successfully. What I found interesting about this exploit is that it could be used on any url as long as the deserialization functionality was enabled in the Drupal instance. After I plugged in the endpoint values I decided to also swap the included php payload with my own. The logical choice was to use a php meterpreter payload like the one below:

I had trouble getting this payload to stay alive long enough to migrate to another process, eventually I attributed this problem to packet loss though.

I then decided to generate a PowerShell payload using PowerShell Empire instead of using the php meterpreter payload. I then used php’s system function to combine this payload with the exploit provided in the Ambionics article. I created a listener in Empire to catch the connection initiated by the execution of the payload.

After running the exploit I received two json files written to my local directory, one contained the admin user account’s hashed password, attributes, permissions, etc. The other json file contained the session details such as id, name, and token. I also received a message that the file uploaded successfully. I accessed the file from my web browser and received my empire agent.

I performed some quick enumeration of the system and gathered a few more details. I wanted to check for more vulnerabilities on the system in hopes of escalating privileges.

I’d been hearing a few people mention Windows Exploit Suggester so I decided to try it out. https://github.com/GDSSecurity/Windows-Exploit-Suggester Interacting with my empire agent I ran systeminfo and exported the results to a txt file, I downloaded the file and then used it with Windows Exploit Suggestor.

I decided to look up a few of these exploits using findsploit https://github.com/1N3/Findsploit for more information and see if there were any metasploit modules I could read more information on and determine if Bastard ( was vulnerable to these exploits.

As I looked into the details of the Metasploit modules I noticed some of them needed a metasploit session in order to execute so I used one of Empire’s features to pass an empire agent’s session to a metasploit handler. I first setup a meterpreter listener in Empire. I then used PowerSploit’s Invoke-Shellcode.ps1 injectshellcode module which injects shellcode to stager meterpreter’s reverse listener into foreign processes. I used the Empire meterpreter listener I just created with the injectshellcode module. I then setup a meterpreter reverse handler in metasploit to listen for the incoming connection.

I executed Empire’s injectshellcode module in my Empire’s terminal window and watched as a meterpreter session opened in my Metasploit’s terminal window!

Escalate: The first thing I noticed is that the x64 Architecture of the system, this means in order to escalate my privileges it would probably be in my best interest to migrate to a x64 bit process. I migrated successfully to conhost.exe which was really my only option for a x64 bit process at the given moment. I began researching online for potential exploits after reviewing the suggested exploits from Metasploit’s suggester as well as GDS’s suggester.

After reviewing these exploits and narrowing down the exploits based on the supported target’s architecture and operating system I decided to try the CVE-2014-4113 kernel exploit detailed by Microsoft’s MS14_058 security bulletin which as outlined by this article http://www.cvedetails.com/cve/CVE-2014-4113/ states that win32k.sys in the kernel-mode drivers in Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 allows local users to gain privileges via a crafted application, as exploited in the wild in October 2014, aka “Win32k.sys Elevation of Privilege Vulnerability.” It didn’t take long for the exploit to execute and then spawn an escalated System command prompt!

Mitigations: Let’s discuss the Drupal RCE first, in order to mitigate this problem it would be best to obviously patch the instance. However, patching isn’t always done instantaneously so disabling application/vnd.php.serialized option would help prevent this exploit in the meantime. This mitigation is explained in the Ambionics article. The specific patch is also listed in the article. Now let’s discuss the Windows kernel exploit. The exploit can be mitigated by following one of the various patch methods mentioned here: Microsoft Knowledge Base Article 3000061