Saving Bug Bounties from AI Slop

Saving Bug Bounties from AI Slop

Speakers: Anto Joseph, Security Engineer, Eigen Labs

Conference: BSides SF

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

Overview

In an era increasingly influenced by advanced artificial intelligence, the traditional landscape of bug bounty programs faces significant challenges, particularly from the proliferation of AI-generated "slop" reports. Anto Joseph, a security engineer at Eigen Labs, delivered a compelling talk at BSides SF titled "Saving Bug Bounties from AI Slop," addressing these pressing issues and proposing a revolutionary, cryptographically-backed solution. This article delves into Joseph's vision for a trustless bug bounty ecosystem, leveraging the power of Zero-Knowledge Transport Layer Security (ZK-TLS) to authenticate vulnerabilities and ensure fair compensation for security researchers.

The core problem Joseph highlights is the erosion of trust and efficiency in bug bounty programs. AI agents can now generate highly convincing, yet often fabricated, vulnerability reports, overwhelming human triagers and increasing verification costs. Simultaneously, researchers frequently contend with issues like underpayment, bug theft, or companies refusing to acknowledge legitimate findings. Joseph's talk introduces a paradigm shift: replacing subjective trust with objective, mathematical certainty through applied cryptography and mechanism design, thereby creating a system where both hackers and companies can operate with verifiable assurances.

This innovative approach not only aims to combat the surge of AI-generated spam but also to rebalance the power dynamics between researchers and organizations. By enabling cryptographically verifiable proofs of vulnerabilities, Joseph's proposed system ensures that legitimate findings receive priority and fair evaluation, while also offering mechanisms for researchers to control the disclosure of sensitive exploit details until a mutually agreed-upon bounty is secured. It represents a significant step towards a more transparent, efficient, and equitable future for the bug bounty industry.

Background

▶ Watch: Introduction and problem: AI slop in bug bounties (0:00)

Bug bounty programs, in principle, offer an elegant solution for improving software security: incentivize external security researchers to find and report vulnerabilities, and reward them for their efforts. However, the reality of running and participating in these programs is often far more complex and fraught with issues. Joseph points out that while the ideal scenario involves a researcher finding a bug, reporting it, and getting paid, the practical execution is frequently marred by systemic problems.

One of the most significant emerging threats is the rise of AI-generated vulnerability reports. Tools like ChatGPT or Claude can now produce sophisticated-looking penetration test reports for non-existent vulnerabilities, leading to a flood of spam. This "AI slop" necessitates human verification, draining valuable resources from bug bounty platforms and security teams. As AI agents become more autonomous, the volume of these automated, low-quality submissions is only expected to increase, further exacerbating the problem.

Beyond AI spam, Joseph outlines several long-standing trust issues that plague the bug bounty landscape. Researchers often face situations where companies:

• Lower the severity of critical bugs, impacting payout.
• Refuse to acknowledge a bug's existence, sometimes patching it silently without credit or payment.
• Steal bugs by incorporating the findings into their internal fixes without compensating the original reporter.
• Disclose private information related to the researcher or the bug without consent.

These issues collectively boil down to a fundamental lack of trust – the "trust me, bro" mentality, as Joseph puts it. Researchers must trust the program to act ethically, which isn't always a safe bet. The core motivation behind Joseph's work is to dismantle this reliance on trust and instead build a system where integrity and authenticity are cryptographically verifiable, removing the need for subjective human judgment in the initial stages of bug validation. This approach seeks to establish a level playing field, ensuring that both parties adhere to verifiable facts rather than opaque processes.

Key Findings

▶ Watch: Understanding Zero Knowledge: The Club ID analogy (4:00)

The central finding and contribution of Anto Joseph's talk is the application of ZK-TLS (Zero-Knowledge Transport Layer Security) to revolutionize bug bounty programs. This technology provides a framework for cryptographically verifiable bug reports, directly addressing the issues of AI spam and trust deficits.

Joseph breaks down the core components underpinning this solution:

1. Zero-Knowledge Proofs (ZKPs): At the heart of ZK-TLS are zero-knowledge proofs. A ZKP is a cryptographic method that allows one party (the prover) to prove to another party (the verifier) that a statement is true, without revealing any information beyond the validity of the statement itself. Joseph uses the analogy of showing an ID at a club: the bouncer only needs to verify age and identity, not your home address. ZKPs enable selective disclosure, proving specific facts (e.g., "I know the pre-image of this hash") while keeping the underlying secret (the pre-image) private. This property is crucial for researchers who want to prove a bug exists without immediately revealing all exploit details.

1. Core Cryptographic Building Blocks: Joseph briefly touches upon the fundamental cryptographic primitives required to construct ZKPs:

• Hash Functions: Essential for data integrity and verification. Joseph specifically mentions Poseidon, a ZK-friendly hash function optimized for performance within zero-knowledge circuits.
• Arithmetic Circuits: A way to translate logical operations into mathematical equations, forming the basis for ZKP computation.
• Elliptic Curve Cryptography (ECC): Widely used in modern cryptography for efficient and secure digital signatures (like ECDSA) and key exchange, also integral to ZK systems.
• SNARKs (Succinct Non-interactive Arguments of Knowledge): A specific type of ZKP that generates very small proofs, which can be verified quickly without requiring continuous interaction between the prover and verifier. This "non-interactive" property is key for practical applications like bug bounty reports, where a single proof can be submitted and verified asynchronously. Joseph specifically mentions Groth16 as a common SNARK proof system.

1. Multi-Party Computation (MPC): ZK-TLS relies on MPC, a protocol that allows multiple parties to jointly compute a function over their inputs while keeping those inputs private. In the context of TLS, this means splitting the symmetric key used for encryption into multiple pieces. Neither party (e.g., the user's browser and the web server) holds the full key, requiring both to participate in the MPC protocol to establish a secure connection. This distributed key management is fundamental to the security guarantees of ZK-TLS, preventing any single party from unilaterally manipulating or faking the TLS session.

1. TLS Notary: Joseph highlights TLS Notary as an open-source project by PSE (Ethereum Foundation) that implements ZK-TLS. This architecture involves three main roles:

• Prover: The security researcher who initiates a TLS connection and wants to prove something about it.
• Notary: A trusted third party (e.g., a bug bounty platform, or even the target company itself) that participates in the MPC protocol with the prover. The notary attests to the authenticity of the TLS session.
• Verifier: The party that receives the ZKP from the prover and verifies its validity (e.g., the bug bounty platform or the company's security team).

By integrating these components, TLS Notary ensures that a TLS session's contents (HTTP requests and responses) can be proven to have occurred with a specific server, without either the prover or the notary being able to unilaterally falsify the communication. This forms the bedrock for trustless bug bounties.

Technical Deep Dive

▶ Watch: Key building blocks for Zero Knowledge Proofs (5:55)

The technical foundation of Joseph's proposal lies in the ingenious combination of Zero-Knowledge Proofs (ZKPs) with the Transport Layer Security (TLS) protocol. This section will elaborate on the mechanics of ZKPs and how they are integrated into TLS to achieve cryptographically verifiable web interactions.

Understanding Zero-Knowledge Proofs

Joseph first illustrates the core concept of ZKPs with a simple, yet powerful, demo using zk-repl.dev. The example demonstrates how to prove knowledge of a pre-image for a given hash without revealing the pre-image itself.

The program, written in a ZKP-friendly language, takes a secret input (the pre-image, e.g., the number 5) and a public input (its hash). It then generates a proof that the prover knows the secret input that results in the public hash.

The steps involved in this demo highlight key aspects of ZKPs:

1. Input and Hash: A secret value (5) is hashed using a ZK-friendly hash function like Poseidon, producing a public hash.
2. Circuit Compilation: The ZKP program, which defines the logic (e.g., assert(hash(input) == public_hash)), is compiled into an arithmetic circuit. This circuit represents the computation in a form suitable for ZKP generation.
3. Proof Generation: Using a SNARK system (specifically Groth16 in the demo), a succinct proof is generated. This proof is a small piece of data that cryptographically attests to the truth of the statement ("I know the pre-image that hashes to this public value") without revealing the pre-image itself.
4. Proof Verification: Anyone can take this proof, the public hash, and the program's public parameters to verify that the statement is true. The demo explicitly shows that tampering with either the pre-image or the generated proof renders the verification invalid, underscoring the cryptographic integrity of the system.

This fundamental capability—proving knowledge without disclosure—is the cornerstone for the "pay to reveal" mechanism in trustless bug bounties.

ZK-TLS: Integrating ZKPs with Secure Communication

Joseph then transitions to ZK-TLS, explaining how the principles of ZKPs are applied to real-world web communication. ZK-TLS is described as a Multi-Party Computation (MPC) protocol that integrates zero-knowledge capabilities directly into the TLS handshake.

The critical innovation here is how ZK-TLS handles the symmetric key established during a standard HTTPS connection. Instead of a single party (your browser) holding the entire symmetric key, ZK-TLS splits this key into two pieces or "shards."

• Party 1 (Prover): Holds one shard of the symmetric key.
• Party 2 (Notary): Holds the other shard.

Because neither party possesses the complete symmetric key, neither can independently decrypt or encrypt the TLS traffic. Both parties must engage in the MPC protocol to collaboratively use the key and establish the TLS connection. This ensures that the entire TLS session, including all HTTP requests and responses, is witnessed and cryptographically attested to by both the prover and the notary.

TLS Notary Architecture

The TLS Notary project, developed by PSE from the Ethereum Foundation, provides a practical implementation of this concept. Its architecture involves:

• The Prover (Hacker): Runs a local Docker container that acts as their client. This container includes the MPC logic and communicates with the Notary.
• The Notary: A trusted third party (e.g., a bug bounty platform or a reputable security entity) that also runs an MPC service. The Notary's role is to attest to the TLS session's authenticity.
• The Server: The target web application (e.g., google.com) that the Prover is interacting with. Crucially, the target server requires no modifications whatsoever; it simply uses standard HTTPS.
• The Verifier: The entity that ultimately receives and checks the ZKP (e.g., the bug bounty platform's automated system or a company's security team).

The workflow is as follows:

1. The Prover initiates a TLS connection to the target server through their local ZK-TLS client (the Docker container).
2. During the TLS handshake, the Prover's client and the Notary collaboratively derive and split the symmetric key using the MPC protocol.
3. The Prover's client then interacts with the target server, and all HTTP requests and responses are effectively "notarized" by the MPC scheme.
4. After the interaction, the Prover's client generates a ZKP that cryptographically proves the contents of the HTTP request and response as witnessed by both the Prover and the Notary.
5. This proof is then submitted to the Verifier. Because the Notary participated in the key sharing, neither the Prover nor the Notary can individually fake the TLS session or its contents. The cryptographic properties ensure the integrity and authenticity of the captured request and response.

This intricate dance of cryptographic protocols ensures that the bug report is not merely a screenshot or text but a cryptographically undeniable record of a real interaction with the target server.

Demo / Proof of Concept

▶ Watch: First ZK program example: Proving hash pre-image (7:00)

Anto Joseph provided a compelling live demonstration of a fully functional bug bounty system, dubbed "Acme Corp," integrated with the ZK-TLS Notary process. This demo showcased the practical application of his proposed trustless bug bounty workflow.

The demonstration followed a typical hacker's journey to finding and reporting a vulnerability:

1. Vulnerability Discovery: Joseph simulated a common web application vulnerability: an authentication bypass. He logged into a test application (similar to Pentester Labs) as a regular user ("test").
2. Exploitation with Burp Suite: He then used Burp Suite, a popular web proxy tool, to intercept and manipulate the HTTP traffic. Specifically, he identified a cookie named auth with the value test. By sending this request to Burp's Repeater and changing the cookie value to admin, he successfully bypassed authentication and retrieved a "flag" (indicating administrative access). This is a classic example of a session hijacking or privilege escalation bug.
3. Generating the ZK-TLS Proof:

• Crucially, instead of taking a screenshot, Joseph navigated to a "TLS Notary" extension within Burp Suite.
• The extension offered two options: "generate a plain proof" or "generate a proof with hiding the request." Joseph chose the latter, demonstrating the ability to selectively disclose information.
• In the background, a Docker container running the TLS Notary MPC client was active. This container participated in the ZK-TLS handshake with the notary service (which would typically be run by the bug bounty platform).
• The system then generated a cryptographic proof. Joseph showed that the "send data" (the HTTP request containing the modified auth=admin cookie) was masked, while the "received data" (the HTTP response containing the administrative "flag") was publicly visible. This generated two versions of the proof: one with the redacted request and one with the full request and response.

1. Submitting the Bug Report (Hacker's Perspective):

• Joseph, logged into the Acme Corp bug bounty platform as a hacker, created a new report titled "Admin auth bypass."
• He attached the redacted proof (the one hiding the request) to the submission. The platform displayed the public response, confirming the presence of the bug, but the crucial exploit details in the request remained hidden.

1. Reviewing the Report (Program Owner's Perspective):

• Logging in as the program owner for Acme Corp, Joseph demonstrated how the platform would display the submitted report.
• The owner could see the cryptographically verified HTTP response, which clearly indicated the vulnerability (e.g., the "flag" for admin access).
• However, the HTTP request, which contained the exact method of exploitation (e.g., auth=admin in the cookie), was still hidden. This confirmed the bug's existence without giving away the "how."

1. The "Pay to Reveal" Flow:

• This is where the mechanism design aspect comes into play. The program owner, confident that a bug exists due to the verifiable response, could then initiate a "pay to reveal" flow.
• The owner would bid an amount (e.g., $5,000) to unlock the full private request.
• Once the company agreed to the payout, the hacker would log back in. The platform would prompt the hacker to upload the full proof (containing both the request and response).
• The system would then cryptographically verify that the newly uploaded full request proof matched the previously submitted redacted proof, ensuring integrity.
• Upon successful verification, the full HTTP request (e.g., the GET request with the auth=admin cookie) would be revealed to the company.
• Finally, the company could proceed with the payment, knowing they have all necessary information to patch the bug, and the researcher is compensated fairly.

This end-to-end demo powerfully illustrated how ZK-TLS and mechanism design can create a transparent and equitable bug bounty process, eliminating AI spam, ensuring verifiable reports, and empowering researchers to negotiate fair compensation for their valuable findings.

Defensive Implications

▶ Watch: Live demo: Generating and verifying a ZK proof (8:15)

The adoption of ZK-TLS for bug bounties presents several transformative implications for organizations and defenders:

1. Elimination of AI-Generated Spam: This is perhaps the most immediate and impactful benefit. By requiring cryptographically verifiable proofs, bug bounty platforms can automatically filter out AI-generated "slop" reports. AI models, while capable of generating convincing text, cannot currently generate valid cryptographic proofs of real-world web interactions. This dramatically reduces the workload for human triagers, allowing them to focus on legitimate, high-quality submissions.
2. Reduced Verification Time and Cost: With cryptographically verifiable proofs, the initial phase of bug validation becomes significantly more efficient. Security teams no longer need to spend extensive time reproducing every reported vulnerability from scratch. The proof itself serves as undeniable evidence that the interaction with their server occurred as described, speeding up the triage and patching process.
3. Enhanced Trust and Researcher Relations: Implementing a ZK-TLS-backed system signals a strong commitment to fairness and transparency. Researchers are more likely to engage with programs that guarantee their work won't be stolen, undervalued, or ignored. The "pay to reveal" mechanism specifically addresses concerns about underpayment and bug theft by allowing researchers to control the disclosure of sensitive exploit details until a fair bounty is agreed upon. This fosters a more collaborative and positive relationship with the security community.
4. No Infrastructure Changes Required for Web Applications: A significant advantage highlighted by Joseph is that the target web applications themselves require zero changes. The ZK-TLS system operates at the network level, leveraging standard TLS/SSL connections. As long as a company's website uses HTTPS (which is a standard security best practice), it is compatible with this system. This removes a major barrier to adoption for organizations.
5. Prioritization of High-Quality Reports: Reports accompanied by cryptographic proofs can be automatically flagged as high-priority. This ensures that genuine, impactful vulnerabilities receive immediate attention, improving the overall security posture of the organization.
6. Clearer Audit Trails: Cryptographic proofs provide an immutable record of the vulnerability discovery process, offering a strong audit trail for compliance and internal security reviews.

In essence, ZK-TLS offers defenders a powerful tool to streamline their bug bounty operations, reduce operational overhead, and build a more robust and trustworthy relationship with the global security research community, ultimately leading to more effective vulnerability management.

Key Takeaways

• AI-generated "slop" reports and inherent trust issues (underpayment, bug theft) are significantly degrading the efficiency and fairness of traditional bug bounty programs.
• Zero-Knowledge Transport Layer Security (ZK-TLS) provides a novel, cryptographically verifiable solution to these problems, moving beyond subjective trust to objective proof.
• Zero-Knowledge Proofs (ZKPs) enable security researchers to prove the existence of a vulnerability (e.g., a specific HTTP response) without immediately disclosing the full exploit details (e.g., the exact HTTP request).
• The TLS Notary architecture, utilizing Multi-Party Computation (MPC), ensures that HTTP requests and responses witnessed during a TLS session are authentic and cannot be unilaterally faked by either the researcher or the notary.
• A "pay to reveal" mechanism allows researchers to negotiate fair compensation by controlling the disclosure of sensitive exploit information until a bounty is agreed upon, combating lowballing and bug theft.
• Crucially, target web applications require no modifications to integrate with this system, as it operates by leveraging standard HTTPS connections.

About the Speaker(s)

Anto Joseph is a Security Engineer at Eigen Labs, a company focused on distributed systems, applied cryptography, mechanism design, and deep learning (now referred to as AI). With a diverse background in security engineering, he has previously held positions at prominent technology companies such as Coinbase, Tinder, and Intel. His work at Eigen Labs, combined with his prior experience, positions him uniquely at the intersection of advanced cryptography, AI, and practical security challenges. Joseph is actively engaged in research, particularly in improving the latency of MPC schemes and exploring other advanced cryptographic techniques like Fully Homomorphic Encryption. He has made the materials for his talk publicly available on GitHub.