Sometimes you find bugs, sometimes bugs find you

Sometimes you find bugs, sometimes bugs find you

Speakers: Jasmin Landry JR0ch17, Full-time Bug Bounty Hunter

Conference: DEF CON

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

Overview

In the dynamic world of cybersecurity, the pursuit of vulnerabilities often involves meticulous reconnaissance, advanced tooling, and complex exploit chains. However, as Jasmin Landry (JR0ch17) illuminated in his DEF CON talk, "Sometimes you find bugs, sometimes bugs find you," luck and unexpected discoveries play an equally significant role for bug bounty hunters. Landry, a seasoned professional with a background spanning 12 years in IT and cybersecurity, including a tenure as Senior Director of Information Security at NASDAQ, shared a collection of personal anecdotes where vulnerabilities manifested themselves through unforeseen circumstances.

This talk delves into a series of "weird, funny, or chaotic bugs" that were not the result of targeted exploits but rather serendipitous findings, often triggered by broad, untargeted payload deployments or unusual backend processing. Landry categorizes these discoveries into "Luck," "WTF," and "LOL" moments, showcasing how seemingly innocuous actions or misconfigurations can lead to critical data exposure, remote code execution, or widespread system compromise. The article dissects these fascinating cases, providing a technical deep dive into the most impactful vulnerabilities and outlining crucial defensive implications for organizations.

Background

▶ Watch: Speaker introduction and talk premise (0:00)

Jasmin Landry's journey into full-time bug bounty hunting, a career he embarked on almost a year prior to this talk, followed a distinguished 12-year career in traditional cybersecurity roles. At NASDAQ, he led Application Security (AppSec) teams and oversaw pentesting and red teaming operations, providing him with a robust understanding of enterprise security architectures and common vulnerabilities. This experience, however, also highlighted the limitations of conventional security testing, particularly in uncovering the kind of "chaotic bugs" that often surface in bug bounty programs.

The talk frames these unexpected discoveries against the backdrop of typical bug bounty methodologies. While many hunters meticulously map attack surfaces and craft sophisticated payloads, Landry's presentation emphasizes the efficacy of less precise, yet sometimes highly fruitful, techniques like "spray and pray." This approach involves deploying generic payloads across numerous input fields, often in the hope that one will eventually trigger an alert in an obscure or internal system. Early in his bug bounty career (around 2018-2019), Landry admits to using this method without always identifying his payloads, a practice he has since refined. The talk serves as a testament to the fact that vulnerabilities don't always reside in the most obvious places; sometimes, they lie hidden in legacy code, misconfigured internal tools, or the unexpected interactions between disparate systems.

Key Findings

▶ Watch: Introduction to 'Spray and Prey' blind XSS (3:00)

Landry structured his talk around three categories of bugs: "Luck," "WTF," and "LOL," each representing a different flavor of unexpected discovery.

Luck: These bugs were largely the result of blind XSS payloads finding their way into unexpected internal systems.

1. Cloud Compliance Application - Quicklook CSV Blind XSS: While hunting on a cloud compliance application (designed for SOC 2 or ISO 27001 validation), Landry employed a "spray and pray" strategy with XSS payloads. An alert from XSS Hunter revealed a pop from a peculiar URL containing Xapp QL ID UUID and a screenshot of a CSV file, not a web page. Further investigation of the downloaded DOM (Document Object Model) revealed the string quicklook CSV. Landry deduced that QL stood for Quicklook, a macOS feature for previewing files, and Quicklook CSV was a specific plugin. This plugin, last modified 16 years prior (with the license file updated 8 years ago), was found to be vulnerable. The root cause was internal staff exporting production data (including organization IDs, AWS account IDs, and partial credit card data) and viewing these CSVs on their macOS machines, triggering the blind XSS through the outdated Quicklook CSV plugin. The program acknowledged it wasn't a direct application vulnerability but awarded a P1 bounty and a bonus due to the exposure of PCI-sensitive customer data, highlighting the risk of production data leaving the environment.

1. Hardened Rails Application - Internal Email Blind XSS: On another highly hardened Rails application, Landry again deployed blind XSS payloads. An XSS Hunter pop showed a screenshot of an internal email with the subject "Please investigate customer ID." The email body contained Landry's XSS payload. It turned out that an internal employee, annoyed by Landry's "BS stuff" (fuzzing and payload spraying), had filed a complaint against his account. This complaint, containing the XSS payload, was then rendered in an internal email system, triggering the XSS. This unexpected interaction resulted in a "nice four-digit bounty" and a humorous interaction with the complaining employee on Twitter, who later became a source of tips.

**WTF (What The F\\\*):** These bugs were truly bewildering, with their origins initially unclear to Landry.

1. Live Hacking Event (LHE) Application - Internal Distribution List Access: During a live hacking event with a vast scope, Landry targeted an application requiring employee credentials, which he lacked. After failing to bypass authentication through various methods, including fuzzing, he received an email a week later. His research email (jrocker.com) had been added to an internal distribution list that received new access requests for the target application. This list contained dozens of employee emails and exposed Personally Identifiable Information (PII) from users requesting access, including their addresses and other sensitive details. This PII leakage persisted for about a month, with Landry receiving 4-5 emails daily, despite still being unable to log into the application directly.

1. WordPress Deployment Application - Ansible SSTI to RCE: This was the most complex and impactful finding. Landry, as part of his routine, included a Server-Side Template Injection (SSTI) payload {{7*7}} in his email address during account registration for an application that automated WordPress deployments and provided tools like PHPMyAdmin. Weeks later, while reviewing tables in PHPMyAdmin, he observed his email address rendered with 49 instead of {{7*7}}. This confirmed an SSTI vulnerability. After initial confusion about the template engine, the program revealed its backend stack: WordPress/PHP -> Python serverless API -> Ansible. Landry quickly realized that Ansible uses Jinja2 for templating, which uses the {{...}} syntax.

• Information Disclosure: He first used {{ playbook_dir }} to extract the Ansible playbook directory and {{ expand_vars('SOME_ENV_VAR') }} to extract environment variables, confirming the Ansible context and initial information leakage. This initially earned a P1 bounty, which was then downgraded to P2.
• Escalation to RCE: Driven to escalate, Landry discovered that while email addresses were RFC-compliant on initial registration, they were not validated when changed in the user profile, allowing arbitrary characters. He also noted that parentheses ( and commas , were being filtered. Research into Ansible's Jinja2 templating revealed the lookup plugin, specifically the pipe lookup, which executes shell commands. To bypass the character filtering, he used hex encoding (e.g., \x28 for ( and \x2c for ,). This allowed him to construct an RCE payload like {{ lookup('pipe', 'id\x28\x29') }}. Upon execution, the id command (and later cat /etc/passwd) successfully ran on the backend, revealing that the Ansible process was running as root, elevating the bug back to a P1.

LOL (Laugh Out Loud): These bugs were simply ridiculous in their simplicity or impact.

1. Fantasy Sports Application - Password Stripping: On a fantasy sports application allowing private leagues with passwords, Landry observed that the WAF (Web Application Firewall) performed SSL termination and aggressively stripped XSS-related characters from user inputs. Crucially, this stripping extended to password fields. If a user set a password like "I love <script>dogs," it would be stored as "I love dogs." Worse, if a password started with a stripped character, it could become an empty string. Admins were unaware, and invite emails sent with cleartext passwords would show no password for affected leagues. By simply brute-forcing the first two characters (or just trying an empty password), Landry could join over a thousand leagues, with 56 having no password at all.

1. Perl Password Reset Application - Backtick RCE: A new (2019) self-service password reset application was built using Perl. Landry discovered that inputting id in backticks (` id `) into a field resulted in the command's output being returned in the application's response, confirming a straightforward Remote Code Execution vulnerability. The sheer simplicity and the choice of Perl for a new application made this a truly "LOL" bug.

Technical Deep Dive

▶ Watch: Blind XSS reveals Quicklook CSV vulnerability (4:00)

The most technically profound discovery presented by Jasmin Landry was the Server-Side Template Injection (SSTI) leading to Remote Code Execution (RCE) in the WordPress deployment application. This vulnerability chain illustrates the critical interplay between different technologies and the dangers of insufficient input validation across a complex software stack.

The initial hint of an SSTI vulnerability came from a routine "spray and pray" technique: embedding the payload {{7*7}} within an email address during user registration. This particular payload is a common indicator for template injection, as it leverages mathematical operations that templating engines often evaluate. Weeks later, observing the user's details in PHPMyAdmin, Landry noticed 49 rendered where his email address should have been, confirming that a backend process was evaluating the template expression.

The challenge then became identifying the specific templating engine. The application's core was WordPress (PHP), but the program later clarified that the data flowed through a Python serverless API before reaching Ansible. This revelation was crucial, as Ansible extensively uses Jinja2 for its templating, which aligns perfectly with the {{...}} syntax observed.

Landry's escalation path from basic template injection to full RCE involved several calculated steps:

1. Information Disclosure via Jinja2 Variables: Knowing it was Jinja2, Landry experimented with built-in Ansible/Jinja2 variables. He successfully extracted the Ansible playbook directory using {{ playbook_dir }} and environment variables using functions like {{ expand_vars('SOME_ENV_VAR') }}. This confirmed command execution within the Jinja2 context and revealed potentially sensitive configuration details, leading to an initial P1 rating. However, this was downgraded to P2, prompting further escalation.

1. RFC Compliance Bypass and Character Limitations: The critical observation for RCE was the inconsistent input validation. While the email address field enforced RFC compliance during initial registration, it did not re-validate RFC compliance when a user updated their email address in their profile. This allowed Landry to insert non-standard characters. A subsequent challenge was that specific characters, namely parentheses ( and commas ,, were being filtered or blocked by an unknown mechanism. These characters are often essential for function calls or arguments in many programming contexts.

1. Leveraging Ansible's lookup Plugin: To achieve RCE, Landry investigated Ansible's capabilities. He discovered the lookup plugin system, which allows Ansible to retrieve data from external sources. Crucially, the pipe lookup plugin is built-in and designed to execute shell commands and return their output. A typical usage in an Ansible YAML file would be {{ lookup('pipe', 'date') }}.

1. Hex Encoding for Filter Bypass: To overcome the filtering of ( and ,, Landry employed hex encoding. Since Jinja2 (being Python-based) supports \x escapes for hexadecimal characters, he could represent the blocked characters as \x28 for ( and \x2c for ,. This ingenious bypass allowed him to construct valid pipe lookup commands.

1. Achieving Remote Code Execution: With the pipe lookup and hex encoding, Landry crafted payloads like {{ lookup('pipe', 'id\x28\x29') }} to execute the id command. After successful local testing, he applied this payload to the application's email field via the profile update mechanism. The output in PHPMyAdmin confirmed RCE, revealing that the command was executing as the root user. This elevated the vulnerability back to a critical P1, demonstrating full system compromise.

The Quicklook CSV vulnerability, while less intricate in its exploit, highlights another crucial technical detail: the persistence of legacy software vulnerabilities. The Quicklook CSV plugin for macOS, with its last significant update 8-16 years prior, represented an unpatched, client-side vulnerability. When internal staff viewed production data exports on their machines using this outdated software, the embedded XSS payload triggered. This underscores the risk posed by any component in an organization's ecosystem, even those seemingly outside the "application" itself, especially when handling sensitive data.

The Perl RCE, though brief in explanation, points to a common pitfall in older or less rigorously developed applications. The use of backticks (` command `) in Perl automatically executes the enclosed command and substitutes its output, a powerful but dangerous feature if user input is not properly sanitized. This type of vulnerability, while often associated with older codebases, was found in a product built in 2019, emphasizing that fundamental security flaws can persist even in newer developments.

Demo / Proof of Concept

▶ Watch: Lesson learned: Identifying payloads in blind XSS (7:00)

Jasmin Landry's talk effectively conveyed the practicality of his findings through clear demonstrations and descriptions of his Proof of Concept (PoC) steps.

For the most impactful vulnerability, the Ansible SSTI to RCE, Landry detailed the following PoC:

1. Local Testing of pipe Lookup: He first validated the core RCE primitive locally. This involved executing a simple Ansible command using the lookup('pipe', 'id') syntax to confirm that the id command would run and return its output. This established the feasibility of command execution through the pipe plugin.
2. Local Testing with Hex Encoding: To address the character filtering (parentheses and commas), he then tested the hex-encoded variations locally, such as \x28 for ( and \x2c for ,. This confirmed that {{ lookup('pipe', 'id\x28\x29') }} would successfully execute the id command, bypassing the application's input sanitization.
3. Application-Specific Payload Deployment: The final step involved deploying the RCE payload within the target application. By changing his email address in the user profile (where RFC compliance checks were absent), Landry inserted the hex-encoded lookup('pipe', 'cat\x20/etc/passwd') payload.
4. Verification of RCE and Privilege: Observing the PHPMyAdmin table associated with his user account, he confirmed that the /etc/passwd file content was rendered, demonstrating successful remote code execution. Crucially, the output of the id command revealed that the underlying Ansible process was running with root privileges, a critical escalation that transformed the vulnerability from a P2 to a high-impact P1.

Regarding the Quicklook CSV Blind XSS, the demonstration involved:

1. Local Vulnerability Confirmation: Landry performed a local test of the Quicklook CSV plugin. He installed the plugin (likely via brew install) and confirmed that a specially crafted CSV file containing an XSS payload would trigger the XSS when previewed using Quicklook on macOS.
2. Exploitation Scenario: He then described the real-world scenario where the XSS Hunter payload popped. This was triggered when an internal employee exported production data into a CSV, which unknowingly contained Landry's XSS payload, and then viewed that CSV on their macOS machine using the vulnerable Quicklook CSV plugin. The XSS then exfiltrated sensitive data back to XSS Hunter.

For the simpler "LOL" bugs, like the Perl RCE via backticks, the PoC was inherently straightforward: inputting ` id into the vulnerable field and observing the id` command's output directly in the application's response. The password stripping bug was demonstrated by showing how specific characters would be removed from passwords, leading to weakened or empty credentials.

Defensive Implications

▶ Watch: Beginning of the second bug story: Email XSS (8:00)

The diverse array of vulnerabilities uncovered by Jasmin Landry offers critical lessons for organizations seeking to bolster their security posture.

1. Comprehensive and Consistent Input Validation: The Ansible RCE vividly demonstrates the dangers of inconsistent input validation. While initial registration enforced RFC compliance for email addresses, subsequent profile updates did not. Organizations must implement robust, pervasive input validation across all entry points and all stages of data processing. This includes not only web forms but also APIs, backend systems, and any component that processes user-supplied data. Validation should be consistent throughout the data's lifecycle.

1. Strict Output Encoding: The blind XSS vulnerabilities highlight the necessity of proper output encoding. Any user-supplied data, whether stored in a database or processed by an internal system (like an email client or a legacy file viewer), must be appropriately encoded for its context before being rendered or interpreted. This prevents malicious payloads from executing in unexpected places.

1. Vulnerability Management for Third-Party and Legacy Software: The Quicklook CSV case underscores the often-overlooked risk of third-party and legacy software, even internal tools. Organizations must have a comprehensive program for identifying, inventorying, and patching all software assets, including client-side plugins, operating system components, and internal utilities. End-of-life software, particularly that which handles sensitive data, should be retired or isolated.

1. Principle of Least Privilege: The Ansible RCE's severity was dramatically amplified because the process ran as root. This violates the fundamental principle of least privilege. All applications, services, and automated tasks should operate with the absolute minimum set of permissions required to perform their intended function. Had the Ansible process run as an unprivileged user, the impact of the RCE would have been significantly mitigated.

1. Secure Software Development Lifecycle (SSDLC) for Integrated Systems: Modern applications often integrate numerous technologies (e.g., PHP, Python, Ansible). Each integration point and data transfer between components must be secured. This requires a robust SSDLC that includes security reviews, threat modeling, and testing at every stage, especially when disparate technologies interact. The unexpected flow of data from a PHP/WordPress application through a Python API to an Ansible engine is a prime example.

1. Internal System Security and Data Loss Prevention (DLP): The internal email XSS and the PII leakage via the distribution list demonstrate that internal systems are not an inherent security boundary. External payloads can reach and compromise internal infrastructure. Organizations must apply the same security rigor to their internal tools, email systems, and communication channels as they do to their public-facing applications. Furthermore, robust Data Loss Prevention (DLP) controls and monitoring are essential to prevent sensitive production data from being exported, viewed on unmanaged endpoints, or transmitted outside secure environments without proper controls.

1. Robust WAF/Filter Management: While the fantasy sports app had a WAF that stripped XSS payloads, its misapplication to password fields created a new, critical vulnerability. Security mechanisms, including WAFs, must be carefully configured and tested to ensure they protect against intended threats without introducing new weaknesses or unintended consequences. Overly aggressive or poorly targeted filtering can be just as dangerous as no filtering at all.

Key Takeaways

• Unexpected Attack Vectors are Prevalent: Vulnerabilities often manifest in unforeseen ways, such as blind XSS popping in internal email systems or template injections in email fields that lead to backend RCE.
• Comprehensive Input Validation is Non-Negotiable: All inputs, across all application layers and throughout the data lifecycle, require rigorous and consistent validation to prevent injection flaws. Inconsistent validation, as seen in the Ansible RCE, creates critical bypasses.
• Third-Party and Legacy Software Pose Significant Risks: Outdated or unmanaged third-party components, even client-side plugins like Quicklook CSV, can become critical attack vectors when interacting with sensitive data.
• Adhere to the Principle of Least Privilege: Running backend processes (e.g., Ansible) as root dramatically escalates the impact of any RCE vulnerability, turning a compromise into a full system takeover.
• "Spray and Pray" Can Yield Unexpected Results: While not a primary strategy for targeted attacks, broad payload deployment can uncover vulnerabilities in obscure or internal systems that might otherwise be missed, though it should be done with proper payload identification.
• Internal Systems are Part of the Attack Surface: Do not assume internal applications, email systems, or distribution lists are immune to external payloads. Treat them with the same security scrutiny as public-facing assets.

About the Speaker(s)

Jasmin Landry, known by his handle JR0ch17, is a full-time bug bounty hunter. Prior to dedicating himself to bug bounty, Landry amassed 12 years of experience in IT and cybersecurity. His professional background includes a significant role as a Senior Director of Information Security at NASDAQ, where he was responsible for managing the Application Security (AppSec) team and overseeing pentesting and red teaming operations. A proud French Canadian, Landry is also an avid hockey player and fan, demonstrating a passion for both cybersecurity and sports.