WordPress CVE Reversing

Now that we’ve discussed the Trac feature of WordPress, we can use it to execute the concept of CVE reversing.

What is CVE Reversing?

CVE reversing is the process of creating a working proof-of-concept by diffing the code between vulnerable and patched versions and using that difference to figure out the vulnerability in the vulnerable version of the software.

It is a widely used concept in the realm of security to get the PoC as soon as the CVE and the patched version of the software are released. Researchers can try to reverse the CVE as an exercise to learn and grow their skill sets.

How to CVE-Reversing?

Unlike other huge enterprise software, reversing the CVE for an open-source WordPress plugin is easier. At the very least, getting the difference in the code between two adjacent versions is important.

For getting the patch-diff, as mentioned above, we use the Trac feature. After we have the patch-diff, we can work our way backward to generate the working POC.

Steps for CVE Reversing:

1. Get the vulnerable and the patched version for a given plugin
2. Go to https://plugins.trac.wordpress.org/log/plugin-slug/trunk
3. Select the changes for the vuln and the patched version
4. Navigate through the changes in the code and generate a PoC out of it

Demo

Let’s take some entries as an example for our CVE reversing demo to see how it works.

WordPress Master Slider Plugin <= 3.9.5 - PHP Object Injection

Looking at the entry, we can see that the vulnerable version is <= 3.9.5 and it was patched on version 3.9.7. We need to navigate to https://plugins.trac.wordpress.org/log/master-slider/trunk and select the changes in 3.9.5 and 3.9.7.

Click on “View Changes” and you will be greeted with a page that contains all the changes in the code. If the total file size is less than 5.0 MB, you can navigate the code changes through the UI easily. Otherwise, you will have to go through each file individually or download the unified diff.

Since we know that the vulnerability is PHP object injection, we can just search for the keyword unserialize as it is responsible for the object injection in PHP.

Searching for it quickly gives us the result. We can see that the use of maybe_unserialize() function was removed from the code in version 3.9.7. The maybe_unserialize() function acts as a wrapper for the unserialize() function, hence is equivalent to the unserialize() function. Removing that function effectively prevents the PHP object injection vulnerability.

As for generating the proof-of-concept, the user-input $setting is passed into the function through parse_setting(), $slide through the parse_slide(), and style_obj through parse_each_style().

Tracing back those variables should give a point of injection for the vulnerability.

WordPress RegistrationMagic Plugin <= 5.2.4.1 - Reflected XSS

From the entry, we can extract the information that the plugin was vulnerable up to version 5.2.4.1, and was patched on 5.2.4.2. We are going to have to navigate the changes similar to how we did above.

1. Navigate to https://plugins.trac.wordpress.org/log/custom-registration-form-builder-with-submission-manager

2. Scroll down to the versions 5.2.4.1 & 5.2.4.2, select them and click on View Changes

3. Note that the code is directly not available on the site. We can download the unified diff, and search for certain keywords to find the changes in the code.

4. After downloading the diff, search for echo to see whether there have been changes in the reflective endpoint. We have a match on the template_rm_user_view.php file. The direct reflection of section_id can be seen in jQuery('#<?php echo $_GET['section_id'];?>').click();. It was patched by adding the esc_html() WordPress function.

Now that we have the vulnerable parameter, all that’s required is to trace back where the user input is being taken from.

Conclusion

This article demonstrated how researchers can use the WordPress Trac functionality to look through the patched security vulnerabilities and work on getting the proofs-of-concept for the vulnerable version.

To enhance the code review skills and learn about new vulnerabilities, CVE reversing is recommended as researchers can get insights on what the vulnerability was even when the POC is not published for the given vulnerability.