Swagshop — Hackthebox Writeup

I had a lot of fun with this machine. Let’s get in to it!

nmap -v -sV -A -p- -oN nmap.txt swagshop.htb

The server has ports 22 and 80 open, pretty standard. I open http://swagshop.htb in my browser:

Magento software running on port 80

Although I haven’t heard of Magento before, this looks like some normal e-commerce software. I can’t see a version number anywhere, so before I use searchsploit I decide to learn a little more about Magento. I run gobuster:

gobuster -w /usr/share/dirb/wordlists/common.txt -u http://swagshop.htb -x html,php,txt -o gobuster.txt

I see a lot of 200/301 status codes, great. Normally I get a wall of 403. This means I might not need to install Magento on my own machine to sift through the installation.
I come across a nice file at http://swagshop.htb/app/etc/local.xml

http://swagshop.htb/app/etc/local.xml

MySQL credentials, nice! I can’t use them yet, because the host is ‘localhost’. But these should come in handy later.

When I finish looking around the ‘app’ directory, I take a look at the ‘downloader’ one. It’s a login page for “Magento Connect Manager”.

I’ve got a version number!

The MySQL credentials don’t work. I note down that I can try bruteforcing this later if I get desperate. The more important information is the version number. I consult searchsploit:

searchsploit magento

I browse through the results but because only three are scripts, I decide to dive straight in to the RCE one. It’s quite a significant exploit called the “Shoplift bug”. I set the target URL and run the script:

DID NOT WORK

The vulnerability wasn’t fixed until 1.9.1.1, so I check the URL that the script was trying to hit,which is http://swagshop.htb/admin/Cms_Wysiwyg/directive/index/

Makes sense. I start reading the Checkpoint blog post about the vulnerability and start looking for this “/Cms_Wysiwyg/directive” directory. I find:

http://swagshop.htb/app/code/core/Mage/Adminhtml/controllers/Cms/WysiwygController.php

I also find an article which details how to move/rename the admin directory (https://www.properhost.com/support/kb/15/How-To-Change-The-Magento-Admin-Url-Path), and find that all you have to do is edit the “local.xml” file that I found earlier.
Opening it up again shows that the admin directory is still ‘admin’, the default. If I created this machine, I think I would have edited it to ‘swagshop’ or something else.

I install Magento 1.9.0 on my own machine to more quickly look through the directories, and eventually find the admin directory behind ‘index.php’:

Finally finding the ‘admin’ login page

I update the exploit script so the target URL is:

http://swagshop.htb/index.php/admin/Cms_Wysiwyg/directive/index/

I also update the credentials of the admin account I’m creating from forme:forme to test1234:test1234. I do this because I tried them earlier and was able to log in only because other HTB users hadn’t updated the credentials that come with the script.
Please excuse my print lines.

Using SQL injection to create an admin account with credentials test1234:test1234

Logged in to the admin panel

I look around but don’t see any obvious ways to access the system. I spend a lot of time trying to use “Magento CE < 1.9.0.1 — (Authenticated) Remote Code Execution” now that I’m authenticated, but I can’t get it to work.

Next, I try “eBay Magento 1.9.2.1 — PHP FPM XML eXternal Entity Injection”, but find that “SOAP extension is not loaded.”

I read online that the attack vector is to install a Magento extension that gives us access to the system. One that is recommended is Magpleasure File System, which allows you to edit files on the system from inside the admin console.
https://pluginarchive.com/magento/magpleasure_filesystem

I make sure to untick “Put the store on maintenance mode”, and upload the extension.

Installing the extension

The extension installed in the list

Now that it’s installed, I go back to the admin console and in the “System” menu I open “Filesystem”.

Using the newly installed “Filesystem” extension

The extension allows me to edit files in the filesystem. I look for a file that doesn’t seem to be used often and find /app/design/adminhtml/default/default/template/example.phtml. I delete its contents and replace them with PentestMonkey’s PHP reverse shell. I access the file through my browser, and get my reverse shell.

System access as www-data user

After a little trouble finding python to upgrade my shell to pty, I navigate to the user’s directory and successfully cat the user.txt flag.

Moving on to privesc, I couldn’t see anything obvious in env. The kernel running was Linux version 4.4.0–146-generic, with Ubuntu 5.4.0–6ubuntu1~16.04.10.

I found “Linux Kernel < 4.4.0–83 / < 4.8.0–58 (Ubuntu 14.04/16.04) — Local Privilege Escalation (KASLR / SM” and although it had a bit of a confusing name, I thought it should work. Unfortunately gcc wasn’t installed on the machine, so I sent LinEnum.sh over before I started to make a move on the ‘haris’ user.

Contents of the sudoers file

Possible sudo pwnage indeed, vi allows you to spawn shells. Since the sudoers file lets www-data run vi on any file in the /var/www/html/ directory as root, privesc is simple.
I run “sudo /usr/bin/vi /var/www/html/helloworld” which opens vi as root, and type “:shell” to spawn a shell. Then I navigate to the root directory and get the flag!

Along with the usual string, the root.txt flag file contains a cool surprise.

I really enjoyed this machine. All in all, it took about 10 hours.
At first, I thought that I’d need to write my own exploit code and was excited for that, but I took the time to thoroughly read the detailed Checkpoint article and am happy with that.

The most annoying thing about it was that Magento Connect Manager pre-ticks the “Put store on the maintenance mode while installing/upgrading/backup creation” box, and when the service is in maintenance mode you can’t use the admin portal to plant your reverse shell.
A lot of people weren’t unticking this option, and were putting the service in to maintenance mode which killed everyone’s access to Magento.

A very annoying message

This caused people to constantly send reset requests (HTB has a cool feature where anyone can request to reset a box if there are no objections after 2 minutes), while the one guy with a reverse shell who put it in maintenance mode would cancel them all.
One good thing is that I learned that the US server is almost empty during the hours that I’m online. On the EU server there would be a reset request every 5 minutes, and there wasn’t a single one for the few hours I was on the US server.

Things I learned:

1. If I can get my hands on it, start downloading a copy of software that I’m trying to exploit. Noticing differences to the default installation could be really helpful.
2. That I’m excited to read a vulnerability report and write my own exploit code. It’s time to stop copying scripts from the exploitdb folder or online. I’ll try to at least re-write any that I use.
3. The Checkpoint article was amazing. I think it was my first real example of the exploit chaining and persistence that this kind of work requires.
4. If you can install custom modules for a service, it’s (probably) trivial to get system access as the service’s user.
5. If you want to add anything to the sudoers file as root, understand exactly what the program is capable of/vulnerable to.