UPDATE
Researchers have created a proof-of-concept exploit that would enable bad actors to target a severe vulnerability in the PHP programming language behind several major CMS companies, including WordPress. The vulnerability remains unresolved – more than a year after it was reported.
The researchers at Secarma who uncovered the exploit said it enables bad actors to potentially open up thousands of WordPress sites (and other web applications) to remote code-execution.
The vulnerabilities stem from the behaviors of PHP’s built-in “phar://” stream wrapper, which helps it implement complex file handling functionality for various URL-style protocols, researchers said this week.
Typically, Phar archives are used to hold self-extracting or self-contained applications, researchers said. Part of this archive’s function revolves around “unserializing.” This means that when a file operation tries to access the archive files, they need to be unserialized, or converted from plain string data into objects, which it does automatically.
However, researchers said, this process has glitches, enabling bad actors to launch remote code-execution attacks. They can do this by placing a maliciously created file into the archive, which will be automatically unserialized and executed by the legitimate process.
“This [is] a novel attack technique specific to PHP which can cause unserialization to occur in a variety of exploitation scenarios,” Sam Thomas with Secarma said in a white paper about the attack.
Exploiting the vulnerability is broken down into two stages, researchers said. First, an attacker would place a valid Phar archive containing the payload object into the victim’s local file system. Then, he or she would trigger a file operation on a “phar://” path that refers to the file.
This is enabled through a series of what have been historically considered low-risk flaws, such as XML External Entity processing (XXE) vulnerabilities. These flaws are a type of server-side request forgery (SSRF) vulnerability that enables attackers to cause a denial of service (DoS) and then access local or remote files and services, by abusing a widely available but rarely used feature in XML parsers.
“XXE issues whose maximum impact would previously have been considered file disclosure provided that out-of-band communication was possible, must now be considered potential code-execution issues, whether out-of-band communication is possible or not,” Thomas said.
For WordPress, an attacker would need privileges to upload and modify media items to gain sufficient control of the parameter, researchers said.
Thomas said that he reported the issue to WordPress in February 2017 – but it remains unfixed at the time of writing. Threatpost reached out to WordPress for comment and will update this post with any reaction from the CMS purveyor.
Aside from WordPress, the issue impacts several other CMS, including Typo3, as well as the widely-used PDF generation library TCPDF.
These kinds of unsecure unserialized processes in PHP have been spotted before – the issue was first presented by Stefan Essar in 2009, and the topic is closely associated with similar flaws, including CVE-2017-12934 and CVE-2017-12933).
“Recent years have also seen several vulnerabilities in the native code implementing unserialization further demonstrating the risk of exposing unserialization to attacker-controlled data,” researchers said.
As for mitigation, researchers said that it doesn’t seem possible to disable the Phar extension from the command-line options in settings. But, prevention of the security issue starts in blocking attacker-controlled data that can trigger stream wrappers: “To prevent the exploitation of this issue it is imperative to prevent attacker-controlled data being used in the beginning of a file name used in any of the file operations which can trigger stream wrappers,” they said.
They added, “A first line of defense should of course be to avoid such vulnerabilities in application code.”
This article was updated August 21 at 4:30 p.m. to further detail certain privileges that attackers would need to launch a WordPress-based attack.
