 Please introduce Anshuman Bhardia who's going to give a great talk on bug bounty hunting on steroids. Everyone give a great mid-afternoon welcome. We'll just all look at him awkwardly for a minute. I'm just kidding. No pressure. So hello and apologies for all the technical difficulties here. So the talk is obviously on bug bounties and how to hunt such a way that you don't have to look for them manually and it just works for you. So the first slide is basically just a team. It's not me working on this thing. We are a team of three. Unfortunately I am from San Diego so I was able to come but there's Glenn from Australia and Mohammed from Egypt and we've all worked on this together. So today we're going to talk about the problem, right? What the problem that we're trying to solve, the situation that we are in right now, I'll briefly introduce what is the system that we've built and show you in action and then just conclude the presentation with some thoughts. So let's look at some of the problems. The first problem is, you know, I mean all of us do hacking but we also know that not all the hacking is fun. There are so many things that you have to go and do for each, you know, job like one after the other and if there's some kind of automation that would help all of that processes it would really be helpful. So that's something that, you know, we should be able to automate and I mean there are people who are doing it right now. So that's number one problem. The second problem is we often see that if there are no tools out there to do certain things that you want to do we start building it from scratch. I just want to point out that this is really a lot of waste and we should use whatever is out there and just keep on improving on it. The third is most of the security tools that we see these days, they're not really scalable in the sense that, you know, you can run a tool to do something at like one time and then if you want to scale it across multiple domains or whatever it usually breaks. So scalability is something that security folks, I mean, they're trying to solve but it's not really there. And then the fourth problem is, you know, with the advent of all the cloud servers like AWS, GCP, the IP addresses don't remain the same anymore, the domains don't remain the same anymore. So how do we keep a track of all these changing attack surfaces? So these are some of the problems. Now let's look into some of them in more details. I feel this XKCD represents the state of open source tools pretty nicely. Basically, you know, there are 14 tools out there and then there's somebody who wants to basically improve on it or add a new feature and then they end up writing the 15th tool, right? So this really is the state of open source tools right now. I mean, there are so many tools trying to solve the same problem and, you know, it's not really solving the problem by just adding more to it. And then, you know, like with so many open source tools, how do you actually know which ones you want to use, you know, the output of one tool might work with a different tool or it might not. So how do you compare these different open source tools that are out there? There's no standard and that just makes it so much more difficult. The third one I've already mentioned is the poor interoperability between the tools. Now, suppose if you want to use a tool and the tool only produces output in, let's say, JSON or CSV and the thing that you have, that uses a different format altogether. Again, there's no standard. So, you know, most of the times the tools just do one job and then that's pretty much it. If you want to combine those tools into multiple workflows that mostly won't work. And then the last problem that I've already discussed is the scaling and the reliability, right? Most of the tools are not scalable. You have to do some kind of altithreading. You have to use some kind of orchestration system. So the state of affairs is unfortunately really sad. Now let's look into some of the things that we know right now and that can be improved. So the first one is, you know, when we hunt for vulnerabilities in open source software or just like any software, we keep everybody saying that reconnaissance is really important, right? Like if you don't know what you have, you can't possibly hack it, right? So identifying assets is one of the most important things in basically like any sort of hacking, whether it is, you know, hardware hacking or like physical security even, reconnaissance is the key. This is just some data from last, I think this is from last year. But basically you can see almost 50% of the total number of beaches were because of, you know, assets that people didn't know they had. So the A9 is basically a standard. It says using components with known vulnerabilities. If you don't know what asset what you have, how are you going to protect against the known vulnerabilities? So just an idea of how much is out there which can be automated and just the low-hanging foods can just be gone away. And then, you know, like I mentioned, with everybody moving towards a cloud like AWS, GCP, how do you keep an ongoing real-time inventory of all the assets that you have? How do you keep track of all the IP changes? The domain names, subdomains, how do you do all that? It's a very difficult problem to solve. And then, with, you know, the advent of DevSecOps, all the companies are moving more towards agile. They push code on a daily basis, multiple frequencies. There are all sorts of regressions. There's new code that is constantly being pushed up. How do you keep up to all that, right? The attacks are constantly changing and evolving. So in order to solve some of these problems, we built something called a bounty machine. And we considered, you know, all the things that we've discussed so far, and I'll actually walk you through it, some of it. So before going into, you know, showing it in action, I just wanted to walk you through the architecture of how we think we've solved this problem. So the first thing, it starts with what we want to hack, right? Whether it is an IP address, a subdomain, a domain, an organization. So you start with that, and that value gets fed into an input forker, which then drops that value into a queue. So basically, the idea is a very asynchronous microservice based architecture where it's horizontally and vertically scalable. And you can do that against not just one domain, but multiple domains at a second. So the first step is this. And then after that, the queue that gets that value, it passes on to a different worker, which is where we'll be running all the tools. We'll be doing all the scanning, right? So we call it the workflow worker, right? And then after these workflows finished, they drop the results into a different queue. So you can see it's all based on queues. It's all horizontally and vertically scalable. And then suppose if you want to combine multiple workflows, right? Suppose if you want to scan all the ports, and then after you scan all the ports, you want to find out what are the different CMS systems that the server is running. So you want to be able to pass the data or information from one workflow to the other workflow. So the idea is that, again, you can just link multiple workflows together. And then once the workflows finish, there's a worker that kind of compares the results from the previous run to the new run, right? So one of the biggest problems in bug boundaries is that if you keep running the tools again and again on something, you'll keep seeing the same information, right? But ideally, you want to know if something has changed. And if something has changed, what is new in that new attack surface, right? So we have a concept of a diff worker which just kind of compares all the results that have been stored in the database with the new run that we just ran. And then it just sort of outputs all that information into a different queue. And then from that different queue, we have a notification worker which just takes all that data and spits it out into whatever output you want to have. So we use Slack for right now. So we use Slack to start the workflow and Slack to receive all the output. But this can easily be changed into, let's say, CLI of website. So just the concept of it's very extensible. It's all mutually separated from each other. So if you want to add a worker that just notifies, you can do that easily as well. So in the end, the entire architecture looks something like this, right? You start off sending your attacker whatever target you have into a queue, which is then picked up by the workflow worker. We run a bunch of workflows which are basically open source tools. So if you have your own tool, you can do that. And then after that, the results get split into a diff worker queue, which kind of differentiates the results from the old run to the new run. That spits into the notification worker, which finally shows you all the output. And all these components that you're seeing, they're all running as containers on a Kubernetes cluster on a GCP or any of the cloud where you want. But the idea is that you can have multiple of these workers as well. So you can see how horizontally and vertically scalable this really is the whole architecture. So in terms of the workflows, some of the workflows that we have built so far are to find all the hidden files on a particular domain, to find all the cross domain.xml files which have star entry, which means you can basically host a file on a website and then xfill data out of it. And then there are things like doing a port scan, so for all 65535 ports. There's tools, there are workflows that find open S3 buckets. There's a workflow that looks for all the open, like if it's a Jenkins system, if it is WordPress, is it running any plugins that are vulnerable to known vulnerabilities or not. So you can see these are all the different workflows we have. And they are all sort of separated as well. So if you can think of a new workflow, you can easily go and build it. And let's see. So there's a recorded demo because I only have 20 minutes. But before we actually see it in action, we set up a target. We made a company. We called it Ellingson Mineral Corporation. And there's just two things that we know about this company. There's a GitHub organization's repository for this. It's called Ellingson Corp. You can go check it out right now. It should be online. And there's the domain EllingsonCorp.com. Now if you, as a hacker, if you want to do your reconnaissance on this asset or if you just want to hack this, how would you do it? You would go through your written notes and you would try to follow it step by step. Instead of doing that the way we do it, and there's a recorded demo. So I've actually recorded it and uploaded it on YouTube if there's internet connection on this laptop. So you can see that the way we start this whole reconnaissance process or the tool is that we have different slash commands in Slack. So the first thing we are going to do is we're going to find all the secrets in the organization's GitHub repositories. Probably can't see the command. So I just added a slash command to find all the secrets in that repository. And then the next thing I'm doing is actually providing the main domain to the tool. And you can see that it actually spits out all the secrets which are stored in that GitHub repository. It also spits out all the subdomains of the main domain. So you can see that. Is it? Yeah, I guess it's a bandwidth. I don't know. We'll see how this works much better. And then after it spits out all the subdomains, it actually finds out all the open S3 buckets for that subdomain. And then it also shows that that S3 bucket is listable. It's writable, right? So all the information is right here. Moving on, you can see that it identified two subdomains that can be taken over, which means that if you can just go and register a subdomain and have the CNAME point to it in the right way, you can actually take over their subdomain, one of the subdomains. Moving on, it shows all the port scans of all the subdomains. So remember, we started with the main domain. It actually brute-forced all the subdomains. And then it actually port-scanned all of them. And when I say port-scanned, I'm talking about all 65535 ports. It's not just 203 ports or the first 1,000 ports. It's basically the entire attack surface. And then it shows the status of the ports so that they are open or closed. After that, it sort of identified any course vulnerabilities. For those who don't know, course is the cross-origin resource sharing. And if they're not set correctly in the headers, it might result in different kind of vulnerabilities being exploited. And then you can see that it identified a cross-domain.xml file, which had a star entry, which basically means if you have control, you can take over. It identified all those hidden endpoints. You see there, robots are TXC. And if there was a secret endpoint, it actually identified that. And then this is the best part. So it actually port-scanned. It identified it was running port 8080. And it actually scanned for what kind of server this is. And it found out that it is running Jenkins. And it ran and exploited against that. And then this is the output from that exploit, saying that this installation might be vulnerable. So you can see how it started from a main domain, it's going all the way towards the end. And these are all the issues about the known CVEs against a WordPress sub-domain that it found. Moving on, these are all the JavaScript endpoints. So these days, you'll often find that in the HTML source code of different websites, websites basically have a way in which they kind of import JavaScript from a third party. And oftentimes, we see that they'll have sub-domains in that HTML source code, which are no longer valid. So if you can take over that sub-domain, you can basically serve your own JavaScript file to the website. So we have a tool that actually scans for all the known JavaScript endpoints and tries to see if there's anything there which is not already registered. It tries to see if there are any secrets in the source code. So you can see that it found a JavaScript endpoint, and then it scanned those endpoints for further endpoints. So these are all the JavaScript files you can see, again, JavaScript endpoints. And these are from different sub-domains you can see. The last one is from sredorlingsoncard.com. The one before that is from Help. So it's actually scanning. It's kind of spidering out and doing it for all the sub-domains. And then moving on, you can see that it actually found that there was a MySQL server running on that IP address on the port of MySQL, which is 3306, and it was able to brute-force it. It found out that the user was rude, and the password was a password. So again, you can do some basic brute-forcing attacks as well by just going through the attack surface and knowing what to scan, when to scan, right? Then I think that's pretty much it. Yeah, so I've basically showed you in action all the workflows that I discussed. And if we look closely here, I don't know why it's so slow, but I'll just walk through this like this. So we basically started here, right? We just knew a domain and the GitHub repository of that org, and we were able to find all these things just from that simple reconnaissance. And the approach of spidering towards all the attacks, surfaces that we've identified. So again, this is too small, but again, we found out three buckets, sub-domains that can be taken over, secrets committed in their GitHub repositories, JavaScript endpoints, secret files hidden, all of that. So in conclusion, I just have a few things to point out that obviously automating everything is not practically possible, but there's still so much in terms of low-hanging fruits, in terms of some basic scanning that we don't do a good job of and we should do it. So there's a lot we can automate and we should. And then this actually helps, so you can see all the information that I've received. It actually helps me to go out and do more further attacks and exploits. And all the scanning work is already there for me. I just have to go and use that data. And then exploring new technology. We in the security industry, we are very skeptical and often intimidated by using containers or orchestration systems, but we've actually used all the latest technologies and then built something for a security problem. So that's really important to know. Keep tooling simple and consumable. Oftentimes we see a tool that tries to do all things at once. We've seen that it's not really scalable. If you wanna combine multiple tools, it's really difficult. So just keep it simple and just improve on existing tools that are out there. Don't try to build something from the scratch. So that was it. Any questions? No, so there was one more slide that I wanted to show, but I can't hear. But basically all the workflows that I showed, all the different tools, all the tools are already open source, but we're not gonna open source the entire architecture, but I've shared the high-level overview and it's really simple to just go and build something like this out there, but the short answer to that is no. We're not gonna open source it. Any other questions? All right. Thank you folks.