F5 Labs published the first edition of our annual Application Protection Report in July 2018. For that report, we collaborated with Whitehat Security, Loryka, the Ponemon Institute, and Whatcom Community College’s Cybersecurity Center to analyze a wide range of data from 2017, and offer a comprehensive breakdown on the threats, tactics, vulnerabilities and impacts facing web applications in 2018.

This year, we’re collaborating with a wide array of partners to cast our gaze wider and deeper into the world of application security—for example, we leveraged the capabilities of the Cyentia Institute and Loryka for this article. We also aim to make our conclusions more digestible and timely this year by releasing them as shorter pieces focused on specific trends and conclusions, instead of a single 100-page report released late in the summer. This is the first installment in the series of articles we’ll release as we identify patterns, draw conclusions, and formulate guidelines for corrective action.

PHP is a widespread and powerful server-side language that’s been used in 80% of sites on the web since 2013. It underpins several of the largest web applications in the world, including WordPress and Facebook. This prevalence, particularly among beginning web developers, also makes it a big target.

From a security standpoint, 2017 was a bad year for PHP. As part of our 2018 report, which focused on trends in 2017, we found that PHP represented 69% of the exploits that Exploit DB published. Our data partner Loryka found that 58% of the web attacks that they observed in the wild targeted PHP as their primary attack vector.

The early data indicate that 2018 was just as bad. PHP had almost the same representation (68%) in published exploits on ExploitDB as it had in 2017. In the wild, we saw an even greater proportion of PHP related traffic. Loryka’s sensors found that 81% of the malicious traffic they detected was focused on PHP in one form or another. The implication is that PHP will likely remain one of the Internet’s weakest links and broadest attack surfaces for the foreseeable future.

On closer examination, the Loryka data also shed some light into the specific tactics of attackers who target PHP, as well as some low-cost steps to mitigate some of the risks posed to one of the web’s most prevalent platforms. Loryka’s sensors identify connection attempts and capture the source IP and target URL, among other things. The target domain or target IP address is not significant, since attackers often cycle through millions or billions of targets looking for opportunities to attack. However, the back half of the target URL contains the target file or path, the specific location on a web server that the attacker is targeting across all of its target IPs. This tells us much about an attacker’s goals and tactics.

The first thing that stood out about the Loryka dataset was that while there was a great deal of variation in the target paths—with more than 100,000 unique values in the dataset—a huge portion of traffic was focused on just seven paths or filenames. All seven are commonly used for managing phpMyAdmin (also known as PMA), which is a PHP web application used for managing MySQL databases. Of the ~1.5M unique events that Loryka captured targeting more than 100,000 different URL paths, 667,000 (42%) were targeted at one of the following:

• www.example.com/PMA2011/
• www.example.com/pma2011/
• www.example.com/PMA2012/
• www.example.com/phpmyadmin3/
• www.example.com/pma2012/
• www.example.com/phpmyadmin4/
• www.example.com/phpmyadmin2/

The traffic volume targeting these paths was almost identical from path to path, with less than a 3% difference between the volume of the most and least frequent. The timing of the campaigns targeting these paths was also more or less identical, with traffic spiking in coordination. Note the juxtaposition between the seven phpMyAdmin paths and the blue point cloud in the graph, which seems to follow no identifiable trend. The blue curve represents traffic that targeted no file or path beyond the target domain itself, which was a common path in the dataset but showed no patterns over time or source IP. In essence this means that a significant amount of traffic hitting Loryka’s systems were trying to connect to the root domain or web servers with no specific designated file or path, and these types of connections featured no identifiable patterns.