Scanning
We scan with nmap all ports, scripts and software versions.
Enumeration
Accessing the site by IP address, we see that the web service is only accessible through the domain "vulnnet.thm".
We insert the domain in our "/etc/hosts" file, we access the web site, the subscription form is checked, but it does not seem to work.
Listing of possible subdomains (virtual hosts), several subdomains are listed.
Website blog.vulnnet.thm:
Website api.vulnnet.thm:
It appears that an API is operational here:
Website shop.vulnnet.thm:
Website admin1.vulnnet.thm:
After reviewing several, I focus on API and admin1, it seems that they may have more relevance.
Fuzzing with dirsearch on "admin1.vulnnet.thm", we identify several interesting files and directories.
We list the file "INSTALL.md", it reveals the deployed TYPO3 CMS:
Access to the TYPO3 administrator panel:
We access admin1.vulnnet.thm/fileadmin/, but there seems to be nothing in the folders:
We continue to list another interesting directory:
Extract the user "chris_w" and the hashed password:
We tried to crack the hash with the tool John, but it seems that the password is not in rockyou:
We review the other table of the blog, we see that there is a table of 651 users with strong passwords, so it makes me suspect that maybe one of these passwords could be reusing one of these passwords on the administrator user of the other panel.
We transfer the list of passwords to a file called "passwords.txt" and use it again with the john tool.
I try to use the credentials on the SSH service, but they don't work, so I keep trying on the CMS administration panel.
We list the "fileadmin" section, this reminds us of the directory that we find with dirsearch where possibly the users upload their files, this could be interesting to try to upload a webshell or reverse shell.
But it seems that it does not allow us to upload PHP files:
But this has an easy solution, you can remove or edit the banned extensions from the list:
We remove all the restrictions, save and upload the PHP file again, this time it works, we access it, and we get a connection to the server.
We do not have access to read the "user.txt" file, but we see the ".mozilla" folder, this folder is not default, so it would still be possible to obtain credentials or relevant information from user's websites.
Directly, I downloaded the files "logins.json, cert9.db, cookies.sqlite and key4.db", and used the tool "firefox_decrypt.py".
We access through the SSH service and read the "user.txt" flag. We see that we cannot execute any binary or script through SUDO.
We launch the linpeas script and enumerate the list of capabilities, and we see that we can take advantage of the openssl binary:
It also indicates that it is vulnerable to CVE-2021-4034:
But if we try to exploit it, we see that the system is patched:
So nothing, we continue with the OpenSSL exploit, and create the file "openssl-exploit.c":
#include <openssl/engine.h>
#include <stdio.h>
#include <stdlib.h>
static int bind(ENGINE *e, const char *id)
{
setuid(0);
system("/bin/bash");
return 1;
}
IMPLEMENT_DYNAMIC_BIND_FN(bind)
IMPLEMENT_DYNAMIC_CHECK_FN()
From our attacking machine, we compile the exploit by executing the following commands:
gcc -fPIC -o openssl-exploit.o -c openssl-exploit.c
gcc -shared -o openssl-exploit.so -lcrypto openssl-exploit.o
/home/system/Utils/openssl req -engine ./openssl-exploit.so 
