Vulnerability Hunting
Researchers began by examining a Kiteworks virtual machine file, which they mounted easily. This provided access to the platform's source code, which helped streamline vulnerability analysis.
Inside the image, several components were identified:
- A PHP-based public-facing website
- An internal Python API running with Gunicorn
- An external PHP API
- MySQL and MongoDB databases
- A Python command-line tool used across the platform
The team focused first on the website, which appeared to be the most accessible route for identifying flaws.
Gaining SSH Access
Kiteworks includes a feature in the admin interface allowing “Remote Management over SSH” for support use. The admin enables this function and shares a generated management password. However, this password alone doesn’t grant SSH access.
By examining the source code, researchers found that the real SSH password is a combination of two values:
- A randomly generated phase (usually the first 10 characters of the password)
- The first 10 hexadecimal characters of a license file’s digital signature
Another secret called filex_key, stored inside the license, was also required. It could be extracted by decoding the license using base64, then decrypting it using AES-128-CBC with a static key. Once the phase and filex_key were known, generating the valid SSH password was simply a matter of applying a SHA-1 hash.
This enabled successful login via SSH as the system user prometheus.
Forging a License (No Original Required)
If the original license wasn't available, the researchers found a way to bypass license verification and generate a valid but fake one.
The vulnerability stemmed from poor validation logic in the license verification process. Although the system defaulted to using strong public-key cryptography for version 2 licenses, inserting a secondary version indicator (version 1) in the JSON structure forced it into legacy SHA-512 hash-based verification.
This weaker validation allowed a crafted license to pass checks if it matched a calculated hash, despite not being signed with the proper private key.
Uploading such a forged license gave the attacker full control over:
- The phase used in SSH password generation
- The filex_key
- The license expiry date (which could be set to never expire.
- This enabled SSH access to the appliance.
Privilege Escalation from prometheus to root
Once inside as prometheus, the researchers found that this user could run a Python script as root using sudo. The script (admin.py) lived in a folder symlinked from the user’s home directory.
By renaming the directory and replacing it with their own that contained a symlink to /bin/bash (while keeping the same script name), they could trick the system into running a root shell.
Executing the command elevated their access to full root privileges, achieving complete compromise of the system.
Recommended Fixes
Upgrade Kiteworks to version 7.3.1-ng9 or later
Disable external SSH access to the appliance by blocking port 22
Harden sudo configurations to restrict binary paths and symlink-based bypasses
Summary
- The license verification process could be manipulated to forge a valid license, enabling attackers to gain SSH access
- Once inside, a weak sudo policy allowed trivial escalation from prometheus to root
- Combined, these issues create a critical post-authentication attack path
