One Request to Kill Them All: Amplification, Data Landmines and Parser Killers - Patrik Jokela

One Request to Kill Them All: Amplification, Data Landmines and Parser Killers

Speakers: Patrik Jokela (Queso)

Conference: Disobey

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

Overview

Patrik Jokela, also known as Queso, delivered a compelling presentation at Disobey, dissecting the often-underestimated threat of application-level denial of service (DoS) attacks. Titled "One Request to Kill Them All," the talk provided a practical and in-depth exploration of how seemingly innocuous application misconfigurations and design quirks can be weaponized by attackers to bring down services with minimal effort. Jokela, an offensive security researcher recently joined Cipherix, demonstrated six distinct attack vectors, categorizing them under a "kill vector model" that includes response size amplifications, data landmines, and parser killers.

The central thesis of the talk is that these application-level DoS attacks represent a significant risk due to their low cost and high impact for adversaries. Unlike traditional network-level DoS, which often requires large botnets and massive traffic volumes, application-level attacks can be executed with just a few carefully crafted requests. This makes them exceptionally difficult for conventional defensive layers to detect, as they often blend in with normal application usage patterns until the service suddenly collapses. For organizations, especially those reliant on online presence like e-commerce companies, such outages lead to immediate financial losses, erosion of customer trust, and costly recovery processes.

Jokela’s presentation serves as a crucial wake-up call for developers and security professionals, highlighting the subtle yet devastating vulnerabilities that can exist within modern web applications. By showcasing real-world examples, often discovered through bug bounty hunting and penetration testing, he underscores the importance of rigorous input validation, careful error handling, and comprehensive resource management at the application layer. The talk not only exposes these attack methodologies but also provides actionable defensive strategies to mitigate these potent threats before they can be exploited by malicious actors.

Background

▶ Watch: Talk introduction and speaker's background (0:00)

Application-level denial of service attacks differ fundamentally from their network-level counterparts. While network DoS aims to overwhelm infrastructure with sheer volume (e.g., SYN floods, UDP amplification), application-level DoS targets specific application logic, resource consumption, or parsing mechanisms. These attacks exploit vulnerabilities that cause the application to consume excessive CPU, memory, or I/O resources when processing a seemingly small or malformed request, leading to service degradation or complete unavailability. The talk emphasizes that these are not about "spamming targets with millions of requests" but rather "utilizing different application misconfigurations and all the small quirks that the application might have."

The motivation for attackers to pursue application-level DoS is clear: it’s low cost, high impact. An attacker doesn't need a botnet; a single, well-crafted request can be enough to severely disrupt or even crash an enterprise-scale application. From a defender's perspective, these attacks are "much harder to detect by any defensive layers" because they don't manifest as "massive spikes of incoming requests." Instead, they appear as "normal application usage," making traditional volumetric DoS mitigation techniques ineffective. The consequences for businesses are dire, including direct financial losses for e-commerce sites, reputational damage, and a costly, time-consuming recovery process that involves identifying and patching the specific vulnerability.

Jokela introduces a kill vector model to categorize these diverse attack types into three primary groups:

1. Response Size Amplifications: These occur when a single, often small, user input triggers the application to generate a disproportionately large response. The amplification ratio can turn a few bytes of input into tens of megabytes of output, consuming server resources and bandwidth.
2. Data Landmines: This category involves building up a massive data payload incrementally through multiple, separate requests. The "landmine" is then "triggered" by a single subsequent request that attempts to load all of this accumulated data at once, leading to resource exhaustion.
3. Parser Killers: These attacks exploit the behavior of parsers (e.g., JSON, XML, Regex engines) when confronted with unexpected or specially crafted input. Malformed input can cause parsers to enter inefficient states, consume excessive processing power, or trigger verbose error messages that then become amplification vectors.

This model provides a structured approach to understanding and identifying these often-overlooked DoS attack surfaces, laying the groundwork for the detailed technical deep dive into specific cases.

Key Findings

▶ Watch: Introduction to the Kill Vector Model categories (4:30)

The presentation showcases six distinct cases, each illustrating a different facet of application-level DoS, categorized under Jokela's kill vector model. The overarching theme is the critical importance of robust input validation, output limiting, and careful error handling to prevent resource exhaustion and service disruption.

Under Response Size Amplifications, Jokela demonstrates:

• An empty response explosion in a CTE 5G router, where unauthenticated input of commas (3.5 million commas) amplified a 1-character input into a 12-character output, leading to a 19-20MB response and a router reboot.
• An HTML encoding reflection vulnerability in a login screen, where a failed login reflected the user's email five times, and HTML encoding of special characters (e.g., " becoming ") further amplified the response. A payload of 1 million quotation marks resulted in a 30MB response and a 502 Bad Gateway error.
• A GraphQL error-based amplification, exploiting verbose error messages for unused variables. By combining 100 unused variables with an extremely long operation name (800,000 'a's), the server was forced to generate an estimated 80MB response, leading to a 502 Bad Gateway and total server takedown.

The Data Landmines category featured:

• An unlimited saved user input vulnerability in an API that allowed users to create API keys with arbitrary names and unlimited length. Creating 800 API keys each with 100,000 'a's as names, and then fetching them with a single GET request, resulted in an 80MB response and a 502 Bad Gateway, effectively taking down the service.

Finally, Parser Killers illustrated:

• An error-based DoS in a messaging API, where malformed JSON input ([1,1,...]) triggered verbose error messages. Each 2-character input (1,) was amplified into a 61-character error message, leading to a 9MB response from 300,000 ones and commas and causing server hiccups.
• A Regex DoS vulnerability, where a poorly constructed email validation regex was susceptible to catastrophic backtracking. Using the redos checker tool, an attack string with 50 underscores was shown to increase response delays from milliseconds to 19 seconds, ultimately leading to a complete server takedown.

Across all cases, the common threads were a lack of input validation (length and character limits), verbose and unconstrained error messages, and insufficient resource management, all of which could be exploited with minimal attacker resources for maximum impact.

Technical Deep Dive

▶ Watch: Case Study 1: ZTE 5G router response amplification (6:00)

Jokela meticulously dissected six distinct application-level DoS vulnerabilities, providing a detailed look at their exploitation and impact. Each case highlights a different vector, demonstrating the breadth of this attack surface.

Response Size Amplifications

1. Empty Response Explosion (CTE 5G Router)

The first case targeted a CTE 5G router with an unauthenticated endpoint, /modem_main_state, accessible on the local network. This endpoint allowed querying the router's status using a query parameter. A normal request might look like query=modem_main_state,pin_status, returning a simple 0.

Jokela discovered that by introducing extra commas, such as query=modem_main_state,,pin_status, the server interpreted these as additional, empty queries. Each empty query resulted in a 12-character response segment. This established a 1-to-12 amplification ratio for each extra comma.

To demonstrate impact, a payload of 3.5 million commas was sent. This forced the router to generate a response of approximately 19-20 megabytes of data, which took 42 seconds to return. During this processing time, the response delays for normal requests to the router escalated dramatically, from a baseline of 400 milliseconds to 10-20 seconds. Sending three such requests in quick succession caused the router to exhibit "Christmas tree" blinking lights, become unresponsive, and ultimately reboot itself, confirming a full denial of service. The vulnerability stemmed from the lack of input length validation and the application's inefficient handling of empty query parameters, resulting in excessive resource consumption. This issue was reported and received a CVE, though the specific ID was not mentioned in the talk.

1. HTML Encoding Reflection (Login Screen)

This scenario involved a common login screen feature: when a user enters an incorrect password, their email address is reflected back into the input field for convenience. While seemingly benign, Jokela found that the target application reflected the user's email five times within the HTML response.

The critical detail was the application's HTML encoding mechanism. Special characters, like a double quotation mark ("), were encoded into their HTML entity equivalent, ". This means a single character input (") became a six-character output (").

Combining these two factors, each quotation mark in the email input was reflected five times, and each reflection was HTML-encoded. This created a powerful 1-to-30 amplification ratio (1 character input 5 reflections 6 characters per encoding = 30 characters output).

An email address containing 650,000 quotation marks was submitted. This generated a 19.5 megabyte response after a 25-second delay. Pushing the payload to 1 million quotation marks resulted in a 30-megabyte response, which ultimately caused a 502 Bad Gateway error, rendering the login page and potentially the entire service inaccessible. The vulnerability was attributed to the absence of input length limits for the email field and the excessive, unconstrained reflection and encoding within the response.

1. GraphQL Error-Based Amplification

GraphQL's helpful nature, specifically its verbose error messages, was weaponized in this case. When an invalid query or unused variable is provided, GraphQL typically responds with informative error messages. For example, a query like query aaa($b: String, $c: String){} would generate errors stating "variable b is never used in the operation aaa" and "variable c is never used in the operation aaa."

Each new, unused variable (e.g., $b: String) added approximately 7 characters to the input and produced an error message of 101 characters, yielding an initial 1-to-14.4 amplification. The key discovery was that the operation name (e.g., aaa) was reflected in every error message. GraphQL, by default, allows up to 100 error messages to be returned in a single response.

The attack combined these insights: 100 unused variables were included in the query, along with an extremely long operation name consisting of 800,000 'a' characters. This forced the GraphQL server to reflect the 800,000-character operation name 99 times (as the 100th message would be a "maximum errors reached" notification).

The expected response size was around 80 megabytes. Upon sending this request, the server timed out after 60 seconds, returning a 502 Bad Gateway error. Subsequent attempts to interact with the application resulted in 504 errors, indicating a total takedown of the server. This vulnerability underscored the danger of verbose error messages and the lack of limits on input length, particularly in powerful query languages like GraphQL.

Data Landmines

1. Unlimited Saved User Input (API Keys)

This type of attack leverages the ability to store vast amounts of data incrementally, which is then retrieved in a single, resource-intensive operation. The specific case involved an API endpoint for creating new API keys, where users could assign a custom name to each key.

The critical flaws were two-fold:

• There was no limitation on the amount of API keys a user could create.
• There was no limitation on the length of the name provided for each API key.

The attacker exploited this by creating 800 API keys, each with a name consisting of 100,000 'a' characters. This process involved 800 separate POST requests to create the keys.

The "landmine" was then triggered by a single GET request to retrieve all API keys associated with the user. This single request forced the server to fetch and return all 800 keys, including their extremely long names. The resulting response was approximately 80 megabytes.

This single GET request caused a 60-second timeout and a 502 Bad Gateway error, effectively rendering the service unavailable. Jokela emphasized the danger of allowing unlimited storage and retrieval of user-controlled data, especially when length limits are not enforced.

Parser Killers

1. Error-Based DoS (Messaging API)

This case targeted a messaging API that expected a JSON array of dictionaries, each containing text and id fields (e.g., [{text: "hello", id: "123"}]). Jokela discovered that submitting a malformed input, such as [1], would trigger a verbose error message from the parser: "value is not a valid dictionary."

Similar to the GraphQL case, the error message itself became an amplification vector. By submitting an array like [1,1,1,...], each invalid element (effectively 2 characters: 1,) generated a 61-character error message. This resulted in a 1-to-30.5 amplification ratio.

A payload consisting of 300,000 ones and commas was sent. This forced the server to construct a response of approximately 9 megabytes. While this didn't immediately cause a full takedown, it led to noticeable "hiccups" in the service, with some normal requests failing with 502 errors. The crucial detail here was that the initial request size was only 0.3 megabytes, well below the typical 1-2 megabyte default request size limits, allowing the attack to bypass initial defenses. This demonstrated that even short-period DoS or service degradation can be achieved through parser errors, which can be scaled up for a full takedown.

1. Regex Denial of Service (Email Validation)

The final case involved a Regex DoS vulnerability. Jokela found a company's application configuration file that exposed an email validation regex. Using the redos checker tool, he was able to quickly identify that this regex was vulnerable to catastrophic backtracking and generate an attack string.

The attack string consisted of a series of underscores (_). A baseline request with 1 underscore resulted in a 500-millisecond response delay. This delay progressively increased with the number of underscores:

• 10 underscores: 1.3 seconds
• 40 underscores: 5 seconds
• 42 underscores: 19 seconds (entering the "danger zone")

The critical point was the exponential increase in processing time. By increasing the input length by a tiny margin, specifically to 50 underscores, the server completely failed, responding with "cannot get availability information from external system." This demonstrated a total server takedown caused by a single, carefully crafted input exploiting a vulnerable regex. The talk highlighted how a seemingly minor difference in input length can lead to a massive increase in resource consumption due to backtracking, making regex DoS a potent and often overlooked threat.

Demo / Proof of Concept

▶ Watch: Demonstrating the 1 to 12 character amplification bug (7:30)

Throughout the presentation, Patrik Jokela provided compelling demonstrations and proofs of concept for each of the six attack vectors. These were not merely theoretical explanations but live (or pre-recorded, as indicated by wait times for responses) showcases of the attacks in action. For each scenario, Jokela presented the raw HTTP request being sent and the subsequent response from the server.

The demonstrations visually reinforced the technical explanations:

• For the CTE 5G router, the audience saw the long delay of 42 seconds before the 19-20MB response was received, followed by the dramatic "Christmas tree" effect of blinking lights and the eventual reboot of the router after multiple requests.
• The login page amplification demo clearly illustrated the 25-second delay for the 19.5MB response and the ultimate 502 Bad Gateway message after the full 1 million quotation mark payload.
• The GraphQL error-based attack showcased the 60-second timeout and subsequent 502 Bad Gateway and 504 errors that users would experience, demonstrating a complete service outage.
• The data landmine demonstration similarly highlighted the 60-second timeout and 502 Bad Gateway after a single GET request triggered the retrieval of 80MB of accumulated data.
• For the messaging API parser killer, the demo showed a 9MB response and the resulting 502s for other background requests, indicating service hiccups.
• Finally, the Regex DoS was powerfully demonstrated by showing the exponential increase in response delays from milliseconds to 19 seconds with just a few more underscores, culminating in the server's inability to provide availability information.

Jokela emphasized that most of these tests involving full DoS were conducted in testing or staging environments after initial reporting to the respective companies. This responsible disclosure approach allowed the full impact to be verified without harming production systems. The visual evidence of server timeouts, error pages, and even physical device reboots provided undeniable proof of concept for the devastating potential of these application-level DoS attacks.

Defensive Implications

▶ Watch: Full impact: 3.5 million commas cause DoS (8:30)

The detailed analysis of these application-level DoS vectors provides crucial insights for defenders. Patrik Jokela outlined several key defensive takeaways, emphasizing a proactive and thorough approach to application security:

• Enforce Length and Amount Limits on All User Input: This is perhaps the most fundamental defense. As seen in the router, login page, GraphQL, and data landmine cases, the ability to submit excessively long or numerous inputs directly led to resource exhaustion. Implement strict character limits for all text fields (emails, names, query parameters) and quantity limits for repeatable elements (e.g., number of API keys, array elements).
• Limit Error Message Lengths or Avoid Verbose Error Messages: Verbose error messages, particularly in GraphQL and parser-based scenarios, were repeatedly exploited as amplification vectors. While helpful for debugging, these messages should be sanitized, truncated, or replaced with generic messages in production environments to prevent information disclosure and DoS amplification.
• Use Pagination or Enforce Result Limits: For APIs that fetch collections of data, it is critical to implement pagination and enforce strict limits on the number of results returned per request. This prevents "data landmine" scenarios where an attacker can store massive amounts of data and then retrieve it all at once with a single GET request, overwhelming the server.
• Implement Complexity Limits on Regular Expressions: Regex DoS is a silent killer. Developers must be aware of the potential for catastrophic backtracking in complex regular expressions. Tools like redos checker should be used during development and testing to identify vulnerable regex patterns. Consider using safe regex libraries or simpler, non-backtracking alternatives when possible.
• Implement Circuit Breakers and Timeouts: Applications should be designed with resilience in mind. Circuit breakers can prevent cascading failures by quickly failing requests to an overloaded service. Implementing strict timeouts for request processing ensures that a single long-running request (like those causing a DoS) does not consume resources indefinitely, allowing other requests to be processed or the service to recover.
• Proactive Security Testing: "What's the most expensive request I could make right now?": Developers and security teams should actively ask this question during design and testing phases. This encourages thinking like an attacker and identifying potential resource-intensive operations that could be abused. This includes fuzzing input fields, testing edge cases with large payloads, and monitoring resource usage under stress.

By adopting these defensive strategies, organizations can significantly reduce their exposure to application-level DoS attacks, safeguarding their services from the "one request to kill them all."

Key Takeaways

• Application-level DoS is a high-impact, low-cost threat: These attacks exploit application logic and misconfigurations, requiring minimal resources for attackers but causing significant disruption for defenders.
• Input validation is paramount: Unrestricted input length and quantity for user-supplied data (e.g., email addresses, API key names, query parameters) are a common root cause for amplification and resource exhaustion.
• Verbose error messages are a significant risk: While helpful for debugging, unconstrained and verbose error messages can be easily exploited as amplification vectors, turning small inputs into massive responses.
• Uncontrolled data storage and retrieval creates "landmines": Allowing users to store unlimited amounts of arbitrary-length data, and then fetch it all with a single request, is a critical vulnerability for resource exhaustion.
• Regex complexity can lead to catastrophic backtracking: Poorly constructed regular expressions can cause exponential processing delays with specific inputs, leading to a denial of service. Tools and careful design are essential.
• Proactive testing and robust architectural controls are vital: Defenders must actively probe for expensive requests, implement strict timeouts, pagination, and circuit breakers, and continuously monitor resource usage to identify and mitigate these subtle but powerful DoS vectors.

About the Speaker(s)

Patrik Jokela, known by his handle Queso, is an offensive security researcher with a strong background in penetration testing and red teaming. He recently joined Cipherix, a company he believes possesses top-tier backend talent for pentests, offering a unique combination of backend mentality with offensive security services. Prior to Cipherix, Patrik spent six years at Insta, where he honed his skills and contributed significantly to the company. His professional interests extend to various facets of offensive security, including bug bounty hunting, malware research, and the development of cutting-edge malware for red team engagements. Patrik's expertise lies in uncovering and exploiting subtle application-level vulnerabilities, as demonstrated in his detailed and practical presentation on denial of service attacks.