Swagshop was a little rough for me. Bottom line is I’m still relatively new to all this ethical hacking stuffs and while I do have lots and LOTS of theoretical and practical knowledge I am still working on my application of said knowledge. With that said, I’m not too proud to say that although this is rated an “easy” box, it did give me painful nights of restlessness and turmoil LOL. But here it it in all its splendid Rooterification… (trademark).
First, as with all things, we’ll start with our nmap scan to see what’s under the hood:
Right away all we seem to have is ssh and a web server… Not much to really go on but thats ok. We should immediately hit that website and see what’s goings ons. After a quick visit to 10.10.10.140 we can see a cool store of well, Swag. Seems to be a rather simple web application slash e-commerce site. Fun thing about these sorts is researching the environment of the web-application to find out known vulnerabilities. Again, insert HOURS of enumeration, poking at the site and trying to learn the ins and outs of functionality. After some gobuster and dirbuster attempts (and maybe some Nikto scans), I finally came across an admin panel:
This will be important. Again, I’m not documenting all the fails. Just going straight for the milestone findings that led to pwnage. We can see that the application is Magento, so naturally we can begin to look for exploits with searchsploit by typing searchsploit magento. That should provide you a list of already documented exploits and vulnerabilities. One in particular seems to do the trick:
I copy this bad boy to my current directory where I’m storing files and findings for Swagshop and then cat it to look at what’s inside and what if anything is needed from me to customize. After taking a look, it seems the target IP address needs to be modified to the IP of the machine only. Also this script seems to claim that it can create an admin user account for the Magento application. Now that is really important. Let’s get to it.
Ok. That seems to have done the “trick”. The python script reported back that it worked and that I can try forme as the admin and pw for the admin panel.
And voila! I am now logged into the back control panel of the Magento web application. But our work is far from done. We now have to find a way to exploit our new found access to this back panel. For web applications particularly I recommend brushing up on the OWASP attack vectors. Here is a list of the types of attacks that can be used against web applications. As my understanding of web apps and what “seems” to be the intended way to exploit these type of boxes on HTB, (as far as for easy boxes anyway) they usually want you to upload something that can be used to call back to your attacking machine.
Essentially what this means is you can try to find a way to upload malicious files that you can execute on the server or use the native applications functionality to upload plug-ins, packages or “whatever” to see if you can exploit the trust relationship between an admin user and the server. Again, HOURS UPON HOURS of attempts and enumeration would go here. But at the end of the tunnel, I found a github package for the Magento application that once modified and uploaded to the server, can be used to call back to my machine.
Alrighty, so the cliff notes of this find basically says that Magento will trust this package as a plugin, but before we upload it to the server we have to customize a file with a PHP reverse shell, so once we upload it and call it, we can grab that user shell. This is where a little more reading on the specific explicit and trial and error may come into play.
After I git clone the exploit to my current directory I then looked inside to see what was going on. Right away I can see some folders and a handful of files. From reading the file extensions I can see only one is a php file. So this is probably my best bet. I see there is already some exploit code in this file, but tbh I had no idea what it was saying so I decided to just replace the entire file with the PHP-reverse-shell code from the pentestmonkey site. I mean, I see it was saying it would run commands, but instead of going back and forth and trying to run nc commands or whatever I thought it’d be safe to just replace it with what I know… Someone out there may have run this exploit without changing it but I didn’t… One day I will probably look back at this page and feel stupid for not knowing what the initial exploit was doing, but I’ll cross that bridge later…
Moving on, I copied the PHP-reverse-shell code into the IndexController.php file, and customized the call back to my attacking machine. All I had to do now was upload the package to the server right? Well, not quite. After reviewing all the other xml files I noticed the package.xml file had hash values of files.
Now this was something I was proud to say I found before it cost me hours and hours of turmoil and fails, trying to upload a package to Magento that may have not worked because of this file integrity check. To be honest, I’m not sure if this would have made the upload fail or not, there’s a chance it may have worked regardless. Instead of wasting time and taking chances, I decided to md5sum the IndexController.php file anyway and plug the value in this page. Couldn’t hurt right?
I also went and checked each of the other files md5 hashes just in case this was a “gotcha”, just to be on the safe side. After finding the other two hashes did not change, I only had to modify the hash value for the file I actually changed. Now I was ready to upload the entire tar package into Magento, open up a listener on my machine and hit that URL:
to see if this call back would work or not….
and Voila! We obtain the www-data user, BUT turns out it has access to the home directory of the Haris user who has the user.txt file waiting patiently for us.
Ok… getting root for me was not fun. Looking back now, I can see how it was actually REALLY easy. BUT… I’m still learning. So, with that being said. After hours and hours of enumeration and making mistakes (surprise), it turns out the www-data has SUDO rights to the vi application and also to everything in the /var/www/html directory.
So what does this mean? Well, to the more trained eye it means you can pretty much open vi and use the :sh command to execute commands as root. That’s essentially what it means. Literally. That’s it.
To the untrained eye like myself, that means you spend hours trying to use vi to create a shell script inside the /var/www/html directory that would cat /root/root.txt to get the flag. Only the issue is the terminal is crap and you can’t see the mode you’re in, so you spend hours attempting to create a bash script that would execute. Well, that was fun. I always hated vi and now I hate it even more. But after I found out I can execute a shell, I simply did that and used cat to see the flag:
Thanks again for reading!