040#:HTB - Artificial
It feels like its been forever since I have posted an article. I recently started officially studying for the OSCP, so I have been on Hack the Box a lot less lately. Luckily, I did a bunch of the active machines before that and a couple have since retired. Today, we will cover my experience working on the box Artificial.
I got a directory scan going but it errored out and mentioned artificial.htb. I added the site to my /etc/hosts file and re-ran the scan.
I’m poking around the site and its source code just looking for version numbers and maybe a directory we didn’t catch. I didn’t gather much so I moved on to registering an account and logging in.
I downloaded the requirements and Dockerfile to inspect. Requirements.txt mentions ‘tensorflow-cpu==2.13.1’. I tried the file upload feature but I didn’t have any files it would accept. Checking the source code it looks like it wants .h5 files.
I looked up what .h5 files were and then tried to find a way to make a payload from one. I found this page and read over the article they link to.
I updated exploit.py to use my IP tried running it to create the exploit.h5 payload. I got an error about tensorflow not being installed, and they provided that docker file for us so I got that loaded up.
I hit some errors though and after some searching I tried tweaking it a bit.
I worked through multiple iterations of making tweaks to the Dockerfile and then getting a new error that I would address with another change. You can see here when it successfully built and the final Dockerfile that I used to get it to work.
Now that I have this running, I am going to try to make the malicious .h5 file from this container. Had to install git and vim before editing exploit.py again.
Cool, now I just need to look up how to best get the file off there. I also get my netcat listener going.
After uploading and clicking ‘View Predicitions’ we have our initial foothold!
I stabilized my shell before beginning to explore. Inside our current directory I read app.py where we get a password.
We can also see mention of the users.db. I decided to try to access the db after refreshing myself on the sqlite commands.
Nice! We got some password hashes, specifically for the gael user we saw has an account on this machine. I put these hashes and users into hashs.txt and users.txt respectively and began trying to crack. I used dCode to help identify the hash type (MD5) and then cracked with hashcat.
Awesome, we got two cracked passwords. One of them being gael’s, let’s see if we can switch to their account. This works and gets us our first flag.
At this point I tried logging in as gael using ssh for a better session. It looks like gael can’t run sudo. I logged into the site as royer and gael but their dashboard was the same. It looks like gael is in a group named sysadm. I also checked the SUID permissions.
I did a quick look at GTFOBins but nothing applies here. I have a couple passwords I haven’t used with anything, so I tried both with root. Neither worked but that was expected. Time to run linpeas.
Going through the results, we have a high chance at a PE vector flagged for CVE-2021-3560. I launched metasploit and searched for this CVE.
Since we have an exploit here, I used the ssh_login module to get a session inside of metasploit.
This module says the target is not exploitable though. No worries, I tried a metasploit module for CVE-2021-4034 that failed next. I moved on to a module for CVE-2021-3156. This failed to create a session. After tinkering some more I drop this too.
I moved on to looking more into the sysadm group gael is a member of. I checked what files my group owned and found /var/backups/backrest_backup.tar.gz. I started digging through the contents of the tar file. This quickly got deleted so I had to copy to my machine to look it over.
I tried finding a way to read the jwt-secret file. I checked my access to the mounted drives.
Continuing on with linpeas, there are some interesting ports open on the loopback address. We see a mysql user listed, maybe we can try with one of those two passwords we haven’t used.
Doesn’t appear to be installed though. I kept going through and investigating things as I came across them. I saw mention of the backup files we found earlier. Reading over install.sh from those files again, I noticed it is what is using 127.0.0.1:9898. This means we may have an internal site we need to try to access.
Let’s try settings up ssh port forwarding to access this internal resource. Here we are using gael’s ssh ability to tunnel 127.0.0.1:80 on our machine to 127.0.0.1:9898 on the target, which allows us to access the internal resource from our computer.
There, we have access now. Remember you are visiting http://127.0.0.1:80 in your browser if you ran it as I did. We get the Backrest version 1.7.2 here. I tried logging in as gael, app, and royer without luck. I began researching Backrest and tried a gobuster scan against it.
Nothing at the /Download page. I ran a general search for any file containing backrest on the machine and then began looking over those.
I ran strings on /opt/backrest/tasklogs/logs.sqlite and found what looks like a couple MD5 hashes?
I couldn’t crack them with rockyou.txt though. I got through the linpeas results so I need to do another pass at all my notes and think about this some more. I found the Backrest repository and read its user guide. This mentions user credentials being in ~/.config/backrest/config.json. I don’t recall seeing this file so I jumped to that location on the target. I don’t have rights, but I have the backups of this on my attacking machine.
I am kicking myself because I did not list hidden files when I checked it out the first time. That’s okay though, we move to crack this new hash. This doesn’t match the Bcrypt password hash style, so I use dCode to try to identify any encoding, in this case Base64.
Much better, I wrote this to a file and tried cracking with hashcat.
Cool, let’s try to log in to the portal.
That works to get us in. At this point I am fairly certain this is about to be our privilege escalation. I saw earlier that backrest is running as root when I read /etc/systemd/system/backrest.service.
I started by trying to make a plan, but then realized I need to make a repo first. After creating the repo with somewhat random info, we can click on it to get the option to run a restic command. I’m not too familiar, so I run help and then start looking into restic commands.
I tried adding a Hook to my repo where it runs a command when a condition is met. I saw a button for Check Now after we made our repo, so I made this my condition.
I started a netcat listerner on my machine and the used the Check Now button.
This got us root and our final flag. This room was a lot of fun and not too difficult. I am kicking myself for not using ‘ls –al’ and missing that .config folder when I inspected the backup originally. But I guess that will be my lesson learned for this one.