Application Protection Report 2019, Episode 1: PHP Reconnaissance

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.

When we dug deeper, we found that 87% of the traffic pointed at these common phpMyAdmin paths came from just two IPs, out of more than 66,000 IPs that hit Loryka’s sensors. In fact, the two IPs in question represented a huge proportion (37%) of the total traffic, at 24% and 13% of the entire traffic over the year. Furthermore, all of the traffic from these two IPs was pointed at the seven PMA paths. By contrast, no other single IP accounted for anything near as much traffic, nor did any other IP feature traffic patterns over time matching these two, even when they targeted these paths.

The two IPs in question have been allocated to systems on a North American university campus since before the beginning of the campaign. There are a handful of published exploits regarding the specific versions of phpMyAdmin referenced in these paths, such as EDB-18371¹ and EDB-25003,² which target CVE-2011-4107 and CVE-2013-3241 respectively. However, to our knowledge all of them require prior authentication to phpMyAdmin, which means that in all likelihood the traffic targeting these paths was looking for poorly controlled authentication portals.

In short, unknown actors are using a small number of compromised systems on this university’s network to look for specific targets: old and probably neglected MySQL databases with weak authentication. These actors have defined a narrow set of target parameters but are scanning the entire web from a small number of addresses—and are not trying too hard to cover their tracks. Given that SQL injection was the most common PHP attack method in 2017, it seems that the threat landscape in 2018 is going to look similar.

This reconnaissance campaign was not particularly sophisticated, given the easily identifiable traffic patterns over time, IP, and target. Mitigating the risk from these kinds of campaigns would be relatively straightforward for most organizations, provided system owners are aware of what is on their network. Allowlisting authentication pages for admin surfaces is an easy way to prevent a recon campaign such as this from escalating. A robust access control program with strong passwords or multifactor authentication would also mitigate the risk of credential stuffing or escalation from a phishing campaign that might follow the reconnaissance.

These university IPs have also shown up on other parts of the web, based on data that we’ll be discussing in forthcoming articles. Aside from this specific threat, however, early signs indicate that security in 2018 will look very similar to security in 2017. Unsophisticated campaigns against obsolete or difficult-to-secure targets are prevalent. PHP continues to lead the pack in terms of providing rich, soft targets, and situational awareness remains important in terms of mitigating both vulnerabilities and threats.