Het bericht Onvio is ISO 9001 gecertificeerd verscheen eerst op Onvio.

For the past few Fridays I have been working on my second research project at Onvio. This time the challenge consisted of finding 3 new vulnerabilities in existing WordPress plugins. And getting CVE’s registered for each of the vulnerabilities found. In this blog you will read about the process of finding these vulnerabilities, as well as the process of requesting the CVE’s.

The process

Step one: What type of plugins to test?

The first step in the process of finding vulnerabilities in existing WordPress plugins was identifying which plugins were going to be tested. I decided I wanted to look at plugins that made it possible to deliver a malicious payload to an admin user from the perspective of an anonymous user. Plugins that adhered to this requirement were mostly of the following kind:

• Contact forms
• Surveys
• Polls

Also, I wanted to test plugins that had quite a few users. This would have the greatest impact when finding vulnerabilities. I ended up finding vulnerabilities in multiple plugins with the user count of one plugin being a minimum of 10.000+ users and another one with a user count of 400.000+ users.

Step two: What type of vulnerabilities to test?

Next, I wanted to focus my attention on the most common web vulnerabilities. For this I kept the OWASP TOP 10 in mind. I focussed most of my attention on finding vulnerabilities related to injection.

Step three: The pentesting process

As preparation for the pentesting process, I created a list of WordPress plugins that fell into the categories mentioned above. Each plugin was going to be tested both manually and automatically in order to get the highest probability of finding vulnerabilities.

Automatic testing

For automatic testing, I decided to use Semgrep. I looked up some custom rulesets for known injection vulnerabilities like XSS, SQL-Injection, Command Injection, SSTI, SSRF and more.

Each of the plugins were scanned using Semgrep. This was done with the intent of getting a starting point for manual testing.

The automatic testing phase resulted in a lot of false positives, that mostly related to XSS. Nevertheless, it was a good starting point that gave an indication on where to look for exploiting possible vulnerabilities. Which in the end resulted in the detection of a valid XSS.

Manual testing

The manual testing phase consisted of both inspecting the Semgrep findings and investigating if these could be exploited, and installing the plugins to manually investigate them in order to find exploitable injection points.

This process mostly consisted of sending different payloads and seeing if they got executed for someone in another user context, and bypassing filters put in place to prevent these types of attacks.

For example, the following images demonstrate the exploitation of one of the contact forms. First the plugin components are researched. Here, it was concluded that the value sent in the message field would be loaded in a textarea field. Because of this, a payload was created that first closed the textarea field before inserting the XSS image payload.

Here, it can be seen that the image part of the payload is loaded under the textarea field because it was closed off using the first part of the payload, even though normally the value would be loaded within the textarea field.

The code snippet loading the vulnerable component is displayed in the image below.

Step four: The Findings

I ended up finding three XSS vulnerabilities in three different WordPress plugins. With the perspective of two of the vulnerabilities being unauthenticated user to admin, and one being authenticated user to admin.

For each of the plugins the main trigger for further investigation was that the “<>” tags were not always filtered out. Which led me to believe I would be able to exploit the vulnerability.

POC’s for the vulnerabilities will be released by WPScan after users have had some time to upgrade to a patched version. These POC’s can be found as links in the chapter “The CVE’s“.

Step five: Reporting

After finding the vulnerabilities I contacted the developers of each of the plugins in order to inform them about the vulnerability inside their plugin. Finding contact information for the developers of the plugin was easily done by visiting the page of the vulnerable plugin on the WordPress plugin site. A link to the website of the developing organization can be found in the “By *VENDOR-NAME*” section. From here, I contacted support with the question on where I could safely report the vulnerability that I had found.

After that, I created POC’s for each of the vulnerabilities, so the developers could easily identify the issue. These POC’s will also be added to each of the entries created on the WPScan website.

The communication process differed a lot depending on the plugin manufacturer. In one of the three cases I was immediately met with a response via email notifying me they would patch the vulnerability as soon as possible. Which turned out to be the same day!

In one of the other two cases I had to put a lot of effort into explaining and demonstrating the severity of the vulnerability before the developers would consider patching the vulnerability. But in the end I managed to convince them of the risk.

Getting the CVE’s registered

After finding the vulnerabilities, reporting them to the organizations, and waiting for them to fix the vulnerabilities I wanted to get them registered. This was done by requesting a CVE for each of the findings. Requesting WordPress CVE’s was done by filling in a form at wpscan.com/submit.

The CVE’s

The following CVE’s were registered as a result of my research:

• Contact Form Email XSS: CVE-2023-2718
• Forminator XSS: CVE-2023-3134 (still reserved at the moment of writing)
• Quiz And Survey Master XSS: CVE-2023-3575 (still reserved at the moment of writing)

Conclusion

In the end, it was a good exercise for me to better understand how to identify possible vulnerabilities, as well as practising the demonstration and convincing the developers of the risk of the vulnerability. Which helps me better understand the vulnerabilities myself. Because if you can’t explain something to someone else, you don’t really understand it yourself. ;)

This is the summarization of my entire process of pentesting WordPress plugins, from the scope definition phase to the registration of CVE’s. Thank you for reading my blog post.

Happy hacking!

Het bericht RESEARCH DAY: Discovering vulnerabilities in WordPress plugins verscheen eerst op Onvio.