023#:HTB - OpenAdmin
That last room was pretty tough at points, but was a great learning experience for attacking Windows environments. Today’s room will hopefully go a little smoother though.
Not much going on, so let’s kick this off with a gobuster scan. I pulled up the site in my browser but it resolved to a default Apache page. Luckily, gobuster found something for us to look into.
Gobuster found two directories and I was surprised to see that these were for two separate sites. I ran gobuster a couple more times, once against each directory we found in the first scan.
While gobuster found more directories, I knew this couldn’t be all of them. While I was clicking around the site I noticed some pages ending in .html that weren’t detected by gobuster. I added html to the list of extensions I was scanning for and ran gobuster against both directories again in hopes of getting some better results.
I checked over the /artwork/ pages and their source code but nothing jumped out at me. On the contact page for the /music/ directory I noticed the solmusic.com domain, but I didn’t add it to my hosts file just yet. I double checked my nmap results again. With lack of a direction, I ran gobuster scans again with a larger wordlist but didn’t find anything new.
I started using gobuster to enumerate subdomains, and again after adding solmusic.com to my hosts file, but this got me nothing. At this point I consulted the Guided Mode questions and had a pretty good laugh.
I usually do these rooms over the course of a day or more, so sometimes I have to shut down the room and start it up later. Yesterday, I had tried clicking the login page of the /music/ directory almost immediately upon viewing the page. This didn’t load anything though which was similar to other links on this site were doing too. It happens that Task 2 wants us to go to that exact page, and of course today (with a fresh boot of the room), the login page now loads.
This is a great example of when to look for hints with these rooms. I strongly believe that struggling through a room will help you learn, but it can also be bad for morale when you spend hours working on something just to find it was the room that was being buggy at that moment. My approach has been to try my best to work through each room until I get stuck.
When I get stuck I will first refer to my hacking notes (just knowledge I have accumulated), and if that fails I refer to the Guided Mode questions. These are great because they tell a lot through asking simple questions. If I get extremely stuck I start referencing user submitted guides and check only up to the point I am stuck at. I think this is a good balance to challenging yourself while also making good use of your time. The more experience I gain, the longer I go in between each of these escalations in hints. Anyway, let’s get back to it.
Now that we are at this guest user web console, the alert about the software being out of date stands out. I have a version number but not the product name now. I checked the source code of the webpage and notice it mention OpenNetAdmin.com. This seems related to the directory, /ona/, that we are currently in. With searchsploit I saw there is a metasploit module we can use. I gave that a go without much luck.
I googled the default credentials for OpenNetAdmin and sure enough they got us in!
I saw in this dashboard that there is a domain ‘openadmin.htb’ which I added to my /etc/hosts file. I also noticed the database username of ‘ona_sys’ which I added to my notes. I quickly ran out of things to explore on this page so I looped back to that other searchsploit result.
After making the payload executable, I read the contents to see if there was anything I needed to adjust. It looks like we have to pass the target URL as an argument while launching the script. This took a little tinkering, but once I got the syntax right we can see we are running commands as the www-data user.
Let’s try to get a reverse shell before moving on to anything else. I ran python3 –help to confirm it’s installed before starting my netcat listener and trying to catch a shell. This failed, as did a bash, and perl shell attempt. With that seeming like a dead end, I started just poking around my current access.
Seeing the contents of this folder, I now have a good guess of how I’m supposed to get my reverse shell. The contents here are the web pages, so by uploading a malicious PHP payload we should be able to navigate to it from our browser to catch the reverse shell. I used msfvenom to generate my php payload and spun up a python http server to transfer the file to the victim.
We can see that our file was successfully uploaded, we could call it in our web browser, and we were able to catch our reverse shell (after setting it to the same payload as our msfvenom one). I listed the contents of the /home directory to discover a couple users that I added to a users.txt file. I can’t cd into either of their folders as www-data though.
I tried to check my sudo rights and got a somewhat odd error message. I googled the message to be safe, but it doesn’t seem significant. I moved on to looking at the contents of php files in the www/ona/ directory, hoping to find credentials. I checked out this auth_ldap.config.php file which didn’t have credentials, but it does mention a path to store the actual config file. When we check there we stumble across a set of credentials for an ona_sys user account.
I tried using this new account with ssh which failed. I then tried poking around with mysql but my shell couldn’t handle it. I tried to switch users to ona_sys which also fails. This had me a bit stuck so I jumped over to the Guided Mode questions. Its obvious that I am on the right track, I am just missing where I should be using them somehow. Task 5 asks us what jimmy’s password is and they mention checking for password reuse. Honestly, I’m surprised I didn’t think of that. But sure enough we can ssh into the server as jimmy using ona_sys’s password.
This gets us a new account to poke around but not the first flag. I checked my sudo rights, groups, and SUID permissions. I checked the sudo version but I don’t think its vulnerable. I moved linpeas.sh to the target and ran. They have a bunch of suggested exploits which I normally skip over but I decided I would give some a try. I loaded msfconsole, got my ssh session there, and then started going down the list of exploits.
The ones listed as probable didn’t work so I kept scrolling the linpeas results. No cron jobs. It looks like the joanna user has some interesting sudo rights that we will probably abuse later.
A little further down I noticed a subdomain I didn’t know about that is being served internally.
With it being only available on it’s loopback address I won’t be able to navigate to it without some extra work. Since we have ssh access as jimmy this will be easy though. I use our ssh connection to openadmin.htb and tunnel traffic intended for 127.0.0.1:52846 on the target to my own computer on port 80. This means if I pull up a web browser and navigate to 127.0.0.1 I should be able to see internal.openadmin.htb.
It looks like this internal site is associated with joanna’s account, so I figured I would run a brute force attack against the portal. Usually when I do this I will intercept the login request to get the syntax, but I was having trouble getting burpsuite to intercept traffic to my loopback address. I then tried reading the source code of the page to get the login syntax and I thought I had it.
That still didn’t work though. I remembered I could get this info from the browser too, so I opened inspect on the page and discovered the syntax was actually username=test&password=test&login. Adjusting for that, we are seemingly able to crack joanna’s password.
Unfortunately, the password is oddly missing from the results despite it saying success. I looped back to the guided questions and Task 8’s hint mentions looking around that site’s web folder for a hash. I should have caught this myself. I had checked the site files of the first site but never went and checked them after discovering the internal site. Sure enough, if we read the contents of /var/www/internal/index.php we can see what looks like a password hash for jimmy.
I had already tried logging in as jimmy with our other password so this must be something else. I saved the hash to a txt file, identified it as SHA-512 on dCode, and began trying to crack it with hashcat. First I ran it without selecting a mode, then tried a few of the suggested modes but no luck. To be safe I also ran it against a few SecList password lists to no avail. With CTF’s I will try sites like crackstation.com as a last resort. I’ve done Try Hack Me rooms where it was a themed password that I could only find by running it through hashes.com. Lucky for us, CrackStation has the password and we are able to log in to the internal site as jimmy.
I wasn’t expecting to see a private key, and we already have SSH access as jimmy so this must be for joanna. It also mentions the ninja password we were first using. I wrote the private key to a file named id_rsa and tried logging in with the ninja password but it fails. I think maybe this isn’t the right ninja password. Converting the id_rsa file with ssh2john then attempting to crack gets us joanna’s encryption key!
Now that we can log in as joanna we are able to grab our first flag.
I recalled when we ran linpeas that joanna had some interesting sudo rights, so I pulled that up first. I have encountered nano privilege escalation rooms before so I jumped right into launching the command as root. Then while in the nano session, we follow the steps on GTFOBins.
The ^R^X are actually you pressing ctrl+r and ctrl+x before typing the last line right there in the nano text prompt. At first it almost looked like it did nothing but there was an out of place #, but hitting enter a few times revealed I was in a new shell session. After confirming I was root, I was able to grab the final flag.
