The Domino Effect: Chaining Medium and Low Vulnerabilities is The Path to Critical Breaches

Uncover how data breaches happen as we delve into the domino effect of chaining vulnerabilities, leading to critical breaches. Learn more now.

By
Sherif Koussa
9 minutes min read

Chaining Vulnerabilities, Necessity or Overkill?

In today’s security landscape, vulnerabilities are often categorized as Critical, High, Medium, or Low risk. However, a crucial insight emerging from the field is that even vulnerabilities deemed medium or low risk can be chained together to form a critical risk vulnerability. This approach—where attackers leverage multiple, seemingly minor weaknesses to infiltrate a system—is a reality in modern cyberattacks. While many pentesting companies aim to identify and check off individual vulnerabilities from a pre-determined list (i.e. OWASP Top 10), real attackers are not just looking for that one big flaw. They are more likely to find and focus on a series of chained, medium-risk vulnerabilities to reach the crown jewels of a target organization.

In a compelling real-world example, Software Secured was engaged by an anonymous client, ACME, to pentest their application at app.acme.com. The exercise revealed how medium and low vulnerabilities, when exploited in sequence, could allow attackers to traverse tenant boundaries and compromise sensitive areas of the application. This case study demonstrates why it is essential to choose a pentesting vendor who examines the entire security posture holistically rather than simply ticking off vulnerability checkboxes.

In the case of ACME, Software Secured uncovered several such vulnerabilities. Individually, these issues might not have raised any big alarms during a traditional assessment. However, when chained together, they provided a viable attack vector across tenants within the application, a vulnerability that was rated a Critical at CVSS Score of 9.5m demonstrating the classic domino effect where one weakness facilitates the exploitation of another.

The ACME Case Study: A Real-World Attack Chain

When ACME engaged Software Secured to test the resilience of app.acme.com, the goal was clear: understand how an attacker might leverage multiple vulnerabilities to access the most sensitive parts of the system. The pentesters at Software Secured did not just focus on high-risk vulnerabilities but adopted a holistic approach. They simulated a real-world attack by chaining together medium and low vulnerabilities, illustrating that even without a single catastrophic flaw, an attacker could still achieve a critical breach.

Step 1: Identifying the Entry Point with CSPT

The first vulnerability discovered was Client-Side Path Traversal (CSPT). In this scenario, the application constructed an API request path using user-controlled input. Consider a URL structured like this:

https://app.acme.com/profile?p=../../../admin

Here, the parameter p was directly used to construct the API request path without proper sanitization. This allowed attackers to inject directory traversal sequences that redirected API calls from a benign endpoint to an administrative one. On its own, CSPT might be classified as medium risk. However, in the hands of a determined attacker, it opened the door to further exploitation.

Step 2: Amplifying the Attack with an Open Redirect

Next, the pentesters discovered that the application also featured an open redirect vulnerability. Open redirects enable attackers to force an application to redirect users to an attacker-controlled server by manipulating unvalidated URL parameters. By combining the CSPT vulnerability with the open redirect, the attackers could not only alter the API path but also route the request externally.

For example, they prepared a payload in this format:

ANYTHING/../../../../dashboard?to=https://<attackerServer>

Before injection, the payload was double URL-encoded to ensure the traversal sequences remained intact during processing. The double encoding was a clever obfuscation step that prevented simplistic filtering mechanisms from blocking the malicious path. With the CSPT vulnerability already in place, the open redirect allowed the modified request to bypass internal security measures and reach an attacker-controlled endpoint.

Step 3: Exploitation and Lateral Movement

After establishing the entry point, Software Secured set up an attacker-controlled webserver. This server was configured to mimic the expected JSON response from the original API request. However, an XSS payload was injected into one of the parameters that were reflected on the page without proper sanitization. The response was critical for demonstrating the exploit in action, and the server was configured with specific HTTP headers:

  • Access-Control-Allow-Origin: https://app.acme.com
    (Note: The origin is adjusted based on the testing environment)
  • Access-Control-Allow-Credentials: true
  • Content-type: application/json

These headers ensured that the victim’s browser would accept the response, bypassing cross-origin restrictions.

Exploitation Flow:

1. Preparing the Payload:


The pentesters prepared the CSPT payload as described, double URL-encoding it to preserve the necessary traversal sequences.

Now the pentester social engineered a valid reason using a phishing campaig, the user clickon on the crafted URL, which in turn injected the payload into the application’s URL path. The URL format was:

https://app.acme.com/profile?p=<CSPT-Payload>

After the payload was injected and double-encoded, the URL looked similar to this:

https://app.acme.com/profile?p=ANYTHING3%25%32%66%25%32%65...

2. Triggering the Exploit:


As the victim’s browser processed the manipulated URL, the client-side code constructed an API request using the double-encoded payload. This request was rerouted to the attacker’s server, where the JSON payload was delivered. Once received, the JSON response triggered an XSS payload in the victim’s session. The successful execution of this payload was confirmed when the “Overview” section of the application’s navigation menu displayed evidence that the injected script had been loaded and executed.

Through this chained attack, Software Secured was able to cross tenant boundaries, showcasing how medium and low vulnerabilities could be leveraged together to access highly sensitive parts of ACME’s application. Rather than relying on one major vulnerability, the attackers used a series of steps—each exploiting a different flaw—to create a pathway to the system’s crown jewels.

Lessons Learned and the Importance of Holistic Testing

The ACME case study is not just a technical demonstration; it’s a clear message to organizations about the evolving nature of cyberattacks. Here are some key takeaways:

1. Attackers Consider the Big Picture and so Should You:

In real-world scenarios, attackers rarely rely on a single vulnerability. Instead, they map out a series of steps, chaining together multiple flaws—each of which might be considered medium or low risk on its own—to ultimately infiltrate a target system.

2. The Crown Jewels are the End Goal:

While many pentesting vendors focus on identifying and reporting individual vulnerabilities, attackers are primarily focused on reaching the “crown jewels” of the organization—be it sensitive data, critical infrastructure, or key administrative controls. The attack on ACME’s application is a prime example: rather than looking for a massive, singular vulnerability, the attackers used a sequence of chained exploits to move laterally within the system.

3. Holistic Security Assessment is Crucial:

Organizations need a comprehensive security assessment that looks beyond isolated vulnerabilities. This means understanding how different weaknesses interact and how an attacker could leverage them in tandem. When evaluating a pentesting vendor, it is essential to choose one that doesn’t just check boxes but also has the expertise to see the bigger picture.

4. Real-World Expertise Matters:

The expert hackers at Software Secured demonstrated their ability to think like real-world attackers. Their approach went beyond traditional testing methods; they simulated an end-to-end attack that mirrored what an actual adversary would do. This methodology not only revealed the individual vulnerabilities in ACME’s application but also exposed the dangerous potential of chaining them together.

Choosing the Right Pentesting Partner

For organizations seeking to secure their applications, the ACME case study offers a clear directive: focus on holistic security assessments. The ideal pentesting vendor should provide more than a list of vulnerabilities—they should offer a deep understanding of how these vulnerabilities interact and how they could be exploited in real-world scenarios.

When evaluating potential pentesting partners, consider the following:

  • Holistic Approach:
    Look for vendors who analyze the entire application ecosystem. They should assess how client-side, server-side, and third-party components interact, and they should identify potential chaining paths that could lead to critical breaches. This will likely become evident early on, in the scoping conversation.
  • Real-World Attack Simulation:
    Vendors should demonstrate their ability to simulate complex, multi-step attacks that reflect actual adversarial tactics. This includes showing how medium and low vulnerabilities can be chained together to compromise sensitive systems.
  • Proven Expertise:
    Choose a partner with a track record of identifying and mitigating chained vulnerabilities. Real-world examples, such as the ACME engagement, are strong indicators of a vendor’s ability to think like an attacker and protect your organization against advanced threats.
  • Big Picture Focus:
    Ultimately, the goal is to safeguard your organization’s crown jewels. A vendor that focuses solely on individual vulnerabilities without considering the overall security architecture may miss critical attack vectors that can only be revealed through a holistic analysis.

Conclusion: The Value of a Holistic Security Perspective

The ACME case study and the demonstration by Software Secured illustrate a fundamental truth in cybersecurity: vulnerabilities do not exist in isolation. Even medium and low-risk vulnerabilities, when chained together, can create a pathway for critical attacks. Attackers focus on building chains of exploits to infiltrate systems and access sensitive assets—not simply on finding that one big vulnerability.

For organizations, this means that security assessments must be comprehensive. A holistic view of the application, which examines how individual vulnerabilities interact and potentially amplify one another, is essential. When selecting a pentesting vendor, prioritize those who understand the big picture and can simulate real-world attack scenarios rather than just checking off vulnerability lists.

By adopting a holistic approach to security, organizations can break the chain of vulnerabilities and protect their most critical assets from determined adversaries. Ultimately, the true value lies not in isolated vulnerability reports but in the ability to see—and secure—the entire attack surface.

About the author

Sherif Koussa

Sherif Koussa is a cybersecurity expert and entrepreneur with a rich software building and breaking background. In 2006, he founded the OWASP Ottawa Chapter, contributed to WebGoat and OWASP Cheat Sheets, and helped launch SANS/GIAC exams. Today, as CEO of Software Secured, he helps hundreds of SaaS companies continuously ship secure code.

Get security insights straight to your inbox

Additional resources

Here to get you started

Featured Post Image
Icon

The State of Penetration Testing as a Service- 2022 Edition

Say goodbye to 300+ page penetration test reports

Providing the quality of the biggest names in security without the price tag and complications.

Book a 30 min consultation

Manual penetration testing

Full time Canadian hackers

Remediation support

CTA background