React Summit

React Summit 2023

<p>Secrets like API keys are constantly leaking through source code. The 2021 State of Secret Sprawl report found over 6 million secrets in public git repos. This presentation reviews the new, unreleased, 2022 State of Secrets Sprawl report focusing on how JavaScript source code specifically leak secrets.</p>

Secrets in Source Code - How Your JS Code is Exposing Your Credentials 

Hey everyone, my name is Mackenzie. I'm a developer and security advocate at GitGuardian and in this lightning presentation, I'm going to talk about secrets inside code and how your JavaScript applications or your React applications may be leaking your secrets. A good place to start is really what are secrets. When I'm talking about secrets, I'm referring to digital authentication credentials. These are typically things like your API keys, your credential peers, like your database credentials, security certificates, anything that grants access into services or allows you to ingest data or write data. Really, these are the crown jewels of any organization. Because an attacker is going to go after these immediately when they make access into anything, allows them to persist their access or move laterally into different systems, elevate their privileges, and they can do all of that whilst remaining undetected because they're properly authenticated into services. To understand how we use secrets, let's take a step back and look at how we build applications. No longer are we building monoliths. Our applications are more or less a collection of different services. For example, we may use Okta to authenticate users into our systems. Maybe we're using Stripe to process credit cards. MongoDB is a managed database. Very quickly, our applications can become a collection of all these different systems. One of the things we do at GitGuardian is we scan code around the place to try and identify where these secrets are. We release it in a report each year called a state of secrets fraud. One of the places that we scan is github.com. You're probably familiar with it. Lots of developers are. In fact, at 2022, 94 million developers were using GitHub according to GitHub themselves. We've crossed the 100 million developer mark by now. Last year, just last year, over a billion commits were made to public code repositories, just public code repositories. That's a huge amount of data. 84 million new repositories were made, again, just public. This is a literal fire hose of information. You can find anything and everything in GitHub and public repositories, including secrets. There's one billion commits. GitGuardian actually scanned every single one of them last year. We scan them for secrets. In fact, nearly 400 different types of secrets we were looking for. What did we find? Well, we found over 10 million secrets that were detected in public repositories in GitHub. Ten million. This is a big increase from previous years. The first year we released this report was in 2020 when we found three million, and you can see the progression to 10 million now. Partly, this is explained by more developers on GitHub, but it's also explained because we're actually using more and more secrets every year. Now, we have different things like infrastructure as code, which is the fastest growing segment on GitHub. We're now programmatically managing our infrastructure, so we need to use secrets to do that. More secrets, more leaked secrets on GitHub. There's a whole bunch of lots of information that we can find on GitHub. Now, we look for specific secrets and we validate them when we find them. Some of the more interesting things that we've found are, for example, that 20 percent of the secrets that we found were for Cloud providers. Things like Google Cloud Services or AWS. Again, these are valid credentials. This is two million valid Cloud provider keys that we found in public places in GitHub. We even found lots of different things like messaging systems, database keys, and even keys to your version control platform. This is access to your private repositories that you put in a public repository. A lot of the extensions that we found here, Python was the number one language that leaked secrets, but JavaScript is really the second language when we exclude JSON and ENV files, which are really language agnostic files. But we're just looking here on this slide at JavaScript file extensions. Now, it may not be a surprise that app.js or index.js are really the number one applications. This is really a main file where the developer has hard-coded their credentials into their source code. This is a very bad practice, but it doesn't come as an overall surprise. But we can find some interesting things as we look through this data. For example, we have configuration files for specific services. Docosaurus is like an out-of-the-box framework to build websites on, and it comes with a configuration file. You can just simply replace the example text and put your own keys in here, and commit this to GitHub, and now you've just exposed your keys. Is this really a security risk? Do hackers actually monitor GitHub for these credentials? The answer is yes, very frequently. One example that we had last year was with Toyota, where a contractor working for Toyota accidentally leaked public keys, accidentally made a private repository public, which leaked keys to a database that Toyota's mobile application was using, a mobile application called T-Connect. These are keys that gave access to all the users information that we're using T-Connect, that was sitting out there in a public repository. This is just one example, but there's many more examples of where real keys belonging to organizations, having real consequences, have been leaked out in public places. But it's not just public repositories that you need to worry about, it's your private repositories too. Source code that is private is always accidentally finding its way out into public places, or as I call it, involuntarily open sourced. The Lapsus Group, for example, last year, publicly released the source code of NVIDIA, Samsung, Microsoft, and many, many more. You may ask, how did they gain access to private source code? Well, there's lots of different ways. Source code is a very leaky asset, which means it's sprawled everywhere. It's on your developers machines, it's backed up, it's in wikis, it's shared over messaging systems, and of course, it's in your Git repositories. Also, a lot of people have access to your Git repositories. I know for a fact that Lapsus was simply paying employees to grant them access to public private source code. It's not that difficult for a threat actor that's motivated to access your private source code. If you're thinking you're safe because you don't have open source repositories, you're not. Secrets definitely should not be in your code regardless of where they are. Why do secrets get exposed? There's lots of different ways. Maybe you're committing things and you're testing out keys so you've hard-coded them in there, not realizing that those keys are going to be in your history forever. Even if you do something on a development branch, you hard-code credentials, you quickly remove them later because you're just testing it, those credentials are still going to be in your Git history, and they're going to be there forever. They can be printed out in auto-generated files like debug logs. You can include sensitive files in your Git repositories like.env files or.pem files. These should never be in your repository, so make sure you use a.gitignore file. You can also accidentally push code to the wrong place. How do you prevent them from doing this? Well, you should never hard-code secrets. Never directly type in the secret into your application. That's rule number 1. Doesn't matter if it's private, public, or what kind of branch you're working on, or for how long it's there, because it will be there forever in Git. We also can use tools to prevent them from being leaked. We can use tools to enable us to do this. We want to store keys on the back-end. If you're building a React app and you're making it look pretty, we want to make sure that you're accessing your credentials through the back-end, and it's passing you the data that you need, and you're not dealing with it directly. There's not many scenarios where you actually need to handle those keys on the front-end. If you are handling keys, make sure you store them in a centralized place. For instance, a.env file. Just make sure that this.env file is added into your.gitignore file so it's never included in your Git repository. You can use great tools like.onv, which has a JavaScript. You can use great tools like.onv for JavaScript, which will load your secrets and local memory from your.env file into environment variables, meaning that your application won't accidentally leak them, and they won't need to be in your Git repositories. If you want to go a step further, we should definitely be using vaults and secrets managers. We need to rotate our keys regularly, so that even if a key does get leaked, you're on a rotation schedule, so it won't be valid for long. We need to restrict the access of the key. We should restrict it down to just the services that we expect. The threat actor gets it, they can't do anything with the key. For sensitive stuff, we should be signing those keys with a hash of the application that's using it, so that we're absolutely certain that everything that's being used is for legitimate purposes only. Thank you very much. There's a couple of QR codes on the screen. One will take you to the state of secrets we'll report for 2023, and the other will look at a secrets management maturity model of how you can correctly handle your secrets in various different ways. Thanks for listening. I'm McKenzie, and I'll see you next time. Thank you.
