The attacker's guide to exploiting credentials & secrets

all right hello everyone great to great to be here uh really excited, it will be my first time in Estonia and a place I've heard a lot of great things about so thank you for for having me yeah, so uh as I said my name is McKenzie Jackson a little bit about me I'm from Aoterao New Zealand originally but I Now I live in the Netherlands so it's a little bit closer um I work for a French company called Gitguardian You can find me anywhere on social media with the handle Advocate Mac and I'm also the host of the security repo podcast it's my mom's favorite podcast she recommends all of you guys to listen to it so you can check that out if you want to

all QR codes in my presentation are scan at your own risk I'll promise you they won't do anything malicious but you never know all right so if we can just take a moment to pray to the demo Gods uh I was meant to do a lot of demos during this hopefully we have it sorted out but the demo Gods weren't on our sides this morning so hopefully everything will run smoothly right now but uh we will see as we go but in this presentation we're going to be talking about exploiting secrets and it's going to be a little bit of a of a blackhat mindset talking about this of understanding how attackers operate how they find and exploit these secrets so what am I talking about when I'm

talking about secrets so most of you probably know this but when I'm saying secrets I'm generally talking about digital authentication credentials now typically these are things like your API keys or credential peers it could be uh a security certificate these are really the crown jewels of any organization because they authenticate Services, systems and sometimes people into different systems. Attackers are always after these secrets because enables them to do something that all attackers want to do Elevate their Privileges and persist their access so Secrets can be used as a way of gaining initial access if they find a secret publicly or they purchase one then they can use that to break into a network, they can use that to gain access to that system it can be that

first foothold but it can also be used during an attack that they'll find along the way that they can use to then progress further dive deeper into these systems so attackers really really really like these secrets and one of the things that we we really need to understand about secrets is that these are made to be used programmatically so that means that they're not meant to be used by a human they're meant to be used by machines and services but that means that they're a high candidate for ending up in places that they shouldn't be because they end up in our source code and the reality is that secrets are absolutely everywhere if you know where to look look for

them um so today we're going to go through really four uh four parts about different ways and these aren't the only ways to find Secrets but we're going to look at four different ways where you might be able to find secrets in different systems and how you might go about uh abusing them how you might go about finding them and then at the end we'll look at what we can do to prevent this so the first one I want to talk about is abusing the GitHub API so you guys probably are familiar with this website here GitHub this is the most popular code sharing platform in the world it has hundreds of millions of developers that that use it you probably use it what's interesting about GitHub

is that even though your organization might not use GitHub the chances are the developers that work for you do of personally which means that your organization still has exposure to GitHub and there's still ways of finding sensitive information even if your organization doesn't use it at all so just some facts about uh some stats about GitHub last year so 2020 uh 2022 I forgot the year for a minute um uh there was over a billion commits that were made uh during the year so that's a billion commits that were made publicly this is only talking about public information with get you can have obviously private code and you can also have public code but publicly over a billion commits were uh made public last year throughout the year there was 85

million new public repositories so and about 94 million developers using it so what this shows us is it is an absolute fire hose of data and when there's this much data you're always going to be able to find really good information so as I said I work for a company called GE Guardian um and one of the things that we decided to do at gardian was launch a research project to find out how many many secrets we could potentially find on GitHub so what we did is we decided to scan every single public commit that was made on github.com I'll explain how we did that but we made we all those billion commits we scanned every single one of them in real time to try and find if there's

any secrets uh available uh anyone here want to take a guess as to how many secrets we found uh on GitHub last year who thinks who thinks more than a million all right who thinks less than a million right two hands two Brave hands we found 10 million 10 million secrets that were leaked publicly I'm only talking about publicly on github.com uh and so a lot of people say okay but how do you know that they're real Secrets how do you know it's not a test credential how do you know it's not a kind of some generic highend string uh how can we be sure that you what we're finding is real well we can actually categorize these and we did a lot of post validation so in

the categories that we had about 20% were for cloud providers So 20% 10 million some quick maths that's 2 million cloud provider keys that we found and one of the things about cloud provider Keys is we can validate these with their services themselves so we actually found 2 million valid cloud provider Keys uh on github.com again this is all just public and so you don't need to be very imaginative to know what can do with a cloud provider key you could do some crypto mining at the very least if that key is for your organization or something you can break in maybe steal some data maybe try and move into different systems we also found lots of other interesting

things messaging systems things like slack tokens these are actually really interesting for an attacker because it means that if I have one of them even if I can only post a message I can post a message internally to your organization that looks a lot more real so it is a potentially a way that I could get a foothold into the organization and one of my favorites down the 3.88% of what we found were Version Control platforms so basically what this is saying is we've found access keys to your private git repository that you have put in your public git repository it's a bit like putting the password uh in the subject line of an email uh so there's lots of different things that

we actually found in here and a lot of them are really really interesting and they're not always just for individuals a lot of the times these keys they're actually linked to organizations and it's because someone has either mistakenly uh contributed code to the wrong repository perhaps they're working on a personal project and not realized or perhaps there's something in a history that they've forgotten about when they've made something public so what has come specifics obviously there's thousands and thousands of credentials so we have a very long tale but some of the you know more interesting one Google API Keys is one of the most popular keys that we find including uh Google Cloud Keys is as well AWS Keys uh and Google oos token so a lot of these are

really really quite uh sensitive but we find so many that one of the one of the the questions you might have is that how do you actually find these Keys how would an attacker be able to find these keys and use them so there is actually a couple of quite simple ways the first one I'll talk about isn't my favorite but it's the easiest so I'll talk about it and that's literally just using the GitHub search feature to try and find secrets in this so in this case we have uh we're looking for a file name called credentials and we're looking for anws access key this is just one example uh of this now the reason why this isn't really my favorite way of doing this is

basically because when it comes to git when it comes to your source code what git does is it keeps track of everything in the history and that's actually where most of your secrets are going to be when you're using the search function it's only looking at the top layer and that's a drop in the bucket of all the source code that's actually available if you know how to look for it you're also going to find some real secrets in here but you're going to find huge amounts of false positives so you're going to spend all day doing that there are lots of different types of what we call Dos GitHub doing where you can copy these and try and find some interesting things but

luckily there's a much easier way for attackers attackers don't have to go through all that effort they can do it much easier and they can use the GitHub API so the GitHub API is at this address up here API . github.com events you don't need any auth you don't need any authentication to view this anyone can and what this is is it's a real-time Ledger of everything that's happening publicly in github.com so how did we scan every single billion commits you may think maybe we have some kind of partnership with GitHub no we don't uh we just use the GitHub public API um now you may think that this is this could be an abuse of that system but it's not because there's so many

services that do similar things using this API we're simply just using it for the same way now nef Furious actors are also using this so what we want to look at here is there's a couple of different events that get pushed on this API and the two that are most interesting are the public event so this event is when uh uh a private repository is turned public now why this is such an interesting event to look out for is that when you make something public you make all the history that have done public with it so if a developer two years ago working on a remote Branch committed a secret even just briefly that secret now exists and when you make the repository public you make

that secret public um and the other one is the push event this is just when code is pushed to public GitHub so attackers are often looking into this and what you can do is what we've started doing is stting to purposly leak some secrets in the GitHub API to monitor what attackers are doing them and how long so it generally takes the first attacker less than a minute to be able to discover the secret that you push on GitHub and that's not because they're looking someone is looking at it this is a bot that's using probably some basic reg regular expression to try and identify specific Keys test if they work and then move forward later on with an attack so today I have a a

workshop on creating honey tokens these are fake credentials and what we'll do in that Workshop is leak some of these on public GitHub and and see what Happ happens so it really takes about less than a minute for the first ones to actually start being discovered so attackers are really uh using this uh in in their method so let's talk about uh a scenario where that a public key has been leaked and was actually discovered so there's been quite a lot but last year we also had some news around a company called Toyota so small car manufacturing company um and Toyota have uh a mobile application called called t connect Now tconnect can do a lot of things including starting your car so

it's quite important but Toyota actually uses a lot of contractors in their work so this is where things start to get interesting and it paints a story of how Keys May leak on GitHub even without your knowledge so in two in 2017 there was a contractor that was working on the tconnect mobile application with Toyota now that contractor accidentally pushed code to a public repository in December for 5 years that code set there publicly without anyone really noticing what was in those code was hardcoded access credentials that gave access to all the data of all the users that were using tconnect so uh eventually in 2022 uh a uh a a white hat hacker actually discovered

it a security Reacher discovered it and then reported it to Toyota but that key was access and valid for 5 years on public GitHub so you can actually be certain that someone else had found that and was all and and starting to abuse it and toota can't comment on whether or not that actually happened because going through 5 years of logs to try and find malicious IPS is really quite a big challenge to do uh so this is an example of how even if you're not publicly using GitHub even if you're not thinking that hey I don't have any public repositories on GitHub I don't need to worry there's lots of ways that keys can still leak uh to this all right so that's kind of the

first part looking at public code and trying to find secrets and exploit Secrets inside public code so the next part that I want to talk about is private code because this is far more interesting for an attacker if they can gain access to it with public we have to deal with huge amounts of data and we're going to find interesting things but part of the security of that is that there's so much for us to look at and go through that it's hard to identify what's actually of interest to us but if we can get access to the private source code well this is much more interesting so there's been lots of leaks that have happened private source code is really terrible at staying

private and if we have a look we had some leaks like Microsoft had their source code leaked uh Nvidia Samsung and all of these companies I would consider have fantastic security posture I don't think that anyone could say that Microsoft uh has poor secur maybe you can I I wouldn't make that call um but so how did it how did how does this source code from these massive companies something that we'd probably consider to be a high value Target how did these leak well the lapsis group was really prolific in trying to discover uh source code on there and leaking it out and really one of the methods that they were doing is just buying access from employees when it comes to

private source code so many people have access to it that if there are secrets buried in there and I can almost guarantee that there are then all of those people have access to those secrets and a malicious actor can either try and fish them try and purchase access or different or or do different things to discover it now one of the things we also did at get Guardian is we decided uh we have we scan private source code for secrets and so we had a look at how many we would find now this next slide involves some maths so forgive me but uh really uh in an average company with about 400 developers so it's not huge but it's also not small would typically find about a thousand unique

Secrets each of those Secrets occurs about 13 times so we do maths 13,000 secrets we typically find now in a company with 400 Developers there probably going to be four appsec Engineers so each one of those appsec Engineers is going to have to then investigate that leak try and figure out what that secret is for revoke that secret if they need to issue a new secret and then redeploy all the code without creating any downtime and if we divide 13,000 by 4 we come to around about 4 thou 3,400 is secrets that those appsec Engineers have to do every single year so that would be their entire job so why is secrets and source code such a problem well Secrets often

end up inside them and the problem is so large that it's almost impossible to solve so you do the next best thing which is ignore it and then when someone gains access to your source code you can end up in quite a bit of trouble so if we take a look at one of these actual leaks we'll have a look at the the the source code leak of twitch so twitch had all of their source code leaked uh which included 6,000 repositories and those 3 million documents we scanned this leak um it was uh involuntary open sourced let's say uh we scanned it and we found 6,600 Secrets uh that were inside that source code that may seem like a lot but actually that's pretty good the only if we

only find 6,600 secrets in your source carde and you're that big of a company you're probably doing okay CU this is how big this problem actually is but in saying that we still found 194 AWS credentials 69 twilio Keys uh we even found four stripe keys inside their their their source code so this is a huge problem so what does this all mean well this means that attackers are really after your private source code if they can get access to your private source code then they can get access to a whole bunch of secrets that live inside there and they can potentially move into different systems and services right so how is private source code access then how do we actually

access this private source code well there's a bunch of methods I've mentioned a couple of them that attackers are doing the first one is the least exciting um but definitely one that happens and that's purchasing access so I mentioned the lapsis group this is actually a group of teenage hackers that were mostly after clout and they've got access into as I said Microsoft Nvidia Samsung all these companies so how do they do it well if you look at their telegram Channel they're literally just posting advertisements saying that they will pay you if we can give us access to your network or to your source code so if you look at you know who has access to your source code

and how many of them may be having a bad week that day then you can think of uh lots of ways that that people might find this attractive to Grant access to it we also have fishing fishing that's really targeted at developers here there was a campaign that was targeted at developers that were making Chrome extensions trying to get access to their source code so this is another way where developers are really being targeted in fishing campaigns to get access to it we also have exploiting misconfigurations so one common misconfiguration of git is that you accidentally expose your dogit directory this is a folder that has all the metadata of your source code in it

uh and it you can recreate the entire history of that git project from that these are quite often discoverable in public places uh and the other one which is quite difficult but definitely happens are supply chain attacks so we've seen one a good example was code kov where the attackers were able to gain access into private source code repositories by turning this tool that sits in the cicd pipeline malicious I'll talk a little bit more about that but what I really want to talk about for this uh for this presentation is I want to dive in on exploiting the misconfigurations so I mentioned about finding those dogit directories so what actually what actually happens is this

folder accidentally gets included u in when when code is is uh when applications are published and then that can be discoverable on networks so uh a great organization called cyber news did some wides scale scanning on this and they actually discovered that there was 2 million doget directories that were exposed publicly after doing some scanning so again this is a huge widespread problem so then you might have a look at okay how do I actually go about finding these dotg directories and actually starting to do them so I have my my first demo here we'll see if it uh if it works but this will be a video One um where we will take a quick look at at how we can actually

start scanning some of these uh these systems so it's really quite quite simple how I like to do it is I use a system called SubFinder here we are to basically uh discover subdomains so in this case I'm going to be looking for algolia I picked algolia because I know they don't have any uh they don't have any exploitable misconfigurations and I didn't want to uh I don't know if that's playing um but anyway I using algolia cuz they didn't what they didn't want and essentially what we're going to do is we're just going to use this tool to be able to discover as many subdomains as possible for this and we find a quite a few hundred and then we can actually uh look going through here so

we've uh we' found 267 and so what this means is that these are all the places I could potentially look to see if any source code has been exposed on these subdomains and so then what I'm going to do is I'm going to use a different Tool uh which is going to take this this list of all the subdomains and then we're going to try and discover if there's any kind of uh dogit directories that I can actually extract from these so this is just a tool uh this can scan it and then it will also dump it and then lastly it it will uh reconfigure it uh for it uh oh something happened there all right we'll move on um so uh we can extract the the the the git the the git

directories using um yeah using a a git scanner tool so these are the tools that I that I used SubFinder we have uh git scanner to expose them and then the last part of that is I will recreate I will recreate those uh git folders and then I'll scan them using a tool for instance GG shield and you can find lots and lots of different Secrets uh using these methods uh if you want to have a look at more Mis configurations is's a really cool progam called git goat uh which basically is a pable git uh configuration and you can actually have a look at all the different ways that you can exploit Miss configurations uh using this so the last one we've talked a

lot about source code I am going to move on from source code but why are secrets such a problem particularly in source code and a lot of it has to do with the history and how we build so I want to show you a scenario because I'm sure there's some developers sitting here saying other people may leak Secrets but not me I'm not an idiot I don't I'm not going to publish a SE a secret in here but here's a common scenario that we would see we have our main branch if you're not familiar with G this may look a little bit weird but you have your main branch and this has all the the source

code that's potentially out in public and then on that you have feature branches or different kinds of branches which enable developers to work uh to work independently on projects and then merge it in later so in this SP what we have is we have a a developer who's working on a project and let's say that that project is to try and Connect into a system into a database they need to get data from an AWS S3 bucket or something like that so just to test the project Works they hardcode a secret and then because they know they're not meant to do that later on they'll make sure that they remove that which is happening here and then a couple of hundred commits later it'll be time

to merge this into the main branch that secret is no longer visible to the person that's doing the code review because they only interested in what's the latest version of the main branch and what's the latest version of your feature branch and what's the difference between the two with them what they're not interested in is 200 commits ago that you submitted a secret but once that code gets merged in that secret still exists that secret still exists in that history and then a lot of people say yes but I use something like get squash I squash all my history well this secret still exists it's just in your in your bin store and so unless you do a garbage dump then that

secret still exists so Secrets really persist once they get into get it's extremely hard to get them out so this is why secrets so often end up inside inside uh get repositories some other areas it might inside logs and autogenerated files if you do a debug log often that might dump out your environment which has environment variables in it which are often Secrets if you're not using a dog ignore file all kinds of different things can end up inside there a lot of people uh have have secrets. txt or something on their desktop that accid accidentally gets captured in um they can be in template files so Django creates Django Keys automatically unless you know they're there

in remove them then they can end up uh quickly in there and then obviously it's just sharing on git not understanding uh how easy it is to access source code for attackers and finally hardcoding Secrets uh we see that a lot all right so I want to move away from kind of source C I want to start looking at how can we find secrets and abuse them in public other public areas and for instance in Registries or in containers so I want to have a look at Docker images and how we can actually find Secrets inside Docker images uh so just quickly uh this here is what a Docker image actually looks like so what's in green here these are source code files so when you think about Docker a

lot of people think that this is like some kind of black box but actually if you looking here there's a bunch of python files this is source code when you compile your Docker image you still have extractable source code in there and what we can do is we can simply I'm using a tool here called GG shield and we're just scanning this Docker image uh this is one that is vulnerable but they're not real Secrets I just want to show you how quickly and easy it is to do and essentially this is extracting all the source code extracting everything in interesting from the docker image including the docker file and then it's going to present if it finds any secrets in here so

here we have some beer tokens that potentially could be dangerous we have some API Keys uh in here and we also have some other uh passwords on other areas so this is just a a quick example of how easy it is to be able to identify Docker IM Secrets inside Docker images uh if we could go back to the slide yep perfect so this here is dockerhub so this is like the equivalent of GitHub but for Docker images and there's about 8 million or 9 million now Docker images that are hosted publicly uh on here so also we decided to have a look at how many of these Docker images actually contained a secret a hard-coded secret how big of a problem leaked credentials inside Docker images

so after scanning 10,000 images we found about 5% of them exposed at least one plain text credential so this is actually huge and there's been some new research um coming out of a university in Germany that looked at 300,000 docket images and found that about 8% of them contain secrets so this is actually a pretty massive problem and again all these docket images uh are actually publicly available so as an attacker you don't really have to look very far you download a 100 Docker images you're probably going to find at least five of them that are going to be vulnerable and have hardcoded credentials inside them uh so does this actually happen have attackers been able to find

secrets in Docker images and exploit them yes they have and a couple of them have been quite nasty so I want to look at one here this is one uh from a company called code COV you might have heard of it I actually really like COV as a company but they did make a mistake and it affected a few people but uh code COV is a code coverage tool it sits in your cicd pipeline and it's how you how it sits in an area where you build and test your application um so if you're not familiar with all of that here here's what you need to know code code COV tests how much of your application is being tested when

you're testing your application so it does a very specific job it's important to know what your code coverage is how much you are testing but you know this isn't something that you would assume would have critical access to anything so what actually happened well code COV how you often ran this application was that you downloaded the public Docker image and you used that in your cicd pipeline that public Docker image had a hard-coded credential inside of it that credential gave access to some source code this source code was hosted on a on a a Google Store I believe or some kind of storage uh and the hardcoded credential gave the attackers read and write access to be able to uh manipulate that what they were then able to do is turn code COV delicious

they injected one line of code and that line of code did this it said every time someone runs code COV in their testing environment I want you to dump all the environment variables and I want you to send them to me the attacker so if you don't understand what that is is basically when you build your application to test it you need a bunch of credentials to be able to do that properly uh those credentials sit in your environment and essentially this one line of code said take all those Secrets all those passwords and send them to me and the attack is a really only after one type of password though because they were after access to private source code they were access

to they wanted your GitHub and get access tokens and they were able to get that there was 20,000 Targets in the end and they managed to gain access to a lot of private source code so this kind of goes back to you know gaining access to thce code through a supply chain attack uh so this is an example where leaking a leak image really ended up with these attackers being able to move into huge amounts of different resources uh and this is a big problem so some of the companies that were affected by this were quite large companies monday.com twio uh hasi Corp rapid 7 all of these companies had their private source code accessed uh due to this uh misconfiguration if we can call

it that this mistake um now I very rarely pick on any companies to have a breach because I believe that it can happen to anyone um and we we we just need to deal with them but I am going to pick on one company just briefly that company is hasi Corp I hope no one works here for hhic Corp um but I I actually like hhi Corp I think it's a great company please don't sue me but uh uh hasik Corp created a product called hasik Corp Vault it is probably one of the best Secrets managers available on the market it can do all kinds of really great stuff Hashi Corp coined the term secret sprawl which is this unwanted distribution of Secrets um and part of this selling platform

was that if you use vault then you don't need to have secrets in your source code we can really solve this issue of leaked Secrets Hashi Corp because of this attack had to announce that they had a private uh private key that was inside their source code which was accessed by an attacker so if Hashi Corp have secrets in their source code the rest of us have absolutely no hope uh okay so move on now so how do how do Secrets actually get inside docket images here's just one example that I've seen a lot of again if you have hardcoded secrets in your source code they're going to end up in your Docker image if you understand Docker uh this may look a little bit familiar but we can

also get secrets in in what we call our Docker file which is how we build images and in this case like I said with Git with Git repositories your history is maintained well Docker is built up on layers so if you add a secret in one of the first layers and even if you delete it later we can still go back it so in this is a scenario that I've seen you have a nit RC file which contains credentials to a package manager uh generally and what this is doing is basically saying Hey I want you to use this nit RC file and then I want you to remove it at the end and the person then thinks

that because they've removed that then it's not going to be in the dock the docker image at the end but we can go back through the layers and actually access it so that's just one other way that that we can do it all right so I want to move on away from docket images I want to talk about one other type of application before we move on uh and that's mobile applications mobile applications are an absolute Trevor Trove for Secrets uh you can find them absolutely everywhere and this kind of comes down to a big misconfiguration or a big misunderstanding that we see in security a lot and that is that if something's non-human readable it means it's secure right so uh what do I mean by

that it's kind of similar with Docker images is when you compile something into a way that's not really extractable for you it looks like mumble jumble it's been OB fiscated then we think that that makes that secure but it's absolutely not the case and it's especially not the case for mobile application so there's generally two types of mobile applications if you're using uh iOS then you're going to have an IPA file and if you're using Android you're going to have an APK file this is really the the the file that at the end of the day when you construct your mobile application when you compile it it spits out one of these files so what are these files they're

not very friendly they're not that human readable um but they do contain a lot of great information uh and they're essentially glorified zip folders I'll talk about about that and that just means that they're extremely easy to extract it uh so we have the the last demmo that I want to do here if we could play video uh yep perfect so what I'm doing here is uh I have a uh an application here app 1.apk this is an Android mobile application I'm using a tool called JX to basically decompile this uh and what I want to show is this how easy it is to kind of get back to some kind of readable source code now when it comes to mobile applications you can find Secrets

everywhere but there's a couple of key places the strings.xml file uh in Android applications or the Android manifest are particularly of interest uh and as you can see here we've now gone back to a point where we have this original source code of this uh of this mobile application so we can see it now a lot of the things may have changed the names of the files may have changed it may be a little bit harder for me as an attacker to really understand uh everything that's going on in here but luckily we have tools so all I'm doing now is using the same tool I used before GG Shield uh there's other tools you can use as well to scan secrets and I'm just going to look inside

this Android application and I want to find some secrets so this will take just a couple of seconds but uh to talk about this this this particular application for the moment this is one that I downloaded from the Play Store this is a real application uh it's it's available I've masked the name and I'm not going to expose any of the secret but this is quite real I downloaded 10 applications to trial of this four of them contain Secrets one of them was far too vulnerable to show anyone and this was kind of the next best thing uh so this is really a massive problem and we'll talk a little bit about it all right so now that this has been decompiled again I want to point

out that this is real uh what do we have in here so once we get to the top we'll go through some of the secrets not all of them but you can see there's a lot of secrets that it's discovered so what's the first one we have uh generic password Here we have a slack web hook ID now as you can see this is valid uh so we've done a test to see if we can actually use this so that means that I potentially could post something in slack channels uh this is really helpful a slack web hook ID in most cases for an Android application will be to like crashing logs to send information about when

an application crashes so I could post something in there to try and gain further access we have some generic passwords here we have a Google API key again this is valid um uh and we have other Google API Keys as well um uh and and a few more we'll keep keep going but uh we can uh I think we can stop here and here you'll see the file that they're in so this is in a Java file the name won't mean anything but it's just been hardcoded in there um and if we can now get on to the next video should be the last video uh that we have in here so here I want to talk

about the IPA how do you how do you extract data from IPA we had to decompile the last one all you need to do for iOS is change the extension to zip once you change the extension to zip uh you can then extract that and get back to the source code uh very easily so here uh if we take a minute once this gets extracted so Android is if you want I wouldn't say Android's more secure Android just has an additional step uh but iOS you really you really uh it's when I say it's a glorified zip folder it really is a glorified zip folder uh and then once we here we have the application all you need to do is get rid of the apppp at the end and then that will give you a

folder containing all of the source code and then you can go through the same process of being able to uh to scan this for secrets in in the same amount of way uh and if we could go back to the slides now perfect uh okay so how case you're wondering how did I do this uh it's all it's all using open source tools uh GD Play downloader is how you can download an APK because you can't do it without a mobile but you can trick it into thinking that JX is what I use to decompile it to get back to human readable source code and then I scanned it with GG Shield uh like I did and I'll

talk about some other scanning tools that you can use later on uh we'll skip past this here we are and decompiling apple applications there's a tool called IPA uh download IPA which is a or IPA tool which is a way to download uh applications from uh the and Apple Store uh change the extension from IA to.zip and then you can scan it for secrets so does this actually happen do Secrets actually get leaked in mobile applications are there examples of that uh yes they do there's huge amounts I want to talk about one example now so here uh we have a a story this is this is from a whad hacker called Jason hadex uh who's the sio of bobot which is a pen testing company uh Jason talked about this

on my podcast of how he did this but uh he still does some penetration testing and he still does some bug Bounty programs and then one time he was working on a project for a tier One Bank in America this bank had a mobile application uh and part of that they had uh an APK obviously that he could so the first thing he discovered was that this application was taking images of checks I don't know why but apparently in America they still use checks um and part of this was that you could take a picture of the check and you could cash it using your mobile application what then happened is that he realized that those checks were being sto those images were

being stored unencrypted on on your mobile device and he figured that if they're being unencrypted on the mobile device that means they're being sent unencrypted somewhere so he found out that they were being sent to an Amazon S3 bucket for storage and that S3 bucket conveniently had the hard had the key hardcoded for it uh inside it so he then was able to use that key to access the Amazon S3 bucket and gain access to 10,000 unencrypted images of checks again this is for a financial institution this isn't some fitness app that someone has kind of built in their basement we're talking about uh pretty serious applications here with serious use cases and so the reason why I'll often see something like this is that the correct way to connect to Services is

through a backend and you should always go through your backend um so that your secrets aren't ever exposed you don't have secrets on your application but a lot of people think well if I go through my back end and then I have to go to the storage I'm kind of creating an extra step in there it's much more efficient to go directly to the storage and the only way to do that is to hardcode a credential which as we know is wildly insecure and can create uh problems like this so thank you Jason for uh sharing this story with us uh so how big of a problem is this again cyber news did some great research they found that about uh 56% of mobile applications contain at least one hardcoded

credential and when you look at some of this is that Google bucket storage is which is in line with what I was just saying was the number one uh thing in there now not all of these are going to be extremely sensitive that will create huge problems a lot of them will be keys for messaging systems which won't allow you to do anything unless you've done a misconfiguration on the server but it's still showing really poor practice and we're still huge amounts of examples of how to gain access to these secrets in here all right so I'm almost out of time uh so now I just want to briefly mention how do we avoid this right so I've gone through four examples of how to find secrets

in different ways from compiled applications from source code how do we actually prevent from doing this so the first one should be obvious but apparently not don't hardcode credentials right so even for it so this is our API key equals 1 23 hopefully that's not a real API key uh but basically you know this is the easiest way to do it helps you get moving forward quicker even if your intention is to remove it later don't do it handle the secret correctly from the start because it will end up in your history and it will create problems for you um now some other things that we need to talk about is how we actually store Secrets correctly so we want to store the

correct Secrets manager and this doesn't always mean that the best one is the right one for you cuz sometimes products like Vault Hy called Vault are too heavy if this four people in your team so you got to make sure that you pick a sequence manager that's going to do the job for you there's a couple of examples you know Vault and vaults are kind of up there at the top then you might have some other ones we got one password has some Cool Tools a keyless Doppler is another one these are kind of SAS sass solutions that help you manage your secrets uh Cloud uh Cloud providers that also have secrets managers in there these lack a lot of the features that the dedicated services

will have but if you're using them then at least you're not hard coding them in credentials and in your in your source code and then the last one is you know you can encrypt your secrets um and store them inside git now every single security person will tell you that the last one is a bad idea and I agree it creates a single point of failure it's really not a great practice to have your secrets encrypted and get however if this is going to prevent you from at least hard coding your secrets for the time being then that's better than storing them in plain text so I'm always like let's get to the first step and work towards having a vault in the end but as long as you're not hardcoding them

in plain text then I think you can be forgiven all right some other tips use automated uh tools to detect Secrets I work for a secret detection vendor so anything I say about this is going to be wildly biased uh so I use I use G Guardian uh there's open source tools like GG Shield which is what I used and there's lots of other open source tools travel hog git leaks yel detect Secrets the point of this is to say doesn't matter where you are doesn't matter what kind of budget that you you have there are free tools available for you to be able to detect Secrets uh so you absolutely should uh be doing this and and using these tools to be a because the the bad guys are using them uh

use GI hooks this is another one of once the secret enters your git repository it's kind of there forever the only way to to then do that to deal with that is to revoke it but if you use a gith hook you can potentially stop them from coming into this repository in the first place uh so this will you know pre-commit or pre push GI hooks actually prevent you from leaking secrets in the repository so it's a great way to get on top of it and actually stop the bleeding um rotate regularly use limit privileges just because having an admin key is more convenient doesn't mean you that you should do it uh whitel less different services and IP addresses so limit who can

actually access it if one particular service is meant to access something then make sure that only that service can and with 5 seconds left uh that's the end of my presentation if you want to find out more uh the state of Secrets for has a lot of the research I was presented and this one here goes much deeper into how to actually manage your secrets so I hope you found that interesting and