wpgarlic

A proof-of-concept WordPress plugin fuzzer used in the research described in https://kazet.cc/2022/02/03/fuzzing-wordpress-plugins.html that helped to discover more than 120 vulnerabilities in WordPress plugins installed on more than 10 million sites.

If you want to continue the research, start with less popular plugins – if a plugin achieved at least 10k active installs between October 2021 and January 2022, I have most probably looked at the fuzzer reports (and most focus has been put on plugins having at least 20k active installs). Because there is a lot of randomness in how fuzzer works, some vulnerabilities in these plugins remain undiscovered – but fewer ones.

Fuzzer reports contain a lot of false positives – most of them don’t indicate a vulnerability. After seeing a report, first, analyze whether the behavior you’re observing is indeed a vulnerability or a false positive. Don’t spam WPScan/vendors with raw fuzzer reports – provide a PoC exploit instead.

Examples

For obvious reasons, the examples will contain only vulnerabilities that have already been fixed.

Arbitrary file read

Let’s assume you are fuzzing responsive-vector-maps in version 6.4.0:

(to fuzz the latest version, just skip –version).

After the fuzzing finishes (which would take 10-30 minutes for this plugin) you can call:

You will see, among others:

That means that the fuzzer detected executing fopen() on a known payload. Most of the payloads contain the word GARLIC in them to facilitate automatic detection in output. You may see or configure them in docker_image/magic_payloads.php.

Then, you may browse the source code and see that indeed the wp_ajax_rvm_import_markers endpoint uses the file content to render output, thus allowing you to read arbitrary files on the server: CVE-2021-24947.

What you see in white is a crash considered interesting (you may modify them or add new ones in crash_detectors.py). Green is the context. In blue, you see the report file name (with plugin name), plugin popularity, and endpoint name (here: the ajax action name).

The data in yellow are what payloads were injected into what variables.

Reflected XSS

Let’s assume you are fuzzing page-builder-add in version 1.4.9.4:

After printing the results, you will see known payload echoed back:

You can then manually test whether indeed this place (remember: in blue you have the endpoint name, here: the menu page name) is vulnerable to XSS. In this case, it is CVE-2021-25067.

Option update leading to stored XSS

After printing the results, you will see update_option being called:

Analysis of the endpoint’s code will tell you that this indeed leads to a stored XSS vulnerability: CVE-2021-25075.

False positives

Unfortunately, for most of the plugins, the fuzzer doesn’t find any interesting crashes, and for the rest, most of the reports are false positives. For example, if you see:

This can mean, that wp_mail is indeed called, but you don’t control the recipient and most of the subject. If you want to be sure, look at the plugin source.

Additional tips for reading fuzzer reports

• If you see the message; May as well be equal: … and … – that means that the mechanism to pretend that a known payload is equal to any other string (described in https://kazet.cc/2022/02/03/fuzzing-wordpress-plugins.html#patched-equality) was triggered.
• If you see __GARLIC_ACCESSED__ _FILES[files] __ENDGARLIC__ – that means that an uploaded file access was detected. No further checks are currently made – to check whether this is a vulnerability, look at the code.
• Sometimes what the fuzzer injects into GET, POST, etc. parameters is not reproducible in the real world: for example, you can’t inject anything into $_GET[‘page’] if you want a particular menu page to be displayed.

Download & Use

Copyright (c) 2022 Krzysztof Zając