Google's Mobile VRP Behind the Scenes with Kristoffer Blasiak (Hextree Podcast Ep.1)

hi my name is Fabian also known as liveoverflow I'm very passionate about bringing security education to the masses through my YouTube channel and I'm also the co-founder of hextree an online training platform to teach cyber security skills and in today's conversation I'm joined by Kristoffer from Google. he's a security engineer and also responsible for mobile vrp so basically the bug Bounty program that covers Android applications from Google from him we can learn the process of a vulnerability that gets reported to Google in an Android application what happens behind the scenes and talk with him about the challenges around educating people on Android security Google has actually sponsored us to create Android security courses because we feel like there is a lack of resources to teach this from zero to be able to find bugs in real life applications so let's talk to Christopher to learn all about this hey everybody I'm sitting here with Christopher from Google mobile vrp and I want to learn a little bit more about your experience and what you do at uh Google so tell me a little bit what is your role at Google and the experience you have especially with mobile vrp yeah so my role mainly when it comes to VP I do other things as well uh so I work in something called ISC or information security Engineering in regards to mobile VRP what I do is I partially lead the panel uh and also do mostly the panel meetings and so on so that's we decide we don't try the bugs it's post triers we start looking at you know how to pay out we verify some of the bugs sometimes and so one you just mentioned panel I think you you're very much locked into the Google words like what does it mean you are working on the panel what is that so maybe I should explain a little bit how the structure works so essentially when you report a bug from your end you send it off and then it comes into uh triaging essentially so a security engineer will take a look at it kind of assess it initially and see like okay how is this you know uh and then after that if it's a valid buug they will file it uh and then you get is like good job you know uh little email and uh it will get sent to a panel so depending on which vrp it is so if it's mobile vrp or the Android vrp or Chrome or just Google vrp in general uh it will get sent to a specific panel and the panel is made up of people or security Engineers who specialize in that field and then they will take a look at it and decide you know what the payout should be essentially so when a report is coming in how many people are involved on the Google site is there like one person that immediately Rejects and filters out before it goes to the panel and then how many people are in the panel like at how many people look at this report that's coming in so it really depends a lot uh I think it can vary a lot but uh in the end there's probably going to be several people like it's never just one it's so initially maybe one PE one person will try the bug and then Set It Off to the panel and the panels very incze so but I think they average of panel you know meeting would be like four or five people at least for a panel meeting and when you receive a report like what differentiates like an easy report for you to try something that just goes through quickly and what is more challenging so I think what makes it easier for us is if you very clearly State what you think the bug is so in your own words uh where you found the code and very clearly you know be and you know properly show it but the most important thing is a proof of concept and also really make sure that you've read the rules before and so that you actually send in something that's valid and that reproduces on the latest version of uh Android and so on so a proof of concept maybe a video you know a lot of time it actually does help and you know a really good explanation of what you think the bug actually is in your own words so when you receive a bug report that is lacking some kind of information where in that pipeline of the triaging does it get like stuck where does it bounce back again with question to the Buck Hunter um has it made its way to the panel already like did you talk about it or essentially what happens if like a report is not very clear to you what does this cause and Trigger so this can happen at any point really so mainly I think it's an at a tri stage where they kind of filter out invalid reports a lot of the time if the person triaging cannot reproduce the bug then they will talk to the researcher and be like okay I can't reproduce this or whatever and if they're unable to verify it and still decide to file it to us then in the panel then we will have to if they feel like there's more like knowledge needed from the security Engineers from that they specify in that field um then we might send it back as well but it can get stuck at several points I don't think it ever really gets stuck uh but it can be sent back and also sometimes if we reject a bug we feel like oh this is not we can't reproduce this we don't see the vulnerability here then people appeal the decision uh and then sometimes there we can also you know retry as and relook at it we

always look if you appeal so you recently also created a blog post about uh increased rewards I believe it was up to 10x reward or something uh and also there's one number that was at least from the outside very curious to me I believe it was like you received 40 submissions last year or something so to be honest that does sound like a small number and looking at like The Bu Bounty community in General on Twitter it seems like a huge community and you see about Buck reports all the time so how come there are only like 4D submissions for like mobile vrp yeah it's I think there's really not that many people that do Android research and I think it's that simple the in comparison to the other VPS there's much fewer uh reporters and much fewer people doing research on it and it's really that simple and also the the panel or like the program is not that old it's only a year old so that's one thing it would just turned one but apart from that it's uh it's just not that many people doing it it's very small community you mentioned already that the proof of concept is very important to get the report trashed well and that you are even able to understand that um what does even a Pock mean what is a proof of concept in an Android app it can really depend so we try to go through it uh on the on the rewards page or the for the mobile VP but it really depends what ever you can show us that in the easiest way can demonstrate the bug so it can be an APK an app uh that you've created and if you do don't send us just the APK send us a source so that we can recreate it because we hesitant to run people's random AP they sent us but if we have to but then it takes more time and then you have to wait for longer if we have to take extra steps to be careful with what we receive the easiest actually is just a uh if you can trigger an intent from um ADB for example that's the easiest sometimes it's just a oneliner we can just you know put in the terminal and try something and if it works then that's the easiest fastest and we can just pay you immediately but if we have to go through a lot of step to try to reproduce it then it will take more time I see personally two large challenges in Android buck hunting and that is what is the threat model like even what can like a malicious app do or what do you consider valid because I could imagine some cases where there's a certain um ADB command maybe that or can every app basic what you can do with ADB every app can do or is that it depends you can do a lot of stuff with ADB that you could not do you could not be able you wouldn't be able to do that any app would so it really depends you have to you be careful what you said yeah um also creating a proof of concept application writing code can be a barrier of Entry um with web hacking you can often just use burp or some other scanning tools and there also exist scanning tools for Android that report something but um yeah sometimes tools make mistakes so it's best to obviously be able to reproduce it and write some code and I guess that is like a huge challenge being able to write code it's a requirement as well we don't if you just send us a scan report or a result from a scan report it's doubtful that will get through to be honest it unless it's really clear you know but then you should be able to take the results from the report make sure that actually valid and then report that result like the finding and then that's a valid finding but if you just send us a report like that's it then that's not going to get through now in terms of scope okay maybe there are only 40 reports because you know there are a few apps and they are very secure also um is it maybe also there are not that many targets or how do the targets look like in Google vrp very many targets there there's no lack of targets like if people actually look then there's a lot to look the scope is huge for Google um and I believe there are like uh two different kind of targets you have the Google main applications and you have TI right so we have uh it really depends so we both pay for first party apps which is mobile vrp what we do is we tier apps into three tiers tier one is a very specific list of apps which are crown jewels so to say tier two apps are everything else that interact with tier one apps that have some kind of permission and can talk to the tier one apps so that would be like a kind of increases the attack Vector for tier one or the attack surface and tier three apps are just everything else but you would be surprised how much actually goes into tier 2 U if for example the calculator is a tier 2 app even though you think it doesn't have any important access to anything because it's just a calculator but in fact it does have some permissions and some access that it needs so the attack surface is actually huge for two apps yeah and besides

this there's also the Android open source project like you have some kind of like default apps that other vendors can build upon um I guess that's also an interesting Target because if you find um issues with these base apps then it could possibly spread to other vendors implementing Android absolutely and those will most likely fall under Android uh vrp because there a part of the Android kind of ecosystem most likely they will fall under there but we also pay for of course to be honest it sounds so confusing I feel like there was an Android bu Bounty forever like and you say it only exists a year was it under a different like brand or did you triage it under a different group or so or did you just literally not accept Android bugs before no so basically the way it has been is that if it's specifically an AOSP or Android related like in the platform then it goes to Android vrp yeah and then there's also some other you know examples of if it's in Chrome it goes to Chrome even if it's Chrome app now when it comes to first party applications it always went to Google vrp and it was Tred by Google vrp under the Google vrp rules but they are not really suited to handle Android applications like the rules are not really you can't really follow them like the rewards table and everything doesn't really reflect properly into Android applications so that's why we started mobile vrp so we can properly handle uh you know Android application bugs I know you only got like 40 reports but is there even a pattern there like what are the typical kind of issues that maybe can be found in apps absolutely so I think there's a huge amount of um vulnerabilities related to intent redirection that's a big issue I think in general uh then also just authentication issues or like authorization issues where like you can bu or permission bypasses that's quite Comm common actually so like Android permissions uh exactly yeah so that's quite common the uh that's I think is I would probably say that permission related issues are among the top ones most common ones yeah I also found the permission system it's not difficult but you have to learn it it's different from like basic Linux that you are maybe used to in terms of permission it's just its own thing so there's a yeah a little barrier of Entry that you have to overcome until you understand oh that's how Android does it and once you do that then it makes sense like what kind of issues can appear but yeah that's a challenge toar but there's a lot of just uh unexpected side consequences of how this permission system is built and I think permission squatting Oran permissions where you expect something to exist on the phone but it doesn't and then something else can claim that permission and so on these are like some kind of corner cases that can create very serious bugs and together with other vulnerability types you can actually get some pretty serious issues now in terms of attack Ser something that I found a little bit difficult to understand like what is a realistic attack for example there are certain permissions or certain abilities that an app in the Play Store cannot take because you want to you wouldn't put them on the Play store or only in special exceptions but people could s side load uh these apps or from alternative app stores so when you trash bugs of vulnerabilities um is this something people should consider like can I basically install an app from Android studio and whatever this app can do it's probably a valid bug or are there other restrictions so there's one thing here that's side loading and side loading is something that will we will still consider a vulnerability that requires you to Sid loadad we will still consider a vulnerability potentially depends on the whole picture of course but we might consider it and we have in the past considered it vulnerabilities but we do see it as lower impact because it requires a lot more user interaction um so we we already feel like it's already mitigated to some point if you require someone to Sid load the application uh so that will that can affect the payout which is I think quite important to mention um but of course it can be a valid bug so there are apps on the phone uh which are Google Apps already maybe pre-installed and so on which are allowing you to access some components if you have certain permissions and those permissions are only owned or actually can only be owned by specific apps or package names and if that is not installed then you can install let's say a third party app or side load something that we would never allow it to be on the Play Store let's say you're required to have Gmail you don't have Gmail installed and you sideload a fake version of Gmail then the

operating system will think that actually is Gmail and then it will have access to a lot of things on the phone um so if you kind of drop a fake app in the place of a legit one it can do some damage based on the package name and so on I guess the lowest severity or impact is like Sid loading an app because when you Sid load you could even use a package name like Gmail you could kind of like if it's not already there yeah exactly so if you find a bug that requires this kind of power basically be able to choose thing then that's the lowest severity and then I guess a little bit higher up are apps that could theoretically be in the Play Store because they don't need for example to use a already existing package name or so yeah it depends right so yeah it is there's a lot of mitigations here and so on and we don't allow just any type of package name some are reserved and so on but yeah and then um of course there are also vulnerabilities that don't require an application at all for example that could be triggered from um a web view or browser um and then I guess there are also vulnerabilities that are like fully remote like can you talk a little bit more about these tier severities impacts from well I mean obviously the more remote and the less interaction from the user you require the higher severity it is and higher impact and also the payout reflects that a lot we mostly get uh vulnerabilities and reports regarding installed apps so you have to install a malicious app and they can do something on the device that's the most common I would say then of course you have the you know if you have to follow a link that's the next most common and then full remote so far we haven't seen one at least I haven't uh but apart from that the follow link where you have to press some let's say trigger a deep link or something and that is able to exploit something on the phone or do that you're not supposed to for some apps um the line can be quite blurry of what is the application and a lot of apps have a server involved so um a lot of back Hunters I think are also looking at Android just to reverse engineer and find some server apis um can you talk a little bit more about this um you know the barrier between what is mobile and then what is uh web because I'm not sure are you paying for third party vulnerabilities in the apis of these apps like there's a huge app with millions of dollar and starts looking into it but doesn't necessarily find or potentially a bu that it's just like the Android app but finds like an API issue of this app um is that still covered under um policy yeah but the thing is with these like kind of chains of bugs and everything it can get quite messy like where is the vulnerability actually um and so we've had several cases where it was not that easy to decide and we had to go back and forth with the researcher and kind of figure it out to see like is this a valid bug or not it's it can get quite messy like it's not black and white can yeah um do you also get a lot of invalid reports or some inval can you what are some typical invalid reports or misconceptions I guess that lead to these invalid reports so I think since I'm in the panel I don't see that much of it we do get some where people feel like the impact is higher maybe than it is I can understand in some cases and it's all it's quite subjective after all but then that's why we have our rules and we really follow them and try to we always play Dev yeah the invalid ones usually get bounc already at Tri I think and then the ones who you know still get to us because it's still technically something but it's unclear how high the impact is it's mostly if the impact is quite low or it requires too much user interaction you know it's just too much it's not realistic that this would actually be a vulnerability so the impact is just so low that those are the ones that maybe would not make it and that's what the panel is for where multiple people then exactly so we discussed and it happens a lot that we may spend one hour discussing one bug just because we cannot like we play Devil's Advocate we're like yeah but I really think that if you kind of look at from this perspective then it is you know we really try to side with researcher always that's the rule we have always side with researcher from the uh web related vrps I have heard that um issues got even higher impact sometimes because Google understands an impact of something like if it's an xss on a certain domain you already know very well the impact it could lead to but the bu Hunter maybe doesn't have the experience or so and then you um increase the impact for that because you know it has this happened on Android as well like are you well aware of like if you find an

intent redirect in a certain app that it could achieve um high things or are the buck Hunters so well experienced in that area because there are only so few as a niche that they already know like what can be done with that I feel like the bug Hunters are quite well aware of the impact and they I think the rules also reflect that quite well so they understand what their payout is going to be uh but it has happened where we feel like oh this is you know maybe higher or a lot of time I think if we see a situation like this where we like this has potential to be more then we will encourage we will come back we won't make a decision yet we'll be like oh okay have you looked at it from this perspective and try to encourage them to try to find what we know is their potentially and we point them in the right direction like try looking at it this way can you show more impact can you demonstrate more can you make a different Pock can you know have you tried doing this because we pay for demonstrated impact we don't pay for potential impact and to try to push them to get you know more impact and paid more essentially and if we know like this like you mentioned like behind the scenes we are aware that the impact is higher already than they think then we will pay for the higher impact of course you did mention that because you are more working with the panel you don't see that many of the reports that are initially coming in but do you still like know a little bit about the very invalid or the typical invalid reports that people um I think there's a lot has to do with uh potentially like if they haven't read the rules correctly and they immediately report something that's just wrong stuff that doesn't reproduce at all Spam and just sending in you know scan reports you run a scan you get 3,700 results and 3,699 of them are false positives and you expect us to go through it like that's not going to happen unfortunately we don't have the time for that uh so it's just that that's kind of stuff I think if you have a good report it will not get filtered away it's just more filtering away the noise that's clearly not real or people trying to game the system or sending AI generated reports and stuff to just try to fool us into paying the money cuz there's a lot of that unfortunately sometimes I see like reports where people start defining like a certain vulnerability in describe the vulnerability you are all security Engineers you know what vulnerabilities are you don't need a new definition of what is an intent for example or so um would you say the most important thing is like if it's just a clear proof of concept um that's like basically all you need with maybe a little bit of text is that I think it's imagine if you're yourself you're sitting there you get this report and you're looking at it for the first time you have no idea what it's about at all and you get a some source code and that's it like yes that would probably work I can look at your code and I can figure out what you're trying to do and what the potential here is and that will just take more time like it will take you know 30 40 maybe an hour sometimes or if it's really complex I will maybe take more time if you just write this code does this and then I can verify that it does exactly that then that just saved us one hour of work and yeah you get paid faster so I think just be clear what you think that this does so we can verify if it actually does what you're saying it does that's really all that we need we don't need like that you don't have to Define all of this um unless you find a new you know vulnerability type bug class then I would love to see that but then we have a different situation also for us it was really great working with you because for us it was not just creating a course we were able to get some really cool insight into um The Bu the receiving site receiving these Buck reports and you were also able to connect us to Buck Hunters to get some really um yeah in-depth knowledge about this stuff so yeah we hope we created some courses for you that really get you started with Android uh buck hunting so thanks again for chatting with me about this topic and yeah hope to see you on the Android continent