PW - Are your secrets safe - How mobile applications are leaking millions of credentials

good afternoon everybody and welcome to bsize Las Vegas we are here for the password con appreciate you coming to hear from Mackenzie Jackson who's going to be talking about are your secrets safe no they're not we know they're not finding millions of credentials and mobile apps just a few things we want to say thank you to our sponsors especially the diamond sponsors Adobe and our gold P prise Primus Prisma sorry Cloud blue coat Toyota and conductor one is there report along with yours that makes this what it is cell phones please turn them off we don't want to hear it if somebody's calling it better be God also if you have any questions save them for the end because we she he

doesn't want to be interrupted so on that note let's get started McKenzie all yours thank [Applause] you that was that introduction is probably like going to be the highlight of this talk so but thank you all for coming here I'm really excited exed to be presenting at bides Las Vegas um this has been one of the one of my goals to be able to present at this conference I have a funny story before we start is uh last year I was a volunteer and I was on the registration desk um and I was chatting to the people on the registration desk to me and I was with three other cisos so if cisos are the people that are

volunteering here I'm kind of terrified to know what the audience members are but I'm uh really happy to uh to be presenting here so my name is McKenzie a little bit about me before we get started uh I'm from Aro New Zealand uh but today I live in the Netherlands and I work for a French company so there's a range of uh of uh of countries there you can find me anywhere on social media the handle advocat uh and I also am the host of the security repo podcast it's my mom's favorite podcast she hasn't missed an episode uh and it would be really great she she recommends it to you uh if you want live dangerously there's a QR

code scan at your own risk uh to take you to that all right we'll get into the the topic so what we're going to talk about uh in this session is really discovering secrets so we're going to talk originally initially about kind of Secrets now we're in passwords con so I don't need to spend too much time about this why there a problem then we're going to look at discovering secrets and source code I'm not going to spend too much time about this because the presentation after me is actually going to go deeper into it but this is kind of what kicked off uh my interest in mobile apps specifically and then we're going to talk about discovering secrets in

these compiled applications downloading them and finding them uh finally we'll talk a little bit about how to securely store secrets and then we'll we'll have a go some questions all right so just quickly um I'm sure everyone here is familiar so but just in case to get everyone on the same page what do I mean when I'm talking about secrets so I'm talking about digital authentication credentials uh these can be things like API Keys security certificates credential peers and the key difference here is that these are made to be used programmatically and generally machine to machine right so I have yet to successfully memorize an API key um and use it these are meant to be used by our

systems to authenticate themselves now why that's important is because when things are made to be used programmatically they often end up hardcoded or in the wrong place because humans still handle them even though machines use them and so that's really what we're going to be talking about now is identifying where they've kind of leaked out of where they're where they're meant to be uh how we can identify them and how we can use them so why do Secrets exist a question I ask myself every day um but if we take just a kind of a a modern application a mobile application um you know secrets are used because of a shift in how we build our software you our applications

aren't monoliths that do everything we connect to lots of different services so you know the easy one to talk about is something like OCTA where are you going to build your own authentication or do you Outsource that to a service that has has is doing doing just that you know that or do you use algolia for search do you do your own credit card processing or do you Outsource that to stripe especially if you're trying to get around the 30% fees that the app stores charge um but um applications quickly end up of these are compiled of these different services and they all communicate with Secrets but it doesn't stop there because we have to have

backend infrastructure we have to have testing we have code that we need to deal with so then our infrastructure also uses lots of these secrets now our mobile application needs to talk to these as well uh potentially through the back end but they still exist as secrets and then it doesn't stop there because we want to monitor it we we need to have monitoring of it perhaps we want to have crash logs being sent somewhere from the app so they we need secrets to be able to do that and get information and these are all potential access points and we haven't even talked about the microservices that we create so your simple little mobile application very

quickly turns into a collection of all these different Services all doing different things and we need to authenticate with each them and we do this through Secrets but every single one of these points if I'm an attacker this is a potential entry if I can gain access to to something even if it doesn't seem that interesting you may not think that me getting access to a slack channel is important I'm going to talk about that EXA exact example later but as an attacker I can do lots of different things to be able to abuse that and leverage that to elevate my privileges and gain access into you know lots of different areas all right so how should Secrets be

stored this is going to be a very very simplistic example um but just before we get into all the bad things that happen we'll talk about how it's meant to happen so we have our front-facing applications for Android this is an APK for Apple this is an IPA uh we shouldn't have any secrets in these now unsurprisingly we we we're going to discover that there's lots of secrets in here but this is we really shouldn't we should have our secret stored in our back end you know perhaps through a secret manager um or just in our Cloud infrastructure they often have Secret manager we want them loaded into our local memory and that's what communicates with the third party

services and sends our data securely to our application this is how it should be set up um but often lots of things uh change people cut corners or they feel like they doing it more efficiently although come up with lots of arguments as to why the insecure way they're doing it is actually secure I'll talk through some of them uh as we go through but this is really how it should be done but it's not often how it is done in practice so let's get into the first part of this uh finding secrets and source code as I said I'm not going to like go too deep into this uh if you're really interested the talk after me will

go deeper uh but I want to address this because this is really what made me start thinking about Secrets inside source Cod inside mobile applications uh based on some initial research I was doing in source code so to give an idea the state of secret scoll is a report that GG Guardian the company I work for uh releases every year and one of the things that we do is we monitor public uh uh code repositories to try and identify if secrets are leaked in there um now the biggest one is obviously GitHub so GitHub has huge amounts of information there was more than a billion commits or contributions made to public repositories in GitHub last year

uh and we scanned every single one of those to try and identify uh how many secrets out there in public repositories so last year we found 10 million so 10 million secrets and we validate a lot of these so this isn't 10 million random hopy strings that look like Secrets but are just you URLs or unique identifiers now this is 10 million secrets that we're fairly confident um are true positives so this is a huge amount of information uh if you want to win some candy if you remember this number for the next presentation it's going to come up um but we looked at the file extensions that we had and I got an interest cuz we

were going through lots of information and I wondered how many of these how many mobile applications how many of these would actually concern mobile applications because I had heard a lot about mobile applications being breached pastors being found in here so I wanted to use this research and this information to get a deeper understanding of how these mobile applications are actually using Secrets now truth be told I'm not a mobile div um I've I've I've D in this into this topic uh from a security perspective and learned along the way but there's a bunch of uh files that really are specific to mobile applications that kept coming up in our research so if we look at some of them the dot properties

now obviously these aren't only exclusive to mobile applications but ones that we when looking into they frequently related to mobile applications XML files were often related to uh mobile applications and the pist file which is nearly always related to iOS uh development and so when I had a look into these I did some further research to find out how many of these uh contain secrets and what are the some of the file names that we had so if we're looking just at Android applications the main one that we were discovering secrets in was the Android manifest.xml we found 23,000 nearly 24,000 secrets in this one XML file um you know other ones as well strings.xml was a big one that

was related to Android developments uh there's a long list of EX of of these files that we can go down here are some of them and just the last one I always like to add in a funny one uh API key. properties feels like something that probably shouldn't be in a public G repository uh definitely not but we still find you know 65 of these uh Keys being leaked uh so this is interesting we found similar results when we looked at iOS uh Android application specific the main one that we found was the Google services- info. pist uh this is a uh a file that's generally always related to Google services and namely Firebase um

Now by default this shouldn't really be that sensitive because it should only contain your Firebase ID which might be useful for attacker but not really but then people started doing really weird things they started adding secret Keys into this file as well I guess maybe it's handy to have both of them together uh and we started seeing lots of weird Secrets inside these and also lots of other ones and again API keys. list feels like something that shouldn't be in a git repository uh but often is so when we looked at all of these files it it really got me got me thinking is to if these are the types of files that are containing secrets in public git

repositories then it really has to be that in private git repositories the problem is much worse and if this is the flow that means that the application at the the end is going to have those secrets in it so looking at this source code uh really got me thinking of to that ultimately these secrets are going to end up in the mobile application um and so that's what kind of started me off of this first I want to talk about exploiting uh secrets in these in these public source code I'm not going to spend too long about it but just bring it up how would an attacker that's specifically looking at exploiting a mobile application uh be able to

discover these types of files in public places like GitHub so generally when Secrets leak for applications they not they don't leak in a official repository they leak in a repository attached to an employee that maybe accidentally leaked something uh or is starting their own project that doesn't realize there secrets in the history that belong to the organization but there's a couple of of ways so firstly this is a kind of my least favorite way but I'll talk about it briefly because it's the easiest you can just use the GitHub search feature what we call GitHub doing so we know that the Android manifest.xml has lots of files so if I'm looking for to exploit an Android application I might

narrow this down to uh specific keywords I'm looking for an API key and there's lots of different types of these dos uh that we could do this isn't a great method the reason why most of the secrets that you find in source code are in the git history when you're using the GitHub search feature it doesn't search the history it just searches the top level or the kind of the latest version on the main branch so there's a much better way that we can programmatically try and find these keys inside mobile applications and that's using the GitHub API so we have this uh uh a events API if you anyone can go to it you can do it

on your phone right now it's api. github.com events everything that happens publicly on GitHub is on this Ledger is on this uh API so what we can do is we can start using uh the public events and the push events to try and find uh code that or code for for things that shouldn't be in GitHub for instance narrowing it down to the Android manifest and strings this is a huge amount of information to digest but if you're uh trying to exploit a mobile application if you know that it's going to be an Android manifest XML or strings.xml that's going to give you your most amount of uh most amount of prizes then we can narrow it down and

all of a sudden this fire hose starts becoming digestible uh so this is really some of the ways that we can do it and also if I'm trying to exploit a specific mobile application then what I might do is I might discover what employees are working for that if they have personal GitHub accounts and then abusing this API to try and find uh files that relate to this specifically for them uh but that's enough about source code all of this sent me off down this journey of trying to figure out how mobile applications can be breached um Can can they can we find the secrets inside of them and exactly how do we go about doing that uh all right so let's

get into that so firstly uh on the Play Store you this is probably something of what you see and we look at these and we trying to figure out what are mobile applications in their raw form if I how can you download it so uh most people make the mistake that nonhuman readable means secure so when we submit an APK file to the Android play store or an IPA file to the uh to the Apple Play Store we all think that okay this is this or a lot of people seem to think that this is a some kind of black box it's not human readable you can't really extract any information from it from just that file

so that means it must be secure it's totally unhackable uh but that's absolutely wrong with so many things uh like this uh same with packages same with containers uh so what we started doing is trying to first step is to turn these files back into something that's human readable and it's very easy so there's two types of files when we're looking at mobile applications so the first file that we we have is the IPA from Apple and the second file is the APK uh from Android and so what are these These are basically glorified zip folders that we can use to extract the source code and once we've extracted the source code from them then we can uh we

can start looking into them to try and find any sensitive information that may be in here so how do we actually uh find these secrets so I'm going to run through quickly uh if you guys all say a prayer to the demo Gods I'm going to hopefully uh this will all work uh but the first thing that I want to do is I just want to show you how easy it is to extract these files so here I have two I have my Android app.apk and my iOS app. IA these are real files that I've downloaded from the respective Play Stores um or app store so uh that I've kind of chosen at random but I've removed their name because

there's some sensitive information uh inside here so I don't want to get in trouble for disclosing uh let give me a

minute okay so the first step is we need to try and get this back to something that's uh human readable so to do this well I guess the first step is we need to download it so you'll notice that you can't download these on your computer you need to use some kind of uh mirror or some kind of tool so there's an easy one for Android applications called uh gplay downloader so I use that to download the application then I'm going to use a different tool called uh J deex to which is a decompiler to get this back to its original form so just to show you what that looks like uh it's just going to take a few seconds

um and then that's going to be able to spit out and take me back to the source code because once you have the source code then really you can actually uh start doing some interesting things and and and looking for uh some files so now that we've done that let's open up uh what we've just created here so this here is the s code uh of the of the application that we've downloaded so here you'll see the Android manifest we've talked about this file so this is where I can already start to find some interesting information and go through and here and also we know that the there are some other files uh very interesting like the

strings.xml uh which we can find uh in various files um here to try and get information about uh and see if there's any strings hidden in there the the problem with this is that these are really massive files and buried under all of this maybe something interesting maybe uh and hackers or at least I am uh very lazy uh so we're always going to find a better way to do it so what I want to do now is just show you what I would do in real life um is this is what I is just scan this file uh for secret so I'm using a tool called GG Shield uh fear warning this is a tool

that uh GG Guardian my employee creates so I'm wildly biased as to why I I use this uh but it's definitely the best totally

um whenever I'm on stage I forget how to spell the most basic

words I told you I was just checking to see if everyone's away you know making sure everyone's paying attention

feels wrong but uh let's give it a

go all right so this is going to take uh just a little bit of time uh oh huh okay this is going to take just a little bit of time to scan so I want to uh go back to something else so I've easily shown you how to extract the um the the Android application now I do want to warn you the iOS application is much more complicated uh so I hope you pay close attention and take lots of notes as to how we can do this so what we need to do in our Android application is we take here our IPA and we change this to zip

and we have a look in

here and we have our source code from this so hopefully you hopefully you took uh lots of notes on how to do that I can't do it again um but yeah that's really how so when I mentioned that these are glorified zip folders particularly for the iOS version I'm like absolutely dead serious these are literally glorified zip folders so now that we have the source code we've extracted that it's really easy if there's a hard-coded secret in in your source code it's going to end up in your application uh and we can easily extract it using simple tools or in the case of iOS not even using any tools uh at all so I'll try and see what my scanning is

doing uh we'll wait a little bit these are all okay we're all done so we'll go up to the top and these are some of the secrets that we've found I want to stress again this is a real application downloaded from the Play Store um but I have hidden all the secrets so you can't do anything malicious with it so the first secret sent we've got some valid Google API Keys uh these can be interesting these are in a Java file so that we know that these are are hardcoded when we decompile things obviously we don't get the original names we lose a lot of information it's human readable but it's uh we don't have

everything that was there but we can see that we have these Google API keys here we have something very uh and we all also can see that these are valid so we've checked to see if these are valid so we can use these we also have Google o or Keys we can't check these automatically but these can be extremely uh sensitive uh depending on the setup we have Facebook app keys and I also said we have here some uh select web Hooks and these are valid I find select web hooks literally everywhere because people kind of assume that they're not that sensitive and in some ways that they aren't so what is this slack hook

allow me to do this slack hook allows me to be able to post information into a private slack Channel what's the use case for this I'm going to assume probably that this may be some error or debug uh logging that's being sent but when something happens it kind of gets sent a crash log gets sent to a select select Channel that's interesting but me as someone that's malicious I can do lots of things like I can create some clever uh fishing messages in the air to say that hey this integration has disconnected please relog in or something like that go to a mirror of slack and get people to give me their credentials now it doesn't always work

but it's it works a lot of the time because how else would I have that slack web hook right you've broken down some barrier of trust I'm not a Nigerian prince emailing you I'm I'm your own system telling you you need to update your information so this is the Ino this is kind of what we get and it keeps going down some more web hooks in different areas um and we have a couple in I'm trying to find this interesting files here and here we have the strings XML so this is obviously what we found so what I found originally on GitHub that led me down this path to kind of wonder if this is interesting

you know translates into the app people were putting secrets and strings. XML and putting it into public GI repositories then I wondered hey does that mean they're going to be in the app turns out it exactly means that they're going to be in the app as we can see right here so this is just the process that I used for Android I downloaded called G with a G play I decompiled it with JX and then I scanned it with uh GG Shield uh so you know this is very simple there's other tools out there too and and this isn't that complicated honestly I'd say that this is definitely at the level of a script Kitty uh or

even below um where you can you can just go through go through this you can pipe these all together um and just download download apps all day long and try and find sensitive information I'm going to talk about when we've done that and what we' found later on but we definitely uh this is my backup demo just in case it failed um and the similar process for for Apple apps I use a tool called IPA uh tool to download it Apple won't let you won't let you download anything unless it's on a a mobile so what this tool does is basically trick it into thinking it's on a mobile it uses your Apple ID and you can download it there

there's also lots of mirrors online um where you can just download files uh you just change the extension you don't even need a tool to decompile it and then you scan it with GG Shield uh so again really simple about the level of a script Kitty uh to be able to do this so we're not talking about highly sophisticated attackers if we were I probably wouldn't be presenting to be honest so let's talk about when uh this breach a breach has actually happened so this one here is from uh Jason heck this is a story that he told on the on the security repo podcast that's a great episode if you want to check out uh and

this is about when he was doing a penetration test on a bank uh application now if you don't know Jason he's absolute Legend uh in in the field he's he's uh been a very highly regarded uh penetration tester himself uh he has a checked pass which you can hear about on the darket Diaries episode with him um but this is an interesting example to show that this happens in real life so there was a bank that uh had a mobile application and Jason decided was doing a penetration test and downloaded that application and started playing around with it this particular Bank application had a functionality um so apparently in America uh United States you guys still

use checks that baffles the rest of us um but but one of the features of this was that you could take a picture of your check and cash it you know all in the app so when Jason decompiled this he looked at how this and found that actually these images were being stored unencrypted uh on on you know in in in his in the mobile device um so he kind of figured well if that's being sort unencrypted somewhere that means it's being sent unencrypted somewhere and if I can get access to that that would be great uh so what did he found that there was a uh S3 bck bucket uh S3 bucket that these were being sent to inside the app

and again we're talking about a we're talking about a tier one bank here just we're not talking about Bob's financials um we're talking about a a bank that I can't disclose because he didn't disclose to me um which was probably a good call um and then in that there was hardcoded uh secret for that Amazon S3 bucket and then with that Jason was able to access that Amazon S3 bucket and find 10,000 images uh of unencrypted unencrypted images of checks from this so this isn't something that just R like happens to you know small applications this is something that's widespread uh where Secrets often end up inside our mobile applications because we honestly think that we don't understand how easy

it is to do it and when you're putting something in an APK online you're putting up your source code you should absolutely remember that so you want to make sure that your source code is basic considerate open source and and expect the same security measures from that so this is just a real life example of when this has happened um uh out in the world so uh what about the what about other examples of discovering secrets on the Play Store so there's actually uh a few research uh that have been done on this Zed net published that there was 12,000 Android apps that they found that contained secrets and cyber news last year did a great a great study on that

and I'm going to shamly steal uh their information and talk about that uh I did a webinar with cyber news we did a full hour on their research so I'm going to talk about it for 5 minutes if it interests you again scan at your own risk there's a QR code if you want to live dangerously uh on the uh on on the YouTube channel of that webinar uh that we did together but I'm just going to briefly talk about uh some of the findings that they they did so the main statistics how many applications contained hardcoded credentials of some kind about 55% so more than half now before before everyone gets too shocked by this not all secrets are the same not

everything's going to give me access to Amazon S3 bucket there are some secrets that we discover that I would still definitely consider secrets that I wouldn't want on attacker to have but won't necessarily give you uh access to the kingdom but it would certainly be used as part of a a a bigger a bigger attack to be able to understand and get more information um but still I would consider that the the correct way would be to have zero uh so the fact that we have nearly 56% uh is definitely very alarming so what was the main uh the main secrets that were found so this this study uh actually only looked at the strings.xml file it didn't look it

didn't scan the whole source code because that would have taken too long for the the research project size um but we we we're going deeper into that now the number one was Google storage buckets so this is really closely in line with the example that we just saw data being sent from the app so the reason why well I just taking guesses of these things but the reason why I think that is because I mean you're sending data directly from the application uh to to the bucket it feels uh unnecessary to go through the back end or something like that it feels more efficient but it's a terrible idea if you're going to hardcore those credentials um other ones

Firebase URLs uh we found lots of these these aren't necessarily uh uh exploitable uh by default however it requires that you've configured your Firebase uh really well and often what we find is that things like this with like Firebase the the the default is insecure the default is poorly configured why because companies want you to be able to get up and running quickly because if you can't if you have to sign your app and get all get and get lots of security working to send a me to send your first message on Firebase then maybe you'll use a different service because it's too complicated to get started but then we don't go back and actually correct and make it more secure

so lots of things like this uh Facebooks lots of different types of secrets that we've found uh on that were on here the top actory categories that Cyber News found um health and fitness was up there but honestly no category was immune you know we talked about the example of the financial sector so this shows that it you know really everyone is suffering uh from these programs uh almost equally so there's no kind of Avenue of that someone that's doing really well on health and fitness uh sucks so and just to talk about it um a little bit after we did this research I decided to have a look it was at the time where there was

endless amounts of chat GPT yeah CH said it right chat GPT uh cred uh apps popping up where they're basically mirroring it so that you got chat GPT on your on your mobile application I scanned about 10 of these and I found nine of them had their open a open a uh open API Keys hardcoded directly into them so there's lots of different areas that you can find that one I found particularly shocking all right so how do you securely store your secrets on your mobile apps how do we hide these effectively so that the attacker can't uh actually use them so the correct answer is that you don't you don't put your secrets on your mobile

application you put them on the server side um so and then people often say well if it's on the server side I have to connect to that server yeah you do and we just do that like any other application right you probably have some kind of login area you log into your mobile application that authenticates the user with the back end and then you can do the heavy lifting on the back end that is the only way there's no way to be able to hide your API Keys effectively if they're on uh if they're on the mobile applications the only caveat to that is if the mobile application themselves is creating the keys so what I mean by that is in the

example of the bank where there were they didn't encrypt the images the app could create an encryption key store this securely on the device and the hardware that's designed for that and use it to encrypt it but we can't use API keys to connect to anything outside of that app uh and the other one is if you have a public application with no login well then you have a public app and you should be receiving public information nothing sensitive should be coming from that um so we don't need to worry about it and please don't hardcode API keys in there all right so uh here's some arguments that people always get to me uh what about encrypting keys in Bay

64 and if you want to throw something at me for that statement don't worry I'm coming back to it um uh what about splitting keys so this means uh what about putting keys in two different areas and then joining them together uh non-sensitive Keys application keys this is what I was talking about with encryption and what about if I offis scate my code so no one can understand so first one Bas 64 is not encryption it's encoding and it's completely useless for security um the tool that I use GG Shield automatically un un encodes Bas 64 um so this is absolutely no level of security and please don't call it encrypt encryption uh splitting keys I'll give you that splitting Keys

makes it slightly harder for the attacker in the sense that I can't just use a g something like GG Shield to scan it because of the keys are split uh it won't know that they're partial keys but if you're relying on slightly harder as your level of security then you've probably got a big problem um and I just suggest doing it anyway nonsensitive Keys uh yeah uh I agree that there are some keys that don't give me complete access however they tell a story they let you know information I'm all as an attacker I'm always wanting more and more information uh to try and put it together so I can coordinate it uh in in

in an attack that that I can effectively use so having any kind of keys in there and it also means that uh it gives me opportunity that if you have done something wrong if you have misconfigured something on your end uh then that's opening the door for me in lots of ways uh application keys this is acceptable as long as you store them in the key store or somewhere similar and code alation is useless to maybe slightly harder um but it doesn't really matter uh so this is what like code confiscation looks like there's some options you know in the Android manifest you can you can select Minify this kind of makes the code less human readable

but it wouldn't it wouldn't stop me using a scanning tool to be able to find these secrets um it just makes it harder for me as a human to look through and understand what the secrets do this is the tip of the iceb there's lots of examples what you can do uh to make code off fiscated but really uh don't waste your energy on trying to make it harder for someone to understand put your energy into making it secure uh so some things that you can actually do so signing your application so code signing you know is basically proving that this application in its current state hasn't been modified that the author is correct and that and you

need those signatures to be able to authenticate with services this isn't in replace of storing them securely on your back end this is another level of security that you should absolutely have it means that if you make a mistake and I the attacker find your API keys I can't simply use my machine to manipulate them and and extract information uh limit your IP addresses to no and machine so if you have a service that's only meant to connection to other service make sure it can only connect to that other Service uh limit your API keys to minimal scope uh so the amount of times that I will find read write access or admin keys for uh for a

job where someone's just trying to ingest information so you're just trying to pull information read information from a Amazon S3 bucket and you've given me uh admin keys to do that um the some people will argue that this is more secure because you have less keys to manage but that's totally uh excuse you're just lazy so please make sure you you if you need to create more keys create more keys to limit the IP uh and then set up access rules so what I mean by access rules is in things like uh Firebase you can set up security rules to be able to understand exactly uh uh what people what people can do and restrict the limits that you can so we

we should be doing all of these none of this is to replace storing the key securely that's kind of number one but what happened here is none of these companies none of these apps that I've scanned think that they have Secret in their mobile applications no one's doing it really on purpose it happens because people don't understand the technology and how it's all compiled um so we need to add additional L of levels of security to catch it when the mistakes happen when not if when the mistakes happen because they absolutely uh definitely will happen uh and there's a couple more things uh that we can do uh to prevent our secrets from from leaking so the

number one here is a change in mindset and that is kind of assume that you're going to be breached assume that your source code is is public uh if you adopt the attitude that an attacker is going to get into your get into your application get into your source code then you're going to change your mindset about how you handle things in there for me this is really one of the the number one rules that we should absolutely be dealing with is kind of changing this mindset so that we're assuming that we're going to be breached we know our source code is going to be looked at from ious things and if we put that hat

on then it becomes a lot easier to be able to secure it and we know a lot more about how to do that uh use automated Secrets detection so mistakes happen Secrets end up out there in the wild what you can do is use tools like GG Shield to scan your applications after they've been compiled to scan your code repositories and make sure no secrets are in there as an attacker I'm always going to be using automated secret detection there's heaps of bug Bounty tools out there like G leaks like truffle hog that we can that we can use as attackers to to find secrets so we uh as security as blue teamers need to

adopt the same approaches uh when it comes to identifying them and preventing them from leaking out in the first place uh restrict access we've talked about this you know uh whitel less Services short-lived credentials uh one of my biggest gripes as people not rotating credentials if you're using uh Secrets make sure you you have rotation policies in place this does two things one it means if a key gets leaked then it shouldn't have a long lifespan so it's not valid for long and two and if you're regularly rotating Keys it means you know how to do it so if a key gets leaked you know what that key is for and you know how to rotate it

the amount of times that someone will find a key and no one has any idea what that gives access to and you don't know if revoking that key is going to shut down and Destroy production um so you kind of just ignore it and hope the problem goes away but if we have a rotation policy in place then we can regularly rotate these Keys um so that they're not a problem uh use honey tokens is one of my favorite things at the moment is just using fake credentials to identify when when you're being attacked um and give give the attackers something to to to chew on honeypots are fantastic ways lines of Defense ensure your secrets are

always server side don't put any secrets in your mobile applications even if you think that they don't do anything uh and the other one is uh we a lot of these because there's misconfigurations you know misconfigurations in your Firebase misconfigurations in your S3 buckets um we absolutely want to try and reduce that use infrastructure as code because it means it's replicatable and then use infrastructure as code scanning to try and identify these misconfigurations I know some of these are a little bit outside of the talk today but this is just kind of uh uh uh my opinion of kind of things that we absolutely should should do so I'm a little bit early U but thanks I have a if if you found this

talk interesting I actually have another talk tomorrow at 5: to 5:45 um where we're going to be looking at how we can explore lots of things like how we can do basically the same thing there'll be lots of demos of how we can abuse Docker images and package managers um find misconfigurations and find secrets so if you're interested in this topic um I'll be speaking again tomorrow in this room at 5 to 5:45 uh and with that I'd like to thank everyone for paying attention and being here with me today it's been really really cool for me to be able to speak besides uh Las Vegas uh one of the one of the goals I had so thanks

everyone for being here and uh making it

possible and uh if anyone has any questions uh preferably easy ones then please let me know yeah your just a second please oh sorry sorry that's my fault oh uh I'm I'm actually kind of like behind on like the Mac OS operating system can you just download iOS apps to Macs these days no you can't you have to use uh an intermediary so if you're like uh I go back uh I used a tool here called IPA tool um so that's how so that's how you do it but um it it can be tricky to kind of like use these things if you just want to do some experiments there are Play Store and App Store mirrors that do

allow you to download it just be careful cuz about 80 of them are super dodgy delivering malware to you um but there are there are some legitimate ones too yeah yes uh your proposed solution is effectively back in for frontend is is sorry it's it's effectively backend for front end yeah yeah and so it puts a lot of um onus on the user to make sure they're using the correct application right so you could have a forged app that tricks the user into presenting their credentials to the back end and then the back end gives the forged app the credentials right yeah but I think that's a I mean that's an issue like a forged application is an issue for

regardless of whether you're you're doing this because I mean how if you got to download a mobile application you need to authenticate somewhere so you're going to be uh you know asking your user for credentials to log in um so that I mean that does put the owner on the user to make sure that they're using the legitimate application but this is but this is absolutely an issue that we're facing regardless I don't think that forcing it to go back in changes that um because if if you don't need to log in to an application then what your backend can do is send your your data so you got a public at you just open it up and you can do stuff

you you can still fetch public data so like it might even just be an RSS that your backend is producing so that you can download it if you don't need to to log in but by putting the credentials in the front in the front of that you know you're you're you're asking for trouble of people being able to manipulate that yeah yeah yeah over there I think it's more for the the videos yeah so uh would you suggest there's any value at all at putting either certificates in like an mtls type situation or cert pinning situation or an API key in an APK or app at all or is because of the the ability to pull them

out so easily there's really no value there I I would say there's absolutely no value it's the same as if you know I think you just assume that the the source code like if you can you put your source code in a public GitHub repository if the answer is no then that's not uh at a hygiene level that you should be creating APK from from from that um now there's lots of people that will say things like what about uh whether uh like Maps Google Maps API keys or you know weather API keys or something that like really offers no value for what I can do and the answer to that is like these things still charge now I'm not

going to be able to get into your infrastructure because of a a weather API key or Google Maps API key these are ones that we find everywhere uh but you have given me a button that if I press this button I'm going to charge you one cent or what at 0.01 Cent right now if I really dislike you I'm going to push that button a lot and I'm going to automate that pushing of the button so that you get a Big Bill so it's still not like okay I'm not going to be able to shut down your application but there's still lots of things that you can do uh to be able to do just to be

it's for your competitors to run up bills for you make you unsustainable I mean even a $1,000 Maps API bill is is is going to be very suspicious and kind of painful to pay so I think there's no value people always AR argue with me about like certain types of keys um and and whether or not you've configured it so that nothing but your app can use it and I agreee that all of that's good uh but you're relying on the fact that everything has to be perfect all the time your infrastructure has to be perfect 100% of the time I don't like the saying that attackers only need to be right once cuz truthfully they need

to be right lots of times to get there but you know it is kind of true in this sense that you're you're you're one mistake away from from that key being useful to me and as an attacker you know especially if I'm malicious I I can do stuff with it so I'd say absolutely no value you can argue you want but I don't think my position will change yeah just wait one second for the for the mic yeah uh how about storing the mtls client keys in the app uh in the Walt like you mentioned Secrets manager yeah so is that the standard practice uh it should be you know like putting putting Secrets see there's different levels the

talk after me is going to is going to discuss secret maturity model uh like so different levels of what to do uh and there's different levels to it um now I I differ from the the the General Security opinion of this so if we look at the very highest level we use haikot Vault we're using Dynamic secrets so secrets are being generated and destroyed after onetime use all that secrets are centralized there that's the best practice but is that reasonable for a small company to be able to manage a heavy tool like hasik V and that so then you go down a level um and and I say like no no if you because the chances

are you're not going to use it properly and you develop you're you're not there yet in your maturity so you shouldn't try and force this crazy tool on them if you go down and you have secret managers if you're using AWS or gcp they have secret managers they're less secure with less features but they do the job you know and and so I I'm an advocate for uh be reasonable with what you want okay aim for the vault have a path to get there um but but if that is what you need because the argument that I have is cu people always argue with this I'm all about finding secrets in weird and wacky and wonderful places so um you're

arguing should I use Vault I'm saying just don't put them in your damn APK like you know like let's start there don't put them in your source code we can talk Vault all you want but we're not at the stage where we can you know so just use whatever you're going to use vault is the best or other these other services out there like one password has some good ones or they've got some new Developers tools Doppler a keyless lots of tools out there that do great great things in managing Secrets um but just pick the right tool and and actually use it and just make sure you're not hard coating Secrets they start there and

then we'll we'll we'll work worry about the rest yeah hopefully that answers your

question oh Matt this one's going to be hard I can feel it no um I'm really kind of curious um where what areas do you see for improvement for that secret scanning aspect of it because a lot of things look like passwords uh so um how do you see you know areas that need additional research to make your job easier to find these secrets yeah so I mean secret scanners are actually getting better and better uh all the time I think a few years ago secret scanners were kind of creating lots and lots of false positives I mean at giging we've put lots of work into reducing that how we do it for it's easy for secrets that you

know it's like an AWS key or twilio key because I can check with the service is this real yes or no yes okay good so that means I can cast a wide NEP it gets tricky when you're talking about generic secrets secrets that are for systems that you built that I have no idea exist and so how we've managed to do that is we've we've created flags and post validation so we find a high ENT string looks like a secret what else clues in this you know do we know can we understand what this code is doing to flag it and we've been doing that but in all honesty I think that secret detection and high quality secret

detection over the next four years is going to become an absolute given like you you won't get away with having crappy uh secret protection AI is helping in this to be a to digest that so we have a record of uh everything that's happened on GitHub for the last seven years publicly so now with some machine learning and AI we can really start training it I think that the detection is going to get as good as it possibly can quickly um but I think where the problem comes in particularly as large Enterprises is not so much the detection of it it's more like how do you actually effectively remediate this issue you've got a th secrets you got

two apsic Engineers like you know like how like what are they going to do all year all they're doing is rotating secrets and investigating them so to me it's all about streamlining that remediation process and improving that area so that we actually know what to do and then um not just putting secret detection in like your source code or code repositories put it everywhere along the along the way do GI hooks to prevent them getting in the code repositories do scans after your application has been compiled uh all all of that kind of area so I mean there's lots that can be improved I think detection itself is getting better and better across the broad not just with us

but everyone even the open source tools are getting really good um so I feel like that's going to be a given which hopefully will help um but where it's going to get complicated is what what you do after you found them how do you actually deal with

that any other questions everybody let's give it up for Mackenzie thanks [Applause] everyone