Starting Point Part 3: Vaccine

ArtilleryRed
6 min readMar 21, 2021

--

So we are on the third box. We got one box done as Windows and one box done as Linux. Let’s see what we can add to our toolbox this time. Always try to add something new!

So starting out, let’s run the nmap. I’ll start by putting the ip address in a variable, then run with a scan. It comes back with three ports, so let’s find some more information: nmap -sC -sV -p 21,22,80 -Pn -oN Vaccine.nmap $IP. We have three basic services running, it nmap indicating that we have a login to MegaCorp on port 80. Seems we are still in the same domain as the last two boxes. Since we pulled an ftp cred from the last box, let’s try that on ftp first and see what we get.

Well. That works. We found one file. I downloaded it. I also tried to upload to see if we could, but got a 553 error. We can’t upload files. No worries, let’s go see what was in the zip file. Looks like it is password protected, and the passwords we acquired over the past few boxes didn’t work. It does tell us that there are two files within it. Guess we need to crack it. I’ll use fcrackzip and it solves it in under a second. Perfect.

Okay, so we can unzip the file and now we can see within the index.php. At the top, it has a password has hard-coded. Perfect.

As you can see, it does an md5 on what the user passes and compares it ot the hard-coded string (which I didnt’ screen capture). Instead of using john or hashcat to crack it, I’ll start with an online database first and see if it is in there. Looks like crackstation.net had it already. So let’s make sure we add that to our credentials file. With that, let’s go to the webpage! Of course we have the right username/password and it lets us right on in. We land on a page that has a search box, but really not much else. The search box works, but can we try some characters that may make it crash? I’ll try things that could make an SQL query, like ‘,”,;,#, — . And looky there, we got an SQL injection error.

Well, I could play with this and start crafting some ideas, but why not use a tool that does it for us? sqlmap to the rescue.

I try to run sqlmap and it gives a 302 redirect and is trying to set a cookie? Wait, I had to log-in to get to this page, I bet it set a cookie. Let’s go check. Going to “Web Developer -> Storage Inspector” of the webpage, yes I have a cookie. We need to copy and paste that cookie into the command so it can use it.

So now running it with sqlmap http://10.10.10.46/dashboard.php?search=myquery — cookie=”PHPSESSID=m6tclb544qjqpkk6ldq07vgucb” it finds that it is vulnerable! It says that it is a PostgreSQL and the search parameter is vulnerable. Okay, let’s check out the databases. My approach is to just keep adding to the sqlmap command and dig deeper into the database each time. My next command I add a — dbs to the command and it spits out 3 tables. You can use the -D, -T, and — dump to dump the tables and databases you find. Unfortunately I dumped them and didn’t have much useful. Sqlmap can also try to get you a shell. Let’s try that and we get a shell!

However, this shell is going through the database and is a little rough. I always like to upgrade the shell as the next step, so I’ll start a listener and use a bash callback to get me a working shell.

Once I got my upgraded shell, time to look around. I’ll start in the home directory and see what we got. There is the user flag…and an ssh directory? Oh, it has a private key in it. Let’s steal it. For things I can cut and paste, we can use a base64 trick to copy the file over to our box.

On my box, I run the command echo “<PASTE WHAT YOU GOT>” | base64 -d > postgresql.id_rsa and now I have what was on the other box. Ensure we change the permissions of the file to 600, then ssh to the box and have the best shell!

Okay, now we can kill that shell we were using with sqlmap and continue with this good one. I’ll go ahead and run linpeas.sh to look around and see what we got. To keep the file from hitting the disk, I’ll run it with a pipe command and keep it fileless!

Okay. Reading through the linpeas output, there are a few things that stick out to me. There are a few ports running on localhost, we are part of the ssl-cert group, it revealed the postgres password, and simon is a user with a lot of good groups. That was my first pass at what looked abnormal. I’ll go back to that if I don’t find anything with these, so we’ll see. Now that I have postgres’s password, I’ll add that to my creds file I’m maintaining. So far, it looks like this:

Since I now have a password, I’ll check the easy win of sudo -l and low and behold it says we can run vi with sudo. I know how to get root from that, but I learned the tricks from GTFOBins and if you don’t have it bookmarked you should! I run the breakout for sudo and I am root!

That was the box, now it is time for cleanup. I want to ensure I leave the place pretty clean for the next user (or in the malicious world cover my tracks). I ran linpeas fileless and the bash history is already piped to null. The only other spot I could go clean up is the webpage log and postgres log where I got onto the box. I don’t want to remove everything from the logs, just my entries. I go check the /etc/postgresql/11/main/postgresql.conf file and logging is not turned on. Their loss, let me check the webpage. Looking in /etc/apache2/apache2.conf they don’t have logs turned on there either. Lets validate through the system what has been changed.

So this command allows us to go find everything that was changed since I started this business. You should be able to see a few files that have your IP address in it (like /var/log/auth.log). You could delete each entry (you are root) if you want. However, don’t make the file blank…that is super suspicious to the admins! Looking at the list, there is a /var/log/apache2/access.log that shows our SQL injection. The config file we saw didn’t have it turned on, but somewhere it was activated. Again, delete out what you have done. After you get done, don’t forget about the .viminfo file and your bash history too. Cleanup complete (as good as we can get right now)! Remember, if you decide to append to the authorized_keys file for root so you can come back later, that is another breadcrumb. Enjoy and see you on the next box!

--

--

ArtilleryRed

Cyber Enthusiast and sharing some knowledge in a systematic way