UPDATED — January 22, 2019
The Threat Stack SOC is aware of the recent disclosure of a breach of the PHP Extension and Application Repository (PEAR). Details of the breach have not been disclosed publicly, and we have no special knowledge of the breach. However, attacks against code repositories and injection of malicious code into third-party application dependencies help to underscore the importance of behavioral detection methods to identify and mitigate the exploitation of insecure PHP deployments. We will update this blog as appropriate pending additional public information on the PEAR breach.
UPDATED — February 1, 2019
Several weeks after the original publication of this blog, the PHP Extension and Application Repository (PEAR) disclosed a breach of its website, which led to the compromise of go-pear.phar. While Threat Stack has no inside or special knowledge of the breach at PEAR, based on publicly available information, we have confirmed that the Threat Stack Cloud Security Platform and Cloud SecOps Program can detect and mitigate an attack leveraging this injected PHP code.
It appears the attackers in this incident leveraged the research Sam Thomas presented at Black Hat 2018, which we discussed in this blog post. Based on publicly available information, the attackers appeared to be performing the first step in the attack chain by attempting to deliver injected phar files into a target environment. It is possible this attack was part of a poison well tactic targeting a specific or multiple organizations known to use PEAR and this file.
Insecure data deserialization first made its way into OWASP’s 2017 Top 10 list by way of community feedback. In the history of application security, that makes it a relatively new vulnerability that can be harder to detect due to the way it uses popular code libraries that are commonly used in web development.
The Threat Stack Cloud SecOps Program℠ (which consists of the Oversight℠ and Insight℠ services) exists not only to monitor customer environments and investigate alerts, but also to work with customers to help them improve their security postures. Occasionally, here in the SecOps Program’s security operations center (SOC), we get questions about the detection capability of the Threat Stack Cloud Security Platform®, and whether it is capable of detecting new and advanced attack vectors. (Our system uses behavioral detection, which is an extremely robust methodology for detecting new and old attack techniques.)
In this post, I’ll walk through how my colleagues and I in the SOC addressed an inquiry regarding a specific insecure deserialization exploit seen in the wild.
phar:// archive wrapper
We simulated an attack that was discovered by Sam Thomas, a security researcher from a penetration testing company named Secarma, which makes it easier for attackers to trigger a critical deserialization vulnerability in WordPress. The attack was documented in a BlackHat 2018 paper entitled “File Operation Induced Unserialization via the ‘phar://’ Stream Wrapper.” We ran this attack on an Ubuntu 16.04 LTS host running the Threat Stack monitoring agent and the WordPress server to view its behaviors in real time. Our results are below.
This vulnerability is specific to PHP, a core component on WordPress websites, that allows remote code execution on the server. WordPress is an extremely popular CMS that boasts a market share of 59.9%. The remote code execution can be used to convert the server into a bot, conduct denial of service (DoS) attacks, create/connect C2 servers, conduct crypto mining, etc.
Data serialization, in a nutshell
Serialization is the process of converting data objects into plain strings whereas deserialization is the process of converting the plain string back into a data object. Serialization is done so that the data object can be stored easily on disk, transferred over a network, or processed on the system. Insecure deserialization is a vulnerability where untrusted/malicious data is used to abuse the logic of an application which can then be used to conduct other types of attacks like arbitrary code execution or DoS attacks.
Serialization and deserialization are core components for several web applications and their use cases. Several programming languages even provide features in order to serialize data. These practices are therefore extremely common in web development. The issue arises when unsanitized, untrusted, or malicious data is unserialized.
Will Threat Stack catch unsafe PHP deserialization?
To test the exploit, we used two systems:
- Attacker System: The payload was created on this system and contained a shell command
whoami && ls -al. The command
whoamiwill show the user who is running the command, and
ls -alwill show all the files (including hidden files) present in a specific directory along with the file’s permissions, name, and owners. The payload was a JPEG/Tar polyglot Phar archive that was injected into the WordPress website. Phar files are an archived format in PHP that store metadata in a serialized format. This format can be unserialized whenever a file operation tries to access the file. This payload was unserialized via the
phar://stream wrapper. (The phpggc tool was used to create the payload.)
- Victim System: An Ubuntu 16.04 LTS server, running WordPress 4.8 and Threat Stack Agent 1.9.0.
When the payload was unserialized, the host agent was able to detect the commands being run on the server. We can see the application user (in our case
www-data) spawning a shell (/bin/dash) and running
ls -al on the main system. We can also see that the
session = 4294967295, which means that a loginuid was not set. This means that the process was not spawned from a login session. It was spawned by the application
user = www-data, directly unserializing the payload in question.
When tracing back the PPID of the events, we can see the executable /usr/bin/apache2 running with
type = accept and the IP address that the attacker was using. This can be useful if we want to pinpoint the attacker’s IP address and take appropriate measures like blacklisting, reverse tracking the address, reporting on the address, etc. The attacker’s IP address in our case is
192.168.1.219, which is a LAN IP address. If the WordPress is exposed to the internet, the event will show a publicly routable IP address.
We can see the activity generating a Sev 3 alert from the screenshots below. Depending on how the server is supposed to function and business needs, this severity can be raised to a Sev 1.
The rule used to generate the sev is shown below.
The attack is triggering events with fields
user = www-data,
command = dash, and
syscall = execve as a result of which it will be caught by our rule and displayed as a Sev 3 alert.
- OS: Kali
- PHP version: 7.0
- Tools: Burp Suite (Free Edition), Python 2.7
- Proxy: Foxy Proxy
- Browser: Firefox 52.0
- Payload details:
- Original image used: bird.jpeg
- Image injected with payload: guzzle.jpeg
- OS: Ubuntu 16.04 LTS
- WordPress: 4.8
- Server: Apache
- Author level permissions: user – “attacker” and password – “toor”
- Threat Stack Agent: 1.9.0
Short answer: Yes
By simulating an attack, we see that Threat Stack’s out-of-the-box monitoring and alerting capabilities will indeed catch this sort of unsafe data deserialization exploit, albeit notifying users as a Severity 3 alert. Depending on the customer use case — for instance, a large WordPress environment — customers could choose to increase the severity of this alert. As mentioned earlier, raising it to a Severity 1 was the recommendation of our SOC analysts in this case.
If you’d like to learn more about the Threat Stack Cloud SecOps Program℠ or take a first-hand look at the Threat Stack Cloud Security Platform, book a demo today. Our security experts will be happy to discuss your organization’s specific security and compliance requirements.