BSidesSF 2026 - Saving Bug Bounties from AI Slop (Anto Joseph)

By far the best part of besides is our speakers and presentations. Here to present saving bug bounties from AI slop is Anto. All right. Uh can you guys hear me okay? Awesome. Uh So, I'm Anto Joseph. Uh I am a security engineer at Eigen Labs. Uh we work on distributed systems, applied cryptography, mechanism design, and deep learning. It used to be called that, now it's AI. Uh Uh previously I was I was a security engineer at like Coinbase, Tinder, Intel, uh all over the place. And uh you can find uh all the material of my talk at this GitHub link. Uh Yeah, let's get into it, right? Uh I'm sure you all are familiar with uh

bug bounties, right? Uh anyone who is not familiar with what a bug bounty is? Yeah, you find a bug. Okay, so you find a bug on the internet and uh you report it uh to the company that has the bug and then you earn money for it, hopefully, right? This is the case where everything goes right. Uh you you spend your time, you find the bug, and they pay you. Sounds great. But in reality, it's a lot more complicated, right? Uh sometimes with AI, you you can ask ChatGPT or Claude to like go hack xyz.com and it will give you like a super nice report of how they hacked the thing and it will look very legitimate, like a

proper pentest report, and you would send this uh to like HackerOne or like Bugcrowd or any of these like bug bounty platforms. And then a real human being takes time out of their day to like verify if it is true or not. And with with the with the AI agents, it's it's even better, right? Like we get like lots of spam now because it's all automated. We got like the Claude bot and like all all the agents that you could think of that is now submitting reports to uh these bug bounty platforms. So, the spam uh is just going to go up cuz the incentives are like if you actually find a bug, you make money, so

why not, right? Uh But there are side effects to this. Uh this costs verification time. Uh and uh there are other effects uh like a bug bounty program uh when not run right uh maybe you find a RCE, but like the company that you reported to like lowers the severity, right? It has happened. And uh uh sometimes they just like completely refuse to acknowledge the existence of a bug after they patch it. Has happened. Uh stealing bugs uh has happened. And uh private information disclosure uh has also hap- happened. So, what we're trying to do here is to like remove this whole trust me, we'll do the right thing. That is how a bug bug bounties work, right? You trust the

program to do do the right thing and uh hopefully not uh s- s- like, you know, underpay you or steal your uh work. So, if you can remove trust and make everything cryptographically verifiable, then you don't have to trust anyone, which feels like a better solution than trust me, bro, right? So, uh how how we go about doing that is with applied cryptography and some mechanism design. We get trustless coordination. So, let's actually uh see what are the building blocks to build a solution for this. So, one of the core technologies we can use to solve this problem is is a is a technology called ZK-TLS. Uh ZK stands for zero knowledge. Uh TLS is transport layer security. We all are

familiar with HTTPS, right? Same thing. So, what is zero knowledge? It's a cryptographic method that allows one party to prove a statement is true without revealing any underlying data. So uh this is something that we all come across, right? Uh you want to go to a club, you have to show your ID. It reveals more than what the bouncer needs to know to get you in, right? They just need to make sure the ID, the picture looks like you, and you are above 18 or like 21, right? But it has your home address, uh it has a lot more information in there, which he doesn't need to know to let you in. So, zero knowledge has other properties

uh like it can hide the information that you wish, but still prove that you are still the owner behind this ID. So, think of it as putting masking tape on on the information that the bouncer doesn't need to know. Like he doesn't need your home address, but you can he can still verify the ID uh by looking at the picture and uh if the age is above a certain number, he can let you in, right? So, that is how you can like build some intuition on like what zero knowledge is. You can only disclose what you absolutely need to disclose, but the verifier can verify it cryptographically. So, that is one of the things that you can

do with ZK. Have information be private and only disclose what what needs to be disclosed, and it becomes cryptographically verifiable for the party that needs to verify it. So, a bunch of components, right? Needs to be put together to make a zero knowledge proof. Uh so, we are all familiar with hash functions, right? So, it's I'm not going to go into what a hash function is. Uh it's pretty straightforward. Uh what is an arithmetic circuit? So uh it's it's a way of translating logic into math. Uh like on your right, you can see uh some scary-looking symbols. It's essentially just a for loop, right? So, it's not that scary. Uh elliptical cryptography, right? Like it's very important. We use it every

day. Your browser uses it every day to make uh ECDSA's signatures and like connect to websites, all that. So, we make use of that. It has in very interesting properties. And uh SNARKs. Uh this is very close to zero knowledge. Uh this is uh you you can expand it as succinct non-interactive arguments of knowledge. What that essentially means is that it can make very small proofs relatively in size and can prove that something exist without going back and forth with with the prover and the verifier. It can be done with just one proof. You don't have to like go back and forth. So, this is like one of the state of state of the technologies in the ZK

world. So, what does it look like, right? So, this is a ZK program. Uh does anyone know uh from uh from this snippet what what what it's trying to do?

It's not like the easiest programming language out there, right? [laughter] Yeah, go for it. Prove that you know the pre-image. Yeah. Exactly. So, it's this program is trying to prove that I know the pre-image of a hash function. So, like we have MD5, SHA hashes, uh there is a ZK-friendly hash function called Poseidon. And this uh program proves that I know the pre-image of the input, right? So, we can actually try it out.

So, this is uh something you can try today. If you just type in zk-repl.dev, uh you can open this up and you can like copy-paste this. Uh So, here is my input. My input uh the actual message is five. And the hash of five is is this this large number, right? And I want to prove that this is true. So, to do that, you can do shift and uh shift return, and it compiles, right? If I try to like change a change something here and generate a proof, and you can see the assert failed on your on your right. Okay. So, what's the point of all this, right? Once once you do do it correctly,

you can generate a proof system. You can see there's a Groth16, it's a proof system, and it would look something like this. So, it this doesn't just work for five. It can work for six, it can work for whatever arbitrary input, as long as you know the input and the pre-image, you can generate a proof right here. So, let's make sure I have the right numbers in here. You see I was able to generate a proof and I can share this proof with anyone. This this bit right here is the proof. Right? And this is the pre-image. So, now I can verify. And it says the proof is valid. So, just by disclosing just by creating a proof, this proof

right here, I can prove that I know the pre-image to this hash. Isn't that cool? Like, can you think of a way to prove to someone that you know the pre-image of a hash without disclosing the pre-image? Right? I mean, this is how like rainbow tables work, right? Like, you got to build an entire business off of just off of this. Right? Like, you try to like crack a hash and then you pay someone, but you don't know if they actually know the password. You're just going to hope and pray, right? This technology right here, just this simple demo, is enough to disrupt that industry. I don't recommend doing that, but >> [laughter] >> Yeah. So, everyone got the idea, right?

We have the hash and we know that you cannot go from hash to pre-image. But, if I change phi here and I want to generate a proof because I'm trying to like fake it, right? And see if I can generate a proof, you can see it fails. So, you cannot generate a fake proof. Even if you try to like mess with the proof, so like, you know, I'm just going to Okay, this is the proof right here, right? So, I'm just going to make some edits here. Sneaky edit. I'm changing it to six. And then see verify, proof is invalid. So, if you mess with the proof or with the pre-image, things are going to fail.

So, you can trust that cryptographically the system is secure as long as, you know, the underlying assumptions hold. Okay. So, in that demo, we we know that zero knowledge is very powerful. It allows you to like prove things without disclosing things, right? Now, >> [laughter] >> let's let's go let's go to ZK-TLS. How do we use all that at with ZK-TLS, right? So, ZK-TLS is a MPC protocol, a multi multi-party computation that integrates zero knowledge with the TLS communication. So, simply put, every TLS connection that you make ultimately requires like a symmetric key between you and the server. Now, imagine splitting up that symmetric key into two pieces. And the MPC is literally that, right?

Multi-party communication. Computation. So, I'm I'm party one. Maybe we have a party two there. We both have to be in this dance so we can make a TLS connection because none of us have the full symmetric key. That is that is really what ZK-TLS is. We instead of your browser holding onto that symmetric key that allows it to like make a full HTTPS connection, you split that symmetric key up into two pieces. I hold onto one. And the server hold ons to the other part. Now, we made it impossible for one party to just make that connection because you don't have the symmetric key, you cannot make a TLS connection, right? Both parties have to use this MPC protocol to

like talk to each other and then they can use the symmetric key because they both have like shards of the symmetric key, right? It's a popular concept in applied cryptography, multi-party computation. So, if this is too much, you can definitely like YouTube it, Google it. It's it's simple as like instead of holding onto one key, you split it up into multiple parts so it's safe and secure, right? Like cuz one key can do a lot of damage. And one of the projects that implement ZK-TLS, it's open source. It's by PSE from Ethereum Foundation. It's called TLS Notary. And this is the architecture of how TLS Notary works. And you can see that MPC is in a box, so

you don't have to like really worry about it. It's a Docker container. You just like run that thing and it does all the all the cryptography bits. We have the server. So, imagine I want to prove that I connected to google.com and I got the home page, right? So, that is the server part. And the verifier is the one that wants to verify that I indeed connect to google.com and I got a response. So, this is the verifying party. And now we have two entities, right? Within the MPC scheme. At the notary. Notary is literally attest to things. So, this can be run by a trusted party. It could be run by a by a bug bounty platform or like google.com

or anyone with some reputation. And the prover, that is you. You are the one who is trying to prove that you did visit google.com, right? So, once we have the setup, you should be able to prove that I did go to google.com and the notary will attest that yes, he did do that because the notary and the prover is in this MPC scheme. So, and that that that makes it impossible for prover to fake things or the notary to fake things because they cannot change things in the TLS session because they don't hold the full key. That is the trust assumption for TLS Notary. So, now you can see where I'm going with this, right? With this kind of a system,

you can make trustless bug bounties. So, this is your typical workflow. A hacker finds a SQL injection. They attest to this HTTP request and response using the TLS Notary server. And they post the proof to the bug bounty platform. They don't post screenshots. They post cryptographically verifiable proofs. Cuz screenshots, as you know, with the latest AI, you can you can do whatever, right? So, if screenshots are not like valid anymore. And once the platform can automatically verify this cryptographic report. And these reports get priority over reports with no cryptographic proof because you know that they did happen because it's cryptographic. You cannot fake that. AI cannot break cryptography yet. Right? Okay. And there is an optional flow and

this is the interesting bit. You can prove that this you can prove just the HTTP response. So, imagine a SQL injection, right? The output would be like contents on a database. So, just by disclosing the HTTP request response, you can prove that I was able to do an S SQL injection, but they still don't know how I did it. So, now we can establish a price on the bounty right? So, now we are in like equal footing with with this company that wants to understand how I did it. Before, you are at the mercy of the company and hopefully they'll pay you, right? Now, you just prove you just prove that they have a bounty.

They have a bug with this SQL injection HTTP output. But, the request is still hidden. And once they agree to like a certain amount, you can also upload the HTTP request and the system make sure makes sure that the HTTP request that you later uploaded cryptographically cryptographically ties into like the earlier proof that you uploaded. So, let's do a demo, right? So, I white coded HackerOne yesterday. >> [laughter] >> No, I I really did. So, let's do it, right? >> [laughter] >> So, this is a full-on actually working bug bounty system. And this is Acme Corp and they have they host a bunch of bug bounties, right? And uh Acme Corp has like a crypto bug bounty.

And you know, you can you can see everything there is and it's a leaderboard and a dashboard. All the bugs that that that is submitted. So, as a let's log in as a hacker. It has working authentication, too. Yeah. Okay. Yeah. So, you know, you can like report bugs like usual, right? Like, you find a program and let's say Acme got bug bounty program submit a report, right? Like you type in all the fun stuff. So, let's actually go find a bug. So, we have like this is I believe Pentester Labs. So, you know. Uh yeah. We log in as test and uh we open up Burp Suite.

You can see like, you know, this is your usual workflow, right? You open up Burp Suite like you want to hack this thing. And uh uh you can see that there is a cookie called auth test. You change it. So, what do you do? Go to send to repeater. You change it to admin send if Wi-Fi works. Yes. You You have the flag right? Now, you want to prove that you did get the flag. So, what do you do? Go into Go to extensions TLS notary. You have this option generate a plain proof generate a proof with hiding the request. Let's do that. So, it we have a Docker container running in the background which has

all the goods. And then it generates a proof. You can see that the send data is masked. Right? Like we don't know we are masking the send data, but the received data has the has the flag right? Okay. And you open up the proof. So, you have two versions of the proof. One is the redacted request and one is the uh request with the response. Right? So, uh let's let's submit this bug. Admin auth bypass. Yeah, please don't do that. Running out of time, so I'm just going to Okay. So, I upload this proof. So, I attach proof. So, I attached the proof. And you can see uh you know, the response is out here.

But the request is hidden. Right? And now I log in as the program owner. And you can see the request. See programs.

So, here is the uh request. Uh here is the response. Let me

So, here is a example of a request, right? So you can like see that there is a request here. This is a response. Everything is like, you know, you can see the whole thing here if you like. And you can like uh it's all cryptographically verifiable. And there is a redacted request reveal flow where once uh the platform agrees to pay you like a certain amount of money, like say $5,000 uh you can like log in back as a hacker and then reveal the full private request. So, uh yeah, you this is like uh this is this is something like you can implement today. So, uh yeah, let me show you like a full end-to-end.

Okay.

So, you can see the hacker like submitting a report like the usual. Uh you attached the proof.

Uh uh we we already did this, right? Like we went through Burp, generated the proof. Uh you can see the request is hidden. The response is like public. And uh now you log in as a company that is interested in like finding out how you did this. Yeah, you log in as the company. Uh you you you see the request. See that? Now you have to pay to like reveal. Yeah. You have to pay to reveal cuz you don't know what is the HTTP request. You only know what is the HTTP response, but response is good enough to know that you actually have a bug. So, here you can like you can like bid. Yeah, it's like $5,000, right?

And confirm amount and like you can fully unlock. Yeah. So, now that the company has confirmed the payout, you log in as a hacker. There you go. Uh and you have a redacted request reveal flow. So you you know that he's getting paid like $5,000 once the cryptographic verification matches. So, you upload the full presentation and reveal full request. So, it has been verified. Um you know, the SQL injection right there is in the get request. Now, you can see that. The company can see that. And now the company can hit a button and pay him. So, everybody is happy, right? There is no AI slop and the researcher gets paid for uh an amount

that he's happy with. Uh it's it's there is no lowballing the researcher. So, we fixed two things. And we can fix further things which uh is part of my ongoing research and hopefully we'll we'll get there. But yeah, essentially that is the that's basically it. Uh let me I think we have a few more slides.

Yeah, so we did that. So, next steps, right? So, because it's an MPC protocol, there is a latency that the thing adds. And there are some servers that are very latency sensitive. So, it might reject requests. So, improving the latency of the MPC scheme is like something that I'm working on. Also, TLS notary is going undergoing active development. So, all these APIs are going to change. So, it may work today, but like tomorrow you know, depending on how the development goes, it may not. So, this is a very much cutting edge on the bleeding edge of like what you can do. We are also exploring the user use cases of like a fully homomorphic fully homomorphic encryption

which has even better trust assumptions. So Yeah, that's that's basically it. Thank you for listening and being here. All right, thank you. And uh we have three questions in the queue. I'm going to try to get through them real fast. We only have about 2 minutes. We will have to clear out here fast when we're done. So, let's get those questions. It's super important. Hiding a disclosure until payout is agreed kind of sounds like ransom. How do you suggest researchers stay out of that path? Yeah, I mean the the whole pay to reveal is more of an optional flow, right? You You don't have to do it. You can just prove that you are not an AI slop report and

that's that's it. It is one of the features where uh you know, uh the this this problem of like how does how do you make sure the researchers don't get underpaid? That is really what I'm trying to solve with like an option to like uh pay to reveal, but the company sets the price again. So uh I think it's a little more fair when the company doesn't know what is the input that went into creating the bug. But once you reveal the input, it's completely in the hands of a company, right? So, uh yeah, that is the balance that we are trying to achieve. This next one is pretty practical and I think it's a great one to answer which is what does

the customer need to do the on their web app to help them verify the response came from their web app. I think the answer is actually pretty simple, not much, but tell me. >> changes. That is the beauty of this, right? This just uses regular TLS. As long as you use SSL then you're good. You've already gone through the time to set up your SSL certificate. Your SSL certificate proves that it came from your side. >> Exactly. And that's what I just All right. Someone here is failing to see the benefit of this I I do, but can you maybe just real quickly you prove that the request sent is real, but I'm failing to see how it

helps verify that a vulnerability exists. Uh because the HTTP response is uh uh like in clear text. So, if you can prove that the HTTP request did come from google.com and the contents of the HTTP request has like personally identifiable information from a database in Google, then you know that the Google did have a SQL injection, right? So, just this just how we test using Burp Suite. Uh yeah. Well,

Yeah, so we are not testing AI. We are proving that a SQL injection exists and you're talking to a database or like an API endpoint. So, your output is really like uh you know, Etsy cat password. You're you're not like asking an LLM to generate a report, right? The the bug reports that come to you say claim that you have an RCE on Google, but how do you prove that? You probably have can read like files in the root server or something like that, right? Uh that is what you are proving that this was the output and this is the endpoint that you used from this server. So, cryptographically what you're proving is that uh this request happened and this was

the response. Just like you use Burp Suite to like test web applications today. That's all we are proving. And how we help is that you cannot fake these HTTP request and responses. AI can tell you that there is a RCE, but it cannot make a cryptographic proof of an HTTP response that that shows that there is an RCE on google.com. That's all the time we really have. Uh