- XXE (XML External Entities)
- PHP Phar Exploitation
- Log4Shell
These vulnerabilities have a common characteristic: they are inherent features of programming languages or libraries. However, it took a considerable amount of time for them to be recognized as attack vectors and actual vulnerabilities.
The existence of these vulnerabilities, previously unknown until their public disclosure, resulted in a substantial and previously unidentified attack surface for malicious actors. This discovery had far-reaching implications, as applications that were once considered secure suddenly became vulnerable. Although the security gap existed all along, the revelation of new exploitation techniques that leveraged existing features opened the floodgates for attackers.
XXE
XXE (XML External Entities) vulnerabilities were first published by a researcher in the early 2000s. However, it took some time for the security community to fully grasp the significance of this vulnerability. In 2013/2014, bug bounty researcher Reginaldo Silva, a Brazilian software engineer, played a crucial role by discovering and reporting multiple XXE vulnerabilities to Facebook and OpenID. This exemplifies how the security community learns rapidly from each other through shared write-ups. Consequently, multiple vendors, not limited to Facebook and OpenID, had to address this newly classified vulnerability type in their applications. XXE was first introduced into the OWASP Top 10 in 2013 and remained there until 2017.
XXE, as a term, describes a feature rather than a bug within the XML standard. In XML, every file or payload can contain a Document Type Definition (DTD), which may include entity definitions. Entities act as variables within the XML file, enabling various functionalities. For instance, an entity can contain a URL, allowing requests and content retrieval from websites. Furthermore, entities can execute code in specific programming languages, potentially leading to remote code execution (RCE). The main issue arises from engineers using XML processors in their projects who may be unaware of these capabilities within the employed XML processor library. The frustrating aspect is that these potentially malicious features are enabled by default in all XML processors. Consequently, this vulnerability can still persist today, even with default configurations, as it can be inadvertently introduced by developers who are unaware of this XML specification.
You can read Reginaldo Silva’s famous bug bounty write up here.
This is a prime example of a relatively unknown feature, enabled by default, suddenly evolving into a new vulnerability type.
PHP Phar Exploitation
The risk of unserializing attacker-controlled data in PHP has been well-known since Stefan Esser extensively presented the issue in 2009. However, in 2018, Sam Thomas presented groundbreaking research at Blackhat, unveiling a previously unknown method of remote code execution utilizing the phar:// wrapper in PHP functions like open(), copy(), file_exists(), and filesize(). These functions share a commonality in supporting various wrappers such as file://, http://, ftp://, php://, zlib://, data://, glob://, and phar:// by default.
While it was already recognized that certain wrappers could be misused for specific attacks like LFI, SSRF, and XXE, Sam Thomas delved deeper into the specifications of each wrapper, uncovering a novel path to direct remote code execution. By studying the official PHP documentation and understanding the intricacies of the phar:// wrapper, he devised an attack strategy.
As part of his research, Sam Thomas also reported multiple vulnerabilities in well-known CMS platforms such as Typo3 and WordPress. This publication marked a significant turning point, as functions like file_exists(), which previously required less input sanitization, suddenly became vulnerable. Researchers could utilize open-source code repositories like GitHub, search for the file_exists() function, confirm that the prefix of the parameter could be controlled by the user, and then identify the necessary steps to trigger that function within the target application. This era ushered in a new approach to discovering vulnerabilities at scale, employing simple search mechanisms like CTRL+F within open-source software projects.
Log4Shell
The Log4Shell vulnerability, also known as CVE-2021-44228, is an unauthenticated remote code execution vulnerability that affects the widely used Log4j 2.0 through 2.14.1 logging library.
Chen Zhaojun a employee at Alibaba Cloud Security responsibly disclosed the log4j vulnerability in private directly to the log4j developers, so that a patch to log4j was released by December 6th, several days before the vulnerability went public. The hacking community quickly compared the changed code of the patch to unveil the vulnerability behind the CVE. Not longer than a few hours later, the first attacks have been recorded leading to the compromise of thousand of unpatched systems.
Log4Shell allows an attacker to execute arbitrary code on a vulnerable system by exploiting a specific feature within Log4j, known as the JNDI (Java Naming and Directory Interface) lookup. Log4j supports JNDI lookups to provide a flexible and dynamic way of configuring log appenders and retrieving resources from external naming and directory services
Before the Log4Shell vulnerability was discovered, developers generally did not have to assume that log messages could trigger the execution of actual code. The primary purpose of logging frameworks like Log4j is to facilitate the recording of application events and provide diagnostic information. There was generally less emphasis on validating user input specifically within log messages. Traditional logging practices focused on capturing and recording application events for debugging, monitoring, and audit purposes, rather than considering log messages as potential attack vectors.
TL;DR: Log4Shell was a feature enabled by default in Log4j that required explicit disabling. The documentation indicated that the JNDI lookup feature was enabled, making it important for developers to take action to disable it if not needed.
Summary
While secure software development practices and tools can help protect against known threats, there is currently limited proactive protection against unknown and undiscovered vulnerability types. Logging and monitoring can detect anomalies, but preventing the initial attack vector or exploit is challenging without prior knowledge. We can defend against known vulnerabilities like XSS or SQL injection, but future vulnerabilities originating from features are harder to preempt. It’s only a matter of time until the next major vulnerability emerges. The next threat may be hidden in the documentation, waiting to be uncovered.
The evolving nature of cybersecurity means that even seemingly innocuous features may eventually be identified as vulnerabilities. It highlights the importance of continued vigilance, regular security assessments, and staying informed about emerging threats to ensure the robustness and resilience of software systems.