A technique to semi-automatically discover new vulnerabilities in WordPress plugins

Update (2022-02-26): the tool is now public: https://github.com/kazet/wpgarlic

WordPress plugins expose a number of interfaces, such as:

• AJAX endpoints (/wp-admin/admin-ajax.php)
• Admin menu pages (/wp-admin/admin.php?page=...)
• PHP files (in the /wp-content/plugins/ directory),
• REST routes (/wp-json/...).

These interfaces have a consistent trust boundary: we know where the untrusted input goes and can detect what operations are executed on that input.

For instance, if you visit a .php file, provide appropriate parameters, and cause a file to be removed, you know that it is a vulnerability. You know what parameters you control and what ones you don’t – for example, you may redirect a logged-in admin to an admin menu page with arbitrary GET parameters, but you don’t control their cookies.

Therefore it is possible to semi-automatically scan for multiple classes of vulnerabilities in all WordPress plugins.

I have written a tool that:

• executes each AJAX endpoint, menu page, REST route, or file multiple times,
• injects payloads into the GET, POST, etc. arrays or REST parameters (more on how it’s done in the next section),
• analyses the outputs with an ugly pile of regular expressions¹ to detect:
  • calls to WordPress functions (such as wp_delete_post),
  • crashes (“No such file or directory”, “You have an error in your SQL syntax”, …),
  • XSS (echoing a known payload containing " or <),
  • etc.

This method is transferable to other CMS plugin ecosystems but not directly e.g. to Python packages. If a Python package allows you to remove arbitrary files, it may or may not be a vulnerability depending on the package role and your particular setup.

Injecting parameters

In PHP, the _GET, _POST, _SERVER, _COOKIE, and _REQUEST arrays contain various request parameters (e.g. GET and POST data, cookies, server configuration, and headers). I have replaced them with mock objects that allow access to any key - and with defined probability return a payload from a predefined payload list.

A simple mock $_POST array could be created using the following code:

<?php

class Mock implements ArrayAccess {
    function offsetGet($offset) {
        return "payload";
    }

    function offsetExists($offset) {
        return true;
    }

    function offsetSet($offset, $value) { }

    function offsetUnset($offset) { }
}

$_POST = new Mock();

echo $_POST["parameter_name"];

The above snippet will print payload.

Let’s assume that the $_REQUEST array has been mocked in a way similar to the one described above and that an AJAX route is handled by the following function:

public function delete_saved_block() {
	$block_id = (int) sanitize_text_field($_REQUEST['block_id']);
	$deleted_block = wp_delete_post($block_id);
	wp_send_json_success($deleted_block);
}

When $_REQUEST['block_id'] gets accessed, the mock will return a payload, thus allowing to detect that wp_delete_post was called on an attacker-controlled value.

This approach allowed to easily inject payloads even if the parameter name was hard to guess – the tool didn’t distinguish between id and secret_parameter_65e3c14a1d.

Some of the keys needed to be excluded manually (for example $_SERVER['HTTP_AUTHORIZATION'] or $_GET['doing_wp_cron']) because their values were handled by WordPress, and providing them caused plugin code to not be reached.

Besides, with some probability, a random type of array was returned instead of a string payload:

• a singleton array with a string payload,
• recursively, an object that allows access to any key,
• a singleton array: random payload → random payload.

Detecting vulnerabilities

The tool contained checks to detect:

• various kinds of crashes,
• potentially dangerous operations,
• information leaks.

Some of these checks led to a large number of CVEs (such as the XSS checks), some didn’t (e.g. the checks for syntax errors designed to catch eval() on untrusted code).

XSS

To detect XSS, checks were implemented that detected payloads being echoed back (or echoed back with escaping that didn’t prevent XSS, such as prefixing " with \).

Crashes

The following types of crashes were detected:

• fopen() / file_get_contents() / require() / require_once() / include() / include_once() errors and “No such file or directory” or “failed to open stream” error messages,
• unlink() error messages,
• crashes related to call_user_func(),
• SQL error messages,
• unserialize() errors,
• parse / syntax errors to detect eval() calls,
• “command not found” error message,
• simplexml_load_string() error messages².

Information leaks

The output was analysed to observe whether known user e-mails or file names are displayed.

WordPress operations

WordPress has been instrumented to detect:

• calls to maybe_unserialize,
• calls to update_option/update_site_option/delete_option,
• calls to wp_insert_user,
• calls to wp_insert_post/wp_update_post/wp_delete_post,
• calls to wp_mail,
• calls to query (this one yielded an especially large number of false positives that needed additional filtering),
• calls to get_users (this one has been added after accidentally discovering CVE-2021-25110 where an attacker can leak arbitrary user e-mails via a crafted user search query).

Additional checks

After fuzzing, the admin panel, the homepage, and the post pages were crawled to find occurrences of known payloads. That allowed for instance to detect CVE-2021-24975 in social-networks-auto-poster-facebook-twitter-g.

Update (2022-02-26): additionally, any attempts to access uploaded files are logged, so that they may be checked manually.

Changes to PHP

Patched equality

I have patched PHP so that equality comparison between any value and a known payload returned true with 1/3 probability. Forgive me about this one.

With this patch, I was able to detect vulnerabilities such as:

if ($_GET['action'] == 'please-remove-post') {
    wp_delete_post($_GET['id']);
}

Unfortunately, this resulted in a large number of false positives as well. The false positives were e.g. in the form of:

if (in_array($order, array("ASC", "DESC"), true)) {
    query("(...) ORDER BY $order");
}

The only solution for this problem I have used was browsing through these false positives and cursing. Further research can lead to coming up with other solutions.

Other changes

Besides, I have patched the PHP interpreter so that:

• When base64_decode was performed on a known payload, this payload was returned again,
• When json_decode was performed on a known payload, an object was returned that returns payloads when any key was accessed. These were the same objects that served as e.g. $_GET arrays,
• when a redirect was performed, relevant information was displayed so that Open Redirect vulnerabilities could be detected.

Testing

A test-driven approach was critical during development. Tests checked that the tool would find a known vulnerability. For example, I could write a test to check that:

when fuzzing the wp_ajax_heateor_sss_import_config endpoint of the sassy-social-share plugin in version 3.3.23, the tool should detect that maybe_unserialize() gets called on an attacker-controlled payload.

False positives vs false negatives

This approach yielded a large number of false positives. It was a deliberate decision because I wanted to sort through multiple reports instead of missing vulnerabilities.

An alternative could be to write additional filtering logic. For example, there were multiple reports where an HTML payload was echoed back – but when checking them, I’ve observed that a correct JSON Content-Type header is added. This was one of the cases that could be checked automatically.

Other

Fuzzing was performed inside Docker containers, re-created for every plugin.

It was important to disconnect the network, because a lot of plugins call other web services, and I wanted to avoid sending random payloads there.

I found it also helpful to separate plugin fuzzing and analysis of the outputs. Because the outputs were analyzed by a lot of regular expressions, bugs happened. Therefore a relatively quick rescan allowed to speed up development.

Automating the fuzzing Added: 2022-02-16

Scanning thousands of plugins would not be possible without automating the job. Fortunately, WordPress plugins use consistent interfaces to integrate with WordPress, for example:

• all REST routes are collected in a central registry, accessible via: rest_get_server()->get_routes(),
• AJAX actions are created by adding a hook with a name starting with wp_ajax_,
• there exists one registry with all admin menu pages.

Therefore all REST routes, AJAX actions, and menu actions can be enumerated in the same way regardless of which plugin is scanned. Of course, all PHP files can be easily listed as well.

All plugins can be installed in the same way: I have used WP-CLI – a tool that allows to install, activate, deactivate or delete a plugin from the command-line. The list of plugins could be downloaded automatically from the WordPress plugin registry API.

All of the above techniques made it possible to create a tool that doesn’t require any plugin-specific code.

Results Last updated: 2022-12-17

Because of time constraints, I have focused only on the most popular plugins. As of this moment, the following bugs found by the tool have already been fixed and published:

Not all of the vulnerabilities were found directly by the fuzzer. For example, CVE-2021-25096 was found accidentally when writing a PoC for CVE-2021-25095. For some other vulnerabilities, the tool alerts were only part of the vulnerability information – for example, the tool notified that a WordPress option can get updated by any user - and finding the consequences (whether it can lead e.g. to stored XSS) required manual work.

Findings worth mentioning

I won’t make fun of any particular plugin author, however, I think some findings are worth sharing.

is_admin

The WordPress is_admin() function, as you may probably have guessed:

Determines whether the current request is for an administrative interface page.

(from https://developer.wordpress.org/reference/functions/is_admin/)

The documentation warns as well, that it:

Does not check if the user is an administrator; use current_user_can() for checking roles and capabilities.

As you may probably have guessed, it was a source of a couple of vulnerabilities in the form of:

if (is_admin()) {
    /* dangerous action */
}

REST route URLs

Let’s consider the following code:

register_rest_route((...), '/(...)/(?P<id>[\d]+)', array(
    array(
        'methods' => WP_REST_Server::READABLE,
        'callback' => array($this, 'callback'),
        'permission_callback' => '__return_true',
    ),
));

/* ... */

function callback($request) {
    $id = $request['id'];
}

What ID values could be passed to the handler?

The correct answer is: all of them – just use /?rest_route=/(...)/1&id=hehehe.

get_users()

Some plugins allow searching for users by providing a part of an e-mail address. That allows to leak any user’s e-mail using the following steps:

• Bruteforcing the first letter of the domain name (searching for @a, @b, etc., and checking when the user’s name appears in search results).
• Remembering the first letter and using it to guess the second letter. Let’s assume the user’s e-mail domain name starts with g. You can then brute force the second letter (@ga, @gb, …).
• Repeating the above steps for the rest of the e-mail address.

Because of that, I have added a check that alerts when get_users() gets called. Unfortunately, besides finding vulnerabilities of this type, it led to numerous false positives as well.

XSS protection

Don’t do the following:

if (/* potential XSS in $parameter detected */) die('Invalid parameter: ' . $parameter);

Several XSS vulnerabilities were also caused by debugging helpers in the form of:

echo "<!--";

var_dump($_POST);

echo "-->";

CAPTCHA verification

Don’t do this:

if (isset($_POST['captcha'])) {
    /* verify captcha */
}

/* do action that should be CAPTCHA-protected */

I have observed this pattern multiple times, both for CAPTCHAs and nonces.

Conclusions

This was just a proof-of-concept to check whether automatic techniques are a viable method to find WordPress plugin bugs. I am sure it can be improved by e.g.:

• adding checks to detect other types of dangerous operations,
• attempting to decrease the number of false positives without a large loss of true positives. The percentage of false positives was one of the main obstacles in this project.

This technique can also be implemented for other plugin ecosystems.

Many of the vulnerabilities I found were easily preventable by modern software engineering practices. In many WordPress plugins, HTML is built using an error-prone pile of echo statements, instead of a template language. Similarly, AJAX endpoints are by default available for all logged-in users or all not logged-in users, instead of requiring the developer to provide a fixed allowlist of roles or permissions (so that they would have to explicitly mark a route as available to all logged-in users). Introducing techniques that make it harder to make mistakes and promoting their use is, unfortunately, something only the WordPress team, not plugin developers, can do.

Footnotes