Bashed

nmap scan

scan with -Pn shows port 80

Looking at the webpage, it looks like they have phpbash running on it

in the blog post, there is an screenshot with the file /uploads/phpbash.php, but that doesn’t lead to anything

dirbusting

running dirb http://10.10.10.68 shows a few directories

phpbash.php can be found in the /dev directory

opening up phpbash.php gives us a shell

getting root

Attempts at simple revshells in the webshell don’t work

running sudo -l shows that we can sudo scriptmanager with no password

Additionally, the /scripts folder is only accessible as scriptmanager

looking into scripts, we see that there’s a python file and text file, and that the python file makes the text file every so often.

this probably means that a something is running test.py regularly as root to create the test.txt file.

We can abuse this by replacing test.py with a reverse shell. To get our file onto the server, we have to wget from the /var/www/html/uploads folder and then moving it to /scripts, as we don’t have write permissions in other folders.

After that, we open a port and wait until we get a reverse shell.

Solutions

The phpbash repository has not been updated since 2018, so it doesn’t look like there’s any updates that would fix privillage escalation issues.
Limiting users from accessing anything outside of the blog pages, such as /dev and /css could resolve this issue if the phpbash functionality isn’t required.

Disallowing www-data from sudoing with no password would prevent anyone on the webshell from modifying /scripts.

Another thing that could be done would be to switch from using a task scheduler that doesn’t run as root, as it allows scriptmanager to run things as root from the scripts folder.

Blue

nmap scan

eternal blue time

Solution

• update windows to the latest version or according to this or this

Jerry

Nmap scans

scanning with no options is blocked

scanning with -Pn shows tomcat is running on port 8080

scanning port 8080 with -sV -sC -Pn

Looking at the website

Logging in with admin: admin works, but it has no perms
insert screenshot of no perms here

Login enumeration

Run metasploit/run common passwords

results in tomcat: s3cret as a username password pair
insert screenshot here

Reverse WAR shell

Use msfvenom to generate reverse jsp shell specific command

upload shell.war under war uploads
insert screenshot of upload page here

listen on port ___ with nc -nvlp 3155

navigate to 10.10.10.95/shell
and then the reverse shell is connected

finding flag

navigate to C:\Users\Administrator\Desktop\flags and print flag

Solution

Change the credentials to a non-default username/password

Lame

nmap scan

searching up “Samba smbd 3.0.20-Debian exploit” results in this

rce

executing the exploit with metasploit gives us root access

solution

Update samba to >3.0.25rc3

Precious

nmap scan

Looking at the website, it looks like the websites you can put are very limited.

I made a python http server and downloaded a pdf of that webpage

rce

looking up “pdfkit v0.8.6” gives us this, which is v0.8.7.2

running the exploit

There is the ssh password for henry under /home/ruby/.bundle/config

we can ssh to henry@precious.htb with the password

henry can run /usr/bin/ruby with no sudo password

We can find a ruby update dependency exploit here
Running it confirms that we are root.

Replacing the payload with a reverse shell gives us a root shell.

solution

• don’t leave ssh exposed
• don’t put ssh credentials in .bundle/config
• don’t give users the ability to modify dependencies.yml or run ruby as root
• update pdfkit to >=0.10.0 (not sure if this is actually true)

Shocker

nmap scan

dirb

Initial dirb shows index.html, as well as two inaccessible directories

Dirbing on cgi-bin with .cgi doesn’t show anything, but we get a result for .sh

downloading /cgi-bin/user.sh gives us something that looks like something from uptime

looking for “apache cgi exploits” gives us this

nmapping shows that the server is vulnerable

we can run the exploit using metasploit

it looks like we have access to /usr/bin/perl, so we can probably do a rev shell through that.

running the script results in a rev shell

solutions

• disallow the user from accessing perl with no password, as it’s what allowed for the revshell
• patch the issue with this
• upgrade past bash 4.3, as the exploit only works from 1.14-4.3