Armageddon — HackTheBox Writeup

Source

This is a practical Walkthrough of “Armageddon” machine from HackTheBox. Credit goes to bertolis for making this machine available to us.

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

Nmap

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.

POC — https://github.com/dreadlocked/Drupalgeddon2

Clone the repository and run the exploit.

Shell

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.

File Permissions

As you can see from above screenshot, we have permission to read “settings.php” file.

DB Creds

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.

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.

DB table

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.

user credentials

We got user’s credentials (hash). We need to identify the hashing algorithm before we crack it. Save it in a file to crack.

Identify hash

It’s Drupal v 7.x hash. Let’s find hashcat has any modes related to drupal hash.

hashcat mode

We can use hashcat to crack the hash using above mode. Let’s do it.

Cracked Password

We got the password of user. Let’s login via SSH and read our first user flag.

user flag

If we check for any binaries that current user can run with root privileges then we’d find one.

sudo binary

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.

snap setup

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.

command

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.

yaml

Everything is set, now we need to build the snap package.

Build

Snapcraft built our package with named dirty_sock_0.1_amd64.snap. Now we need to move this file from ubuntu to target machine.

run snap

It executed our commands successfully. Now we need to login root via SSH from Kali Linux and read our root flag.

root shell

We got all the flags required to complete this machine.

Quirks

Our initial shell was literally dumb.

dumb shell

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.

SeLinux

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/