 Hello, my name is Sean. Hopefully all of you are here for a bug bounty hunting talk. If not, you still have like a minute to leave. Otherwise, this probably will be a bit too boring for you. Nice to see you all. Thanks for coming. This talk, you should expect just like a light beginning talk. We should not dive into like any two technical details. Though, feel free to interrupt at any point. Feel free to ask any questions. I'm perfectly fine with saying I don't know what you are talking about, and we will just continue, or I will try to answer to the best of my abilities. So yeah, my name is Sean, and this will bug bounty hunting talk. Feel free to come in, guys. Also, if I'm not loud enough for the recording, by the way, hi, guys. We're online, then just tell me. Right, OK. Thanks for the doors. That would be disturbing. All right, so what's in front of us? First, I would like to give a bit of my background, and how did I end up bug bounty hunting? What things did I manage to maybe do or find? Then I will tell you a bit more about today to day things that you do as a bug bounty hunter. Where do you do it? How do you do it? Then I will tell a bit more about things that you actually are expected to do, and things that you are not expected to do. By the way, maybe just let's start show hands who knows what the bug bounty hunting is. OK, good. Who is a bug bounty hunter? OK, that's good as well. So I can say, or was there a raised hand? OK, OK. Sure, sure. That's good. And then I will try to give you a bit of a demo, or it won't be live demo that technology is failing me today, so unfortunately. I can't do it live, but maybe it's for the better. First, what's my background? Well, I, oops, and this. OK, perfect. What did I do? So I pressed different button and things. That's a great start. OK, so just start the presentation again. Cool. Things break. That's why we can hunt for bugs. So that was unplanned demo. All right, so at the end I would like to end with a demo. Just like to show you practical reports that might be interesting for you. What's my background? I did some mathematics. I'm trying to, or saying this, because you can come from any background. It doesn't matter what was your original, maybe. Did you pursue originally? But don't worry, there won't be that many equations. Every equation in slides is bad, as I heard. So let's not go there. I worked for some corporates. I worked for smaller companies. And I also did some forensic analysis, not this type of forensic analysis, rather this type of forensic analysis. So just looking into bits and bytes and try to get some meaning out of them. And right now I'm doing PhD at Crocs at the different faculties. So if you are confused about Verdi venue of Def Conface, there are two faculties in Burna. And the other one is my alma mater. And I ended up doing Babontis roughly two years back during COVID. And I worked on various programs for companies. So you might recognize GitLab or GitHub. Maybe you don't recognize this one. I think it's Ivan or some different company. I also find something during COVID in one of the European Union projects for digital COVID certificates. There are also programs for companies that do not disclose that they are running Babonti program and that those programs are considered private. So some of the things that I will be telling you about, I won't be telling precisely in details. What's the company, for example? Word of caution, just a disclaimer. I'm not inviting you or giving you the right to just go heck on the internet, of course. That's up to you and your responsibility. Just so that the lawyers are satisfied. Also, everything that I'm saying is on behalf of me and not my employer. Right, so Babonti hunting, founding bugs, founding security issues, vulnerabilities. Is it actually ethical? Well, the state of the things evolved, but thankfully nowadays, there are ways how you can just go heck on someone else's software, meaning that you just go as much as you can, go deep, go wide, try to find issues, try to leak data from the website, try to do remote execution or whatever, and still remain ethical. So it's sort of like a win-win situation. You will learn something, you might get, or gain some bounties, the companies will eventually get more secure. So that's where we are at right now. It wasn't always the case, so I'm quite happy about this. I'm not sure what are your expectations, even from this talk, but it's like, okay, I want to see whether I should get into Babonti hunting. I feel like often the misconception is that it's some kind of a get-rich-quick scheme that you just like, okay, I know software, right? I will just sit down and play around and find bugs and maybe some RC and suddenly I will make a lot of bugs. So I would discard this approach just because it might take you a few months before you find actually something reasonable, that someone else on the other side of the globe will be willing to pay you for, even though you two have never met before. Though, to sort of start on the more nice side, yes, it is possible to make some bugs, and I'm worried to press another button here because I would like to show you, is this deglazer, do you know? Let's give it a try, okay, at least. Cool, so what are you looking at? This is a GitHub page of Shopify, that's an e-commerce platform that allows you within just a few clicks create your ad shop and you can sell goods or whatever to customers. So a lot of money flows maybe directly through Shopify or indirectly from some other banks that are involved. And I mean, it's a good company, right? They have GitHub, so they must be good software buys. But only as long as another guy like Augusto shows up and just throughout other project that he's working on, he stumbles upon some repository that maybe he want to use or something. And so he's like looking into the code and suddenly there's, oh, there's .enfile. And you're looking at the report that he created for Shopify. And so he was going through some Shopify's code and suddenly there was .enfile. It's like, that's configuration file, right? So first he was like, I'm not interested in that because I'm looking for the functionalities of the code. But then it contains GitHub token. And what's the point of GitHub token? Well, you get read or write access to the repositories, right? So to all the things that I was showing you here, this is one repository, but to other repositories as well. So just like he stumbled on it maybe just by chance, but it's quite critical, right? Because now you can do big door of all Shopify products. It is even authorized because you are using GitHub token, right? So it's like you are not hacking through the software, through the server to change the production software. And what's the payout? Well, it's 50 grand, right? So that's a sum that probably people would be willing to switch jobs for and just go hunt bucks. But again, especially finding valid GitHub tokens, nowadays it's, I would say quite rare, GitHub scans for all the code. The tokens nowadays are not just like some random byte strings, but they are also annotated or there's a tag like this is GitHub token or Shopify token, something. And so you can just grab for them for every commit. And so finds like these are quite rare. Nonetheless, they still happen, but don't go into bug bounty just for the money. However, what I can promise that you will get out of the bug bounty hunting is learning or knowledge. So I cannot stress this enough, like this is basically infinite amount of sort of opportunities or possibilities to learn interesting things. So if you are into this and you say, yes, please, I want to learn, then definitely go ahead. You can basically go as wide as you want, as deep as you want. If you have like a language that you would like to work on, you can just find a project that has a program listed as a bug bounty program and you can just spend your time there. And not just you learn, but if you find something, you can go then report it and maybe get a few bucks out of it. There was one thing, like what maybe your motivation should be. Now I don't want to offend anyone, but even though we are sort of developer community and we have points that we feel strong about and we are on the same boat, I would still try to convey that for hackers, the intentions are quite different. I know people often I want to reinvent a wheel and they want to create new projects and so it's like, yeah, new features, like project manager will be happy, customers will be happy, but like some kind of bug fix, like I don't care. Like the bug shouldn't be there, right? But it doesn't bring anything new. For the hacker, that's precisely where we want to look. And it's like, if you read documentation and you write as a developer, this endpoint is authenticated, like I don't trust you. I don't care that you want this endpoint to be authenticated. I will just like make few curl calls and see whether it actually is. If you say you cannot enumerate whatever emails through the Reset password feature because we are rate limited or it's rate limited. Well, have you tried it? It's actually rate limited. Maybe you are running through some cloud fraud or something and the rate limit breaks in the path. So hackers will go and test all the claims that you have, so they basically have this as their motivation. All right, so if you want to go and actually start hacking ethically, there are a multitude of programs. So there's hacker one, there's integrity back out as well. Maybe another question. Is there anyone from a company that you know that you have a bug-bounded program so that, okay, too, cool. So basically maybe you are using like one of these platforms as a company. It's basically a game of three entities. Me as the hacker, the companies, for example, GitLab or GitHub that are running the program and the platform itself. The platform is sort of like a mediator between those three because you can also imagine, and this question that I often get, like how do you know that they will actually pay you, right, you spend like weeks and weeks, you are finding all those like good vulnerabilities that you can exploit, but then you just like leak the information to the company, they fix it and then just like, we knew about it and we won't pay you a thing. So that's why, or one of the reasons why it's good to have the platform as well because the platform sees the communication between the company and the researcher and they can say, hey, like, you are claiming that you are not obliged to pay but we have this in the terms of conditions, in the contract with the company that you are supposed to pay and we will make sure. So that's what sort of enables this to actually be practical. Also for the company, it's much easier, they just like, I haven't ran a program so I can't necessarily go into the details but I imagine that the company just gives a bulk of money to the platform and the platform then can just like pay to the researchers so it's quite a smooth process. All right, again, if you have any questions, feel free to stop me as I go. So if you go to the platform, you make an account and you want to go check a program. So what programs do we have? So there are public programs and private programs. The public programs are usually like, the big players do have them, right? Everyone knows there's a GitLab, GitHub, Facebook, Google, whatever, so it doesn't make sense to hide the fact that they have a program. They are also quite big so that they can manage the program. If you imagine that just like the whole world goes heck on GitLab, it will create so much potential noise for the company to go through. So the big players are public, some smaller companies are private. The one of the reasons is not like they are trying to obscure the fact but they simply are starting the process. So if you are in a company and you are thinking like, is bug bounty program something for us? Well, there's one way how you can get into just have a private program, just say to the platform, okay, we expect only like few tens of reports because we don't have the manpower to go through all of that. So this is sort of the page for the program. There are some statistics like how many reports have been resolved. This is not really up to date as of today. So don't take it as a fact for now but there are at least 1000 reports on GitLab. One nice thing, for example, is the response efficiency because you can imagine that you spend weeks finding the bugs, then you report and then you just sit and wait. And here you would expect it's probably better than in some open source project that only one person manages but I can tell you that you can take weeks or now you're sitting on possibly remote code execution and just like nothing happens. So 10 hours for GitLab, that's exceptional. And of course, we are interested probably also in what are the categories and what amounts you can actually get. And so there are low things for just few hundred bucks. So if you find just like something like you leak email address here and few addresses here and so on, nothing that important, that's probably like hello. If you get remote code execution, SQL injection, things like this, that's critical. That's another program that can be private, for example, but this one was just deducted for the purpose of the talk and it's GitHub's actually, they also get a good response efficiency. Another important part or aspect is the policy. So what actually makes this legal or ethical? So as part of the page that you've seen, there's also just policy, just straight up text like you can do A and you cannot do B. I'm not from the USA, but I know about the Computer Fraud and Abuse Act which basically to my understanding sense like if it's not yours, don't touch it digitally. Like you're not authorized to do so. But GitHub has especially or the program to especially say like you are authorized to do this as long as you follow this policy. Though if you violate certain restrictions, you suddenly go beyond this policy and it might just mean that, okay, we are interested in the report but we are not paying you anything or we ban you from our program or we ban you completely from the platform or maybe even more severe consequences. The policies differ quite a lot. So this is GitHub that's quite nice. Like GitHub is a software company, right? So they understand a lot of the things. PayPal on the other hand has something in the policy that can even this sort of make you not want to report to them. You don't have to read the whole thing but basically they say if you report to us, you hereby grant PayPal and not just PayPal but basically anyone we choose to like subsidiary basically it's customers irrevocable right or license to the things that you've given us, okay? It's not exclusive so hopefully it's still yours but we can publish, distribute, we can sell, offer for sale and do whatever. And this like for some researchers, this is like well I don't want to get into this like I want to just submit a report, I'm not giving you a license to just go sell it suddenly. And they even explicitly say like well don't submit to us if you don't want to and I can tell you like this was one of the reasons not to submit to PayPal for example. So that was sort of on the high level and now what you can do and cannot do so the next thing it's the explicit listing of things that you can hack on. So those can be any assets you imagine, those could be IP address ranges just like from this range to this IP address you can hack whatever you can scan, you can run automatic tools. It can be just the GitHub repository, it can be Android, iOS app, it can be like a hardware product, maybe hardware wallet that you can hack. And with those things like do whatever you want, like green is good, but those are things that like you cannot touch. Maybe the company acquired like a small business so now you know that it's part of the bigger business but they are first going internally trying to fix all the issues that they are able to fix. And you can really break things as you can probably imagine if you like try remote code execution and production website and you break everything. The next thing that's important is impact. Maybe you are like, if you want to contribute to open source like people care about like typos in documentation, small things, small bug fixes like things like these. But for bug bounty hunting, it's like we want something that's actually practical that there is an impact. Like if you leak one email, maybe like we don't care that email probably exists on the website somewhere on the internet somewhere as well. But if you leak like the whole database or if you have remote code execution like yes, we do care. And this differs per program. So it's not like you get the denial of service on GitLab and GitHub will pay you the same or even more. That's what I experienced. Like GitLab said, yes, this is high severity. We want this. GitHub says, oh, denial of service. Sorry, we don't care. That's not even known. And so for example, self cross-site scripting meaning that you can save on the website your JavaScript but it only affects you. So for example, it's in your, I don't know like bio that only you see or something like that they don't care. It's excess says that's good but it's not impactful, impactful. Right, so again, if you have any questions, feel free to ask. Right now I would like to get into more specific reports. Unfortunately, the ones that I reported are not disclosed. So I cannot go through these but there is one guy, William Bowling that does seriously good stuff on Hacker One and it's all disclosed. So we can just look through the reports and hopefully you will see as like how good of a resource the activities are. And so one thing that I have mentioned is that the platform sort of gamified the whole experience. So right now there are things like rank. Okay, for William for some reason he doesn't have a rank assigned but basically you can say like, how those are the top 10 hackers in this year, top 10 hackers on this program. There is some kind of general reputation like this guy knows what he's doing. There is some impact. So like if he reports, it's really impactful. Okay, it's not like just some rubbish that maybe would cause something but not in general. And then there is a signal like if he says something, it's not noise. Like you should go and listen to his stuff. And you can see that Vax, by the way, if he ever listens to this, thanks a lot. That's really good research. And the resources, for him it just works to go direct to GitLab and to specialize on GitLab because it's not a small feat, right? I'm not sure if you are familiar with Ruby, Go, all the backend stuff. You can deploy different Docker instances and see how all these things interact together. So it makes sense to just like go specify on GitLab. I also said like you should not go in it for the money but you can see that for Vax it kind of works nicely. He has several arbitrary file reads. So if you have a server, you have slash ETC, slash password, you can get it. You have remote code execution, stored, cross-site scripting, another remote code execution, another one, another file reads, et cetera. So that's very good stuff. And we will go through one of these. I suppose all of you are familiar with GitLab. I don't have to explain. You short code, you version code, you create issues so you can write some text, you can get the XSS, that's just for the examples. But now remote code execution when removing metadata with XIFTool. So who knows what XIFTool is? Okay, so imagine you have a JPEG, you take a picture and it stores also GPS location, timestamps, what kind of device took this picture, right? If you imagine that you would have access to all the data of all the profile pictures of GitLab, you would know basically the location of like several thousands of people, right? So that would be an issue. So what GitLab does, it takes XIFTool and run the images through this tool and it strips the metadata. It can strip the GPS location, I'm sorry. It can strip the GPS location, it can strip whatever, what device took the picture. And so what they do, they have a runner, GitLab Borg Horse, and whatever you upload for images, at least conceptually, it goes through this tool, it strips the metadata. But there's a clash of what GitLab expects and what the tool expects, okay? GitLab just goes, maybe it would be test if I show you the code. So, okay, so we have something like this. You upload an image and it goes to some part of code that asks, is this XIFTool? So it should be running through the XIFTool. Well, there are some regex, that's always good for background hunters if there are regexes. So we just check, is this JPEG, JPEG with E or TIFF. And if it is, we mark it as something that we should take care of. The next thing is the problem where, okay, so GitLab thinks that based on this code that you should go through it. But once you go through XIFTool, it doesn't check the extension, but it checks the header of the file, just like reads through bytes and see what kind of tool it is. And so you might actually end up with a different parser that parses DjView. And I have no idea what it is, but as a hacker I don't really have to care. But my point is that I'm able to make this clash of what you expect and what the tool expects. And so you suddenly can feed any file and make it parsed by this kind of parser. And unfortunately, it's possible to get to a state where even though there is some check, so there's maybe again some regexes, but the JPEG file that will get parsed will suddenly end up being evaluated. So if you've been to any basic 101 faculty course on security coding principles, like do not write, evaluate, or system calls, or whatever, because suddenly they can end up here and the file that Wax has uploaded will get evaluated. And the payload sort of, the file that he uploads is not that complex. You can just see it down here. So it's just this thing. So you get some metadata, some copyright, whatever. Then this is the crucial bit. You escape a new line. Suddenly all the checks break, and then you can just run arbitrary parallel. So you just echo Vax into slash temp slash Vax. So just like a proof of concept. This is by the way a very good example of how you can prove to them that this indeed works, for example on GitLab.com. You just create temporary file, no harm done. You don't touch any ATC password. You don't try to like, oh, like I'm such a good hacker. Like I can remove something from the database. No, no, no, you just like show them. I can run echo. That's it. Like now they know. And now you have a report for 20 grand. The whole sort of steps to reproduce are only those two five. So just download these payloads. You create a new snippet on GitLab. You attach the file, you select and upload, and suddenly the file will appear on the server. Nothing too complex. There's lots of text to sort of describe, but this is, those are the reports that if you want to learn things, just go to hacker1.com slash hacktivity and find these reports. Maybe one more that I can show you. That's also, so this was a remote code execution, right? So this is, that's very good. But maybe you can just get arbitrary file read and how this can happen. Again, it was critical. There was some path traversal, meaning that our input hits some code that can traverse your file system and maybe retrieve file that you weren't expecting the user to end up with. Again, serious bounty for that if you are into that. Actually, one thing that I haven't mentioned, like the people that read this on the other side are not necessarily like as good as the researchers as you are, right? And so sometimes it's just nice to attach a half a minute video of like what actually can happen. And so thanks to that, we can try to watch this. Basically, again, we have a GitLab. I'll just comment it. So there is some GitLab. You don't even need to like have access to some special, special project. You only need two projects that you can create yourself. You create a new issue. So whatever some issue and you paste a special payload. So if you know markdown, this is like a link or attachment A and it goes to some slash upload slash one, one, one, one. And then now we see the path traversal or at least the attempt. So we are jumping into the parent directories. Oh, hey, and now we have the ETC password. That's the file that we are up to. And this is just like a comment in snippet, right? Like how can this have any effect? So you save the issue and now you have the issue. And what you can do with GitLab is you can move issues between projects. So we just say like, oh, this was the wrong project. I want to move it to different project. So let's see what happens. So you move it to some different wax project. And suddenly, yeah, it worked. So you have issue. There is a sudden attachment with password. You can download it. And if you view it, that's ETC password from GitLab.com. So again, Alfred, it's two wax for this very nice find. Is it hard to recreate? Well, you just saw, like just create projects at an issue, copy paste this, where you change the file that you are interested in. The smart-down is broken, but just like move the issue to the second project. And that's it, three steps and you have your file. However, finding the issue is the crucial bit. And that's hard. But if you as a company run back bounty program, you incentivize researchers, hackers all over the world to just like go spend some afternoon or maybe more afternoons because understanding GitLab will take some time. But because our thanks to it being open source, you can just like, it's out there. Like you can just go and see and try to find issues like this. And basically that's about it. To wrap up, a few things. So those were the slides for the issues. What things can you hack on? Well, there is also internet by bounty program where basically the big players put money into one big bag and then you can pay out for different smaller projects. So if you find something on Rust or Rails or Curl or Lip SSH, Nginx or OpenSSL and not just like the software products like the ones we know, but for example, Xro which is a project between different countries in the northern part of Europe. So Estonia and Norway, et cetera, they're using this as a data exchange layer. So they also run a bounty program. And not only these things, but also European Union cares about things like mastodon or library. So you have on integrity, you can just like go hunt on these. Google, of course, they have whole platform for themselves. They can by the way support also researchers for just like they give you budget. If they trust you and your knowledge and you say, okay, I'm going to fix this open source project for maybe a few weeks. So that's also another possibility. I haven't talked much about tools. Like you can imagine, you can do all sorts of analysis. You can automate all different things. One thing that I would stress is like you find a bug. The platform or the program tells you have you fixed it. Well, then you just go and check whether they actually fixed it. This was probably the easiest money that I ever made. I just rear end one crawl command and said like, no, no, you haven't fixed it. And within a few minutes, I get a few hundred bucks more because they just saw that like their fix was not working and they got this immediate response. So yeah, there's a bunch of tools. No time to spend talking about those. There are nice resources that you can have a look around the activity on hacker one. There are nice podcasts, critical thinking, zero day or more. If you're more into cryptography, there is a security cryptography, whatever podcast, very nice one. And I will also suggest one of my friends, which is Mr. Problem, it's a Czech podcast, not really about bug bounty hunting, but rather about various ways how to think about things. And I think that's related because you sort of have to step outside of the regular developer creating issues or features writing code. You want to really understand how things work and interact. And so be careful because there is a user input everywhere. It can get very nasty. It can be quite easy as we've seen. And stay safe. That's basically all from my side. And if you have any questions, hit me and also we'll stay around in the hallway if you want to discuss. With that, thanks a lot. That's it. Okay, so the question is how do the private programs work? They basically work the same way. You have to be invited. So after you report a few things that actually make some sense, they have impact, you will suddenly start receiving emails from heck around saying like, yeah, we want you to hack. Interestingly, interestingly, you only have like a week to actually submit the, or respond to the program. And there are various things also, like people just have a like a window of two weeks where you can get like twice the payouts for the issues and it differs per the programs. You can also be kicked out of the program if you don't hack on them. Okay, any other questions? Yeah, there's a very nice question. What do you do if the company that you found back in doesn't have any program? I would say they should have. So as soon as you do any website or whatever, at least have your email there that you can access. If they don't have, it sort of depends. Like I've been in cases where I found various tokens that for example, for GitLab, if you find active token, you can just query one API endpoint and see whether the token works. So sometimes you can like check whether it's a valid find and you get the email address of the one to whom the token works. So you can just submit to them directly. Sometimes I just try to just search for security at that company or just like any email. And sometimes you just don't get any response and like that's it, the end of story. And they probably don't care. Yeah, it's sometimes hard. We have one more minute for questions. Last one, yes. Yeah, nice question, yeah. Nice question, thanks. I think I get it. So basically how do you start? Do you go through various services? Do you just hunt for one buck? The one thing that you suggested, just like if you are good with, I don't know, networking or like TLS, just like go try to like go for engine X and try to see how the code behaves there in the areas that you do understand that's a good start. If you just like don't know, there are capture reflex games where you can just like play around and you will get the results or like you will learn more easily because the things are prepared for you to learn more. If you know a little bit more and want to find the good stuff, go read the activity reports and then try to recreate them. But it's like it varies. Like for example, I didn't know PHP but I wanted to see what are the bugs in PHP about and so I was just going through PHP projects and learning PHP and finding things there. It can take time, it can be like months before you actually find something impactful. Okay, I think we are out of time. I'm not sure whether the chair agrees, if so then. Okay, if you have any more questions, I'll be around, feel free to ask me. Otherwise, thanks for listening and have a nice rest of DevCon.