Passwords, hashes and Flags will be redacted to encourage you to solve those challenges on your own.
Synopsis
“Armageddon” is marked as easy difficulty machine which features Apache, hosting vulnerable Drupal CMS on Linux OS. We exploit Drupalgeddon2 vulnerability to gain initial access on target machine, then use stored credentials of database to access the DB and retrieve user credentials (Hash). We crack the hash and login to user account, this user has permission to run a binary as root. This binary has vulnerability in its API function, by exploiting it we SSH into root.
Skills Required
- OSINT
- MySql Enumeration
Skills Learned
- Exploiting CVE-2018–7600
Enumeration
Initial Nmap scan reveals that target is running SSH and HTTP service. Drupal version 7 is running on HTTP. If we do a quick google search, then we’d find CVE-2018–7600 based on Drupal version 7. This vulnerability exists in Drupal before 7.58, 8.x before 8.3.9, 8.4.x before 8.4.6, and 8.5.x before 8.5.1 and allows remote attackers to execute arbitrary code because of an issue affecting multiple subsystems with default or common module configurations.
TL;DR — Drupalgeddon2
The vulnerability can enable remote code execution and results from insufficient input validation on the Drupal 7 Form API. Attacks against Drupalgeddon2 target AJAX requests composed of Drupal Form API’s renderable arrays, which are used to render a requested page through Drupal’s theming system.
Initial Access
If we search exploit-db for POCs then we’d find two, one is ported to Metasploit and another is ruby based. I will follow non-metasploit exploit process in this writeup.
Clone the repository and run the exploit.
Aight, *hacker voice* we are in. We got shell access, it not a user shell but a service (apache) one. Now we need to escalate our privileges to user shell.
Drupal’s Database connection settings are stored in a specific php file. We can read that file and retrieve database credentials.
As you can see from above screenshot, we have permission to read “settings.php” file.
We got the Database credentials, but the port is left blank. Even in our initial Nmap scan we didn’t get any database port. Let’s do a quick look up on local open sockets.
We got 3306 (MYSQL) and 25 (SMTP) port open on 127.0.0.1 not on 0.0.0.0. Both ports are bound to only 127.0.0.1, that’s the reason we didn’t get these port information in our Nmap scan.
Now know that there’s a DB port, we can access database with previously retrieved credentials.
Note: Due to restrictions on this “apache” service account we can't able to spawn upgraded TTY. We will look into that after getting root access.
There’s users table in the database, let’s explore that.
We got user’s credentials (hash). We need to identify the hashing algorithm before we crack it. Save it in a file to crack.
It’s Drupal v 7.x hash. Let’s find hashcat has any modes related to drupal hash.
We can use hashcat to crack the hash using above mode. Let’s do it.
We got the password of user. Let’s login via SSH and read our first user flag.
If we check for any binaries that current user can run with root privileges then we’d find one.
We can run snap binary with root privileges. So what is snap?
TL;DR — Snap
Snap is a package manager for linux, just like brew for macOS. It is easy to use, no dependency issues, auto update and secure.
Snap has a local privilege escalation vulnerability CVE-2019–7304. 0xdf has explained this vulnerability more accurately than other blogs. The actual blog by the researcher who found this vulnerability is here.
To exploit this vulnerability we need to craft a snap package. We need Ubuntu OS to craft it.
The below commands are being run on Ubuntu OS.
Now we need to add script or commands to ‘install’ file which we want to execute as root. It can be any thing, which would give us complete access to root shell. I will add my Kali Linux SSH public key to root’s authorized_keys.
Note: By default root doesn't have .ssh directory, so in this script it will create it first, then add my Kali Linux SSH public keys (which I have kept it on current users home directory) to root’s authorized_keys.
Now we need to configure snap YAML file.
Everything is set, now we need to build the snap package.
Snapcraft built our package with named dirty_sock_0.1_amd64.snap. Now we need to move this file from ubuntu to target machine.
It executed our commands successfully. Now we need to login root via SSH from Kali Linux and read our root flag.
We got all the flags required to complete this machine.
Quirks
Our initial shell was literally dumb.
They do not have the ability to process special escape sequences that perform functions such as clearing a line, clearing the screen, or controlling cursor position.
We couldn't able to run any bash scripts or python scripts. So, when I got root access I found that “SELinux” is enabled on the box.
Most modern Linux OS has SeLinux enabled by default, but this box has custom policy to restrict some of the binaries. This might be the reason that we couldn't able to upgrade our fully functional TTY.
Thank you for reading this blog. While attempting this challenge I learned so many things. This was unique target with unique vulnerability.
References
https://0xdf.gitlab.io/2019/02/13/playing-with-dirty-sock.html
https://initblog.com/2019/dirty-sock/
