Bypassing Authentication and Achieving RCE via XML and Argument Injection

TLDR: This research highlights how simple logic flaws in authentication workflows and insecure handling of XML data can lead to full system compromise. By manipulating SMS token verification and exploiting XML injection in backend processes, researchers can bypass authentication and achieve remote code execution. These findings serve as a reminder that even mature, large-scale applications often harbor critical vulnerabilities in their custom business logic.

Modern web applications are often built on a foundation of complex, custom-coded business logic that sits atop standard frameworks. While developers focus on securing the framework, the custom glue holding the application together is frequently where the most critical vulnerabilities hide. This research, presented at DEF CON 2024, demonstrates how seemingly minor implementation details in authentication and data processing can be chained into full remote code execution.

Authentication Bypass via SMS Token Manipulation

Authentication mechanisms that rely on SMS tokens are common, yet they are frequently implemented with flawed logic. In the case of the Swisscom Cockpit application, the authentication flow required a user to input their phone number, which triggered an SMS token. The vulnerability was straightforward: the staging environment used a static, hardcoded SMS token of 1111.

While a hardcoded token in a staging environment is a classic finding, the real issue was the lack of isolation between the staging and production environments. By identifying that the backend authentication service was shared, it was possible to use the staging-specific token to authenticate against the production system. This highlights a critical risk in modern DevOps: if your staging environment is not strictly air-gapped from production, it becomes a direct attack vector.

XML Injection and Path Traversal

Beyond authentication, the research explored how insecure XML processing can lead to severe outcomes. Many legacy or custom PHP applications use XML for data storage and configuration. When an application fails to properly sanitize user input before incorporating it into XML structures, it opens the door to XML injection.

In the Swisscom Worklink application, the vulnerability stemmed from a general path traversal prevention mechanism that was easily bypassed. The application attempted to strip path traversal characters like ../ but failed to account for different encoding or alternative representations. By using a payload like ..|/..|/, the filter was bypassed, allowing access to restricted directories.

The impact was magnified by the application's use of XML databases that were named with a .php extension. Because the application stored session tokens within these XML files, an attacker could read sensitive session data. Furthermore, by manipulating the XML structure, it was possible to trigger an XInclude directive. As documented by OWASP on XML External Entity (XXE) Prevention, this allows an attacker to include arbitrary files or data into the XML document, which in this case, led to the ability to overwrite or delete critical files, effectively providing a path to RCE.

Argument Injection in Sendmail

The most technically interesting finding involved exploiting the mail() function in PHP. When PHP calls the mail() function, it often interacts with the sendmail binary on the underlying Linux system. The fifth argument of the mail() function allows for the passing of additional command-line parameters to the sendmail binary.

If an attacker can control the input passed to this fifth argument, they can perform argument injection. In the case of the PepperShop CMS, the application used escapeshellarg() to sanitize input, but because PHP automatically applies this function to the entire command string, a double-escaping issue occurred. This effectively neutralized the security control.

By injecting parameters like -C (to specify a custom configuration file) and -X (to specify a log file), an attacker can force the sendmail binary to use a malicious configuration file. If the attacker can also upload a file to the server—which was possible here due to an insecure file upload feature—they can point the sendmail binary to a file they control. This file can then be used to execute arbitrary PHP code when the application attempts to process the mail queue.

Defensive Strategies for Developers

The common thread across these vulnerabilities is a failure to treat user input as untrusted, regardless of where it originates. For authentication, never rely on static tokens, and ensure that staging and production environments are cryptographically and logically separated.

For XML processing, the best defense is to disable external entity resolution entirely. If you must use XML, use a hardened parser and ensure that your configuration files are stored outside of the web root. Regarding argument injection, avoid passing user-controlled input to system binaries whenever possible. If you must use functions like mail(), validate the input against a strict allowlist of expected characters and formats. Relying on built-in sanitization functions like escapeshellarg() is often insufficient if the underlying system call chain is not fully understood.

These findings underscore that the most effective way to secure an application is to assume that every input field is a potential entry point for an attacker. Whether it is an SMS token, an XML configuration file, or a mail header, the logic governing how that data is processed is just as important as the security of the underlying infrastructure. Always test your assumptions about how your application handles data, especially when that data interacts with system-level binaries or sensitive configuration files.