I wrote about an influx of PHP Object Injection attacks previously, warning about a trend of attacks targeting a known but somewhat under-reported PHP vulnerability. Looking back since that time, I get the odd feeling that object injection (or as they’re sometimes called unserialize) vulnerabilities keep cropping up. Wondering if this is just a frequency illusion (once you notice something like a certain make/model of a car, you notice it everywhere!) or actually a trend; I dug into the numbers.
Confirming Growth:
These type of attacks are in fact becoming more popular. Using WPVulnDB.com (a website which keeps tracks of WordPress core, theme and plugin vulnerabilities) I found that object injection vulnerabilities had 1 report in 2014, 4 in 2015, then doubled to 8 in 2016 and so far in 2017 there have been 13 reports (not bad for half way through the year)
Back in November, I reported seeing a spike in attacks targeting insecure objects, and looking historically at reported vulnerabilities, we’re seeing these numbers going up each year. It’s not a stretch that these two facts lead me to suspect the WordPress and plugin developer communities may have had no (or bad) knowledge of the risks behind insecurely trusting serialized objects, while attackers have been weaponizing and targeting vulnerable sites.
Full disclosure: I am the reporting party for some of the above vulnerabilities. One in 2016, and so far in 2017, seven. I took a weekend to see how many insecure usages of unserialize() I could find in the plugin code base and within hours had handfuls of working vulnerabilities; I stopped only so I could start triaging and notifying plugin authors regarding how to enact fixes. Many of which were appreciative for the help.
About the Vulnerability:
If you want to learn more about how the exploit works, read here:
- https://www.owasp.org/index.php/PHP_Object_Injection
- https://www.notsosecure.com/remote-code-execution-via-php-unserialize/
It is a well known high risk action to accept user input into the unserialize function. PHP.net even publishes a very large and mostly red warning on the usage page for unserialize():
Addressing the threat:
Every WordPress developer (plugin or otherwise), nay everyone who writes PHP code, should take the above warning to not insecurely use unserialize() to heart. We (as in the WordPress community) could use some help with spreading knowledge about this vulnerability around.
If you are already using unserialize insecurely, you’re in luck as patching may be easy to address:
The majority of code we have seen insecurely using unserialize could just as easily patch their code by changing how they hand off the data from a serialized object to a JSON representation of the values. In some cases simply replace serialize() with json_encode() and unserialize() with json_decode() is the only change that needs to be made.
For developers:
Please, if you are a developer, double check that you’re not trusting serialized data sent from user input and passing it directly back to unserialize().
For security researchers:
There are a lot of plugins out there, and a lot of vulnerabilities – I had to cut my research short just due to time constraints. If you’re a researcher interested in picking up or helping out with this issue (hunting vulns, writing PoCs and recommending patches), get in touch.
For everyone else:
If you’re not a developer or a researcher but worried about this threat, you can still help. Share this post with your friends and others who have WordPress sites, ideally developers. Together we can stop these Object Injection attacks from continuing to be a problem.