Verifiable Bug Bounties in the Age of AI slop

Transcript

Awesome. Uh GMGM, hey guys. Uh thank you for showing up. Uh I'm Anto Joseph and uh we will be talking about uh how we can u save bug bounties from u AI slop. Uh so who am I? I am uh an engineer at IEN Labs. We are the creators of IGEN cloud I can layer the protocol and uh all the good things over there. I'm

interested in um doing distributed systems applied cryptography and uh previously I've been at like a bunch of fund companies and uh if you want to get any uh code from this presentation you can find it at that GitHub. So what are we fixing right? Uh bug bounties u now nowadays get hammered with a lot of LLM generated reports. Uh LLMs are good. I use them every day but uh I'm sure like you all know that if you are on the receiving end of these bug reports a lot of them end up not being a real bug. It's just uh

hallucinations right? So uh fake reports cost verification time. It's usually my time. Uh and uh I I would love to like use that for something else. And uh lowest uh and there are other issues with bug boundaries but one of the main things we want to address with the current state of bug boundaries is that there is a lot of information disclosure. If you look at like web two uh imagine you reported like a SQL injection you are literally disclosing what's on the customer's database it could be PII and you don't want that private information on like a bug bounty platform uh because uh why expose data

if you can do without right uh and because we have so much volume of like bugs being reported we see that a lot of these reports get triaged with AI and there is also uh bug bugs with when you triage with AI right so if AI is the problem AI is also the solution and then we have problems in both the spaces right so we are trying to fix that with applied cryptography and some mechanism design and this is also something that what we do at ien labs so the core techn technologies that we use to do this are

ZKTLS and ZKBMS. And today we only have like 20 minutes. So we'll only dive into like the ZKTLS aspect of it. Uh and uh are you guys familiar with what is CKTLS? It's a very popular topic these days. But let's start with what is ZK? Uh ZK is a zero knowledge proofs. It allows uh it allows for certain properties like privacy and uh correctness uh if you do it right. And this is like a textbook example of what uh ZK allows you to do like prove that you are above a certain age uh without revealing all the other

information in your um ID. Uh this is something you probably do every day. Okay, go to like a club like show him everything like where you live blah blah blah. All he needs to know is that you are above 18 but this is the state-of-the-art today. So ZK can do a lot here and uh these are the ingredients of ZK. Uh we can go uh deep into all this but uh we will save that for some other time. But this is how you could write a very basic CK circuit and this is uh called circom. Uh it's a DSL and what we really do here is that we

are verifying if the message corresponds to like a hash. Uh so this can be done in Python. So why do it in circum right to prove that I know the pre-image of a hash I have to let the world know that this is the pre-image. So I can verify it myself. That is how we do it today. But with like CK uh with circum I can create a proof that I know an input that satisfies this condition and not reveal that input. So now I can prove to you that I know the pre-image without revealing it. If you come from like a web two uh background, you know, we have like uh machines that crack passwords.

Uh and uh we could literally use this uh in interesting mechanisms if you if you know where I'm going with it. So uh let's actually see a demo, right? Like let's see what that looks like. So this is uh a CK ripple. Uh so if you just type that in, you will get this code and you can like compile it. And when you compile it, you get a bunch of files and you get a GR 16 proof.

Click on that and you can see if I generate a proof I this is what the proof looks like and if I click on it I can verify right so imagine so what is it that I'm doing here right two inputs one output if you multiply them you get C very very simple right so 5 * 77 and you at this and five is a uh public input.

So let me change something here and I'm trying to verify and you can see the proof is invalid. See that? So this right here u says that if I don't have the right u inputs this this proof right here will will not work. like you can try changing any of this. The proof is invalid. And uh we can go in depth about what this means. But this is also uh something you could do like you can see that I have a verifier.

file right here. And you can download that right from here. You see the soul file here. Yeah. So uh once you download the soul file once you um write your code base and like do all this you can like put it in a ripple and uh you can provide the inputs here and it would look something like this. Okay. So you compile Okay, I'm deploying and I'm just providing inputs as a

function call here. So this is what we did uh with the web UI but this is more in ter in in like how you would do it with solidity because we have a solidity verifier. Uh you you can use uh CK without smart contracts. So that is why um uh the first demo work but yeah you can use it in the context of uh smart contracts as well and you can see I make a call and the boolean right there it gives you like a true or false uh that is how you would use it in the context of smart contracts.

So getting back to the presentation so we just proved that uh we know the pre-image of a hash without revealing it. So ZK is awesome. We all agree right now. Let's let's look at what is ZKTLS. So CKTLS is a MPC protocol that integrates uh ZK with TLS enabling uh secure transmission of data just like how TLS does. Uh and it gives you properties like selective disclosure. So you can hide some of your input or some of the response. So an HTTP request is uh you have some uh HTTP uh keyword like

uh post or get and then you have some body where you send some data to the server and then in the response the server responds with like the the specific data right so your input in when you think about of a web two sort of a hack your input is something like a an SQL injection like an XSS uh or any sort of um malicious payload and that is the secret sauce. Sometimes when you report uh bugs to like bug bounty platforms you have to uh disclose what your input is because that is the secret source. Why do you need it? Why do you

need to disclose your input? because uh that is the only way for someone to verify that what you are reporting is actually true. But what if you can cryptographically prove that the response in your HTTP u payload came from that specific web server. Say if I found a bug in google.com, if the if the response if I can prove that a certain response was from google.com then then they don't need to reproduce because it's cryptographically verifiable, right? And what that allows us to do is we can hide the input. So you can prove that there is a bug by

disclosing the HTTP response, but you don't need to like reveal the input. So uh this gives the bug bounty hunters a lot of tools because sometimes when you disclose a bug uh people would be like uh maybe this is not a bug I'm interested in but they already know what the input is and then they patch it afterwards. So the the bug bounty hunter is like left uh like he he doesn't feel right. So with this mechanism you still don't disclose your secret sauce but you prove the existence of a bug then you can talk about payment severity on all

that agree on it and then you can disclose what is the actual payload. So let's see a demo right. So uh internally you can think of the highle architecture of TLS notary like that. Uh it is an MPC system and then there is a verifier and an attestation server. But let's do a demo and then we'll get back into it. Okay.

So, this is uh as an an example um example right here. So, you can see I'm going to like prompt airlines.com. So, uh everyone uh is aware of prompt injections, right? So the idea is you inject a specific prompt uh to get the key the CTF key that is it's a very simple CTF uh and I want to prove to my buddy that I cracked the CTF but I don't want to I don't want to give him my prompt very simple problem right so that that is really what I'm doing here so I'm setting up a connection and you will

see u your basic HTTP request test right here. And uh this is the prompt. This is the secret secret sauce. And uh then I'm running the attestation. It starts an MPC connection with the server. And uh you can see the C is the CTF key right there. So this is your uh typical experience, right? Uh you send a prompt uh if your prompt is good enough, you you get the

CTF and this is the the the real uh UI. And you can see my prompt injection worked and I got the CTF key. But now I want to prove uh that I was able to get the key uh without uh disclosing the the input prompt. So the first demo shows you what the end to end TLS notary experience looks like and the next demo shows you how you can hide the input. So this is just basic TLS notary verification to prove

that this entire transcript the the the request and the response is all verified. Okay. Right. Yeah. Okay. So in this one uh so we created these u attestations before and you can see that I'm going to hide.

You see that? So here is here is what uh happened right like the input got masked and the output still has the CTF key. So this is a cryptographically verifiable uh text that you can send to a bug bounty platform that can automatically verify that everything works just like how you would like verify that a hash is correct. This text is cryptographically signed by the TLS notary attesttor but it hides the input. So if you find a bug uh you hide the input, you send the HTTP

server response and then the the verifier, the person who is looking at your bug report already knows that this report is cryptographically correct. So they can trust this portion of the transcript. And you see the CTF key right there, the this CTF key right there. but they don't know what my prompt is. So, you can create very interesting uh marketplaces even to sell your prompt injection attacks with this, right? I don't recommend you do that, but [laughter] but I'm just saying the implications are huge here. So, you you keep your exploit

to yourself. You prove to another party that the exploit worked based on the HTTP response. And in the regular bug bounty setting, you discuss severity, payments. And once you agree, you can disclose your input and they can cryptographically verify that the dis that the hidden input matches the the new report that you will send. that is in clear text. So everything is trustless. Uh you don't uh bug bounties are no no longer trust me bro. Right. So I think uh this

is how uh like we can help like the web three can help web two bug boundaries level up. And uh I have another talk on how we can also level up uh web3 bug boundaries but that requires a deep dive into CKVMs which we don't have time today but um yeah that was um that was uh everything I had this was the outcome and uh that that is what I mean by trustless bug boundaries and uh Yeah. Uh, thank you for coming and [applause]

yeah, if you have any questions, yeah, go for it. Uh you kind of touched on it a little bit already, but is there a version uh where can for instance prove that I can steal funds from balancer but not disclose the actual transactions and how hard is it to port this system or apply it to blockchains? >> Yes, I have an entire slide deck just for that. So uh we use ZKVMs and uh there is a demo that I have which allows you to prove arbitrary programs while you run it in a ZKVM setting to prove that uh a certain outcome is possible

without uh disclosing the inputs and uh some some kind of exploits it's it's possible to prove within a ZKVM Some you can prove that uh you were able to like move tokens on a test net without actually doing it but you create a zk proof that it is possible just like how you would do a fork test in foundry you know uh so risk zero which is a zkvm uh company has uh has a product called steel proofs and uh steel proofs can be used to prove that on a test net you are able to do something but you can have

that uh proof be verified on mainet. So you can even do like trustless payments and uh and you can like immediately pause your mainet protocol once a pay payment was made. So you don't even need a man in between and you can fully automate this. Yeah. It just needs more time. >> Yeah. Yeah. >> Very quick. How do you know that a bug is reproducible? >> Oh, so uh a bug re TLS notary proves that this bug this was the output of a specific response at that time. It doesn't prove

re reproducibility. So if there was >> I was thinking when Cloudflare went down. So you capture it at that moment and then you say, "Well, I have a way to hack Cloudflare, but you don't actually have it because Cloudflare just happened to be down." Yeah, we can't fix availability. We can only make it verifiable. So availability is a problem that we do not solve with this. Uh if your vulnerable web server needs to be up so it can be reproduced. Yeah. But at least you can prove that it was exploitable at that time.

>> At least once. >> Yeah. Otherwise, if you show up with a screenshot, it's like, "Trust me, bro." Right. >> Exactly. Yeah. So, at least it is cryptographically verifiable now. >> Yeah. Okay. Thanks. >> Yeah. >> Thank you very much. Thanks, Anto again. >> Thank you. Thank you. >> [applause]