This experiment began when Josh Frantz, one of our intrepid security consultants, remarked that he would be curious about the potential exposure from the just-reached end-of-life (EOL) date for PHP Version 7.0 and the forthcoming EOL date for PHP 5.6.
In response, I poked at the Dec. 3, 2018 Project Sonar scan data and looked for
X-Powered-By HTTP headers that were valid PHP release version strings in the 4.x–7.3 ranges. Lower than 4.x, greater than 7.3, and and non-valid version string values have a high probability of being deliberate version string misconfigurations or website operator-customized versions.
Not all PHP-powered websites will use this header, and that fact—combined with the aforementioned aggressive validity filtering—means that the chart below is underreporting the sorry state of PHP on the web as we head into 2019.
This is pretty centralized exposure as well, since 12 hosting organizations make up 33% of that exposure:
|DXTL Tseung Kwan O Service||39,449|
|Tencent cloud computing||23,331|
|KDDI Web Communications||22,128|
The United States and China house over 50% of total exposed nodes:
Hosting providers aren’t generally responsible for the incompetence (or ignorance) of the admins who poorly maintain servers they’ve set up in hosting environments. Unfortunately, we’re in an age in which attackers turn any vulnerable “thing” into a bot to use in campaigns of all shapes and sizes. Lack of ongoing support—especially for security fixes—very likely means our combined adversaries will have access to a vast number of systems providing significant raw compute power and bandwidth that they can use to accomplish their goals.
Rapid7 customers can use InsightVM and InsightAppSec to check for outdated versions of any software component (including PHP) and create remediation plans to help reduce exposure. It’s very important that all of us who hang things off the public internet do our part to ensure we’re not accidentally enabling attackers while we’re serving up our own content.