Recon
This site is a basic e-commerce site with just a few products filled in as examples. Magento is the platform and it’s very well-known.
Port Scan
NMAP doesn’t show anything out of the ordinary for a web host:
PORT STATE SERVICE REASON VERSION
<strong>22/tcp open </strong> <strong>ssh </strong> syn-ack ttl 63 OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 b6:55:2b:d2:4e:8f:a3:81:72:61:37:9a:12:f6:24:ec (RSA)
| 256 2e:30:00:7a:92:f0:89:30:59:c1:77:56:ad:51:c0:ba (ECDSA)
|_ 256 4c:50:d5:f2:70:c5:fd:c4:b2:f0:bc:42:20:32:64:34 (ED25519)
<strong>80/tcp open </strong> <strong>http </strong> syn-ack ttl 63 Apache httpd 2.4.18 ((Ubuntu))
|_http-favicon: Unknown favicon MD5: 88733EE53676A47FC354A61C32516E82
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Home page
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 3.12 (95%), Linux 3.13 (95%), Linux 3.16 (95%), Linux 3.2 - 4.9 (95%), Linux 3.8 - 3.11 (95%), Linux 4.4 (95%), Linux 4.8 (95%), Linux 4.9 (95%), Linux 3.18 (95%), Linux 4.2 (95%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 0.003 days (since Tue Aug 13 09:45:05 2019)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=261 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernelWe can see that Apache 2.4.18 is the web server platform.
Directory Scan
GoBuster was able to find quite a few directories related to Magento:
=====================================================
Gobuster v2.0.0 OJ Reeves (@TheColonial)
=====================================================
[+] Mode : dir
[+] Url/Domain : http://10.10.10.140/
[+] Threads : 10
[+] Wordlist : /usr/share/wordlists/dirb/big.txt
[+] Status codes : 200,204,301,302,307,403
[+] Expanded : true
[+] Timeout : 10s
=====================================================
2019/08/13 13:32:28 Starting gobuster
=====================================================
http://10.10.10.140/.htaccess (Status: 403)
http://10.10.10.140/.htpasswd (Status: 403)
http://10.10.10.140/app (Status: 301)
http://10.10.10.140/downloader (Status: 301)
http://10.10.10.140/errors (Status: 301)
http://10.10.10.140/favicon.ico (Status: 200)
http://10.10.10.140/includes (Status: 301)
http://10.10.10.140/js (Status: 301)
http://10.10.10.140/lib (Status: 301)
http://10.10.10.140/media (Status: 301)
http://10.10.10.140/pkginfo (Status: 301)
http://10.10.10.140/server-status (Status: 403)
http://10.10.10.140/shell (Status: 301)
http://10.10.10.140/skin (Status: 301)
http://10.10.10.140/var (Status: 301)
=====================================================
2019/08/13 13:33:45 Finished
=====================================================Going through each of the directories and searching for anything out of the ordinary didn’t return very much results. However, the ‘downloader’ page gives details on the version of Magento:
We have Magento Connect Manager ver. 1.9.0.0, which the base version should match.
Exploitation
Research
With the information found so far, we can look for public exploits or vulnerabilities to use.
There are a few that are applicable to this version, and after researching them for a little bit, it is obvious the one we need is related to the ShopLift vuln. During research on the ShopLift vuln, I found another public exploit that has slight differences, and it could be useful to have both.
The Blackhat Way
After seeing there’s a preprogrammed password in the exploit, and it’s a very easily found one, I thought there might be some other hackers on the free server I’m using that would simply leave the default creds in. So I put them into the ‘/downloader’ page, and voila!
There’s a “Return to Admin” button that will then take us to the normal admin dashboard. Or…
The Not-Quite-As-Blackhat Way
If taking advantage of other hackers on the server isn’t your way, or if you’re alone on a paid server, it’s almost just as easy to exploit it yourself.
Thing is, the exploit code as it comes doesn’t work, even after changing the target to our host address.
So, good thing we found a second exploit version.
The critical difference is the addition of /index.php/ to the target URL, as shown in the screenshot.
After adding that change to the exploit code (don’t forget to modify the default credentials) it works!
Shell Hunting
This is where I spent the most time looking around and poking at things, searching for command injection. Eventually, I stopped wasting time and started Googling and searching the forum.
I was able to find one CVE for code execution on this version. However, on the forum, several people mentioned abusing extensions to get to a shell. So that’s the direction I took instead of the CVE.
First I tried to manipulate the extension creation process to get some code exec result, but I eventually gave up that route and figured there’s probably already some extension to load that would help. Thanks to other hackers on the free server, it was relatively easy to figure out what extension that could be. On the Magento Downloader page, there is a section that lists which extensions are loaded:
And at the bottom of the list, there is an extension allowing access to the filesystem! That can’t be there normally…
Since it’s already loaded in this instance, I shouldn’t need to load it again, just learn how to use it. However, that is definitely not always the case. This box spends a lot of time being unavailable on the free server and has to get reset often, and when it does somebody will need to upload the Magpleasure extension. Turns out there’s a checkbox on the Magento Downloader that causes it to be unavailable if left checked during extension uploads… uncheck that when uploading.
How to use the extension:
Once in the filesystem, I tried to create a file, but there was no clear way to do so with MagPleasure.
Another thing to do is to modify files already on the system, and there are several targets to choose from. From having to restart so many times dues to service unavailable issues, I’ve noticed other hackers tend to prefer the ‘get.php’ file. To not get clobbered, I used the ‘install.php’ file for my reverse shell.
Escalation
For the first shell connection, we’re logged in as ‘www-data’. Not too surprising. What is surprising though, is that www-data can access the user home directory! That’s not really a normal scenario, but I’ll take it! Just cat /home/haris/user.txt for the flag.
Now to find a privilege escalation to the user account.
I was going to find a way to upload LinEnum and do proper enumeration, but I remember reading on several forum posts that there’s a very basic permissions issue to use for root privileges escalation. One of the very first things to look for is sudo permissions, so that’s what I did:
Look at that! We can use vi as root, and then a simple shell escape from inside vi:
First, I used the command sudo vi ./test.txt … but it errors with “sudo: no tty present and no askpass program specified”
After trying a few things I landed on the fact that I didn’t type it in exactly as it is in sudo -l … so I tried again with: sudo /usr/bin/vi /var/www/html/test.txt and that let me in as root.
To use a shell escape in vi, we can type :!/bin/sh for the win 🙂