Ghosts of the Past: Classic PHP RCE Bugs in Trend Micro Enterprise Offerings

Ghosts of the Past: Classic PHP RCE Bugs in Trend Micro Enterprise Offerings

Speakers: Poh Jia Hao, Security Researcher, STAR Labs

Conference: HITCON CMT

YouTube: https://www.youtube.com/watch?v=DZjmKFL8Zb8

Overview

In this compelling talk at HITCON CMT, security researcher Poh Jia Hao of STAR Labs unveiled a series of critical vulnerabilities in Trend Micro's enterprise-grade security products, Apex Central and Mobile Security Enterprise. The presentation, titled "Ghosts of the Past," meticulously detailed how classic PHP remote code execution (RCE) bugs, often dismissed as relics, can still be found and exploited in complex, modern enterprise applications, particularly those burdened by legacy codebases. Hao's research highlights the significant impact that chaining seemingly minor or "limited" primitives can have, culminating in unauthenticated RCE on high-value targets.

The core of the research focused on two distinct RCE chains, along with several other vulnerabilities like Cross-Site Scripting (XSS) and Server-Side Request Forgery (SSRF). The first chain targeted Apex Central, leveraging a post-authentication SQL injection vulnerability in a SQLite database to achieve RCE through an ingenious code-golfing technique for payload delivery. The second, and arguably more impactful, chain exploited Trend Micro Mobile Security Enterprise, demonstrating a pre-authentication RCE achieved by combining an authentication bypass, a limited file upload, and a limited Local File Inclusion (LFI). These findings underscore the critical importance of continuous security auditing, especially for applications that integrate diverse technologies and carry over substantial amounts of legacy code.

Hao's presentation served as a powerful call to action for the security community, emphasizing that despite the prevalence of groundbreaking new bug classes, a wealth of unreported vulnerabilities still lurks within established enterprise software. The talk not only provided deep technical insights into the exploitation methodologies but also offered crucial defensive implications, urging developers to adopt secure coding practices like prepared statements and robust input validation, and for organizations to recognize the widespread impact of code reusability across product lines.

Background

▶ Watch: Introduction and talk agenda overview (0:00)

Poh Jia Hao embarked on this research journey with a specific interest in uncovering 0-day and N-day vulnerabilities in enterprise applications. His motivation stemmed from observing a significant amount of legacy PHP code within Trend Micro's offerings, which often indicates a higher likelihood of overlooked security flaws. Enterprise applications, while challenging to acquire and set up in a test environment, frequently harbor critical bugs due to their complexity, extensive feature sets, and often, a lack of independent security scrutiny compared to more widely used open-source projects.

Trend Micro, a prominent cybersecurity vendor, provides a vast array of solutions, broadly categorized into home and business segments. Hao specifically focused on the Business Solutions due to their larger attack surface and the potentially greater impact of any discovered vulnerabilities. The primary targets for this research were Apex Central and Mobile Security Enterprise.

Apex Central, originally known as Control Manager before its rebranding, serves as a centralized management console for ensuring consistent data and threat protection policies across registered endpoints. Its technological stack is remarkably diverse, incorporating C#, Microsoft SQL, PHP, Java, Node.js, and even SQLite, suggesting a complex and potentially fractured development history where security practices might not have been uniformly applied. Mobile Security Enterprise, on the other hand, centralizes the administration of mobile devices within an organization, allowing administrators to restrict unauthorized applications and manage aspects like CA certificates across corporate devices.

A critical observation across both applications was the extensive code reusability. This modular approach, while beneficial for feature extensibility, creates a significant security risk: a vulnerability found in one shared module often translates into identical vulnerabilities across all applications utilizing that module. Hao focused on the web components, specifically the widget directory found in the web root of both applications, and within it, the repository/wp1/proxy directories. These directories house the core logic following an Model-View-Controller (MVC) pattern, with controllers and models residing in the proxy directory and views in the widget directories. All interactions with these modules are routed through a central proxy_controller.php file, which dynamically loads the desired module based on request parameters. This architectural design, while promoting modularity, ultimately amplified the reach of the discovered vulnerabilities.

Key Findings

▶ Watch: First RCE: Post-auth SQLi via file upload (6:00)

Poh Jia Hao's research uncovered a trove of vulnerabilities, predominantly leading to Remote Code Execution (RCE), across Trend Micro Apex Central and Mobile Security Enterprise. The overarching theme was the successful chaining of individually limited or seemingly innocuous primitives into high-impact exploit paths.

The primary findings can be categorized into two distinct RCE chains and several other significant vulnerabilities:

1. Apex Central Post-Authentication RCE (via SQL Injection and File Upload):

• This chain originated from a SQL Injection vulnerability within the tmms module, which utilized an internal SQLite database separate from the main Microsoft SQL database.
• The SQL injection was possible due to direct concatenation of user-supplied input into an exec function call, allowing for stacked queries.
• The challenge of a strict 64-character length limit on certificate Common Name (CN) fields (due to openSSL_x509_parse validation and RFC 5280) was overcome through extensive code golfing to craft a payload that could attach a database and write a PHP webshell.
• This post-authentication RCE was further upgraded to a one-click RCE by chaining it with existing Cross-Site Scripting (XSS) vulnerabilities found elsewhere in the application. Multiple CVEs were assigned for this chain and the associated XSS bugs.

1. Mobile Security Enterprise Pre-Authentication RCE (via Auth Bypass, Limited File Upload, and Limited LFI):

• This highly critical chain allowed for RCE without any prior authentication.
• Authentication Bypass: A design flaw allowed arbitrary user creation and authentication by simply manipulating the session_info cookie. The application would automatically create a new user with a blank password if a non-existent email was supplied via the cookie.
• Limited File Upload: An authenticated (post-bypass) vulnerability in the TMMS_SPM module allowed attackers to upload arbitrary files to the C:\Windows\Temp directory. This was "limited" because the directory is outside the web root, preventing direct web access to the uploaded file.
• Limited Local File Inclusion (LFI): A path traversal vulnerability in the WidgetPoolFactoryAbstract class allowed an attacker to include arbitrary files from the server's filesystem. While the included filename was partially fixed (PoolManager.php), the path could be manipulated via URL parameters, allowing the inclusion of the previously uploaded webshell from C:\Windows\Temp.
• The combination of these three primitives resulted in a full unauthenticated RCE. Due to code reusability, this entire chain was found in two different endpoints, leading to the assignment of six CVEs for these two exploit chains.

Beyond these primary RCE chains, Hao also reported numerous other vulnerabilities, including several straightforward XSS bugs (due to a lack of sanitization of user input in server responses) and Server-Side Request Forgery (SSRF) vulnerabilities. The SSRF flaws allowed attackers to force the server to send arbitrary web requests, potentially exposing internal network resources. The research underscored that even seemingly "low-hanging fruit" vulnerabilities remain prevalent in complex enterprise software.

Technical Deep Dive

▶ Watch: Second RCE: Pre-auth user creation bypass (22:00)

The technical core of Poh Jia Hao's presentation revolved around the intricate details of two distinct RCE chains, showcasing how multiple, often limited, vulnerabilities can be meticulously chained to achieve maximum impact.

RCE Chain 1: Apex Central - Post-Auth SQL Injection to Web Shell

This chain targeted Apex Central and began with a post-authentication SQL injection vulnerability.

The entry point was the tmms module, which, despite the application's reliance on Microsoft SQL for most operations, utilized its own SQLite database (found at tmms.db). The vulnerable function, addCert, within the tmms class, directly concatenated user-supplied data from a cert variable into an SQL query without proper sanitization:

The use of exec instead of query was crucial, as it allowed for stacked queries, enabling the execution of multiple SQL statements in a single connection.

To reach this sink, the addCert function was called by uploadX509Cert, which in turn was invoked by the tmms module's proxy file (proxy_controller.php loading tmms/proxy.php). The path to exploitation required setting the HTTP parameter tmmsCmd to setCertificatesConfig and supplying a file via the certFileName parameter in a POST request.

A significant constraint was the openSSL_x509_parse PHP function, which validated the uploaded file as a syntactically correct X.509 certificate. Furthermore, the RFC 5280 standard limits the Common Name (CN) field in a certificate to 64 characters. Since the name and issuer fields (derived from the certificate's CN) were the injection points, this imposed a total payload length limit of 128 characters (64 for name + 64 for issuer).

The goal was to write a webshell to a web-accessible directory. Given SQLite's capabilities, the classic ATTACH DATABASE method was chosen. The initial payload, designed to create a PHP webshell (a.php) in the repository directory with <?=$_GET[0]?> content, was 211 characters long, far exceeding the 128-character limit. This necessitated extensive code golfing:

1. Remove Redundant Spaces: Standard minification.
2. Short PHP Tags & Backticks: Replaced <?php echo exec($_GET[0]); ?> with <?= and backticks: <?=$_GET[0]?>. This drastically reduced the PHP shell size.
3. 8.3 File Naming: For Windows paths, C:\Windows\Temp could be shortened to C:\WINDOW~1\TEMP, leveraging the 8.3 filename convention.
4. Relative Paths: Instead of a full path like C:\Program Files\Trend Micro\Apex Central\repository, a relative path like .\repository was sufficient, as the PHP process had write access to a directory very close to the target.

After these optimizations, the payload was reduced to 122 characters, fitting the 128-character limit. It was split into two parts, with /* and -- used to comment out the intermediate SQL, bringing the final payload to 125 characters.

Example SQL payload (conceptually split):

• Part 1 (CN for name): x; ATTACH DATABASE '.\repository\a.php' AS x; CREATE TABLE x.y(z TEXT); INSERT INTO x.y VALUES('<?=$_GET[0]?>'); --
• Part 2 (CN for issuer): (Empty or dummy to complete the certificate, or more SQL if needed)

The final step involved using OpenSSL commands to generate a CA and then a certificate with the crafted SQL payload embedded in the Common Name fields. Sending this certificate via a POST request would trigger the SQLi, creating the a.php webshell in the repository directory. Accessing repository/a.php?0=id would then execute arbitrary commands. This post-authentication RCE was then chained with an XSS vulnerability to create a one-click exploit.

RCE Chain 2: Mobile Security - Pre-Auth RCE

This chain demonstrated a pre-authentication RCE in Trend Micro Mobile Security Enterprise, combining three distinct vulnerabilities.

1. Authentication Bypass:

The application's authentication mechanism checked two cookies: is_session_info and PHP_SESSION_ID. Crucially, session_info was tied to PHP_SESSION_ID. The WF_User class's productUserInit function called productGetSessionUsername, which retrieved the username from the PHP session. This username value was directly controlled by the session_info cookie, specifically by providing a comma-delimited string (e.g., ,foo).

If the provided "email" (derived from the session_info cookie) did not exist in the SQLite users table, the createUser function would be invoked. This function would then insert a new row into the users table, using the attacker-controlled string as the email and a hardcoded blank string as the password. Subsequently, the bindUser function would set the auth session variable to true, effectively authenticating the attacker.

Exploitation: Setting the session_info cookie to ,attacker_email would create a new user and grant authenticated access with a blank password.

1. Limited File Upload:

Once authenticated via the bypass, a vulnerability in the TMMS_SPM module's proxyExec function (specifically within the setCertificatesConfig switch case, triggered by setting tmmsAction parameter) allowed for arbitrary file uploads. Critically, no file type or content validation was performed, and the uploaded file was moved to the C:\Windows\Temp directory.

This was a "limited" primitive because C:\Windows\Temp is outside the web root, meaning the uploaded webshell could not be directly accessed via a browser. However, it provided the essential capability to place a malicious file on the server.

1. Limited Local File Inclusion (LFI):

The final piece of the puzzle was an LFI vulnerability in the WidgetPoolFactoryAbstract class. The getWidgetPoolManager function took an stringUpdateType argument, passed it through getUpperCamelCase (which converted casing and performed replacements but was ineffective on Windows due to case-insensitivity), and then concatenated the result into a require_once path: require_once $directory . $stringFileName . 'PoolManager.php';.

While the PoolManager.php filename was fixed, the stringFileName portion (derived from stringUpdateType) was vulnerable to path traversal.

Exploitation: By sending a JSON request with act set to check and updateType containing a path traversal sequence like ../../../../Windows/Temp/pool_manager.php, the attacker could force the application to include their previously uploaded webshell (pool_manager.php) from C:\Windows\Temp.

This inclusion would execute the webshell, leading to full RCE. Due to the modular and reusable nature of the code, this entire pre-authentication RCE chain was duplicated across multiple endpoints, multiplying its impact and leading to additional CVEs.

These detailed technical breakdowns underscore the complexity of enterprise application security, where legacy design choices and code reusability can create fertile ground for sophisticated exploit chains, even from seemingly basic vulnerabilities.

Demo / Proof of Concept

▶ Watch: Combining limited file upload with LFI (26:00)

While the full demonstrations were not live during the conference talk due to time constraints and pending post-conference release, Poh Jia Hao provided clear conceptual walkthroughs and screenshots illustrating the successful exploitation of both RCE chains.

For the Apex Central RCE chain, the demonstration conceptually involved:

1. Authentication: Obtaining valid credentials (or using a low-privileged account).
2. Certificate Generation: Using OpenSSL to craft an X.509 certificate with the highly compressed SQL injection payload embedded in the Common Name fields of the subject and issuer.
3. File Upload Request: Sending a POST request to the vulnerable proxy_controller.php endpoint, specifying tmmsCmd=setCertificatesConfig and including the crafted certificate as the certFileName parameter.
4. Webshell Creation: The SQL injection successfully executes, attaching the database to a PHP file (a.php) within the web-accessible repository directory, writing the <?=$_GET[0]?> webshell content.
5. RCE Trigger: Accessing repository/a.php with a GET parameter (e.g., ?0=whoami) to execute arbitrary commands, with a screenshot showing the output (e.g., phpinfo()).

The speaker also mentioned that this post-authentication RCE could be triggered with a one-click exploit using an existing XSS vulnerability, where an authenticated victim loading a malicious URL would automatically trigger the webshell upload and command execution.

For the Mobile Security Enterprise Pre-Auth RCE chain, the proof-of-concept steps were described as follows:

1. Authentication Bypass: Sending an HTTP request with the session_info cookie set to ,any_email (e.g., ,fubar). The application automatically creates a user with a blank password and sets the auth session variable to true, granting an authenticated session. A screenshot of the user ID cookie being granted confirmed successful authentication.
2. Limited File Upload: Using the newly authenticated session, an attacker would send a POST request to the TMMS_SPM module, setting tmmsAction to the specific value to trigger the file upload. The request would include a malicious PHP webshell (e.g., pool_manager.php containing <?php phpinfo(); ?>) which would be uploaded to C:\Windows\Temp.
3. Limited LFI Trigger: A subsequent request would be sent to the vulnerable endpoint that utilizes the WidgetPoolFactoryAbstract class. This request would contain a JSON body with act set to check and updateType containing the path traversal payload (e.g., ../../../../Windows/Temp/pool_manager.php).
4. RCE Execution: The path traversal would cause the application to include and execute the pool_manager.php webshell from the C:\Windows\Temp directory. A screenshot displaying the output of phpinfo() was used to demonstrate successful RCE.

Hao confirmed that the detailed Proof of Concept code and slides for both chains would be made publicly available after necessary clearance from Trend Micro, ensuring that the security community could further analyze and learn from these complex exploit techniques.

Defensive Implications

▶ Watch: Key takeaways and future research opportunities (34:00)

The vulnerabilities uncovered in Trend Micro's enterprise offerings provide critical lessons for both developers and security professionals. The defensive implications span secure coding practices, architectural considerations, and ongoing security posture management.

1. Strict Input Validation and Sanitization:

• SQL Injection Prevention: The most glaring vulnerability was the direct concatenation of user input into SQL queries. Developers must exclusively use prepared statements (e.g., PDO with parameter binding in PHP) for all database interactions. This fundamentally prevents SQL injection by separating code from data.
• File Uploads: Implement comprehensive validation for uploaded files. This includes checking file extensions against a strict allow-list (as Trend Micro's patch eventually did), verifying file content (e.g., magic bytes), and potentially sandboxing uploads. Files should never be directly executed or placed in sensitive system directories without rigorous checks.
• Path Traversal: Any function that constructs file paths from user-supplied input must perform robust sanitization to prevent path traversal sequences (e.g., ../, ..\). Canonicalization of paths and validating against an allow-list of allowed directories are crucial.

1. Robust Authentication and Session Management:

• Trust No Input: The authentication bypass highlighted the danger of blindly trusting client-supplied session information. Authentication mechanisms should rely on server-generated, cryptographically secure tokens that are properly validated on each request.
• Secure User Provisioning: Applications should never automatically create users based on arbitrary client input, especially with blank or weak default passwords. User creation should require explicit administrative action or a secure registration process.
• Session Binding: While session_info was tied to PHP_SESSION_ID, the logic failed to prevent manipulation. Secure session management involves strong session IDs, HTTPS-only cookies, HttpOnly flags, and proper session invalidation.

1. Managing Legacy Code and Code Reusability:

• Security Debt Audit: Organizations with extensive legacy codebases must conduct regular and thorough security audits to identify and remediate accumulated security debt. This is particularly important for code that has been carried over through rebrands or product integrations.
• Centralized Security Review for Shared Modules: The "find one bug, find many" phenomenon due to code reusability underscores the need for stringent security reviews of shared modules. A vulnerability in a core component can have a multiplicative effect across an entire product portfolio. Fixes should be applied centrally and propagated consistently.
• Component-Based Security: Treat each reusable component as a mini-application, subject to its own security lifecycle and testing.

1. Principle of Least Privilege:

• Filesystem Permissions: The PHP process should operate with the absolute minimum necessary privileges. It should not have write access to system directories like C:\Windows\Temp or even web-accessible directories like repository unless strictly required for its legitimate function. Limiting write access can mitigate the impact of file upload vulnerabilities.
• Database Isolation: The use of a separate SQLite database for specific modules, while potentially a design choice, should still adhere to security best practices. Each database instance, regardless of its size or purpose, requires protection against injection.

1. Comprehensive Security Testing:

• Dynamic and Static Analysis: Employ both Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST) tools, especially for large, complex codebases. However, as this talk demonstrated, manual code review and creative vulnerability research remain indispensable for finding subtle logic flaws and chained exploits.
• Penetration Testing: Regular, expert-led penetration testing is crucial to identify exploitable weaknesses that automated tools might miss. Testers should specifically focus on chaining limited primitives and exploring edge cases in application logic.

By addressing these defensive implications, organizations can significantly enhance the security posture of their enterprise applications, reducing the attack surface and mitigating the risk of sophisticated RCE attacks originating from "ghosts of the past."

Key Takeaways

• Enterprise Applications are Prime Targets: Despite their complexity and often proprietary nature, enterprise applications, especially those with legacy code, are a rich hunting ground for critical vulnerabilities like RCE. The effort to obtain and set up these applications can yield significant security findings.
• Code Reusability is a Double-Edged Sword: While modularity and code reuse aid development, a single vulnerability in a shared component can lead to widespread exposure across multiple products, as seen with the multiple CVEs assigned for duplicated code.
• Don't Underestimate "Limited" Primitives: Seemingly minor vulnerabilities (e.g., file upload to a non-web-accessible directory, partial path traversal) can be chained together to achieve high-impact results like unauthenticated RCE. Always note down all primitives found, as they might become part of a larger exploit chain later.
• Persistence and Creativity in Exploitation: Overcoming strict constraints, such as the 64-character Common Name limit for SQL injection, requires significant creativity and "code golfing" to craft payloads. Never give up easily when an exploit seems impossible at first glance.
• Fundamental Secure Coding Practices Remain Critical: The core vulnerabilities (SQL injection, authentication bypass, path traversal) stem from basic insecure coding practices like direct input concatenation and unchecked user data. Emphasize the consistent use of prepared statements, robust input validation, and secure authentication mechanisms.
• Ethical Disclosure is Paramount: Researchers have a responsibility to report findings ethically to vendors, allowing them to patch vulnerabilities and protect users, thereby contributing positively to the security ecosystem.

About the Speaker(s)

Poh Jia Hao is a dedicated Security Researcher based at STAR Labs Singapore. His professional interests are deeply rooted in web application security research, with a particular focus on discovering both 0-day and N-day vulnerabilities. He has a track record of success in researching various open-source Content Management Systems (CMS) and possesses practical experience in penetration testing. This talk at HITCON CMT marked Poh Jia Hao's debut as a conference speaker, highlighting his expertise and contributions to the cybersecurity community.