The last 7 days have been very busy with a number of vulnerabilities being disclosed on multiple WordPress plugins. Some of them are minor issues, some are more relevant, while others are what we’d categorize as noise. How are you supposed to make sense of all this?

To help provide some clarity on the influx of data, we want to provide some insights to help you, the website owner, navigate and understand these vulnerabilities. We will provide a summary and an explanation of the ones that matter and the ones that do not.

The Impact of Roles (Authentication) in Vulnerabiltiies

Contrary to popular belief, just because you hear “SQL Injection”, it doesn’t mean someone can actually hack your site. The real problem comes in remote and unauthenticated attacks. These can lead to mass compromises; compromised can be mean leveraged to distribute malware, spam and can lead to brand reputation issues like getting blacklisted by Google.

When an attack requires an authenticated user, the severity drops. However, it is not that uncommon for sites to allow subscribers to register. So, any vulnerability that requires a subscriber user can also lead to serious issues.

Once a vulnerability requires a higher role, think authors or editors, the severity and our overall score drops though. The reason this is true is because users with higher roles often have higher permissions and abilities to do things that can sometimes be seen malicious, but are in fact by design. A perfect example of this can be seen in WordPress core.

In core, an administrator is able to inject unfiltered html in posts and pages, and can also execute any command they want via plugins they install. Is this a vulnerability? No, it’s a feature and it’s based on one very important element – Trust. The user that is given that role is given permission to do whatever features have been made available, so if that’s to inject unfiltered html, then the user is expected to do so responsibly.

In security, this is why we place so much emphasis on concepts like Least Privileged – the principle of giving someone the permission they require to do their job, no more, and no less. If they require higher permissions, then give them what they need, for as long as they need it, then reset the role to its original configuration. This however is a topic for another day, but worth understanding as it sets context moving forward.

Scoring Vulnerabilities on WordPress Plugins

We like to use the DREAD score when assessing a vulnerability in WordPress Plugins. A question we often get is, why did you not report on this recent release? Or, why did you report on this release? DREAD allows us to take a more objective approach to released, in hopes that we’ll be able to cut down on the noise and market confusion.

DREAD was developed by Microsoft many years ago and is not that widely used anymore. For us however, we find it to be very useful for web applications, especially when it comes to Content Management System (CMS) disclosures.

DREAD breaks a vulnerability down into 5 categories:

Damage – How bad would an attack be?
Reproducibility – How easy is it to reproduce the attack?
Exploitability – How much work does it take to launch the attack?
Affected users – How many people will be impacted?
Discoverability – How easy is it to discover the threat?

Each category gets a score from 0 to 10 and at the end, you sum them all and divide by 5 to get the final value.

How we classify each category is what counts the most in the work we do:

1. Damage – 0:same as what the role has, 3:Information Leaks, 5:XSS, 8:Authenticated RCE or SQL Injections, 10:Unauthenticated Remote command execution or SQL injections.
2. Reproducibility – 0:requires admin, 2:requires editor, 3:requires author, 6:requires subscriber, 10: unauthenticated
3. Exploitability – 0:fully manual and takes very long, 3:hard to automate, requires author+, 5:hard to automate, requires login, 8:easy to automate, multiple steps 10:one click on a browser
4. Affected users – 0:less than 1k installs, 5:100k+ installs, 10:1m+ installs
5. Discoverability – 0:you have to attempt an exploit to see if it works or not, 3:you have to guess and it requires a log in,6:you have to guess but can attack remotely, 10:plugin announces that it is installed.

With these ranges in mind, let’s see how each vulnerability stacks up.

Gravity Forms: SQL Injection / Severity: Low

The gravity forms team just released an update fixing a SQL Injection (SQLi) on the “sort” argument on their edit page. Only an authenticated admin or editor can actually reach that part of the code, so we consider it a low severity vulnerability. Editors and admins can do so much already, that only trusted people should have this role. If the admin user is performing a SQLi attack, they are likely conducting a number of other attacks and SQLi is probably the least of your concerns.

It can be used on targeted attacks, due to the lack of nounces, but we will not see any major issues coming out of it.

Looking at DREAD:

D: 8
R: 2
E: 3
A: 7 (since it is a paid plugin, we don't know exactly the number of installs)
D: 3

The final score is 4 – Low (8 + 2 + 3 + 7 + 3 / 5)

Pods Plugin: SQL Injection / Severity: Low

The Pods vulnerability is actually very similar to the GravityForms and the WordPress SEO ones. Looking at the DREAD score:

D: 8
R: 2
E: 3
A: 2
D: 5

Final score is 3 – Very Low (8 + 2 + 3 + 2 + 3 / 5)

MainWP-Child: Password Bypass / Severity: High

The MainWP vulnerability was found by our team and we gave it a high severity. The reason we did so is that it was very easy to exploit (unauthenticated) and allows anyone to get admin access to the vulnerable site.

D: 10
R: 10
E: 9
A: 5
D: 6

Final score is: 8 (high) (10 + 10 + 9 + 5 + 6 / 5)

WooCommerce: SQL Injection / Severity: Very Low

The WooCommerce vulnerability is interesting, since it requires an admin or shop manager in order to exploit it. We would not treat is a vulnerability, but as a bug, since it does not allow more damage than what the role (admin) actually can cause.

D: 0 (same damage as the role itself can cause)
R: 0 (requires admin)
E: 1
A: 10 (1m+ installs)
D: 3

Final score is: 2 (very low) (0 + 0 + 1 + 10 + 3 / 5)

WordPress SEO: SQL injection / Severity: Low

The WordPress SEO vulnerability got a lot of media coverage due to its popularity. Was it valid? Let’s look at the scores again:

D: 8
R: 3
E: 3
A: 10
D: 3

Final score is: 5 (Low) (8 + 3 + 3 + 10 + 3 / 5)

Judging Vulnerabilities

Judging vulnerabilities and its impacts is always very hard. A low severity score on DREAD, doesn’t mean it can’t be used on a targeted attack against your site. It doesn’t mean you do not have to patch it and keep your site updated.

That’s why we always make sure our Website Firewall (WAF) is protecting against all of them. For every new vulnerability disclosed, our research team invests the time to test, verify and validate their impacts and ensures that our protection mechanisms are effectively patching and protecting or users.

When looking at the internet as a whole, low severity vulnerabilities will have a small impact overall and requires less marketing to get to the ear of the users. It’s also difficult to decipher the amount of noise being disclosed, we hope this helps provide some guidance into how to make sense of all the information you might be reading.

– Your Trusted Security Team

Daniel

Via Sucuri.net