Larry's Cabinet of Web Vulnerability Curiosities

One of my responsibilities as a member of the Akamai Security Intelligence Response Team (SIRT) is to research new web application vulnerabilities. For the last year, I have focused on Wordpress plugin vulnerabilities, and looking for any interesting code tidbits in my box of Wordpress toys. There are almost 50,000 wordpress plugins (at time of publication) and Wordpress is** the** Content Management System (CMS) of choice for over 30 million websites. This creates a very large Internet footprint. I’ve been asked if I have any 0days or interesting research tidbits that I’ve come across and would be willing to share. The answer is, “No, I don’t have high value 0days to sell on the dark web!”

What I do have are some interesting tips and tidbits to share. There are many Wordpress plugin vulnerabilities worth taking a closer look at. While they may not be groundbreaking discoveries, I’ve chosen a few interesting examples of insecure code in the wild to highlight. These examples can be utilized when preventing or exploiting these types of vulnerabilities. I like to think of these vulnerabilities as being similar to malignant tumors. As a doctor uses a dissection of a tumor to educate medical students, I hope my work here will help readers understand some of the common and uncommon mistakes I frequently see.

The first specimen I will examine, CVE-2017-1002016, was found while on a walkabout through a directory I populated with gigabytes of plugin source code. The abnormality I found allows an attacker to upload a file by writing the contents of a URL into the path of the Wordpress web root. The vulnerability is exploited through an attacker-controlled web page that simply prints out the PHP code for a small webshell. An example of what I mean is pictured below:

The URL to the page that prints the webshell code is then passed in as a parameter to the plugins $url variable in the GET request.

The code I highlight in the advisory performs the following:

$url = $_GET[“url”];
$fl = wp_daozhao_download_flickr_picture($url);

Where the function wp_daozhao_download_flickr_picture() writes the contents of $url to disk:

$response = wp_remote_get($url, array(‘timeout’ => 300));

.

.

fwrite($handle, $response[‘body’]);

I understand the intent of the plugin author - to download flickr pictures from remote sources to use on your Wordpress installation. However, allowing the user to specify the URL, file without requiring authentication creates a fatal flaw in this tool.

This next exhibit, CVE-2017-1002008, is a textbook example of what can go wrong when modifying user input in an attempt to make it safe. I’ve never seen this type of vulnerability in the wild before. It’s the sort of thing you read about in web application security books or show up in web server logs, but almost never see in reality. The …/./ path traversal bypass! The code attempts to thwart would-be hackers from downloading files outside of the specified path, by modifying the user input by removing any instances of ‘…/’:

$fullPath = str_replace(“…/”,“”,$fullPath);

The problem here is, if you supply a path of ‘…/./…/./’ as input the call to str_replace() will transform it to ‘…/…/’ which is the desired sequence of characters, to download files from directories.

These next two specimens up for gross examination, CVE-2017-1002006, CVE-2017-1002007, are both found in the same software sample. The code in save_mail.php and save_contact.php use parameterized calls to wpdb->insert (avoiding SQL Injection) to add email contacts to the database, but they don’t check if a user should be adding emails to the database. This means a user could inject a BeEF hook into the contacts database, to later be executed by the Wordpress site administrator.

This anomaly is also found in the same plugin as above; however, this time the code in download.php doesn’t protect itself against SQL injection and we can get blind SQLi via the ‘id’ and ‘contact_id’ parameter. I have had these specimen numbers, CVE-2017-1002004 and CVE-2017-1002005, assigned to identify this defect.

$doc_id = $_GET[‘id’];
$file = $wpdb->get_results("SELECT * FROM wp_posts WHERE ID = $doc_id ");

$contact_id = $_POST[‘contact_id’];

$query = “DELETE FROM wp_contacts WHERE id = $contact_id”;
$wpdb->query($query);

The user isn’t required to be authenticated by Wordpress in order to exploit this vulnerability. It is an easy way to compromise a wordpress installation.

In this final example I examine a failed attempt at rectifying an abnormality in code that I had previously reported to its author. I’ve assigned this specimen the identifier CVE-2016-1000156.

The developer attempted to fix a bug I reported in a previous advisory, only slightly mitigating risk by requiring any logged in user to be able to upload arbitrary files to the Wordpress site. They added the following line to ensure the user is logged in before uploading a file:

if (!is_user_logged_in()) {

An attacker can request a login to the site, and if approved, upload their web shell.

Conclusion

I’ve been a vulnerability researcher for 18 years, and some bugs I find stand out in my memory. It could be because an exploit required finesse to develop, a string of vulnerabilities lead to the prize, or a unique piece of code creates the bug. I enjoy sharing some of the details on occasion, as I think new researchers can use this information to look for security vulnerabilities on their own. Particularly programming mistakes that could be avoided, that modifying user input to meet security requirements might be a bad idea. Also, when fixing code, think about the flaw you’re fixing and if it’s the most through solution when solving a problem. Does your fix merely add another step to exploiting a flaw when it could have eliminated the vulnerability entirely?