A Konami Code for Vuln Chaining Combos
Automate finding relational vulnerabilities for a more accurate risk rating
Intro
Anyone else thinking about pretzel Combos right now? Yeah me neither.. This blog isn’t actually about those (sorry), it’s about vulnerability chaining in Application Security but this concept could apply to Network Security as well. I was asked recently to present at my local OWASP chapter so I had to review my journal of old ideas and pull this one out of my back pocket, if I’m being honest. I’m glad I did though because I needed some motivation to pursue this and it could even potentially become an OWASP project itself!
Vuln Chaining isn’t a new concept, but I do want to explore an idea that I haven’t seen proposed or implemented anywhere in the community yet. For those that follow my blogs, I like to take old ideas and try to put a new spin on them if I can. In practice, this could be a new tool, plugin, or knowledge resource to help offensive security professionals as well as those looking to strategically defend their environments, while having a more accurate risk perspective. I dive into risk rating and vuln chaining backgrounds first, so feel free to skip ahead to the Getting Started With a Vuln Chain MindMap and Database paragraph or see the PowerPoint if you want to get right into it!
Importance of Accurate Risk Assignment
If you’re in this field, either on the receiving end of a security assessment or on the side providing it, you know that risk ratings can be largely subjective. Understanding and assigning risk relies on an understanding of not just the vulnerability, but the environment and other factors as well. Vulnerabilities do not live in a vacuum. Other vulnerabilities that exist (which we’ll talk about soon), factors such as external vs internal, pre-authentication vs post-authentication, roles, privileges, ease of and likelihood of exploitability all should factor into the severity assignment, among others.
Vulnerability scanners often spit out reports that only take the “base” Common Vulnerability Scoring System (CVSS) or Common Weakness Scoring System (CWSS) into consideration. The other metric groups that fine-tune the rating, such as the attack surface which attackers must overcome for exploitation or environmental factors, are not factored into these. What you end up with is a vulnerability report with risks that are not accurately portrayed. Context is everything! Should an insecure cipher vulnerability within an internal, heavily segmented environment be considered a Medium-severity finding? Probably not, and it’s okay to challenge these as a peer and as a customer! This also doesn’t mean lower-severity findings should be ignored, because as I’m about to get into, several low and moderate-level vulnerabilities may be able to be combined together or used in the context of the environment that introduces a new, critical issue.
It’s important to accurately understand risk. If the risk is lower than it should be, the vulnerability won’t get prioritized and may not be acknowledged until it’s too late. If it’s too high, priority gets taken from other issues that should be addressed more immediately. Development efforts cost time and money and an application, developer, or even the company’s reputation could be damaged if issues were made to look worse than they are.
We get risk wrong often because we don’t understand the environment we’re testing against. For consultants like myself who deal with different customers regularly, it’s critical to understand what industry this application is going to be used in. Information Disclosure may be a Low for a public app with usernames being shared on a Social Media platform for example, but this same leak could be critical in a healthcare app due to HIPAA reasons. It’s also important to take the time to know what an application actually does, and not just dive right into the routine of testing for vulnerabilities. I can’t stress this last one enough and it’s something I’ve been guilty of myself earlier in my career. At least request a demo!
Other reasons for getting risk wrong include a lack of experience. Vulns might be missed entirely or they aren’t taken far enough. You see this often with new hires or in public bug bounty programs. There are people who even dive in and help new bug hunters increase their payout by combining issues together for an increased severity. Otherwise, the company participating in the bounty would be unaware of and only resolve a portion of the issues, opening themselves up to a potentially greater attack in the future. Everyone benefits from an accurate risk rating!
Vuln Chaining For the Win!
Vulnerability chaining is the practice of combining multiple issues together, often for a greater impact. Oftentimes, more than one lower-severity issue can be used together for a higher risk rating. If you follow what goes on in the annual Pwn2Own hacking contests, the winner is often someone or a team who chained several lower-severity 0day vulnerabilities together to jailbreak an iPhone or something, resulting in a massive payout. Each of these vulnerabilities by themselves may be minimal and result in a tiny reward, but chained together, they have a much greater impact.
It’s not uncommon for a more experienced AppSec tester to identify and propose new findings during a technical review of another peer’s assessment, based on other factors and vulnerabilities that are seen in the report. This is a learning opportunity and is one of the ways most of us sharpen our skills and better ourselves, outside of technical challenges and training. Even experienced AppSec professionals could miss something since all of this knowledge is floating around in our heads.
Where’s the documentation? A lot of vuln chaining examples like the one above can be found in public bug bounty reports and random blogs, but there’s not a good centralized resource to map them all out. My idea? Let’s create a community-driven open resource where they’re all defined in a relational database! OWASP project, anyone?
Getting Started With a Vuln Chain MindMap and Database
In what felt like a real-life meme of Charlie Day from It’s Always Sunny, I started with a list of chains in a note application until it got confusing. I had to create a MindMap of certain vulns and was amazed once I started relating them to each other just how interconnected they all were. I also found more vulnerability combinations than I had collected previously this way. The MindMap above is just a Proof of Concept (PoC) and a small sample of what a completed relationship map could look like. It’s a lot of work and I could use the community’s help to keep it updated and accurate. You can find it here. Still, I got excited seeing the potential so I took my PoC further by developing a relational database with a web front-end as a tool that could be used by an AppSec professional or someone looking to do a threat modeling self-assessment.
Closing Thoughts
I had envisioned an online resource that can be used in a variety of ways, including the conditional logic form in the gif and the MindMap above. As I thought about this even further, I realized it could also have a command-line component that imports vulnerability management report data and uses its logic to more accurately assign risk, or find missing issues without context previously being taken into consideration.
For AppSec testers and bounty hunters, this could simply be a Burp Plugin (any takers?) that looks at your Issues list and suggests other findings. Sure, these are suggestions and you’ll still need to validate findings, but that should already be what we’re doing. This would make for more accurate assessments and can be used as a training resource. It could even make for a cool card game with “multipliers” and other vuln cards (think Backdoors & Breaches IR game from BlackHills InfoSec). As I mentioned previously, an internal team could use this to perform their own threat modeling self-assessment based on vulnerability scan results or pentest reports. Ideally, I’d love this to not have to be a plugin at all but be built directly into vulnerability scanners so they take environmental factors and other vulnerabilities into consideration. There are platforms that already aggregate vulnerability information, this could be applied in those solutions as well. Even simple things, like confirming an IP address is private vs public (internal vs external), do not currently have an effect on the severity assignment given by most “dumb” vulnerability scanners. Let’s get more accurate with our risk understanding. We shouldn’t rely on our knowledge alone for keeping these vulns in check, so let’s use our Konami Code to make it easier! Remember, ˄˄˅˅<><>BA Start. 🤓
Thanks! — Curtis Brazzell
