#drupal

Introduction

Every business that has an online presence depends on content management systems to manage their website and blog. There are so many different kinds of content management systems around, so which one would be the best for your business? Each content management system has their own qualities and features, so choosing one out of all of them would be tough.

The benefit of using CMS is that it doesn’t require high level coding knowledge and so anyone with minimum coding knowledge can create functional pages and modify the website themselves. In this article, we would be discussing Drupal and Webflow, two of the most popular CMS around.

What is Drupal?

Drupal was founded way back in 2001 by Dries Buytaert in Belgium. The name for the CMS was initially intended as Druppel, meaning droplet in Ditch. But he accidentally misspelt the name to Drupal while he was searching for a domain name, and the name stuck. Ever since it was introduced into the world, Drupal became one of the most popularly used CMS around, used by millions of websites, including small websites, huge corporation websites, government agencies etc. The web developer community of Drupal grew and eventually you had documentation and support.

The multiple features of Drupal contributed to its major success:

Drupal 10 Poll Module | 2023

The Poll module at https://www.drupal.org/project/poll is great but doesn't work with Drupal 10 unless you use the 8.x-1.x-dev version.

Another Windows machine down; again, I can’t say this was particularly difficult.

It has a rating of medium but I’m unsure why if I’m honest...Perhaps there’s more resources out on the two attack vectors?

It took me a little longer than I’m happy with but I’m afraid web apps are where I lack at the moment- I spent a considerable amount of time checking for SQL injection, XML-RPC weaknesses and it also doesn’t help that my Kali Linux VM can’t connect to Ruby servers for downloading Ruby libraries (or gems)- after spending some time attempting to solve that issue I simply hopped over to my host to get the bastard rooted. ;P

So, my enum script (since made amendments to this: it wasn’t picking up some files it should have such as robots.txt) and then manual checks:

There are 3 logon forms- one to login, one to register and one for password resets- and some misc web app config files such as CHANGELOG.txt and robots.txt.

CHANGELOG reveals that Drupal is running on version 7.54 while robots shows an array of disallowed URLs.

Firstly, I performed some checks on the present forms and I did discover the existence of user ‘admin’ via the password reset form: existing users can be enumerated as the server will respond with username/email not recognized for non-existent usernames and an error on sending a reset email to valid usernames.

I played around with both this and the login form for a while- tried some classic SQL injection cases and alike; unfortunately for us, we’re temporarily locked out if we enter the incorrect password 5 times.

Now this is a shame for the brute force queen... My first thought with login forms is brute force if there doesn’t seem to be any other vectors present. Taking this as a sign that I was barking up the wrong tree, I moved on to instead seeing if there were any other users on the server by utilizing a username brute force script I have in Bash on the password reset form while I looked around a bit more.

It was around here I ran into drupwn- a Drupal web API enumeration tool written in Python. It’s a bit rubbish to be honest as it has a tendency to hang and requires you to manually stop the running process; it did reveal that my enum script had missed robots.txt and CHANGELOG in it’s execution (since been amended.)

It also revealed the version of Drupal in-use; the script probably just looked through CHANGELOG and grabbed the mentioned version.

I did look into these files but robots had alot of entries that -as an inexperienced web app hacker- would have taken me hours to manually test while CHANGELOG revealed nothing but the version of Drupal in-use.

With the version of Drupal identified, however, this did mean that searching for public exploits was a great deal easier. I took to searchsploit -a native Kali Linux tool- and discovered several Drupal exploits:

Here we see mentioned Drupalgeddon3 and 2; by process of elimination we know 3 wouldn’t work due to a lack of valid credentials. If any, the vulnerability in question is exploited by Drupalg2.

Drupalgeddon2 (https://github.com/dreadlocked/Drupalgeddon2) is a remote-code execution vulnerability resulting from a lack of input validation on form API AJAX requests. This allows users to inject malicious payloads -in the form of renderable arrays- into the create user form.

In the case of the registration form, this applies to the mail parameter- by setting the values of indexes [#post_render][] to exec, [#type] to markup and ][#markup] to our desired system command we gain RCE (I briefly just tried to exploit this manually but I simply used dev tools within FireFox browser, probably would have succeeded if I’d tried through Burp Proxy or similar!)

It was at this point that I had to switch over to my host to finish up; honestly at this point the bulk of enumeration is complete.

drupalgeddon2>> whoami nt authority\iusr

iusr is essentially Window’s version of an ‘anonymous’ user that is utilized by default by IIS servers in order to access the required system files.

We can grab the user flag from Users/dimitris/Desktop instantly; thankfully there’s further privilege escalation needed for complete admin access!

By following any WIndows privesc cheatsheet, you should check out the privileges on the logged in account and see that we have an interesting one named ‘SeImpersonatePrivilege’- the ability to impersonate a client after authentication.

From previous reading I was aware that this Windows privilege basically means we’re system as there is a well known privesc technique for this called Juicy Potato- the last step is simply seeing how we can download files onto the victim and finding the relevant CISID for our Windows version. Bastard is a Windows 2008 server- as revealed by checking systeminfo.

After some trial and error, I managed to utilize CertUtil:

CertUtil was originally intended to be used to display CA (Certificate Authority) config information and to also make any neccessary alterations to CA components (basically an administrative tool for all things CA related :3)

Part of CertUtil’s functionality includes the ability to download files... Don’t ask me why they thought this was safe. I guess it was in the event of needing third party CA templates (basically pre-config of CA via certificate templates)?

With netcat and JuicyPotato now on our victim, we are able to exploit this privilege for a reverse shell.

This vulnerability is famously named Rotten Potato and -at a simple level- involves tricking AUTHORITY/SYSTEM into authenticating via NTLM to a TCP endpoint under our control.

This authentication process is then captured via a local MITM attack utilizing several Windows API calls. Finally -with one of the relevant privileges- we use the captured token for impersonation, thus gaining the ability to execute commands as SYSTEM.

For those who didn’t guess by the screenshot, a reverse shell is established through our run of jp.exe (I was running a nc listener on port 6969 to receive the connection) and we are able to read root.txt from Administrator’s Desktop directory.

The CLSID I used was obtained from https://github.com/ohpe/juicy-potato/tree/master/CLSID/Windows_Server_2008_R2_Enterprise.