Skip to main content

Platform: HackSmarter · Difficulty: Medium · OS: Linux

Hacksmarter Casino 2
You have been provided the IP of the Wifi Captive Portal… but no other information.

​
Enumeration

First things first, running an NMAP scan on the given IP of 10.1.198.129:
We’ve got three open ports:
  • 22 (SSH) — OpenSSH 9.6p1 Ubuntu 3ubuntu13.18
  • 80 (HTTP) — Werkzeug httpd 3.1.8
  • 2222 (SSH) — OpenSSH 8.4p1 Debian 5+deb11u7
It is odd that there are two open SSH ports, maybe the second one will come in handy later. It’s also odd that they are different versions, with one for ubuntu and the other for Debian. Regardless, it isn’t my priority to attack SSH since it is unlikely that either of them are vulnerable, but we can come back to it if needed.

​
Enumerating HTTP (80)

First, gobuster to find potential hidden directories:
Nothing much here since the interesting endpoints (/dashboard and /profile) seem to just redirect us to login. Heading to the login page, at first glance we see that this is the WiFi capture portal hinted at previously. Image Opening up Caido in the background and capturing a request when clicking “Connect to Network”, we see that as expected there are two main parameters captured, room_number, and last_name. Image

​
Authentication bypass on the WiFi Portal

We get authentication failed when providing the two parameters of “room_number=304” and “last_name=NTH”. My first thought is going to be spraying the room_number parameter with common last names like “Johnson”, “Smith”, “Doe”, etc. similar to a password spraying attack. We can use Caido’s Automate tab for this. Image Spraying the last name “Smith” against room numbers 0-500 Looking through the results, we see that we actually get a hit! Sorting by the length or the status we can find that a combination of room_number=105&last_name=Smith nets us a successful login! Image

​
Continuing Enumeration as James Smith

Going back to the web page and logging in, we’re redirected successfully to dashboard! Image Going to the /profile endpoint, we find that we don’t have a ton of “WiFi Preferences” other than being able to change our display name. Image One thing stands out to me. The setting says “This greeting appears on your dashboard, device connection logs, and smart room controls.” This makes me think that we can do some kind of log poisoning attack, where we can change our name to insert malicious code into the device connection logs, and hope that we can find a way to trigger that file. Also we have fun HTML injection. Image Not just HTML injection though! The web page also allows XSS. Going back to the note it makes me think we may have more than just log poisoning, but also a potential stored XSS as well! Image We can test this with a cookie steal payload:
If we DO have stored XSS, we should see the cookie of whoever is viewing our payload in kali, but nothing comes across other than our own IP, so this one may be a no go. Image Another thing I think of when I see reflection like this is SSTI. There might some kind of template processing on the backend to display our Nickname, so we can try to break out of it. Image Success! This proves that there is some kind of template (Jinja2 from the curly braces and knowing that this server is running python) processing our format. Let’s try to break out and run a small amount of code. To do this, we can simply use direct global references available in standard Jinja2 environments, eliminating the need to guess subclass array indexes:
And we are returned with the id of the www-data user! Confirmed RCE! Image We can also enumerate /etc/passwd and extract two users, george and david: Image

​
Initial Access (Foothold) as George

Now that we know we have RCE through SSTI we can attempt to grab a shell with this payload:
Though each attempt doesn’t seem to be coming through on our listener… Image Going back to the two users we found, george and david, I wonder if we can read their SSH keys out of their home directories, or maybe any other files that can disclose information?
Image Looks like we can read george’s home directory to grab the user flag!
Image We can do the same thing to read George’s SSH key:
Image Note: Make sure to copy this from the source code (pressing CTRL + U), as it is a lot cleaner and will import properly). Hmmm, looks like we don’t authenticate on port 22. Image But remember our first enumeration step! There is another SSH instance open on port 2222, and we can log into that one to grab our shell as george! Image

​
Lateral Movement to David

We land on what looks like a docker container (because of the hostname). One thing I noticed right away is that .bash_history has a bunch of stuff in it (from the file size) and that it isn’t redirecting to /dev/null, meaning we can read it! In the bash history we find that our user used the su command to switch to david’s account with the same password used to make a connection to the backend mysql database. Let’s see if we can simply switch to david’s user? Image That was easy! Image

​
Privilege Escalation as David → Root

Off rip, it doesn’t look like we have an easy sudo -l privesc, so we can move on from that. Image Looking at our user groups, we find that we are in the adm group. Image While this doesn’t give us any crazy permissions out of the gate, it means we can read /var/log, which may give us creds to another user either on the port 22 instance of SSH, or other sensitive information.
Catting out all the logs, we find that in the ‘provisioning.log’ there is a root password! Image Now we can simply SU to root and grab the root flag! Image Overall a very fun and realistic box! I loved the theme of this box and the initial foothold to spray common last names. Until next time 🌟