Akamai Diversity
Home > Web Security > Half-baked Patching: More Common Than You Think

Half-baked Patching: More Common Than You Think

In the last year or so I've been looking at Wordpress plugins. I've seen some poorly written code, plugins that had little purpose (one plugin's stated purpose was to only download a copy of itself!) and patches that attempted to fix a problem but weren't thorough enough or didn't follow the official Wordpress recommendations and codex.

Bad code can not only be a threat to the system it's hosted on and the users that use it, but the Internet community as a whole. On Dec. 12, 2015 a zero-day exploit was uploaded to 0day.today by sniper.t. The uploaded text was simply a proof of concept to remotely download /etc/passwd. The exploit abused the plugin author's lack of authentication and file type verification to steal arbitrary files from a victim's server.

The exploit is shown below:


That proof of concept exploit is:


The code in map_download.php was improperly patched to fix an LFI vulnerability, that fix had faulty authentication code in map_download.php that can easily be bypassed by setting the required cookie:

8 if(!isset($_COOKIE["mapdownload"]) || $_COOKIE["mapdownload"] !== "true")

9   die ($_COOKIE["mapdownload"].'  <b>Something goes wrong, you don\'t have permission to use this page, sorry.</b>') ;

A vulnerable installation of this plugin can be used to download files with mp3, mp4a, wav and ogg extensions from anywhere the web server application has read access to the system:

Exploit one - Arbitrary media file download:

$ curl "http://[vulnerable site]/wp-content/plugins/wp-miniaudioplayer/map_download.php?fileu

rl=/tmp/s3kr3t_audio_file.mp3"  --cookie "mapdownload=true"

I also noticed with the use of fopen() you have the ability to also fetch URLs which would allow a malicious person to use this plugin as a blind proxy. You could download mp3s or use it to proxy attacks via HTTP GET requests. Since the code to check the file extension is done after the request is made you can get two requests to the target server regardless of the file extension restrictions.

Exploit two - 2 x amplification attack (CVE-2016-0796):

$ curl "http://[vulnerable site]/wp-content/plugins/wp-miniaudioplayer/map_download.php?

fileurl=http://[target]/test.php" --cookie "mapdownload=true"

Results in the following log lines in apache's access.log: - - [02/Feb/2016:21:52:32 -0500] "GET /test.php HTTP/1.0" 200 187 "-" "-" - - [02/Feb/2016:21:52:32 -0500] "GET /test.php HTTP/1.0" 200 187 "-" "-"

With an amplification factor of two, the first is to check if the file exists and the second is to finally read data from the file. The attack will originate from the vulnerable wordpress installation masking the attackers true identity.

This bug could easily be utilized to create an attack tool with a bit of code and some google dorking we could enumerate vulnerable sites to amplify and reflect our attacks. The Wordpress plugin wp-miniaudioplayer has as of this writing more than 210,000 downloads. If we could enumerate even just 1% of the active sites using that download, we could create a list of 2100 hosts capable of doubling our GET flood attacks.  A basic python script using threading could be developed to send out as many requests to a block of these sites, masking the malicious actor and doubling our attack intensity.  A quick google dork results in 12,700 hits.

It's important when fixing code to ensure the code to remediate the vulnerability is complete.  

While the fix didn't open up new vulnerabilities it only partially fixed one. Both the researcher and the plugin author missed the fact that this code can be used to direct connections to an arbitrary site.

Any time a path or url is used to input information, it should always be untrusted and be sanitized. In this instance, clearly a domain should not be acceptable, and should only be pulling files from the local server. The author fixed the plugin to only allow certain file types to be downloaded, but missed the ability to change which server the request comes from.

Security is not easy. As we've seen, possibly an entire attack botnet platform can be created from just one overlooked detail.

Developers should be aware of best practices, which the Wordpress team makes available: https://developer.wordpress.org/plugins/the-basics/best-practices/ as well as a thorough understanding of application security vulnerabilities, like those described by OWASP.

Learning more about these best practices can ensure better security for everyone and avoid these unintended consequences.

Larry Cashdollar is a senior researcher in the Akamai SIRT.


Leave a comment