Your latest pentest report was just delivered and there are a dozen findings with severity scores ranging from critical, high, medium, low, and informational.
How do you prioritize remediation?
First, businesses must establish a good understanding of the different severity levels and the finer details such as the differences between high, medium, and low-severity vulnerabilities.
Thinking more broadly, modern security teams have a plethora of tools and data to help allocate resources properly but oftentimes all of this information creates a situation where low-severity vulnerabilities are seen as “not a risk at all.” This is incorrect.
A security team should be concerned with leaving vulnerabilities unfixed — even ones ranked as low-severity. To better allocate resources, it's important to have stakeholder buy-in for a thorough remediation plan. Having a strong understanding of severity levels and thus being able to explain them to stakeholders will help achieve this resource allocation and remediate vulnerabilities more completely.
This post will not only help you understand how to properly interpret low-severity issues but also cover how to make important stakeholders (managers/directors/budget holders who need to approve resources) understand that they can be just as dangerous if left unaddressed.
Furthermore, we’ll examine an interesting new research project that highlights an example of this in real life. This should further empower InfoSec professionals to get the necessary sign-off from business leaders to properly address and remediate risks strategically.
Vulnerability Severity Levels
As the security sector continues to evolve to better support customers, so does the terminology. When thinking of vulnerability severity, it’s important to understand that not all vulnerabilities found during a pentest require the same response.
Vulnerability severity helps companies differentiate between the critical and lower or informational findings. As the name implies, there’s a difference between a critical vulnerability and an informational one. An informational vulnerability is usually due to the inclusion of best practices but is not exploitable in an organization’s current setup and thus, does not have risk associated with it.
Looking away from the extremes towards high- to low-severity vulnerabilities, these should be taken into account with credence in addition to critical ones. In particular, security teams having to prioritize their work should still consider remediation for low severity vulnerabilities, despite being a lower priority. This is because low-severity vulnerabilities can still pose security risks to businesses which the example below highlights.
How Do Low-Severity Vulnerabilities Still Pose a Risk?
Without a clear understanding of how vulnerabilities are assigned to different severity levels, low-severity vulnerabilities may be improperly deprioritized or worse, ignored altogether.
This doesn’t mean teams should remediate a low-severity vuln before high-severity ones (while accounting for the remediation effort needed for each) — it does mean that low-severity vulnerabilities should still be fixed because of factors such as multi-chain exploits and business logic exploits. In both types of attacks, attackers will connect a series of exploits to create a larger, more serious one.
Essentially, it’s important to remember there’s a difference between severity from risk. A pentest report will set the vulnerability severity based upon the risk to a business. Risk requires an understanding of business operations and then taking the severity of a vulnerability into account. The two terms can be thought of as theoretical (risk is set in general terms) and reality (severity is set within business context).
Let’s now look at one example researchers recently discovered where a low-severity vulnerability paired with a hardware attack could lead to a breach.
PACMAN Attack Example
Recently, researchers discovered an interesting example of pairing a low-severity software vulnerability together with a hardware vulnerability to create a critical concern.
The PACMAN Attack1 functions through an exploit in Apple’s M1processor paired with a software exploit known as memory corruption. Researchers were able to execute this exploit remotely by turning a software bug into a more severe authentication bypass exploit. This attack offers an extreme (and more relatable) example of how pairing exploits together often creates more serious vulnerabilities for businesses to defend against.
To be more specific, PACMAN exploit works by pairing an existing software bug in the memory ready/write functionality and transforming it into a more serious pointer authentication bypass exploit. As researchers explain, to achieve this, they need to first learn what the PAC value is for the target pointer.
Enter PACMAN, which researchers created using a self-described “PAC Oracle, which is the ability to tell if a given PAC matches a specified pointer.” Then the team suppressed system crashes using speculative guesses from PAC until learning which guess is correct through a micro-architectural side channel. Then, a code sequence known as PACMAN Gadget authenticates attempts to use the victim’s pointer.
Lastly, researchers then paired this with an existing memory bug to successfully create the PAC Oracle and breach a target’s computer. While a scary thought to consider for InfoSec teams, the awareness of the potential attack is the first step to proactively preventing it from occurring in your environment.
In closing, hopefully, this article empowers conversations with stakeholders by showing the importance of addressing low severity vulnerabilities and better prepares security teams for the next time they request extra resources or need to justify existing budgets.
It’s important to remember that even low-severity vulnerabilities deserve attention and therefore, proper resource allocation.
Citation
1. @inproceedings{PACMAN:2022, title = {PACMAN: Attacking ARM Pointer Authentication with Speculative Execution}, author = {Ravichandran, Joseph and Na, Weon Taek and Lang, Jay and Yan, Mengjia}, year = {2022}, isbn = {9781450386104}, publisher = {Association for Computing Machinery}, address = {New York, NY, USA}, url = {https://doi.org/10.1145/3470496.3527429}, doi = {10.1145/3470496.3527429}, booktitle = {Proceedings of the 49th Annual International Symposium on Computer Architecture}, location = {New York, New York}, series = {ISCA '22}}
