I recently read an interesting blog post by Adam Shostack on Adversarial Thinking and Wargames. In it, he explores the concept of adversarial thinking in the context of cybersecurity through the lens of wargames and emphasizes its role in strengthening security practices and identifying vulnerabilities.

Adam has always had a dislike for the concept of thinking like an attacker.

In his own words, “Here’s what’s wrong with think like an attacker: most people have no clue how to do it. They don’t know what matters to an attacker. They don‘t know how an attacker spends their day. They don’t know how an attacker approaches a problem.“

When it comes to hacking apps and APIs from a security testing perspective, I’m not sure that’s always true.

In this article, I will show you how to approach attacking a web app through adversarial thinking. All thanks to the help of work published by OWASP and MITRE that you can follow to “approach the problem.”

Let’s get to it!

But first… what are we trying to accomplish?

Let’s start by laying the foundation for what our goal is here. We want to attack a web application and its APIs as part of our security testing. This may be an internal engagement or part of an external bug bounty program. Ultimately though, we are looking for security vulnerabilities in the apps and infrastructure we are responsible for testing.

QA efforts usually focus on testing that the feature works as expected. We aim to make it work in ways NOT expected. We make the software work in ways never imagined to give us more access to resources and data.

“Make software work in ways it wasn’t intended or expected.”

So let me show you a way to find attack patterns against weaknesses in software. You know… like how an attacker might do it.

Getting Started: The OWASP Top 10

The “OWASP Top 10” is a well-known and widely respected document created by the Open Web Application Security Project (OWASP), a nonprofit organization dedicated to improving the security of software.

The OWASP Top 10 is a list of the most common web application security risks. It provides an awareness of the vulnerabilities and threats that you should be aware of and take steps to mitigate.

This guidance comes with a mapping of potential vulnerabilities and weaknesses that can exist in the software. These are commonly called CWEs.

Common Weakness Enumeration (CWE)

Common Weakness Enumeration (CWE) provides a standardized way to identify, categorize, and describe different types of vulnerabilities and weaknesses that can exist in software and systems. It is a valuable resource for the cybersecurity community, including developers, security professionals, and researchers, as it helps in understanding and addressing known security issues.

CWE is often used in conjunction with other standards and tools, such as the Common Vulnerability and Exposures (CVE) system, to improve the security of software and to facilitate more effective vulnerability management and mitigation.

For us as attackers, CWEs are awesome. Firstly, they help describe demonstrative examples that often include sample attack payloads we can use as a starting point in our own exploits.

Secondly, they link to observed examples, which are examples found in real production software. These are generally linked to CVEs.

Thirdly, and this is my favorite part, they link to related attack patterns, a knowledge base of common attack patterns that helps to identify and understand attacks called CAPEC.

Common Attack Pattern Enumeration and Classification (CAPEC)

Common Attack Pattern Enumeration and Classification (CAPEC) is a comprehensive database that provides a collection of known attack patterns. These patterns represent common methods and techniques adversaries use to exploit known weaknesses in software systems.

Developers, testers, and hackers can better anticipate, prevent, and mitigate potential security threats by understanding these patterns. CAPEC serves as a critical companion to CWE by tying in the attack patterns related to specific system weaknesses.

A typical CAPEC entry includes a detailed Execution Flow. This consists of 3 sections:

1. Explore – Guidance on what to look for that may indicate that the software may be vulnerable to this attack.
2. Experiment – Guidance on possible ways to test if the software may be vulnerable to this attack.
3. Exploit – Summary of possible ways to exploit the software if your experiments are successful.

In many of the CAPEC entries, there will also be an external mapping to one of three possible other data sources:

1. WASC Threat Classification 2.0 – A comprehensive framework from The Web Application Security Consortium that categorizes and organizes key security threats to web applications to facilitate standardizing threat reporting and response.
2. ATT&CK Related Patterns – A curated set of adversary behavior descriptors collected by MITRE, providing invaluable insights into the techniques used by threat actors to compromise and maneuver within systems.
3. OWASP Related Patterns – A set of techniques that attackers use to exploit the vulnerabilities in applications.

Putting it all together – The OWASP Security Testing “Basics”

Thinking like an attacker is possible when we have so much linked guidance that can help. Let’s walk through an example end to end. It will end up looking something like this:

Security Risk → CWE → CAPEC → Testing Pattern = Attack

No plan survives first contact. But let’s give it a try anyway.

Step #1 – Identify a potential security risk to attack

The OWASP Top 10 is organized with the most common risks listed in descending order. So it makes sense to start there.

The first item in the list is ”A01:2021 – Broken Access Control”. If we click on it, we are presented with an overview and description of the security risk. We are also presented with the total number of CWEs mapped to this. In our case, there are 34 common weaknesses identified.

If we scroll down to the bottom of the page, we can see a complete list of mapped CWEs identified, with links to the individual MITRE CWE data.

Let’s pick the first one (CWE-22) and take a look at it.

Step #2 – Research the potential weakness against the security risk

When you click on a CWE, it will take you into the MITRE CWE knowledge base. It will immediately present you with a general description and a much more detailed one that can help educate you on the weakness and how it may make software vulnerable.

If you continue to review the data, you will come to a section called Demonstrative Examples. This includes examples of bad code that demonstrates this weakness. More importantly, it also provides sample attack code that exploits that vulnerable code. This is perfect to use as a starting point for your own attack payloads.

Scrolling further, you will then come to a section called Observed Examples. This lists any references to examples of production software that was found to be vulnerable to this weakness. These will link out to any CVE records associated with the CWE.

Continuing to scroll to the bottom of the CWE, you will get to a section called Related Attack Patterns. This will include a list of Common Attack Pattern Enumeration & Classification (CAPEC) records that have been shown to be useful against this CWE.

This is extremely helpful. It helps to educate you on possible ways to attack vulnerabilities in the software you test. It aligns your thinking and understanding of HOW to go about it. So even if you aren’t a seasoned, elite hacker, you get foundational knowledge to help you look at it from their perspective.

Let’s explore CAPEC in more detail by selecting the first attack pattern (CAPEC-126).

Step #3 – Investigate Common Attack Patterns

When you click on any related attack patterns in a CWE, it will take you to the MITRE CAPEC knowledge base. It will provide a description of the attack pattern, as well as an understanding of the probability an attack can be successful and the typical severity of it.

If you scroll down to the section called Execution Flow, it will highlight how to explore the software to see if it’s vulnerable to this attack pattern.

It will then suggest how to experiment with the software to test for the vulnerability. In many cases, you can cross-reference this with the attack code you got in the corresponding CWE to develop the payloads needed to complete the experiment.

Finally, it will describe how this attack could be exploited and what the damage potential may be.

The CAPEC record even goes so far as to help you understand the skills needed to pull off the attack, what prerequisites may be needed, and what resources are required. All valuable information to help guide you through your attack planning.

If you continue to scroll down, you will find relevant Taxonomy Mappings. It is here where we come full circle, pointing from the attack pattern back to relevant patterns that can be used to explore how to complete your security testing for the potential vulnerability. In our case for CAPEC-126, it points back to the OWASP Attack Pattern database.

Step #4 – Explore External Taxonomy Mapping

Following the link to the external taxonomy mapping from CAPEC-126, we return to the OWASP attack database. It will describe how developers can avoid this sort of attack and how they can go about identifying if their code is vulnerable.

Of course, this is the same guidance you can leverage as the attacker.

In many cases, this guidance also includes linkage to testing for the vulnerability. In our case, this issue links directly to the appropriate section in the OWASP Testing Guide, offering detailed insights on precisely what to do. It also provides example payloads you can use and a description of specific OS-specific nuances you may need to account for.

Step #5 – Attack and Exploit

At this point, you have everything you need. You have identified a potential security risk. You’ve been provided a list of any common weaknesses that may relate to it. You have found common attack patterns you can potentially use to exploit it. And you have information to craft your attack payload and test if the software is vulnerable.

So even if you don’t have the mindset of an attacker, you have appropriate guidance based on how they think, using a history of data from attacks that they have used to breach software in the past. With time and experience, you will gain confidence in your security testing by following this methodology of exploration and exploitation.

Post Mortem – Autopsy of Attack

I wasn’t kidding when I mentioned that this methodology is the OWASP Security Testing “basics.” Even if you thoroughly explored all 34 CWEs mapped to Broken Access Control and tracked every common attack pattern down, you can’t confidently state that you are free from vulnerability. You can’t guarantee the software you are testing is secure.

And that’s OK.

There will be business logic bugs you may have missed. There may be input patterns you didn’t try. Tainted payloads you don’t know about yet that could work. In time, with more experience, your methodology will improve, and those issues may be found.

Then, you must repeat this process against the other nine items in the Top 10 list.

When complete, you will have established a clean and clear baseline against the most common risks using the most common attack patterns used in the real world.

And that’s a great start.

But here’s the rub. It’s only a start. In fact, OWASP offers a more mature open standard with the Application Security Verification Standard (ASVS) that includes three levels of testing to normalize the range in the coverage and level of rigor available when it comes to performing web application security verification using a commercially workable open standard.

Testing against the OWASP Top 10 doesn’t even meet the needs for ASVS Level 1. There are about 51 good application security practices that are verified through this methodology, whereas ASVS Level 1 has over 131 that are verified. Level 1 is the minimum bar all web applications and APIs should strive to achieve, according to OWASP.

A note about the API Security Top 10

Throughout this article, I have been referring to the OWASP Top 10. It is an excellent list for web application security testing that has had many years to mature and improve. However, as an API hacker, it is only right to call out that there is a dedicated API Security Top 10 list as well. And at present, it needs time to mature to follow this methodology properly.

Here’s why.

The CWE mapping is still relatively weak in many OWASP Top 10 projects, including API Security. The community needs to do a better job of providing the required feedback to properly backfill the linkages that need to be there. This will be corrected over time. As it will with other top 10 lists for things like mobile, serverless, and LLM.

As that data gets adequately linked, it will only improve your ability to identify the appropriate attack patterns for your security testing efforts.

Conclusion

We started this article by discussing the fact I believe it is possible to use adversarial thinking to conduct security testing of web apps and APIs. I hope I’ve been able to show you how to do that.

I get where Adam is coming from. For many developers and testers, the concept of software development and testing is to get things to function and prove it works. It’s hard to think about how to get it to work in ways not intended.

But building and breaking code in this day and age of OWASP and MITRE includes guidance that can help both offense and defense. You don’t have to have a hacker mindset to be able to attack software. You just need to know what common risks exist, what common weaknesses are exploited, and what common attack patterns are used to do so.

If you do that, you help identify the most common security issues in software today. While getting a clean report against tests following this methodology does not guarantee you have secure software, the opposite can’t be said. By ignoring this baseline, there is a higher probability you don’t know just how vulnerable your software may be.

In other words, let’s not fret about winning the war just yet. Let’s win our first battles and gain the experience necessary for a more secure baseline. Adversarial thinking is a great way to do that.

Security Risk → CWE → CAPEC → Test Plan = Attacker

One last thing…

Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly. If you haven’t, subscribe at https://apihacker.blog.

The post Adversarial Thinking for Bug Hunters appeared first on Dana Epp's Blog.

*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/adversarial-thinking-for-bug-hunters