Navigating Bug Bounties: From NAs to P1s

We have Anamesh who is going to talk us through navigating bug bounties from NAS to P1s. So thank you Anamesh.

>> Cool. Um hello everyone. Thanks for joining to my presentation today about my journey of how I've gone about from NAS to P1s in backgroundies. Um, if you're like what's NA and what's in P1? We'll get to that in a bit. Um, a little bit more about me, I guess not a lot more, but I'm anime. I come from Nepal. Um, I came to u Sydney around like seven years ago now to study uh my bachelor's in IT at UTS. And um after completing that, I started uh penetration testing and I guess since then I pretty much fallen in love with hacking web applications mostly. So I started my role as a pentester and then I started using Twitter because

everyone's like oh you know that's where you go to see the latest and the best. Um and um shortly after I came across this post by someone not actually someone but oh I forgot to redact the name looks like the hashtag. So, um, anyways, so 4 years ago, I came across this post. Um, and then I was like, "Ooh, so someone got like 15k for an idor." Um, how does that work? Started looking into it and turns out there's this thing called bug bounty programs. And what bug bounties essentially are, um, it's basically if a company has a bug bounty program, they're inviting researchers from around the world to, you know, come and try and find issues

in them. And if they do, if the researchers do find an issue, the company will reward the re researcher. How it commercially works I guess um there's managed bug bounty programs. So um primarily like hack one, buck crowd um integrity and yes we hack they're like the four major companies that do um manage bug bounty programs. Um, and so for example, you're a company and you want to run a bug program, but you don't want to like um have to go through all the logistics of it yourself. you go out to one of these four companies and they'll do the hosting for you and they'll also like validate the vulnerabilities that come in um and then

you just have to worry about like you know uh filtered stuff and just blah I guess um apart from managed bug bounty programs there's also big companies like Google, Microsoft, Facebook I guess meta now um who who host it in their own platform and they don't really use like hackon or buck crowd. So um in terms of um I guess categories within bug bounty there's private and public programs mostly. So the public ones are obviously ones that are public. You can see them I can see them. Anyone can see them and we can go and um I guess find and submit bugs in there. Um there's also private programs. So once you do sign up to one of these platforms

and submitting bugs, you also get invited by some other companies who don't want to I guess um put it out in the public that they run a bug bounty program. So you get invites and those are you you can then hack on hack and submit on them and those ones are private programs. The way um the reward works in bug bounty it says like you know um I guess most platforms claim it to be we'll reward you um using CVS we'll set the CV We'll set the severity using CVSS or Buck Crowd has a thing called VRT. But at the end of the day, what I've experienced so far, it's literally just business impact. Like

what impact does the bug you submit have on this company, that's how I have experienced the final severity of what you're going to get um is set. This is how it usually works. If you do go through one of the platforms, let's say you find a bug in Amazon and you want to submit it, you sign up to hacker one and submit a bug to hacker one, hacker one does the initial triaging. Um, so what triaging is is really so you're only going to get rewarded if your bug uh hasn't been sub hasn't been submitted by anyone else first. Um, so hack one validates that you're the first one to submit. They also ensure that you know

it's in scope. So you can't just like go into Amazon's buildings and you know find a bug in there and then submit it to Amazon, right? Um it has to be within scope of what Amazon wants people to be hacking on. Then um it also has to be a valid bug. So you can't just submit things that you think are bugs but the it's not actually a bug. After that, hackawan also sets um the initial severity of what they think the company should reward it as and after that it gets pushed on to Amazon, right? Um so then Amazon looks at it and I've personally never experienced it, but apparently there are cases when the

company just says, "Oh, we know about this bug and they won't reward it out." But I've personally not never experienced that. Um and then at the end uh the company Amazon decides the severity and then whatever severity they decide you get rewarded. So why did I get started? So I started pentesting. Um and then like I see all these different things that I now have to learn um and I'm like you know it's going to take forever. um there is like some experience that I gained through the engagements that I was doing and obviously doing labs and whatnot on the side but I wanted to do like you know speed up this process a little bit. So

bug bounty to me looks like the perfect opportunity where I could hack and validate what I've learned on live targets and then also make money while doing it. So I started in right and then I discovered that companies reward like really low severity bugs as well. Like for example, initially I was submitting stuff like I was trying to find every single like contact form there is out there and then check if if it has a capture or any sort of rate limiting. If it does not bounty submit a couple, get paid and then I'm like this is easy. Just do this over and over and over 100 times and I'm rich. didn't really work out that way. Um,

those were I think those two were the only ones that ever got paid out of like I don't know how many I submitted. Um, and I also figured out that okay, so you know I'm not really going anywhere here. I'm not really learning anything and like you know this is not progress. This is not why I started doing this. So I was pretty much stuck in this cycle of having really weak leads that I would just submit without you know trying to escalate or anything and then it would either be marked as not applicable or you know someone else would have submitted it before even um and then uh I also really always like avoided

stepping out of my comfort zone of whatever I knew. So maybe I would learn one thing and then just go and try that whatever I learned in the program and then if it didn't work I didn't really try and ever push okay what else can I do here um before I started bugg bounty like there was like plenty of people who always say look look at the graphql introspection try and make your own queries that the UI is not using look at JavaScript files try and find links that the application is not using through the UI even knowing that it was still like an extra extra step that I wasn't really willing to bother because it's not

fairly easy to read minified JavaScript, right? Who wants to read minified JavaScript? Um, I would pretty much just let the HTTP traffic go through my Burp and then active scan it and then just wait for Burp to start blinking red and then at then it would just be a TLS issue right. So that sucked and at some point I just told myself that look if I want to progress here I'm going to switch to this uh I'm not going to switch any program and I'm going to keep hacking on it until I find my first high severity bug. Shortly after that, the program I was hacking on added some new scope um that looked really interesting because uh

with new scope comes uh new assets that's probably not been as hardened because like it's new and maybe it's not been pentested or maybe you know other hunters have not looked at it as well. Right? So this application looked like this. So there were two I guess major applications as part of the newly added scope. There was an employer app and there was this jobseker app. The job seeker was a mobile app. So if you're a job seeker, you would go on the mobile app and sign up there and if you were an employer, you had a web app for you. One day I log in just, you know, as part of my normal hacking routine of just log

in with one of the accounts that I thought I had been using and then suddenly this specific page called shift types had been populated. Like I was seeing all this information that I had not seen before in my account. Uh, and then I could pretty much tell very quickly that this belonged to other companies. So, I wasn't really sure how I found a bug, but I was sure that it was a bug. I was like really scared that it's going to get duped if I don't submit it like now and then. I don't care about how I found it. Point is, I found a bug and this is the account that I found with, so figure it out. That's not what I did.

I mean I did submit it initially but I was pretty sure that I would have to at least find out you know um how this bug you know like how they could reproduce the bug so they at least they can fix it then. So I took that email account and searched it through my Gmail history and I saw just two emails. The first one was from months ago when I had first signed up using that email in the mobile app. And the second one was the day when I found the bug because what had happened was during that day I thought that I had been using this account uh to sign in. So I requested I did a password reset

from the employer app. So it turns out I've never actually signed up for this employer app uh using this email. But because I had already um signed up in the mobile app, when requesting a password reset via um the employer app, somehow it triggered uh a bug that led to an elevated account being uh created in the employer app. So that's cool. Um at this point I realized that okay so bugs exist. If I give it enough time then I will find bugs. And then while I've submitted the bug and while it's being triaged because I was able to see all this information of other companies, I'm thinking this is a cross organizational Idor issue. You know, it

has to be maximum impact. Probably going to get $4,000 to $10,000 for this. And then the company told me that nope, it's yes, it's a cross idle issue, but um there's not really any sensitive information in there. Um, at the moment, at that moment, I was like really sad, really devastated, you know, h bug bounty. Not going to do this again. Never going to find a critical bug. It's a scam. But um when I do look back um and then I guess it's also a bit of a realization that I had at that point that I did not before was that um bug bounties like if you want to get the big bounties you got to really find

big impact right um and when I say big impact it things like it's things like serake account takeovers remote code executions or at least like session hijacking so up until this point whenever I used to hack on any program. I used to have this mentality when checking for usual bugs that this is a public program, right? There's like 10,000 other people looking for bugs in this. There's no way I'm going to find an authentication like an issue in the authentication flow. But I guess since this point um I learned that I guess it's pretty bad to you know assume anyways in security but this was like a pivotal point for me in terms of bug

bounty to never like assume or never like skip testing on the basic stuff at least. So then I started because the bug I found earlier was in an authentication flow, right? Not in an authentication flow but more like something was fishy in the authentication flow. Um so I started looking at the O flow for this app from request number one. Right when I go to this page um there was this form where I could enter my email address and press on continue. Um, I guess before we move forward, this isn't actually like target.com. I just used I've used like target and like target.com vulnerable.com as placeholders because um just out of respect to companies to

not say hey you know I found bugs in all these like companies. Um so when I pressed on continue this this was the difference between the mobile and the uh employers app sorry mobile and the web app right for the web app they were using this parameter in the get request called profile type employer for the employer app and then for the and doing the same thing on the mobile the only thing that changed was the profile type jobseker if I if you just like press on continue after that for the web app it would um show a form to enter your password. And for the mobile app, it would actually redirect you to the company's SSL page.

This is what the response to those two requests looked like. Um so for the employer app, the response type was legacy. Sorry, not the response type, the type in the response for whatever it type was legacy. And for the jobseker in the mobile app was redirect. And so I thought, okay, so I wonder what happens if I switch the response type to redirect before uh the JavaScript in the web app consumes it. And I saw this. So turns out there was an authentic sorry there was an oath flow. If uh I changed it to redirect in the web app and if I just let the uh authentication flow continue um it would redirect me to the

same SSO page that the mobile app was using. And then after logging to the SSO page, I would then get redirected back to the um employer web app. Now this was interesting because this is totally new attack surface as in the login page of the web app there's no button to go like login with SSO. There's just this option to enter the password, right? Um so ooth and a new attack surface. Um after that uh no more assumptions here like no more thinking there's not going to be an open redirect in a public programs workflow. Oh, okay. Before we get to that, I guess what was happening here was um there was this piece of JavaScript in this uh web

app where um I guess the so after you pressed on continue in that uh UI earlier. Um how you logged in depended on what your account type was. So the legacy would just be the password form and then um the redirect it would do the oath flow. So that's what happened in my case. Um and then I found my first high severity bug. Um this oathflow was vulnerable to an open redirect. And then uh basically when you do have an open redirect in an oath flow, you can steal the uh victim users uh oath code and then exchange it for a token when certain conditions are met. Um I guess oath deserves a talk on its own. So I'm

not going to go any more than that for now. But I guess the gist of it was by I guess modifying the response type of how you I was logging in into the application. I discovered this oath flow and there's probably other people who looked at this application as well before me. I'm pretty certain of that. Um and this was a fairly like straightforward bug in terms of like uh what you can do with an oath. like it's one of the first things I checked and I'm pretty sure like it wasn't found before because uh no one really bothered looking at the mobile app or didn't know that the thing um redirect existed instead of legacy. Uh and most

importantly, no one looked at the JavaScript files even I did not. Right? Just going back to the importance of JavaScript files, I guess. um it is just so important when you're hacking a web application because there's just so much in a web application um that's not in the UI itself and that you're not going to find by just clicking on buttons. So from this point onward I guess what I've realized is that when hacking the only assumption that you can really make is to assume that everything you hack is or everything you're assessing is at least vulnerable. So that oath is done but I wanted to find more bugs in this application and after spending some time I found like

multiple self- stored accesses like those self- stored access is everywhere right but I didn't really know what to do it with fortunately just around that time I had started listening to this uh critical thinking bug bounty podcast and I didn't really understand what they were talking about at that time but they kept like you know going on and on about how they change like uh how did they things with the sort self store accesss and change it with login CSRF login log out CSRF like what the hell's going on I had no idea like when I was uh listening to that but what I did understand like the gist of their podcast or that specific part was that there was a sort

of stored XSS and they managed to escalate it to a session hijacking bond right so usually in XSS there's three basic types reflected stored DOM um DOM based XSS Uh but what I have here is a self- stored XSS and usually by itself it's not really exploitable. Let's say you've got this um e-commerce application that goes hello your name ready to discover amazing products or whatever whatever um you go into your profile information and you change your username to like an XSS payload and then when you go back it pops this alert saying alert one. Okay, you've got XSS, but then you can't really exploit this as of now because if you do like, you

know, convince someone else to visit the same URL, what they're really going to see is just their profile. But let's say you also have a uh session fixation vulnerability where you can somehow, you know, log them into your account via a single request. Um, and now what that what happens is that when they uh visit this URL, they see the XSS payload injected and it fires. But like what's the point, right? Usually with XSS um you get the victim to visit a URL or you've got a self- stored XSS and they like open a page where the sorry we've got a self self sorry you've got a stored excss where they open a page and

the excss fires and your goal at the end with usually with an XSS is to either get their um session token so that so then you can like take over the session and then uh do things pretending to be them uh in their account. So by so the the issue with this right now is that even if you have a self XSS and just to login CSRF all you're basically doing is you're logging them into your account right so even if you have an XSS you can't really steal their token because it's your account where the XSS is fired. However things change when single sign on isn't used because um okay sorry not because things change when single sign

on isn't used. Um, so how does single sign on work? You've got this page you want to log into. You've got this e-commerce app you want to log into and you click on login and you get redirected to a different application which usually is the you know like the main single sign in like main login page for all the applications for this company. And if you ask like why would someone do that? Um it's not just one application that this company may have. So in order to simplify u authentication a little bit they would have uh they may implement an SSO where you know you just have one place where you have to uh think about how to handle

authentication. So how does that changes things for us right? Um let's assume this like we're using this application we click on login and we get redirected into the SSO page. Now what we have is after logging in the SSL page we've established a session in this SSO page and when however it's whatever like method is used to implement it whether SAML or OOTH um after you log into the SSO page you still have to be redirected to the application page and usually how it works is that a new session is generated for your application that you're using as well. So when you're logged into this e-commerce application that you're using, you're not just logged in there.

You also have established a session in the SSO page that you have in your browser. So how do we move on forward from here? First step, we let's assume that a victim has you know navigated to this URL. Um and then uh and then sorry what's there? Okay. Yeah. Um, and what we have here right now is the victim in the victim's browser. We've managed to log them into our account, but just in the e-commerce application. There's no alert one here this time. Instead, there's a script tag pointing to a JavaScript file somewhere. The JavaScript looks something like this. First um it'll create an I frame that will in the so it what the JavaScript will do here is it'll create

an iframe in the page where it's going to use the victim's existing SSO to log them back into their iframe lock them back into their account. So although like on the outside on the main page we still have our JavaScript and we still there they can still see our like name and everything um because that's already loaded in the DOM over there inside the iframe they've logged in back they've logged in back into the account and a new session has been established um so now our session ID does not exist in the browser anymore it's been replaced by the new session from the iframe so what we do is um using the same JavaScript it

was waiting for 5 seconds and waiting for the victim to be logged back into the account. Um, what it's going to do is now read the updated uh session cookie that's been established in the browser and then y it to the attacker. So, I was pretty surprised by how prevalent this is. And this is probably because um companies really don't care to um fix self stored XSS because, you know, how can it really be exploited? Um, I guess that's a mentality. I've just learned how it can be exploited. Um, and I guess there's also a lot of uh, for example, if this was just me like two years or three years ago, I would have submitted the self- throat

XSS as it is and the company would have gone, no, you can't really exploit it and it would just it would have just been that. I've been able to use this technique over and over and over and over again. Um, because I don't know, it's just out there and I don't even like proactively look for a self store accesses in an application. It's just there. Um, and when I do find one, then it's, you know, like tingles my fancy, I guess. Um, because there's just so many different ways you can exfiltrate like someone's token, uh, using this sort XSS plus login CSRF chain. However, um in terms of impact, it'll never ever really be that high in bug bounty

because there's just so many caveats like even from like you let's say you run security for this major application and you've got so many issues to deal with and you're not really going to care as much about this issue where the preconditions are that um the victim user has to be logged into their account and while they're logged in they also have to click on this link or v visit a malicious page um to finally and then the f attacker may finally get their session token. So it might not just be their priorities, right? And even from like a bug bounty hunter's perspective like yes like it is weaponizable and um you can keep submitting it to make some

money but it's a total pain to write reports for these. There's like a 20step report for how to, you know, set this up and then like what you have to do as an attacker and a victim user for all it to work and then like you can notice there there's like 27 comments and 20 comments in there, right? So it's just me going back and forth with triagers saying, "Oh, this is not working. Okay, do this." So it's very painful as a bug bounty hunter as well. And as I started engaging more with the community, I guess I sort of learned that the real impact, you know, uh security-wise and even bounty wise is in the server side

bugs. So while I was starting to get more engaged with the community, um I came across this course by Jay Haddock last year. Um and I had previously watched some of Jay Haddock's talks as well. they were really good uh in terms of giving me a start for both just generally hacking a web application or generally approaching an attack surface. Um and I was really keen to do this and thanks to my boss and I feel really fortunate that you know um those things are taken care of by my workplace and I did this course. So the how this course really worked is um during the course Jason would pick a target and then during the two-day

course uh he would uh basically do reconnaissance while all so that you know basically as a testament to these techniques that I'm sharing you in this course are not just um uh techniques that don't work. They actually work and I'll show you results in two days. So the target for our my cohort I guess was this really large um car manufacturing company and they had this really interesting scope section where at the bottom of their page they had this other target domain section where they had where they basically said we may award a small bonus for these assets but only valid high critical and exceptional findings. Um so what other target domains essentially means is anything

owned by this um any domains or any subdomains owned by this car manufacturing company and that opened you know our like reconnaissance possibilities really wide. So at the end of the course he gave out this spreadsheet where there were a lot of subdomains and then everyone started looking into it and shortly after I came across this uh sub like subdomain that looked really sus. Uh after I was Google talking for it a bit, I opened the page and it's a bunch of SOAP APIs. Um just exposed. I guess if you're like what's SOAP, I was told that it's basically rest APIs for people in the '90s. Um so there's this bunch of SOAP APIs and I

find out that there's WSDL files as well available there. Um, so using Burp's WSDLR um, extension, I make a bunch of sample requests and I start sending them. But no matter what I did, I just could not get the error message to change. It was just this same error message. Um, that would not change. And I was really hopeful that, you know, it would tell me what I was missing in my request saying, you know, you're missing this parameter of this content or this like content type. Um, but it didn't happen. So what I did uh instead of just moving on I took the domain and because we were sort of hacking in a group along with the

course I dropped it in the chat and a few minutes later someone messaged me saying hey I was able to get the SOAP request working you want to collab this guy is very kind because he could have just um you know gone ahead and reported it and I would have never known about it. Uh which just shows to highlight I guess uh collaborations are really good in bug bounties. Um, I was initially really scared to share anything I was doing at all, thinking, oh, you know, they might like just go ahead and report it and um, I might never know about it. But I guess after I've started collaborating with other people, sharing what I have and sharing what they have,

um, like I've been I guess able to learn much faster in back bounty. So I also asked him like because I really wanted to know what I was missing. And what I had been essentially doing is just um I guess sending the sample requests the WSDLR created and not really pushing further than that. And he mentioned that okay so I just added this after that error message and then it told it started telling me that this is not you know it started giving me all these error messages that wereformational enough to um create the final SOAP request. So we ended up submitting it. Um and I guess um it was pretty impactful as well in terms of what we're

able to do with it. Um for a specific country we were able to access um like names, addresses, what like car they had uh for like 50,000 of them. Um and you might be like what that is that all the bounty you get? But remember like from the previous scope section, this is just a bonus and not really like bounty. And I wasn't really upset as well because um we were having a lot of fun just hacking these cuz they were so vulnerable. This was also a really important point for me in my like bug bounty journey so far because um before this I didn't really know what I was missing like I would I I would feel like you know

sometimes like I would find really interesting assets but not really able to push them further. Um but this like collaboration basically told me that I just need to you know spend that extra bit of time and see what is the every single thing I can try against this instance when I do find interesting stuff. So I had over 30 Jason addicts in the data he shared there were around 30,000 subdomains and the entire like the gist of this course was that you know if you can get to a subdomain before someone else does it you're going to find a lot of bugs in it. So I was like, well, we've got all this data. What if there's

one git config file in there that, you know, that is exposed and let's see, let's try it out. And to my surprise, there was one target in there that had the git config exposed. I download it and I see that there's a GitHub personal access token in the git config file. Um, at the moment, I guess I didn't exactly know what to do with it and how to see like what I can do with it. So I just get cloned it and so I accidentally got access to a lot of source code. Um so moving on reported that gets paid out but we have access to a lot of source code right so that so I started

looking into them and one of the first things I do when I do get access to source code is um run like a SAS scanner and in this application I think every single SQL query that was there was vulnerable to SQLI. So I took all the endpoints and then I you know find all the parameters that I need to do and then um during the and then try out the you know magic SQLI tree that no one knows about. Um and turns out like all of these were in fact vulnerable because uh before this point you know like I only had access to source code. Maybe uh the code was old and they fixed it but now I was sure

that I had a lot of SQL here. So I start sending out requests and then I get blocked. Frustrating. There's a few ways uh around this. Um so this error specific was from AWS and I really hate their wife. Um so there's a few ways to um get around this right. Um what's really happening so far is in order for our SQL to work, we need to reach the application server at least. But right now we're getting um rejected by the W in between. So this this in terms of getting around W, you need to be really elite and be able to write like gibberish SQL that the W may not recognize. And it's not my

skill issue, it's the W skill issue. I was just um um lazy and I didn't want to do all of this because I would have to do this for every single potentially for every single endpoint and find a new one. So I didn't want to spend all that time. Second is if we find the origin IP address and hit the target server directly that would be fun as well because uh there's no w in between that's going to stop us anymore. I tried this through looking at historical DNS checks from zumi end mapap however nothing um no success there. So what else just around that time asset node had released no athletes and essentially how it works is

that um so WS have to process the request and basically scan whatever we're sending in order to find out what's being like what to block and what to let through right and what no is is does um typically this is a burp extension so you can install it in your burp and if you if the payload you are sending is part of the request body. What you can do is put a lot of zeros or a lot of junk before whatever you're sending so that the W does not see it. Not necessarily does not see it, but there's just that it's just that the WS have limits to how much data they can process. And for AWS, I think it's like

64 or 128 regardless. I'm this. Um, so however, there's an issue here. All of the SQL I had was in get request. So I couldn't really already use this. I kept this to the side, you know, and went back to the code to see what else was there because there were a lot of bugs there, man. Um, so the first as soon as I go back to in the into the code, one of the things I noticed that they had this um endpoint that was using DOM PDF to convert user supplied HTML into PDFs. And I think serverside HTML to PDF converters are just like vulnerable by design. uh if you just like leave him leave them to default

settings and do not like apply extra protections to them because what this allows is it significantly expands our attack surface on the server side for example right I can supply this uh HTML with an image tag pointing to a favicon and it's going to return me the favicon and how it works is that when I do send that post request the the PHP runtime in the server will fetch fetch the uh fetch the favicon that I requested in the image tag and then give it back to us. Um so that meant that now I can make the get request that I need using the PHP runtime on the server side. how that would work like similar to the earlier

one was when the PDF renderers tries to convert the get request so uh sorry convert the image I guess fetch the image for us so that it needs to put it in a PDF and return it back to us it's going to do it on the server side um our SQL will trigger and then we will notice a significant delay in from when we send the request to when we receive the response u to confirm our SQL however ever. This is still an issue because WS still see um the pay payloads that you're sending in the body as well, right? It's not that it's just the first line that they're going to see. However, um we've got no fees from earlier. So

now what we can do is use the post request uh and put a lot of junk before we put in our payload. And when the server when it reaches the server because it's going to be too much for the W uh because it's not going to see anything after a lot of zeros that we have at the start um the PDF converter is then going to try and fetch the get request and our SQLI would then be triggered on the server side because um it just makes the PDF runtime will just make the get request to the local host and it doesn't have to go through uh it doesn't have to go through the Write um

so that That way I was able to I guess take a get request SQLI and then find something else uh find this PDF converter um put the get request inside of the post request so that we can so uh so so that we can put a lot of zeros uh before our payload and the W doesn't see it and finally when it when the serverside PDF converter does try to convert uh whatever HTML we supplied the SQLI will be triggered and we see a significant response. This is what the final request looked like. Um, it was quite painful to try and figure out all these like Spanish uh characters uh in order to success make a successful

request, but it did work in the end. So then I have like 10 SQL, right? Based on what they had paid out before, I'm assuming like it's going to be like €7,000 and I start visiting a vision pro. But shortly after the program's like, hey, you know, thank you, but we're going to mark everything as high. Um, thank you for your efforts to secure our program. Um, what we've been told is that you don't really have any write or delete access uh write or delete privileges to the SQL tables. However, I was pretty confident that that could be overturned because in the source code, uh, there were insert statements. So, there had to be like,

you know, uh, write privileges at least. So to validate that I did these five requests. First one I created a new data. So this was like obviously SQL and it was way too much to put it in this slide. So I just wrote it like that. How it work was I wanted to prove that I could delete as well and I didn't want to delete anything that they had. So for to prove that we can write and delete. What I did was firstly I created a new database and then wrote SQL so that it sleeps for 3 seconds if the DB creation was successful and then I could see it in the HTTP like response time. After I

create I do another SQL query um which basically checks if I if the DB that I created exists and then sleep for 3 seconds again to validate because now we've validated that you know we've created a new database successfully. We can even show uh that um we can delete as well if we have the privileges. And to show the differences, I deleted the database that I had created. And then I also deleted another database that did not exist. Um because like they might just go and say, "Oh, it just the servers just started responding after 3 seconds whenever you send a request." Now, if I don't have that difference between uh my proof of concept and

something that should not work. And then finally I also repeated uh the second step in here because that's also again to say show the same difference because it did sleep earlier right after I created the database and I ran the SQL query to check if the database exists. It did sleep earlier but now that I've deleted it it it definitely does not exist. Uh and I was able and that way I was able to you know I guess be sure and show them that I've got all these privileges. They overturned all of that. um and then paid out all of the bugs correctly. Um and I guess that's how I found like 10 like exceptional submissions in

integrity. Um which were my first 10 submissions there as well which was a lot of fun. I guess um so far uh what I had learned to this point was context is super important when you look at a bug in any application, right? when you give the bug any context to you know like how does this bug affect this application rather than just look at the bug by itself there's a lot of possibilities that can um that can be done you know um and I guess the other thing is that that I learned from here is that um still don't rush too much even if you have a valid valid block see what you can do

like you know push it as much as you can without doing anything that harms the application and then report. Final thing, I wouldn't say that was a complex bug, you know, it was just that I had certain things there in context um that work for me and then it was fun. But um usually there's this assumption that even I had that you know probably all these like big bounties are super complex like 10 uh like chain of 10 requests or whatever that get the big bounties. Not really. because the first remote code execution I ever found was literally a PHP webell on an upload endpoint. Um you know like sometimes people say that oh like real

life applications are not anything like the CTFs and labs you do but I guess this was a bit of a realization for me as well that you know um these bugs that we do in like juice shop or whatever can exist in the application that uh is out there in the public as well. The funny thing about this was that I made this post request on like Friday and then before making this post request on the same endpoint, I also tried a few like like get requests and put requests and everything was returning 200. So I made this request and I didn't even bother to check if it had uploaded somewhere because um there was no like nice UI

that would just let me like show me the uploaded file. So I actually just left this for like 2 days and then later on I was like oh I should probably check like you know if that file uploaded somewhere. So I guessed that okay so the upload was in the /upload endpoint. So it probably uploaded to uploads and then to my surprise it was there. It was paid as a P1 which was my first uh remote code execution bug uh that I ever found in like bug bounty on since I started doing bug bounty. And I guess I also learned that you know like keep it simple at times like there's no like tender questions. It's just about you

know like keeping it simple and you know looking at what like what's happening in the application. Um I guess um just sort of like starting to wrap things up. It's super important when doing bug bounty to understand like how everything works in the application and not just look at one application but instead look at everything it's connected to. Whenever you do find like low like low severity bugs that may not have impact in impact instantly if you like um I guess give them context and see how they can affect the application or you know in the best case scenario you might have like a critical severity bug that needs that low severity bug uh that you found like from two months ago.

So you know I guess give I guess when you do find bugs look at them from a wider perspective to how it affects the entire ecosystem and not just you know how the what the like the response is for that specific bug. The other thing that I've realized is business impact is much more important than technical complexity of bugs. Like you know the highest bounty I've ever received is literally for accessing a PDF on an S3 bucket. Um, and I guess I almost didn't report it as well because it's just a PDF, right? What's going to happen in a PDF? But apparently it was super important to the business and I received a pretty big boundary for just finding a

PDF. The other thing is that most of the bugs that I showed today here are mo were mostly web bugs, but uh I know that there's all sorts of bug bounties right now. um like if you're good at whether you're good at blackbox hacking or you know like whether you're good at source code review like you can apply almost everything to bug bounties there's also like car hacking stuff like I know Tesla BMW have like automotive uh automotive bug bounty where if you do find bugs in hardware stuff you can um you know you'll get rewarded for them and I guess I don't want to say that mental health isn't talked about but I've experienced

experienced it and I felt it that um it isn't practiced enough, right? Bug bounties are like super addicting cuz you're pretty much gambling your some I guess like that's just my POV of it, right? You're pretty much gambling your time, effort, motivation against like you'll find a bug, hopefully find a bug and get a big bounty for it. And I pretty much feel like, you know, Goku when I when the bounty gets paid out for like 5 seconds. But like when you're just like trying to find bugs, you probably find like for example, I found like 50 bugs over the past two year years. Like there's 700 days. And there's probably not been a days that

gone by where I I haven't thought about a bug. So it once you like I guess do like start doing bug bounty it's super important that you keep like your health um your life and you know cuz like you you don't just live by yourself there's people around you um and just like I guess give all of those things importance as well along with you know finding bugs and winning cool that's the end of my talk um open questions

Thank you, Animesh. Any uh any questions?

I'm curious if you've noticed like AI or changing the landscape like >> uh that's a kind of a tough question. Well, I guess um I don't know how to answer that. Damn. Um how I guess I think this probably with time there's probably going to be bug hunters who are going to use LLMs to you know find certain bug classes. Um, but I think most of the bug bounty, right? Like platforms advertise that there's like a million people who do bug bounties, but it's probably like a not even like maybe 10,000 or 20,000 that do it full-time and do it seriously, right? And I can tell that the bugs that those guys found are probably not going to be found by

other lamps yet. >> Um, I was just going to ask um two questions actually. Um first is like I've heard of the of hacker one complain about people using AI to submit um you know bug bounty um reports. I'm keen to know what you think is the future with regards to um you know what AI is going to do with regards to that. And secondly, how long did it take you to get your first um your first um paycheck? >> Yeah. >> From start to to you know getting that first pay. >> Um I think I I didn't quite hear the last part correctly. Sorry. um from >> obviously based on the title of your of

your talk uh you talked about essentially from noob >> to essentially so how long was that was that because one of the things I think a lot of people misunderstand is how long you know the actual initial work you need to do >> to eventually be able to get one bug that is worthy of someone paying you money so typically from what I've heard somewhere between six month to one year so I'm keen to sort of know your especially for those who are wanting to get into bug bounty so they kind of have that you clear expectation of how long it's going to take before they, you know, they hit that big paycheck cuz it's not it's not a million dollar

payday from day one, right? >> Yeah, totally. Yeah. Um, I guess I'll just answer that part and then we'll move on to the hardware AI part. Um, so I think my first bounty came in like probably after like a couple months I started, but I think that was like a really stupid like bug on a JavaScript file where like a key was leaking. And I don't really really want to claim that as my first proper bounty. And I think it was up to like almost like a year of me, you know, I guess doing part-time bug bounty uh that I found like the first P2 bug that I found, which I consider like one of my first proper

bugs. So I would like actually say probably a year, but obviously that really depends on like what your background is and what your skill sets are. um for me. So I had just finished I think after finishing my uni it was about almost like one and a half year when I found my first proper bug. Uh with regards to the using AI to write reports I think if you found a bug and I guess you just want to write a nice report using AI. There's nothing wrong with that. spot. I guess I've se I've been seeing a bit of like um posts around some people uh submitting absolutely junk uh using like finding like absolutely stupid stuff in curl and

then it got disclosed as well where they're not really actually submitting actual bugs but just AI hallucinations to the program which is I think pretty bad like please don't do that. >> So basically what you're saying is um it's it's pretty safe for someone to get into bug bounty um right now. So it's not it's not an area that LLM say um is essentially going to take a while >> like what what is the likelihood of the someone having an a fully automated um bug bounty program where they basically just get um an NPC or or an agentic um you know engine maybe using N8 or something and then literally just get it to hammer out their at their web app or

their source code. Um do you see that happening? >> Uh so just to correctly rephrase your question if I understood that correctly. So what was the question again? Sorry. >> Okay. Do you see AI taking over bug bounty? That's really >> Do I see AI taking over >> completely? Like fully automated. >> No, I I think to some extent and like said earlier maybe some bug classes but not fully. There's going to be lots of bugs that's still going to take like human intervention to find and exploit. That's my take on it. Yeah.

because

>> oh like how someone can use AI to facilitate >> I understand that it's not going to completely uh automate the process but would it facilitate it? Look, I think like I'm probably not in the best position to give like a definitive answer on like what and how like AI is going to change over the next like 6 months or one year, but I can say for sure at the moment that it's still like there's still a bit of time before, you know, we can start worrying that AI is going to fully take over and they're going to find all the bugs. I've also um I've been following someone recently on socials um who targets about bounties

and he's been making a lot of posts about complaints on uh vulnerabilities that he's identified and um not being paid out. >> Sorry. Vulnerabilities being >> well like he he's found a bug and hasn't been paid out. So what he sees >> um see I think there are like some there's good programs and bad programs in bug bounty. There's definitely some programs, you know, that will treat you unfairly. I guess the only really way we have as bug hunters at the moment is to just not hack on them so that you totally avoid that problem. Um I guess um the good thing would be to for the platforms to take action so that that does not happen. But um there is I guess

some amount of unfairness where companies just pull cards like we know about this bug internally or fix it as soon as someone reports it and says that it was never there. That does happen as well. >> Yeah. Okay. I'm sure there's um there's a lot to still work out. Yeah. You know, you only predict so much, right? >> Yeah. It's a bit mixed honesty. Bug bounty. It's pretty good. Like if you find like I think all you need is like one good program if you want to do bug bounty and find like one big program and then I guess just hack on that. >> Excellent. >> Thank you. >> Thank you very much and thank you

Animesh.