Practical Exploitation of DoS in Bug Bounty

Practical Exploitation of DoS in Bug Bounty

Speakers: Roni Lupin Carta

Conference: DEF CON 32

YouTube: https://www.youtube.com/watch?v=b7WlUofPJpU

Overview

In this DEF CON 32 talk, Roni Lupin Carta, co-founder of Lupin Holmes, delves into the often-misunderstood and frequently dismissed realm of Denial-of-Service (DoS) vulnerabilities within bug bounty programs. Carta challenges the common perception that DoS attacks are inherently low-impact or out of scope, arguing instead that with a responsible approach, they can yield significant business impact and substantial financial rewards for security researchers. The presentation focuses on practical exploitation techniques, differentiating between client-side and server-side DoS vectors, and provides concrete examples of successful bounties.

Carta's central thesis is that DoS vulnerabilities, when properly identified and reported, represent a critical risk to an organization's availability and can be more impactful than many traditional vulnerabilities. He emphasizes the importance of understanding a program's maturity and explicitly seeking permission before attempting DoS tests, even highlighting programs that allow full production environment takedowns. The talk is a valuable resource for bug bounty hunters looking to expand their skillset beyond common vulnerability classes and for organizations seeking to better understand and defend against DoS threats.

The discussion covers crucial definitions, responsible testing methodologies, and detailed walkthroughs of two distinct DoS attack types: a frontend crash caused by malformed HTML sanitization and a server-side resource exhaustion via the N+1 database query problem. Carta illustrates how these vulnerabilities, often overlooked, can lead to complete service disruption and significant financial payouts, totaling over $50,000 in bounties from the research shared.

Background

▶ Watch: Introduction to DOS in Bug Bounty and Speaker Background (0:00)

Denial of Service (DoS) attacks aim to make a machine or network resource unavailable to its intended users. Carta clarifies the distinction between DoS and Distributed Denial of Service (DDoS), explaining that DoS originates from a single machine, while DDoS involves multiple, distributed machines. The core principle of DoS, as highlighted by Carta, revolves around the attacker's resources versus the target's resources. An effective DoS often leverages an "amplification" or "multiplying factor" where a small input from the attacker yields a disproportionately large impact on the target.

A significant point of debate within the security community, particularly in bug bounty programs, concerns the Common Vulnerability Scoring System (CVSS) classification of DoS. Carta notes the ongoing discussion about whether DoS impacts "availability" or "integrity." According to CVSS documentation, the deletion of a resource, while denying access, is classified as integrity, not availability. Availability, in the CVSS context, specifically refers to the performance and operation of the service itself, distinct from the availability of data. This nuance is crucial for bug hunters when arguing the severity and impact of their findings with program administrators.

Despite the potential for high impact, DoS is frequently marked as "out of scope" by default in many bug bounty programs, such as those on HackerOne. Carta explains that this isn't due to perceived low impact, but rather the opposite: the potential for too much impact. Companies are understandably wary of allowing numerous bug hunters to indiscriminately take down their production environments. However, Carta strongly advocates for responsible DoS testing, emphasizing that it is possible to identify and report these vulnerabilities without causing widespread disruption.

Responsible testing hinges on finding the "gadget" – the specific problematic component or logic that triggers the DoS. Researchers can identify potential DoS conditions, such as a request taking over 10 seconds, without fully exploiting it to bring down an entire system. If permitted, testing on non-production environments (staging, integration, sandbox) is a viable alternative. Critically, Carta stresses the absolute necessity of always asking programs for explicit permission before initiating any DoS-related testing. This allows programs to monitor their systems, identify the testing researcher, and communicate if issues arise, ensuring a collaborative and safe testing environment. The willingness of a program to accept DoS reports often reflects its "maturity" and understanding of its own risk posture; some programs, surprisingly, even permit full production environment takedowns.

Key Findings

▶ Watch: Guidelines for Responsible DOS Testing in Bug Bounties (3:00)

Roni Lupin Carta's research and presentation highlight several key findings that challenge conventional wisdom around Denial of Service in bug bounty contexts:

1. DoS is Not Inherently Low Impact: Contrary to popular belief and common bug bounty scope exclusions, DoS vulnerabilities can have a catastrophic business impact by rendering critical services unavailable. This impact often scales dramatically, making DoS a significant threat.
2. Responsible DoS Testing is Profitable: By identifying specific "gadgets" and demonstrating the potential for DoS without necessarily causing a full system crash (or by testing in non-production environments with explicit permission), bug hunters can responsibly find and report DoS vulnerabilities, leading to substantial financial rewards. The talk showcases over $50,000 in bounties earned from the presented techniques.
3. Client-Side DoS Can Be Devastating for User Experience: Frontend crashes, triggered by malformed input interacting unexpectedly with client-side libraries, can completely disable a user's interaction with a web application, effectively denying service to individual users or groups.
4. Server-Side DoS via N+1 Queries is a Potent Attack Vector: The N+1 database query problem, a common anti-pattern in application development, can be easily exploited to overwhelm backend systems and databases, leading to widespread service unavailability with minimal attacker resources.
5. Program Maturity Dictates DoS Scope: The decision to include or exclude DoS from a bug bounty program's scope is often a reflection of the organization's understanding of its own risk, its monitoring capabilities, and its willingness to handle high-impact, albeit potentially disruptive, findings. Some mature programs actively encourage DoS testing.
6. CVSS Definitions are Crucial for Reporting: Understanding the precise CVSS definitions, particularly the distinction between "availability" (service operation) and "integrity" (data deletion), is vital for accurately describing the impact of a DoS vulnerability and effectively communicating with bug bounty program teams.

Technical Deep Dive

▶ Watch: When DOS is in Scope: Program Maturity and Permissions (4:20)

Carta presents two distinct categories of DoS vulnerabilities, illustrating practical exploitation methods for each.

Client-Side DoS: Frontend Crash via HTML Sanitization Bypass

The first vulnerability demonstrates how malformed input can lead to a client-side JavaScript crash, rendering a user's web page unusable. This discovery was made during a hacking session on a chat application with fellow researcher Snorlax, where they were playing a game to XSS each other. Unexpectedly, both their pages went blank.

The root cause was traced to the application's use of a JavaScript library called sanitize-html (described as "some kind of DOMPurify") designed to sanitize HTML content, specifically href attributes. The problematic payload was:

While seemingly innocuous, this payload exposed a critical flaw in the sanitization logic. The sanitize-html library, in its attempt to process the href attribute, would call a function (referred to as naughtyHref in the context of the talk) which then attempted to perform a .replace() operation on the value of the href attribute. The critical error occurred because the supplied value, "undefined" as a string, was not treated as the JavaScript primitive undefined. Instead, when the library internally processed the href attribute, it somehow resulted in the JavaScript variable itself becoming undefined at the point where .replace() was called. Attempting to call a method like .replace() on an undefined JavaScript variable results in a TypeError, causing the entire frontend script to crash and the page to go blank for the user.

This type of client-side DoS is impactful because it prevents users from interacting with the application, effectively denying them service. While it doesn't directly affect the server, it degrades the user experience to zero. Carta mentions that this specific technique, or similar client-side data DoS vulnerabilities, collectively yielded approximately $350 in bounties. Another related client-side DoS technique involved a backend accepting malformed JSON that was subsequently parsed by the frontend. This malformed JSON, using constructs like \\ to escape backslashes in a way that the backend accepted but the frontend's JSON parser couldn't handle, also led to a complete frontend crash. This particular variant was successfully exploited on TikTok, resulting in a payout.

Server-Side DoS: The N+1 Problem

The second, and arguably more impactful, type of DoS discussed is the N+1 problem, a classic database anti-pattern. Carta learned about this from his brother, a backend developer. An N+1 problem occurs when an application executes one query to retrieve a primary set of data, but then, for each item in that primary set (N items), it executes an additional query to fetch related data. This results in N+1 queries instead of potentially just one or two optimized queries.

For example, imagine fetching a list of 100 users, and for each user, the application then executes a separate query to fetch their associated profile details. This leads to 1 (for users) + 100 (for profiles) = 101 database queries, instead of a single join or a batched query.

Exploitation: An attacker can exploit this pattern by crafting a request that triggers an N+1 query. The impact scales directly with the amount of data involved; the more data the attacker can cause the application to retrieve in this inefficient manner, the greater the load on the database and the application server.

Carta describes a straightforward method for exploiting this:

1. Identify a request that, when processed, exhibits characteristics of an N+1 problem (e.g., fetching a list of items with related sub-items).
2. Capture this request in a tool like Burp Suite.
3. Send the request to Burp Intruder.
4. Configure Intruder with a null payload (meaning no specific payload is injected into the request itself, but rather the request is simply repeated).
5. Set the number of concurrent requests to a moderate value, such as 10.
6. Configure Intruder to run indefinitely.

The result of this sustained, concurrent assault on an N+1 vulnerable endpoint is a "complete crash" of the target environment. The application's database and backend servers become overwhelmed by the sheer volume of inefficient queries, leading to resource exhaustion and service unavailability. This technique proved highly lucrative, with Carta reporting that this N+1 exploitation method, across various vulnerabilities, has collectively earned over $46,000, with an additional $10,000 recently added. He specifically credits a collaborator for earning $30,000 from just two N+1 vulnerabilities, demonstrating the significant financial potential of this attack vector.

Demo / Proof of Concept

▶ Watch: Real-world Front-end DOS Case Study Introduction (5:20)

While the talk doesn't feature a live, step-by-step demonstration of an attack, Roni Lupin Carta vividly recounts the discovery and impact of the vulnerabilities, effectively serving as a narrative proof of concept for each.

For the Client-Side DoS, the "demo" begins with an anecdote from a hacking session. Carta and Snorlax were engaged in a friendly competition to find XSS vulnerabilities in a chat application. They were sending various payloads back and forth when, after Snorlax sent a particular message, Carta's web page suddenly went completely blank. Initially, he suspected internet connectivity issues, but Snorlax quickly confirmed his own page had also crashed. This immediate and simultaneous failure for two users interacting with the same application served as a compelling real-world demonstration of the client-side DoS. The subsequent analysis pinpointed the <a href="undefined">Click me</a> payload as the culprit, revealing the undefined.replace() error in the sanitize-html library as the cause of the frontend crash. The direct impact—a blank, unusable page—was the undeniable proof of concept.

For the Server-Side DoS via the N+1 problem, the demonstration is described through the methodology of exploitation. Carta explains that once a suspicious request exhibiting N+1 characteristics is identified, the proof of concept involves a simple, yet potent, setup using Burp Suite Intruder. By configuring Intruder to send 10 concurrent requests with a null payload indefinitely, the resource exhaustion is quickly evident. The speaker states that this method leads to a "complete crash" of the target environment. This implies that the proof of concept isn't merely observing slow responses but rather a full service interruption, confirming the severe impact of the N+1 vulnerability. The financial rewards associated with these findings further validate the efficacy and impact of this DoS vector.

In both cases, the "demo" is less about showing the exact steps on screen and more about recounting the discovery, the observed impact, and the underlying technical mechanism that confirms the DoS condition.

Defensive Implications

▶ Watch: Technical Deep Dive: sanitizeHTML Library Crashing Front-end (6:20)

The vulnerabilities discussed by Roni Lupin Carta highlight critical areas where developers and security teams can bolster their defenses against DoS attacks.

For Client-Side DoS (Frontend Crashes):

• Robust Input Sanitization: Implement comprehensive input validation and sanitization on both the frontend and backend. While sanitize-html was used, the specific flaw (handling undefined incorrectly) indicates that even established libraries can have edge cases. Developers should ensure that all user-supplied content, especially attributes like href, is rigorously validated and transformed into safe, expected formats before being processed by client-side JavaScript.
• Defensive JavaScript Programming: Frontend code, particularly when interacting with potentially untrusted data or third-party libraries, should incorporate robust error handling. Null or undefined checks (if (value) { value.method(); } or optional chaining value?.method()) should be ubiquitous before attempting to call methods on variables that might not be initialized or might receive unexpected types. This prevents single-point failures from crashing the entire application.
• Client-Side Error Monitoring: Implement client-side error logging and monitoring (e.g., Sentry, Bugsnag) to quickly detect and alert on JavaScript runtime errors that could indicate a client-side DoS. This allows for rapid identification and remediation of crashing payloads.
• Use Battle-Tested Libraries and Keep Them Updated: Regularly audit and update all third-party libraries, especially those involved in security-critical functions like sanitization. Be aware of known vulnerabilities (CVEs) in these libraries and apply patches promptly.

For Server-Side DoS (N+1 Problem):

• Identify and Eliminate N+1 Queries: This is paramount. Developers should profile their database queries to identify N+1 patterns. Object-Relational Mappers (ORMs) often provide mechanisms to mitigate this, such as select_related() or prefetch_related() in Django, or eager loading in other frameworks, which allow related data to be fetched in a single, optimized query.
• Performance Monitoring and Profiling: Implement continuous performance monitoring for database queries, application server load, and response times. Tools that can pinpoint slow queries or endpoints exhibiting high database activity are crucial for detecting N+1 issues before they are exploited.
• Rate Limiting and Throttling: Apply intelligent rate limiting to API endpoints, especially those that trigger complex database operations or data retrieval. This can prevent a single attacker from making an excessive number of requests that could trigger an N+1 DoS. Rate limiting should be implemented at the application layer, edge network, or API gateway.
• Load Testing: Regularly conduct load testing and stress testing on applications to identify bottlenecks and potential DoS vectors under high traffic conditions. This can reveal N+1 problems or other resource exhaustion issues that might not be apparent during normal operation.
• Database Query Auditing: Implement auditing for database queries, looking for unusually high numbers of queries per request or queries that are unexpectedly slow. This helps in proactive identification of inefficient data access patterns.
• Resource Isolation and Scaling: Employ cloud-native architectures that allow for automatic scaling of resources (e.g., Kubernetes clusters, serverless functions) and ensure proper resource isolation to prevent one component's failure from cascading across the entire system. While not a direct fix for N+1, it can help absorb some load during an attack.

Ultimately, both types of DoS underscore the importance of secure-by-design principles, where security considerations are integrated throughout the software development lifecycle, from initial design to deployment and ongoing maintenance. Responsible disclosure from bug bounty hunters, coupled with proactive defensive measures, forms the strongest defense against these impactful attacks.

Key Takeaways

• DoS is High Impact and Potentially Lucrative: Contrary to common misconceptions, DoS vulnerabilities can have severe business consequences and offer substantial rewards in bug bounty programs when approached responsibly.
• Prioritize Permission for DoS Testing: Always seek explicit permission from bug bounty programs before attempting any DoS testing, even in non-production environments. This ensures responsible disclosure and avoids unintended disruptions.
• Client-Side DoS Can Cripple User Experience: Frontend crashes, often triggered by unexpected interactions between malformed input and JavaScript libraries (e.g., undefined.replace()), can completely deny service to individual users.
• N+1 Queries are Potent Server-Side DoS Vectors: The N+1 database query problem, an inefficient data retrieval pattern, can be easily exploited with tools like Burp Intruder to overwhelm backend systems and databases, leading to widespread service unavailability.
• Understand CVSS Availability vs. Integrity: Be mindful of CVSS definitions; availability refers to the service's performance and operation, not just data access, which is crucial for accurately reporting DoS impact.
• Defensive Measures are Multi-layered: Mitigating DoS requires robust input sanitization, defensive programming with strong error handling, performance monitoring, aggressive rate limiting, and addressing database anti-patterns like N+1 queries.

About the Speaker(s)

Roni Lupin Carta, who goes by the nickname Lupin, is the co-founder of Lupin Holmes, a security research and development company. Hailing from Grenoble in the French Alps, Carta expresses a particular passion for Denial of Service vulnerabilities, recognizing their potential to significantly impact product environments. He attributes much of the research presented in this talk, spanning a two-year period, to collaborative efforts with fellow accomplished hunters including Rezo, Zax, Hisko, Snorlax, Beefed, Bonsoird, and Donner Hunter. His work focuses on practical exploitation techniques within bug bounty programs, demonstrating that DoS, when responsibly handled, can be a highly impactful and rewarding area of security research.