Hack The Box — SwagShop — without Metasploit (TJNull’s list for OSCP)

Daniyal Ahmed
7 min readMay 18, 2023

--

This is my 13th write-up for SwagShop, a machine from TJNull’s list of HackTheBox machines for OSCP Practice. The full list can be found here.

In a general penetration test or a CTF, there are usually 3 major phases that are involved.

  1. Enumeration and Scanning (Information Gathering).
  2. Initial Foothold.
  3. Privilege Escalation.

Let’s get started with the box!

Enumeration

In order to hack into a system we need to first gather some information about it. For that, we use Nmap to scan the ports of the target machine to find out what services are running; services that we can target. First let’s try to find out what ports are open and then we will run a detailed scan only on those ports to save time.

nmap -p- 10.129.183.82 --max-retries=0

So, we have only 2 ports open. SSH and HTTP.

Of course, we are gonna start with HTTP. Meanwhile, let’s run a detailed targeted nmap scan for these 2 ports.

nmap -sC -sV -A -T4 -p22,80 10.129.183.82

Well it didn’t take much time. The Apache version is 2.4.18. According to launchpad it’s probably Ubuntu Xenial.

https://launchpad.net/ubuntu/+source/apache2/2.4.18-2ubuntu3.4

Let’s see what do we have on HTTP server.

I entered the IP address in firefox and it resolved me to the hostname of swagshop.htb.

Let’s edit the /etc/hosts file and add this hostname.

Let’s navigate to this hostname via firefox.

It’s a Magento CMS. Let’s run GoBuster against it.

gobuster dir -u http://swagshop.htb -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,cgi,sh,db,jsp,html,log,txt -t 200 -k --no-error

Meanwhile it runs. Let’s Google the default location for admin panel.

Let’s try http://swagshop.htb/admin

Nothing appears to be here… That’s weird.

Let’s try navigating to Account>login.

Ok, so there are webpages further through index.php.

Let’s try http://swagshop.htb/index.php/admin

And we have admin login panel here.

I tried looking for version inside the source code. Didn’t find it. Maybe it’s there somewhere but I didn’t find it. Maybe you would, I don’t know. I am gonna try a different technique.

If we go back to our home page. We can see the year 2014 below the home page.

Let’s see what versions were released in 2014 and may narrow down the possible versions for us a bit.

Came across this:

https://www.cloudways.com/blog/magento-versions/

It seems like the version could be 1.9.X (where X can be any number)

Initial Foothold

Let’s look for the exploit on exploit-db. The following exploit looks like a good fit, since its date tells that it was uploaded to exploit-db in 2015.

https://www.exploit-db.com/exploits/37977

Reading the exploit overview tells us that it will create an account for us.

Let’s run the exploit and see what the help tells us.

No help, lol. Let’s read the code then.

Let’s set the target to http://swagshop.htb/ and then run it.

Still doesn’t work. Ok, let’s check what’s wrong in the code.

We can see that target URL is target+/admin/Cms/…………….

And we know that /admin is actually further way inside index.php.

Let’s set the target to http://swagshop.htb/index.php

Now after concatenating the two, the URL could be a valid one.

Let’s run it again.

Okay, so it worked and the credentials are forme:forme. Let’s try loggin in.

And we are in. Let’s search for any upload feature here we could upload either php script or a package.

Afer looking for a while I didn’t find anything. Let’s search for any exploit for RCE.

https://www.exploit-db.com/exploits/37811

This one looks good, since we have the credentials now.

Let’s run it.

It asks for a hostname and a command that we want to execute. (You may need to install mechanize module using pip2 to run the exploit) But a thing to notice is, that it’s not asking me for any credentials even though it is post authentication exploit. So, let’s review the code and see what username and password it’s using.

The username and password is empty. So, let’s edit that. And it also says that installation date should be update to whatever we have in /app/etc/local.xml

Navigating to this location.

It gives me the install date, so I have to replace it inside our code. Now it looks something like this.

Let’s run our code.

It says ‘No control matching name login[password]’.

Again it’s the same thing, I guess. It’s trying to login through http://swagshop.htb/ instead of http://swagshop.htb/index.php/admin

So let’s add index.php/admin to the target while running the script.

Now it says more than control matching name ‘login[username]’. First he had no control matching, not it has multiple login username fields. Give it a rest, dude!!!

I tried different things, but so far nothing. Let’s try to google this error.

https://stackoverflow.com/questions/35226169/clientform-ambiguityerror-more-than-one-control-matching-name

I got my answer on this stackoverflow page.

It says if my code is having ambiguity problem, can add nr=0 to remove it. So, we should try this. Let’s edit the code before the br.submit()

I commented out the previously written br[‘login[username/password]’] fileds and added mine.

Now let’s run the code.

And it runs…!

Let’s get a reverse shell really quick.

Didn’t get any reverse shell. Let’s use nested bash payload.

And we got a shell!

Privilege Escalation

First things first, let’s see what can we execute using sudo.

sudo -l

We can execute the command /usr/bin/vi /var/www/html/* as root without any password. Let’s use the simple GTFObins hack for vi.

We can try the second one since we need to give an argument to vi, that would be easy.

And we are root! :)

--

--

Daniyal Ahmed
Daniyal Ahmed

No responses yet