Reevaluate "low-risk" PHP unserialization vulnerabilities, researcher says

Over nearly a decade, PHP unserialization vulnerabilities have become a popular route for cyber-criminals to plant remote code execution or deliver other malware into systems. But new research, introduced at Black Hat this month, shows that malevolent hackers can introduce this vulnerability, even in environments that were previously considered low-risk for this attack.

bucket with holes breach security vulnerability
Thinkstock

LAS VEGAS — In cybercrime, as in most areas of crime (or business), the more things change, the more they stay the same.

The emergence of Petya/NotPetya and other virulent forms of malware have showcased how the best and most successful black-hat hacks are not entirely new—bad actors simply take older, more established approaches or attack vectors and add a new twist. And so it is with PHP unserialization attacks, as showcased at the Black Hat conference earlier this month by Sam Thomas, director of research for Secarma Ltd, an information security consultancy.

Thomas was able to demonstrate a new exploitation method that makes it easier for cyber-criminals to generate critical deserialization vulnerabilities in the PHP programming language using functions previously considered low-risk. PHP unserialization vulnerabilities, or object injection vulnerabilities as they have also been called, allow hackers to perform different kinds of attacks by supplying malicious inputs to the “unserialize” PHP function. (Serialization is the process of converting data objects into a plain string, and the unserialize function recreates an object back from a string.) This attack vector has been documented since 2009, so the fact that these flaws exist is nothing new.

Indeed, OWASP added PHP deserialization to its Top 10 list, and last year’s massive Equifax breach was reportedly initiated through deserialization.

Given the popularity of PHP (aka PHP: Hypertext Preprocessor), a server-side scripting language that has been around since the mid-1990s, it is not surprising that bad actors have found new ways to exploit this approach. What Thomas of Secarma demonstrated at his Black Hat session, dubbed, “It’s a PHP Unserialization Vulnerability, Jim, But Not as We Know It” (as a shout-out to fellow Star Trek-loving cybersecurity experts), is that cyber-criminals can use low-risk functions against Phar archives to start a deserialization attack withoutrequiring the use of unserialize() function in a wide range of scenarios. Phar files, an archive format in PHP, stores metadata in a serialized format, which gets unserialized whenever a file operation function—such as fopen, file_exists, file_get_contents—tries to access the archive file.

“This is true for both direct file operations…and indirect operations such as those that occur during external entity processing within XML,” Thomas said during his presentation. He also issued a white paper during Black Hat that detailed how this particular variant of the PHP unserialization attack can be used on Wordpress sites to exert full control over a web server. All the attacker needs do is upload a valid ‘Phar’ archive containing a malicious payload object onto the target's local file system and make the file operation function access it.

This vulnerability can even be exploited using a basic JPEG image, originally a Phar archive converted into valid JPEG by changing its first 100 bytes, according to Thomas.

“The way certain thumbnail functionality within an application works enables an attacker with the privileges to upload and modify media items to gain sufficient control of the parameter used in a ‘file_exists’ call to cause unserialization to occur,” Thomas said.“A remote authenticated attacker with the ability to create [or] edit posts can upload a malicious image and execute arbitrary PHP code on vulnerable systems.”

Thomas highlighted that the unserialization is exposed to “a lot of vulnerabilities that might have previously been considered quite low-risk.”

"Issues which they might have thought [were] fixed with a configuration change or had been considered quite minor previously, might need to be reevaluated in the light of the attacks I demonstrated,” he said.

More from Black Hat 2018

SUBSCRIBE! Get the best of CSO delivered to your email inbox.