Dog

Remember the intro to LinkVortex? I talked about getting stuck on another box, then moving on and learning something new. Dog was that other box, and that lesson makes it very easy to complete, as long as we don’t get too deep into rabbit-holes. In short:

Virtual Riot’s “Dog Fight” on

Dog is a Linux machine, so I think you know how this one starts:

After a minute browsing the website with teary eyes, since it’s about one of my favourite things in the whole wide world, I pulled myself back into business. We understand that the site is built with BackdropCMS, we get a few possible usernames from the pages, and we see that the login box allows username enumeration by giving us a different message when it doesn’t recognise the user. A few cheap attempts at passwords don’t get us anywhere, and it looks like Backdrop doesn’t do default credentials either. Good dog!

Next step, subdirectory bruteforcing with our then-usual list:

Apache is misconfigured to allow directory browsing (bad dog!), so I spent some time looking for interesting things. About the only thing was another username that the login form accepted, in a settings file:

Tail between my legs

Next up, virtual host discovery. Nothing. I tried some more brute-forcing of those subdirectories, parameter fuzzing of the CMS’s API, nothing. A robots.txt file exists, and contains a few possible leads, but also ultimately leads nowhere. UDP scan, negative as well. Searching for vulnerabilities on Backdrop only found an authenticated RCE issue, so we’d need credentials first. Apache 2.4.41 has its share of vulnerabilities as well but nothing actionable, and all definitely out of place in a supposedly Easy box.

This was looking interesting, or like I said in LinkVortex, worrying for the OSCP aspirer in me at the time. The checklist of things to try was running thinner, so I went back to the site’s content, since there was lots of it and surely I had missed something. I could swear I read somewhere that the hash in the configuration directory name (config_83dddd18e1ec67fd8ff5bba2453c7fb3) was a checksum of the site’s database connection string, so I scripted something up to try a small brute-force, but there were simply too many variables to look plausible (DBMS, username, host, database name, and of course the password). I’m glad I abandoned that path, because in researching for this write-up, it looks like the hash is very much not derived from the connection string, and I don’t know where I got that idea from.

Out of ideas, this was where I first stepped away from the machine. With LinkVortex I remembered that nikto was a thing and that I should keep it in my checklist, even if it’s at the end. Once again it was nikto that found the .git directory:

And yeah, lesson learned from these two boxes, the common.txt directory wordlist would have found this and more. Just like in the other box though, the excitement was short-lived, because simply browsing through the .git database files didn’t yield much of interest. The latest commit message told me about “url aliases”, so I spent some time researching those, trying to find a way to exploit them:

I found no such thing.

Tail wagging

If you still didn’t read the other write-up despite my constant references, I give up. So tl;dr for the part that matters here, I realised I could use git-dumper to grab the .git contents and rebuild the code repository locally:

Hurray! We go straight to settings.php to look for interesting things, like that very important database connection string:

Ok, we finally have a password we can use on the login form. We try it with the usernames we already knew of, and manage to login as Tiffany. Tiffany is a site administrator so we are presented with an administration dashboard. Any content management system that supports installing plugins should make you think that you can get code execution on the server, and that’s exactly what that authenticated RCE exploit I mentioned earlier does.

When exploits are this simple I prefer to do things manually - you can always learn a thing or two when your attempt doesn’t quite work. In this case, we needed to create a module, packaged in a zip file, containing an .info file describing the module and a .php file with the functionality. I adapted the former from the exploit, and made the latter be a simple reverse shell call to my machine:

I installed the module on the website through “Add new modules for more functionality”, and after browsing to http://dog.htb/modules/backup/backup.php, [hacker voice] we’re in:

We are only www-data though, which doesn’t give us our user flag. Checking the /home directory we find that there’s a jobert and a johncusack, so we are targeting them.

With the connection string we know how to connect to the database, so we can look at the site’s user table, but we find this:

It turns out that the site uses an annoying mechanism to hash the passwords, including a last step that truncates the final hash, negating the use of tools like hashcat out of the box. So if we were to crack this by brute-force we’d have to script something together. I decided to leave this and come back to it later if needed, and spoiler alert, I’m glad I did.

I was preparing for the OSCP and its 24h exam at the time, so I had been trying to avoid going too deep into rabbit-holes before exhausting other paths that could prove to be of least resistance. First, since I had root access to the database I checked the mysql users table, but only root is in it and we knew that password already. Then I looked around the file system some more, but there wasn’t much to be found. Then, I remembered the lesson that I keep having to re-learn, and begrudgingly tried the to reuse our only password on jobert and johncusack…

Boo. Imagine spending time writing that brute-force script.

Learning about the dogs and the bees

This was my fastest privilege escalation path to date, so we’re almost done. If you’re a fan, you know what my first two commands were:

I had no idea what bee was, but running it without arguments tells us it’s a CLI management interface for Backdrop. In the same help output, we learn about the exact kind of feature we are looking for in a sudo-enabled binary:

When sudo and arbitrary code meet, they love each other very much and make beautiful root babies! After a bit more reading and trial and error to learn how to use the tool, it turned out to be the easiest to just run it where the Backdrop site is deployed (/var/www/html). Then, it’s as simple as this:

Roll the credits

• As in LinkVortex: I’ll remember to use common.txt, I won’t underestimate nikto, and I’ll chastise myself for not seeing the potential in a .git directory.
• Give the low-hanging fruit a fair shot before committing to more effort-intensive paths.
• Password reuse. Password reuse. Password reuse.
• As always, for reading this far, you’re a champ.