0:00

Code review is the skill that can take your hacking to the next level, especially when you know in which software to look for bugs. And today I'm joined by Shubs who knows this better than anyone else. Enjoy the interview. Hello Shubs, thank you so much for joining me today to talk about bug bounty and your your hacking tips. For those of you who don't know you, how did you start with hacking? What's your background? Yeah sure, so I started hacking when I was maybe 12-13 years old. One of the things that drew me into hacking was just because my dad had bought us a computer and my brother and I we used to play online games together. But my brother used to always beat me at these games which really sucked and I really wanted to to get either good enough at these games or figure out a way to beat my brother. So I got into game hacking initially. I looked into making things like undetectable cheat engines to bypass anti-game cheat detection and also looked into things like aim bots and things like that for the different online games that we were playing. When I was about 13 I also realized that there's this field of web application security and that was really something that I only realized after connecting with people in the game hacking scene. And from there I was able to really develop a passion and interest in web application security specifically. And that passion and interest has basically come through all the way until now. That's something that I've heavily specialized in. That's something that I spend almost all my time in when it comes to information security. And yeah basically from game hacking and getting into web application security, I eventually got into bug bounties. But the story is essentially that when I was around 14 years old I was working at Hungry Jack's, which is the equivalent of Burger King in other countries. I was making like $6.50 an hour, which isn't really a lot of money to be making but at the time you know I come from an immigrant family, we didn't have that much money, it was still an incredible opportunity for me. But I was also doing bug bounties as much as I could at the time. And at this time there was no HackerOne or BugCrowd really, maybe they were just getting started off. But there was Microsoft and PayPal's bug bounty. And I was submitting bugs to PayPal, a lot of the bugs had almost no security impact. However one day I came across a server-side request forgery bug that affected BillMeLater, which is one of PayPal's acquisitions. And at this time PayPal was running their own bug bounty, it was not managed by any platform or anything like that. And I submitted it and they paid $1.5k USD. At the time I had been working at Hungry Jack's for eight months and I'd only made like $800 Australian. So when I got that bug bounty I basically never showed up to Hungry Jack's again. Did you literally the same day? Yes, literally I never showed up to Hungry Jack's again. Because it was very difficult work and it was very hard work and making $6.50 an hour, it was not really worth it when I could just spend time focusing on improving my skills in application security and specifically finding vulnerabilities for bug bounties. So along the way I participated in a lot of different bug bounties initially, just for the Hall of Fame initially, but eventually I got into the bug bounty platforms like HackerOne and BugCrowd. And since then I've just been focusing on high-paying bug bounties. For how long did you then stay doing bug bounty for full-time? Yes, I was still in school at that time so I was still I guess balancing school work and doing bug bounty work. But it was something that I did pretty consistently. I didn't make that much money to be honest. In the first couple years of my bug bounty journey I don't think I made anything close to what I've been making in the last few years in the bug bounty scene. But I was balancing obviously my high school work and trying to get into university and things like that. But full-time I've only done bug bounty while I was living in Europe, when I was living in Poland in Krakow. So I did full-time bug bounty for around a year when I was living in Europe. But yeah, along the way I mean I had a lot of opportunities here in Australia which I'm very grateful for. When I was 17 and I had finished high school I had sent an email to all of the pen test consultancies in my city and I'd asked them whether or not they would be willing to accept an intern. And I think the fact that I had submitted to a lot of bug bounty programs really helped with that cold email outreach. And one of the security firms in Australia did come back to me and said that they'd be interested in doing an interview. I'd passed that interview and I was very happy to I'd passed that interview and then I joined as an intern. Unfortunately it was a unpaid internship so I didn't get paid anything but I worked there for around six months and I learned as much as I could about consulting and pen testing and all of that. And that was a very invaluable experience for me at 17 years old. After that I worked at Atlassian as a contractor where I found one security issue a day for 30 days. And then I worked at Ernst & Young as a consultant working in basically any security related projects. And I was probably around 18 at that time. And finally I ended up working at Bishop Fox which was a US company that focuses on offensive security consulting. And I was there for two years ending up as a senior security consultant. After that I then co-founded my company that I have now. What were your favorite places in Krakow? Because for those of you who don't know right now I'm in Poland, I'm in Krakow which is exactly the city that Szabz mentioned. Szabz in Australia we have 10 hour time difference so we are pretty much as far from each other as we can be but turned out that he lived in the city that I'm living now so we are your favorite places? In Krakow I don't remember the names exactly but there was a place that Julia used to always take us to where they had all these different types of vodka shots. There was like a few of them in Krakow city. I forget the exact name but probably Pijalnia Wódki i Piwa on the Szabzka street. Yeah, yeah that's probably it. There's also a place called Multi Kulti which is yeah it's got all types of different beers like maybe 30 beers on tap or something which is incredible and yeah really nice spot to just hang out maybe just go with a few friends to the smoking area drink some beers have a few cigarettes you know that's definitely one of the areas that I spent a lot of time at and yeah I guess generally with Krakow it was just you know I love the scenery of Krakow I loved walking in the park love seeing all the beautiful green trees and going to the cafe every morning and going to all these different bars and the nightlife was phenomenal the people were quite good as well so it was a great experience I mean I don't I definitely look back on those memories fondly but I think there was a bit too much drinking going on to remember all the names of the places that I went to. Yeah, yeah but it's great also I've just been before this podcast half an hour in the park very very sunny day very green to chill out and I really really like it. Now at Assetnote do you still do hacking or do you do you do something else? Yeah, yeah I still do hacking so at the moment I'm managing our security research team so we have a team of three people excluding me so it's four people total and basically we take apart enterprise software we find zero days in them and we ultimately do this to find vulnerabilities that we can check for in our platform inside Assetnote and all of our customers they get a basically an advanced notification of any of these zero days that affect their infrastructure. The really good news is that because we have so many customers at Assetnote we can use that information and that data that we have to make really informed decisions about which technologies we should go after. We only really go after technologies that are being ran by our customers so if we notice that a customer is running xyz enterprise product we will you know obtain a copy of that reverse engineer it find zero days and add it to our platform so it is something that we actively do for all of our customers and yeah these days at Assetnote I mean it's a mix between I mean it's a mix between a lot of things as a co-founder I wear a lot of hats I do a lot of customer support I do a lot of engineering and I do a lot of security research so those are the three main things that I focus on at Assetnote and really I'm not afraid to do anything necessary to move the business forward so you know some days I might be doing six hours of customer support work and that's fine like I'm happy to do that that's no big deal I think that by me being able to provide this information and support to our customers there's not that many products that are that are doing that sort of work so it does differentiate us I think greatly from our competitors that you know even the CTO is doing support work Which activities are your favorite? Which is what my favorite sorry? Which activities that you mentioned are your favorite? Definitely security research I mean that's by far my favorite I do a lot of security research with our team and you know managing a security research team also is quite interesting because not only do you have to figure out the targets for the team to go after you also have to do a lot of the work to set up everything in a way that minimizes the amount of time taken for the team to get to get started with this sort of stuff so often I am finding myself setting up enterprise software and I guess getting everything ready but I do also spend a lot of time actually working with my team finding the vulnerabilities as well what I've found is with adding more people to the security research team at Assetnote the chances and likelihood of exploitation of harder to exploit issues has gone down because of the collaboration element between us and you know things that I would typically be stuck on in the past has been things that we've been able to solve recently due to the collaboration element that we have and that's been really really good and I've also noticed that you know a lot of the people that we've hired in our security research team they have different personalities perspectives viewpoints methodologies that ultimately are all complementing each other I mean for me I personally tend to think very quickly and get through things as quickly as possible but we also have people on our team that are really good at that and do take a lot of time to go through each individual controller or whatever is being mapped to an externally routable endpoint so I'm seeing that the methodologies that we have have a lot of benefit but yeah ultimately I do love security research that is my favorite thing how do you split projects between people in the team does do you all work on the same project or do you does do you all work on the same project or is it individual and then you ask someone for help how does it work it's it's quite dynamic so I mean at Assetnote we we see our security research team functioning in basically two major ways one is the proactive security research and the second is the reactive security research so for us you know if anything drops on the internet if there's a vulnerability in xyz product and there's no POC our security research team is responsible in in order to figure out what the POC is so they will have to download the software reverse engineer it find the POC and this also goes for all sorts of other vulnerabilities that are dropping on the internet so if there are things that are dropping on the internet our security research team is responsible for investigating it and adding a check to our to our platform but we also have the reactive side now the sorry the proactive side and the proactive side is where we go out and we actually do security research ourselves and do original security research the the to answer your question when it comes to splitting up of the team it really depends on what the priorities are sometimes we have a lot of work from the reactive side that requires a full resource to be focused on that reactive work so that they will be doing that work and not the proactive work but sometimes we can work together as a team we do tend to give entire projects to an individual so let's say for example we are auditing moodle for example that would be assigned to a single security researcher here at asset note and if they do find anything interesting or anything they want help with then we're happy to collaborate and work with them at any given moment in time but usually one person is leading the audit okay and that's you kind of mentioned it because i've noticed from a lot of your blog posts you mentioned i don't know recently oracle opera software that's used in millions of hotels which i've never heard about and i wanted to to ask how you choose your targets but i i guess you just look at the software your customers use that's right so it's a mix between two things we look at this the software that our customer uses but we also look at any popular software basically um any anything that is popular enough that maybe a future customer might use is something that's valuable to us so it's not necessarily that our customer has to absolutely be running it for us to to do security research on but if there is a software product um some enterprise product that has a lot of popularity or it is being used across many different segments in industries we will definitely spend the time on it because one of the benefits for that is you know we we demo our product um pretty much on the attack surface of any prospect so if someone comes to us and they want to buy us and we're demoing on their attack surface we're scanning their attack surface so um finding zero days in popular products generally is uh basically the goal uh for our security research team on top of any products that our customers are using um oracle opera is something that was actually found as a result of a live hacking event that was ran by bug crowd last year and they had a very famous resort in scope a huge us resort which had exposed oracle opera externally to the internet so that was something that we we looked at because of that specifically but we ended up finding a few customers that had oracle opera exposed on the external internet as well so one of the things that i love about what i do at asset node and the bug bounty world is a lot of the things that i'm doing is basically two birds with one stone any security research that i do has benefits from the asset note perspective and also from the bug bounty perspective and vice versa basically any any research i do on the bug bounty side has benefits to asset so that's something that that for me has been really um uh really been i've really been able to maximize my output with just doing uh zero day research when you find the zero day apart from any adding it to to a detection or whatever do you also monetize it in public bug bounty programs yeah we do so we actually we have a we have a program internally at asset node which is basically the bug bounty bonus program so this is something that we currently offer our employees where if you are doing research during worked hours and work time using our resources and things like that and you find a zero day that affects a bunch of bug bounty programs we will put it into a pool of money which gets split up as a bonus at the end of the year between the research team so really for us we've seen some really big bonuses in the last few years as a result of our team finding zero days in many various popular products which all goes towards this bug bounty bonus pool so it gets split evenly there's no like uh special treatment for anyone on the team and it's a it's a great incentive for our researchers to stay and stick around at asset node yeah yeah it sounds really cool and also the even split probably helps you avoid any conflicts inside because if it's uneven split it's always someone has problems with it yeah how did your hacking style change from when you were only doing bug bounty to now when you focus on the security research of zero days um yeah it's changed a lot actually um so when i was just doing bug bounty and i wasn't doing source code analysis i found that i was spending a lot of time basically doing a lot of menial manual work that i didn't enjoy as much for me now source code analysis always presents a very specific challenge to me that that i know that there's more work to be done to be better at whereas the work that i was doing in manual bug bounty hunting it often felt like it was not predictable it wasn't deterministic it was something that required a lot of effort and sometimes didn't lead to that much outcome whereas now being more strategic about the targets that i pick and being more strategic about how i break into something through security research is something that's led to an immense amount of bounties over the last couple years and as i said earlier like with security research i can knock two birds with one stone and that's that's basically why i do it so much these days but yeah my hacking style um really one of the things that's probably the most obvious thing to me is that i focused a lot on client-side security in my first few years of bug bounty hunting like immensely like i was on top of all the client-side security controls i was doing a lot of work with different techniques with client-side security stuff and then eventually i realized that no i don't really want to get these lower end bug bounties anymore and i don't want to spend this much time reporting on things that have not as much security impact as i think they should like i want to focus on the things that will actually compromise the target that will actually lead to a full compromise and after that point i think i've only exclusively focused on server-side issues i would say in the last couple years i mean i'm still happy to report an xss or whatever but it doesn't excite me as much unfortunately like it's not something that i get super excited about doing client-side security work so these days i've been focusing mainly on server-side security issues and it's something that i think that it's like a specialization within a specialization kind of thing it's not as if i'm not aware of all the client-side security techniques but i'm definitely not as good as some of the bug bounty hunters and client-side security work that they are today but it's the server-side security work that i have really honed and really become a lot better at what if the software your clients are using is not open source yeah so i've got multiple different techniques to discover software that's not open source i mean there's you know one i can look at it on docker hub if i can find someone that's spun up a docker image that has that software i can look for trials if that's possible usually isn't always possible i can look at github to see whether or not someone has put up any amount of code that that resembles that software or i can look at whether or not i can find s3 urls that have that software ova files things like that i also look at amazon marketplace and azure marketplace which often have software that's delivered as a pay-as-you-go sort of solution i also look at community amis on amazon which often contain a bunch of different amis maybe related to the software you're looking for and yeah i think lastly and this is the one that i hate doing is actually contacting the sales team and asking them for a trial but that that is something that you have to do sometimes in order to get that software okay so when you already have the software how does your first hour of hacking look like my first hour of hacking looks like basically understanding what the software is written in well actually to be honest the first hour is usually spent on setting that software up and this this is something that yeah this is something that every security researcher has has to deal with it's not a pretty process it's actually a huge deterrent not many people enjoy doing this i don't enjoy doing it but you have to do it sometimes setting up the software can take a lot longer than even the first hour if you try and set up any complex oracle software it will take you maybe days to set it up properly so i really do feel for the sys admins that set up this software within enterprises it is difficult and boring work but by the way after i've set up the software in the first hour i spend my time understanding exactly what software is running on the system and understanding how it maps back to the to the to the executables or the jar files or to the code or whatever it may be i pull down all of that from the system i may have to disassemble or decompile it and then after i do that i try and understand all of the things that may be routable from a pre-authentication perspective that's the first step for me usually and and just want to clarify i mean at asset note we don't really care that much for post authentication bugs that's not something that we're very much so interested in where we're interested in pre-authentication bugs here at asset note that's what our focus is we're looking for pre-authentication critical bugs as our primary focus okay so you always want to run the software to which you're auditing you never just look at the code preferably preferably you always want to run the software if possible now sometimes this isn't possible like the oracle opera work that we did we did not run that software because it would have taken an immense amount of time to set it up and also for the oracle opera software there were multiple zip files that were corrupt so we even if we wanted to run the software it would be wouldn't have been possible but where possible we will always try and run the software because we want dynamic debugging we want to be able to debug the software you know in real time we want to be able to see all the different variables on the stack all the different threads and we want to be able to manipulate that as we're as we're testing the application we want to be able to set break points in order to step through different parts of code to understand exactly what is happening when we send a request and this is incredibly important because if you don't do this dynamic debugging component sometimes you have to rely on your guesses and instinct which honestly is not that good in complex software there's just so much going on there's just you know there's just so much going on that you you need to have more certainty around what is going on behind the scenes what tools are you using for this yeah so for dot net for dot net i use rider which is a jetbrains product and that has been really excellent for debugging dot net projects that's something that i highly recommend anyone who's doing dot network to use and for java i use intelliJ i think intelliJ has also a feature to debug compiled jar files did you try it out in practice yeah so you intelliJ has a bunch of different ways of being able to debug things but yeah you can you can do that as well typically i like loading up everything in source into the into intelliJ and getting it mapped to the java debug port and then attaching to the process and things like that so i mean that's that's all there's so many ways of debugging i know that some people prefer using eclipse as well for java debugging but personally i've found that intelliJ has been better to use from a debugging perspective one of the things i've also heard recently was that codeql can now run on c sharp without having to compile the c sharp so i haven't used that yet but that that is very interesting to me speaking of of codeql do you use any tools to catch low-hanging fruit like samgrep or codeql scanner yeah i so i don't use codeql that much it's something that i'd love to expand my knowledge on and start using a bit more frequently but i use samgrep a lot so i've i've written a few custom samgrep rules for certain things i've also looked at some other samgrep rules like i think one of the ones i've looked at is eltems custom samgrep rules which they have a custom they have some custom java rules and some other rules there but yeah i i i think that samgrep is an incredibly valuable tool when it comes to finding this this low-hanging fruit although i will say that samgrep often does not always get things right it does require a lot of human i guess it does require a little bit more of a investigation to understand whether or not samgrep is actually truly correct about what it's found but i mean as a tool that assists me in source code auditing i find it very valuable okay and when you get to manually auditing the code how do you do this do you look at at by functionality by functionality basis or do you find sinks how do you do it yes i i usually focus on a list of known functions within any language that i know will lead to some sort of security issue so if it's um dot net or java or whatever i have a list of things that i grep for that i look for um specifically to try and investigate whether or not they're reachable but as i said earlier one of the things that we focus on um in the first hour of getting the software set up is finding all of the routes that are pre-authentication and looking at these routes you can often at a glance figure out what these functionalities may mean or may be wanting to do i mean if you have a controller that's like called download or something that certainly sounds like it's uh it's interesting and worthwhile for you to investigate further um but yeah i i think my testing methodology is a bit bit dynamic i mean i have adhd so i think that i jump around a lot from place to place i don't think that i am as methodological as most people that have a checklist or anything like that um i tend to rely a lot on gut instinct as well and that's just from that's just being developed through doing a lot of source code auditing over the years i mean even professionally when i was working at bishop fox i was doing source code auditing as well there for a lot of different customers in different industries and different languages but yeah i think the more i source code audit the better i tend to become at finding things quicker when new researchers come to to work with you what are the mistakes you see them doing at the beginning um well i think that uh one of the big mistakes can often be giving up on a target too early so one of the things that i've seen is you know like a researcher will say i've audited it there's no security issues and this is like maybe two days after you've assigned them the project or something right and honestly for a lot of the really large enterprise software that we're looking at um it's a very grueling process and it requires a lot of boring things to be done before you find that gold or those gems and sometimes it's a matter of uncovering attack surface that you maybe didn't know existed in the first place or maybe you didn't know where to look for that attack surface because of some gaps in your knowledge about how the product is operating or deployed so so i think the number one mistake that i see from security researchers that you know we we've hired or just in general is that they can give up after a short period of time without actually having uh enough certainty that they've covered everything inside the application how much time do you usually spend before you conclude there are no bugs around uh one week of full-time time is one one to two weeks of full-time work sometimes that's between three people so three people for one week of full-time is usually a pretty decent uh indicator if we haven't found anything after the the one week then we'll we'll probably look back at that product again in the future what we'll we'll set up a calendar invite maybe look at it in a year or something yeah it sounds like a lot of time especially the only look at the unauthenticated part which is probably not even a half of the application most of the time yeah yeah we are happy to find things post authentication but every time we find things post authentication we we usually then spend the rest of the time looking for an authentication bypass that's usually okay what we do so if we if we find stuff that's post-auth it's fine but we will spend a lot of time looking for an auth bypass what screams to you this software has a lot of bugs any any java monolith project anything that has like you know 20 plus servlets defined in a web.xml file i'm sure has something wrong with it okay when you when you're learning something when you're learning hacking or specific technology like you specialize in dotnet after a relatively short time you get to a point where you can no longer just find a tutorial in the internet about something how do you learn it further i i tend to make c-sharp projects for whatever i'm looking at so i mean there have been there's been quite a lot of research um in dotnet that still is beyond me in many ways like uh for example uh there's a lot of research from jang that he recently found an rce in microsoft sharepoint and um you know there's still stuff like that in dotnet that's very esoteric and sometimes difficult to understand and i find that research the only way to fully understand it is by setting up some sort of environment that's similar to what the researcher had and exploiting that vulnerability step by step now i haven't had the chance to do that for jang's vulnerability but i have done this in the past i have exploited vulnerabilities in the past which i didn't fully understand and i've written blog posts about them as well so one of the ones that really caught my attention was a authentication bypass vulnerability i think in vmware workspace one access which i reverse engineered and recreated to understand it better and wrote a blog post about so my opinion is just recreate these vulnerabilities from researchers that you don't understand so you can actually understand them do you think for beginners that are just starting with code review it's the same learning method or there is something easier for them um well if you're starting with code review i i don't think this is something that would even concern you as much um these the things that i'm talking about are probably for the the people that have already done a lot of work in code review and want to get even better it's one of those weird things that once you become good at something you start looking at the people that are even better than you and there's such a huge gap between being pretty good at something and being the best at something so um yeah i think for people who are beginning uh there are a ton of code code review exercises on pentester lab but honestly my my recommendation still is to look at a real life product that's being used and auditing that product and that source code of that product because in my opinion that's how you learn the most if you only wanted to prioritize for earning bug bounty how would you hunt today uh if i wanted to only earn bug bounty how would i hunt today um probably a bit of a hybrid approach so basically what i'm doing right now i mean i'm still using automation in a lot of my bug bounty work um but i'm also doing a lot of manual bug bounty work as well and i'm also doing security research my recommendation is you split up your time between those three things and then you do the rest of the work and that's three things so manual work uh reconnaissance based automation and security research okay who do you think going full-time bug bounty will be good for i think it would be good for someone that um has a lifestyle that that doesn't require too much money to do a lot of work and a lot of things that you can do to get there um but i think it's a good thing to do full-time because you're going to get paid for what you're doing and uh what you're going to get paid um but at the same time honestly if you're very good at bug bounties and you've proven to yourself that you're very good at it and you make a lot of money then you're an ideal candidate to go full-time but i think what a lot of people don't understand that some of the people getting into the bug bounty scene might be thinking is oh you know like i can i can probably do this full-time and make a ton of money um or whatever but usually all the people that i've seen who are successful that are full-time have spent a ridiculous amount of time um becoming really good at their trade craft how do you prepare for live hacking events uh um well i just love collaborating with people so i just i just hang out with a lot of people that are similarly passionate about hacking and we just enjoy hacking things together it's a pretty fair and easy system everyone gets splits evenly if they collaborate and yeah everyone's quite fun to work with i've just been able to build a really nice network over the last couple years that we tend to knock ideas around with each other and we find a lot of different things that wouldn't have been possible if we were just working alone so for preparation for live hacking events i mean i try my best to just take it easy and not take it too seriously but at the same time i do try to prepare well in advance so if i have notification of a live hacking event i'm spending a ton of time before the event even starts to to try and find vulnerabilities that's awesome and you mentioned collaboration here how do you find people that you collaborate with completely organically so either they've reached out to me or i've reached out to them at some point there are some hackers that i'm particularly interested in collaborating with that i've reached out to over the years and have been able to form really good relationships one of the things that i will mention about collaboration is that collaboration is not just the act of doing some technical work with someone so you can get paid some amount of money it's about building real relationships with people and one of the things that i care about the most in the hacker community is building real relationships with you know everyone around me in the bug bounty space that have not that much to do with any money or any transactional element or anything like that i tend to build relationships first and then choose to collaborate after that after i've realized that you know such and such person is a good person i want to i want to spend more time with them and i think that they're good at certain things and i will pull them into collaborations with myself or they will pull me into collaborations with what they're doing what do you think people should watch out for when collaborating with others um i think one of the one of the things that you should watch out for is just really knowing the person that you're collaborating with before choosing to collaborate with them because if the person you're collaborating with has a certain personality that you know um yeah it can it can go wrong easily if that person doesn't understand from the beginning what the splits are if that person thinks that they're entitled to something more than what they're entitled to if that person is maybe jealous or greedy or whatever um it can be quite tricky to resolve those disputes and conflicts so before you start working with someone really try and understand who they are as a person before you start you know collaborating technically with them and seeing whether or not they you know can find stuff for you or with you um but i don't know i think i i have collaborated with people time to time that have just randomly reached out to me but i'm certainly not the type of person that um you know withholds bounties or asks for more cut or whatever that may be unless we both agree on it from the very beginning okay okay let's now switch to a bit different topic um you you have an awesome blog at asset note it's one of the best if not in my opinion the best source of articles in the in the industry because you always also share the process of finding the bugs some technical tips it's much more than just right off the bat and the question is why to share your knowledge and why to disclose your techniques to to the public yeah i mean the thing is i grew up on public free content that was out there in the wild without uh the goodwill nature of everyone in this world that have that has produced content that they've put out for the world for them to learn i wouldn't be here today and i wouldn't have the privilege that i have to be able to audit this software and find these vulnerabilities and to me it's always been about giving back uh to to this ideology that you know that i'm not afraid of sharing things i'm not afraid of sharing my techniques and sharing how i got to some place or another i think that really if i'm able to educate people through my content through my words then that is a success for me and again like one of the things that our blog posts have been phenomenal for is really getting the word out there of the talent and skill that we have at our company and what we're capable of from a security research perspective the work that we do is in many ways uh and it resembles our security research team and we want to be proud of the work that we put out there and that's why we spend a lot of time in actually trying to explain our steps in in how we found what we did really i think that whoever is scared of competition and chooses not to share content because of competition is they themselves not that competitive because the world i mean if people really want to learn something they will learn it and people are going to compete with you either way if you're really that worried about competition then and you don't want to share things then that's fine that's your choice but i would much rather always be learning and even if i release things that have a lot of tips or tricks or whatever i am always looking for our team and myself to go beyond that the next time do you sometimes have problems because of disclosing the vulnerabilities on your blog post because some sometimes you post the timeline in the blog post and sometimes you mention some arguments with the company that maybe they didn't fix the bug or something like this yeah it does happen we we have had a few instances where companies have either refused the bug refuted the bug or they've either claimed that what we reported was not real or in many cases we've also had vendors that just take a lot longer than the 90-day timeline in order to resolve the bug as well yeah i mean this is something that is always a problem with vulnerability and security research but for us we we tend to be lenient to the vendor if they have made any sort of progress so if we know that for a fact the vendor has you know started working on a fix or has done some significant work on the fix then we're more lenient to wait more than the 90 days to release the the blog post one of the things that i've noticed as well with a lot of the vulnerabilities that we find as you know we focus on critical pre-authentication vulnerabilities almost all of our vulnerabilities end up being exploited by threat actors which is you know really something that that sucks but at the same time we are following our coordinated disclosure process we are making sure that the vendors have an ample amount of time to fix we are not selling any of our vulnerabilities to zero-day brokers or the secondary market or the black market or anything like that where we're pretty much playing this whole zero-day disclosure game as carefully and responsibly as we can which you know for us even though we're doing that we we see our bugs being picked up by you know threat actors in russia and china and end up on the caesar most exploited most known exploited vulnerabilities lists and stuff like that so it is really tricky you know it is something that you know we think about quite a lot but we we really make a good faith effort to work with the vendor to help them get as many people patched as possible what are some tips for people reporting zero days on how to make the the process as smooth as possible on our side right yeah absolutely so if you're reporting any zero-day vulnerabilities if that product that you're reporting to has a bug bounty program if you plan to disclose that vulnerability do not report it through the bug bounty program absolutely do not because if you report it through the bug bounty program you are accepting the the code of conduct and the terms and conditions of that platform which basically says that you cannot disclose that vulnerability without explicit consent from the customer if you want to be able to disclose your vulnerabilities and you're finding zero days in whatever it may be and they have a bug bounty report it via email and when you report it via email attach a response attach a coordinated disclosure policy at the top of the bug report this policy usually goes by something like you know you have 90 days to fix the issue or 30 days after patch is when we will release the blog post so after 90 days or 30 days after patch we'll release you know an article or blog post or whatever our advisory that's usually the industry standard terms for vulnerability disclosure and these timelines have been solidified by you know companies like google with project zero so this is based off that those industry standards is there maybe a link somewhere to a policy that that you can say you can link in the report for for the team to see or you just say that you will disclose it in 90 days or 30 days after the patch and that that's all it is yeah so the policy you know i mean it's up to you if you have a different policy you can try and come up with a different policy but you can just copy the one that's from google project zero as a starting point but generally i've also seen some hackers do something where it's like you know once the vulnerability is you know once the vulnerability is remediated we will publish for example i've seen hackers that have done things like that as well so it really depends what you're comfortable with from a policy perspective but if you're going to be reporting zero days you need to be attaching these policies to the top of your vulnerability reports each one yeah obviously we here we assume that publishing a blog post is more important for us than getting a bounty because then you're not getting around right right so this is definitely assuming that getting a bounty is less important but a lot of the hackers that i work with these days they're not as much interested in the bug bounty element as they are in the the idea of documenting their work and publishing their work which is fine i mean if you're just looking for the bug bounty that's okay and look there's also a possibility that if you report it via a bug bounty program they might still be open for you to publish your work but that is completely dependent on them approving the disclosure request yeah yeah and there are i think few companies that that we know that always disclose bugs like i don't know gitlab google and so on but not that many especially when it's like commercial software yeah you mentioned here your team a lot what are some things that you pay attention to when recruiting security researchers yeah actually one of the things i've found with a lot of the security researchers that we've recruited over the last few years is they have really good skills in ctfs they've done extremely well playing for ctf teams and they've also ran ctfs or made challenges in ctfs that have really caught my attention so this has been a constant theme with some of the security researchers that we've hired but it does require a very specific person to be interested in what we do and we also have a very we have a very rigorous technical interview process for the security researchers that involves them finding zero days in a number of in a number of different locations inside the product how about things like certifications i don't i don't really look at certifications i don't look at certifications i don't look at university degree i don't look at age either i mainly look at whether or not they are enthusiastic they know what they're talking about they understand different elements of source code analysis and reverse engineering and most importantly if they can pass a technical take-home interview how does it look like out of curiosity uh it's a enterprise product that has several zero days inside some zero days are much more difficult to find than others and we give them a week and they're able to spin up a docker container with this enterprise software and yeah they have a week to find as much as they can and uh then they support their then they send in their report which is just in markdown we review all of their findings and um depending on what they've found they either pass or fail i mean again this interview is something that's focused primarily on the pre-auth attack surface um we have had some cases where people have focused on things that were post authentication but unfortunately um you know for this interview we really need someone to find all the pre-auth stuff there's a lot of pre-auth stuff and there's varying degrees of complexity with the vulnerabilities the the the take-home assessment is not supposed to be so difficult that you give up but for us to assess how capable you are it will depend on whether or not you've discovered some of the more deeper inherent issues with the application that are maybe five or six layers deep within the application so yeah we do assess based off this technical take-home interview but yeah it is it is something that we we we heavily rely on for our security researcher interviews in general not only for not only for security researchers but for bug bounty hunters pentesters and pretty much everyone in security what skills do you think people should learn to not be replaced by ai soon um yeah i mean patience um dedication and persistence some of these skills are not necessarily things that can be transferred to an ai i mean you can try and to be honest uh using ai for security source code review i found that it often misses things that are a bit tricky or it hallucinates about things that don't exist so we're not quite there yet but i'm not uh i'm not i'm not saying that we won't be there yet i'm just saying that with the current technologies that i've been playing around with with ai um it's not just quite there yet when it comes to discovering some of the more esoteric complex vulnerabilities that humans still need to be involved to discover but yeah i mean really i think i think that the advice to not be replaced by ai is the same as what i'd given what i'd give five years ago which is just focus on what you're passionate about and become the best at it as you can possibly be which if it's security source code auditing they just just become the best at it as you can possibly be because even if there's an ai someone will still need to make sense of those things that that the ai produces how have you been trying to introduce ai to your job i've been using it sometimes for engineering work so i use copilot and i use chat gpt for different things but i also have been trying to use it for some vulnerability analysis now it's not being that good because every time i've done vulnerability analysis with ai i've found that it's not always been super accurate at least chat gpt it's sometimes given me a bunch of leads that didn't actually have any merit so wasted a bit of time following those leads and trying to exploit them or they weren't practical they weren't things that would be feasible to do even if it was technically a vulnerability that they weren't they weren't possible so i'm not quite convinced yet when it comes to discovering vulnerabilities with ai but i'm sure that's going to change within the next 6 to 12 months given how fast everything is moving how do you think it will look in five years i think honestly we will be able to provide a source code repository of some sort and see all of the different issues that it has and ideally we'll be able to ask the ai questions so we'll be able to say how does all the authentication and authorization work how does all of the uh what are all of the pre-authentication routes what are all the post authentication routes where are all the http clients things like that but i'm not sure that ai is just quite there yet for that i think it will be in some time yeah yeah i think it taking the source code and asking ai to to list as uh routes available before authentication should be possible relatively soon i would say because it seems like a doable job but i think it will take a long long time so so ai can actually understand the complex software especially with like different components and different code bases it will never completely replace manual hackers yeah and look like one of the softwares that we're looking at right now is like 11 gb um so that's that's huge uh i don't see us feeding that into a large language model anytime soon right like there's there's a lot of complex software out there so um it will it'll just yeah we'll have to see what happens yeah yeah yeah yeah i'm very very curious uh thank you so much for for this interview but uh before before i let you go what are your plans for the rest of this year my plans um well i'll be going to the london live hacking event um later this year um in june and besides that i think i'll be going to singapore and a few other places probably having a new year's party here in brisbane at the end of the year but yeah that's that's most of my plans i think when it comes to hacking and stuff i mean continuing to write up blog posts and release cool vulnerability research um for um different enterprise products so i'm really looking forward to that and yeah i just progressing asset node i mean we've been doing this for four and a half years and we're looking forward to what the future has for us awesome i definitely cheer cheer you up for creating the blog posts because they are really really the best i think source of learning code code review we'll make sure to link this for people in the description and where people go to follow you in social media uh just twitter twitter's really good um or linkedin but either one is good i mean i'm on twitter and i post stuff time to time but yeah um if you ever have any questions on the source code review just reach out to me my dms are open i may not be able to respond to everyone but i'm happy to help if it's a serious source code review inquiry something that someone's actually worked on or has worked through and has some legitimate question i'm happy to answer okay thank you so much for joining today thank you bye what a fantastic interview here ships mentioned that for security research he doesn't really focus on client-side issues but for bug bounty they can be great and in the last episode of bug bounty report discussed podcast i interviewed yusef shimuda who has been top one on bug bounty facebook's leaderboard for three consecutive years if you want to hear another episode of the podcast i recommend you this one for now thank you for listening and goodbye