Welcome back to the Patchstack Weekly Security Update! This update is for week 34 of 2022.
This week, I will share with you two plugins that patched security bugs you should know about in the weekly vulnerability roundup.
But first, the weekly knowledge share. Which will be all about severity scores associated with security bugs and how they are calculated using the CVSS or Common Vulnerability Scoring System.
CVSS scores help us gauge the severity or risk associated with a security bug. This scoring system gives us a score between 0-10, with 0 meaning no risk at all, 1-3 implying there is low or insignificant risk associated with the vulnerability, all the way up to 9-10 meaning a critical risk running an insecure version of the software.
This severity score is seen with almost all public CVEs and is calculated using the following metrics.
The attack vector defines what level of access, from physical access to the hardware to over the internet requests, the attacker needs to have to perform the attack.
For web applications, which are intended to be accessible from the internet this score will likely always be “Network”.
Next is “attack complexity”, if it is set to “high” this means the attacker needs to have privileged or insider knowledge to perform the attack. If it is the default “Low” then the attack could be performed without needing special knowledge about the target.
The “Privileges Required” metric is simple. If the attack can be performed unauthenticated, then this is set to “None”. If the attacker needs to be performed by a logged-in user (including subscriber accounts in WordPress) then this is set to “Low”. If this logged in user account was a “High” privilege user (like admins or super-admins in WordPress)
Now, on to User Interaction. If it is set to “Required”, the attacker needs to be interacting with another person with access to perform the attack. A good example would be CSRF bugs. in order to perform CSRF attacks, an attacker needs to trick a logged in user to follow a malicious link.
Scope determines if a successful attack could lead to further attacks beyond the application with the security bug. If the scope is “Changed”, then attackers may gain additional access. An example of Scope Changing would be Remote Code Execution attacks, which allow attackers to target the servers running the application after a successful attack.
Now on to the three impact metrics. All security bugs should affect either the confidentiality, integrity, or availability of an application in some way. If they don’t, then it may not be a security bug at all, because there is no way to explainable the risk related to it (and the CVSS score will be zero.)
If the attack could lead to the reading of private data, then there is a confidentiality impact. Low means the attackers could only read limited or partial data from the application, while High means the attackers could read any data they wanted using the attack.
Integrity is about modifying data, if it is limited access then it is Low, while much like Confidentiality, it would be set to High if attackers could modify any data.
Finally, “Availability Impact” meaning the attack may prevent access to the data. This would be something like a denial of service-related attack, Low meaning the app still works but not all of it, and High meaning the whole application is inaccessible for as long as the attack is being performed or longer.
Those are the base metrics, there is a bunch of math behind turning these metrics into a score between 0 and 10 which is simplified by using a CVSS calculator like the one NVD provides helps a lot to do the math behind turning those above scores into a 0 – 10 severity rating.
These metrics do a good job but are not perfect. There sometimes can be discrepancies between individual definitions of the terms above (there is a lot of documentation on this too), and some metrics either do not apply at all or need additional granularity depending on the application in question.
Personally, I trust most CVSS severity scores I see, but I do not treat them as gospel. They are only a guide to help us sort out the huge number of vulnerabilities released per day into higher (more immediate) risk and lower, less likely risk categories.
The All In One Video Gallery plugin patched two security bugs recently, an unauthenticated arbitrary file download as well as a server-side request forgery security bug. I covered SSRF security bugs a few weeks ago in episode 33 what is server-side request forgery (SSRF)?
The WC Marketplace plugin patched two security bugs as well, one has to do with a lack of proper authorization checks in an AJAX call (I covered how to secure WordPress AJAX endpoints back in episode 22), and the second security bug could lead to LFI or local file inclusion attacks. Local file inclusion is a security bug I have not yet covered and I promise I will add it to my backlog to share my knowledge with you in a future episode.
This week’s thanks goes out to the developers of the All in one video gallery and WC marketplace plugins. Both plugins have great developers who look out for their clients and make sure security bugs are being patched.
A special thanks goes out to the anonymous staff behind the National Vulnerability Database. I reached out to NVD last week to discuss a concern about a vulnerability’s severity and impact last week and it was a pleasant and respectful conversation. The end result was a public vulnerability’s details were updated, specifically, the severity score of a vulnerability dropped from Medium to Low. I could have pushed for more, but I appreciate that the NVD staff listened to my concerns, and I know my voice was heard. So, for that, I thank the NVD.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!