Detecting Unsafe Data Deserialization With Threat Stack

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℠ 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.

PHP’s 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 whoami will show the user who is running the command, and ls -al will 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 whoami and 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.

System configuration

Attacker System:

• 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

Victim System:

• 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.

*** This is a Security Bloggers Network syndicated blog from Blog – Threat Stack authored by Aakash Prasad. Read the original post at: https://www.threatstack.com/blog/detecting-unsafe-data-deserialization-with-threat-stack