LAS VEGAS – Access credentials, security keys and other "secrets" are all too frequently found embedded in web and mobile apps, and poor security practices are the reason why, said two researchers at the BSides Las Vegas security conference here on Aug. 8.
In back-to-back presentations, Mackenzie Jackson and Dwayne McDaniel of GitGuardian extrapolated the results of their company's most recent yearly scan of public GitHub commits — more than 1 billion in all.
A GitHub full of secrets
There were at least 10 million secrets revealed in those public GitHub commits, the pair said, 67% more than in 2021. They defined "secrets" as "anything that gives you access to another system or decrypts data" — username/password pairs, API tokens, database connection URLs and browser session cookies.
One reason for this is people uploading code to GitHub without checking for secrets, McDaniel said. He cited the case of a Toyota developer who accidentally posted nearly 300,000 customer email addresses to GitHub, a leak that went unnoticed for five years. Uber famously had a similar issue, as did pharmaceutical giant AstraZeneca.
"One out of 10 GitHub authors exposed a secret in 2022," said McDaniel. "Five-point-five out of every 1,000 commits contained a secret, 50% over the previous year."
The most commonly leaked specific secret in 2022 was Google API keys, which made up 9.7 % of the total.
All your secrets are belong to us
Jackson focused on credentials leakage by mobile apps, citing GitGuardian's own research that decompiled 50,000 Android apps from the Google Play Store and found nearly half exposed plaintext credentials.
"Where should secrets be stored?" Jackson asked the crowd. "Not in a front-facing Android APK or Apple IPA. Instead, the secrets should be in a back-end secrets manager. But in practice, it's a lot sloppier."
Read more of SC Media's coverage from Black Hat 2023 here.
One of the issues is that mobile apps are meant to do everything these days, Jackson said. For example, a bank's mobile app might not only display balances and deposits, but also let you transfer money to other users, speak to customer support and even deposit a written check by taking a photograph of it. That's going to require a lot of developers with different skill sets working on the app, and things might fall through the cracks.
Jackson cited the research of Buddobot CISO Jason Haddix, who took apart an iOS banking app from a major U.S. bank. Haddix found that check images were stored unencrypted in shared folders on the phone; two million unencrypted check images were stored on an insecure AWS server; and a hardcoded plist file in the mobile app contained administrative credentials for one of the bank's Apache Tomcat web servers.
How to pick apart a mobile app
Jackson explained that it's really quite simple to check mobile apps for hardcoded secrets. First you download a mobile app to a computer, using something like GPlayDL (for Android) or ipatool (for iOS).
The Android app can be decompiled using a tool called JADX; for iOS apps, Jackson said, just change the .ipa filetype to .zip and unzip the files. Then you can use GitGuardian's own app, GGShield (available at https://github.com/gitguardian/ggshield) to scan for credentials.
Jackson ran a demo on a decompiled Android app. The scan took about a minute and found hardcoded API keys and Slack webhooks that let you post to a private Slack channel.
Mobile-app developers need to make sure that no secrets are stored on the app itself, but instead on the server side, Jackson said. Apps should be signed, IP addresses should be limited to known machines, API keys should be limited in scope, and access should be restricted with whitelists, multifactor authentication, or short-lived credentials.
Both he and McDaniel stressed the importance of using a secrets manager like Hashicorp Vault, and of doing automated secrets detection on all apps. McDaniel recommended that development teams adopt the DORA metrics put together by Google's DevOps Research and Assessment program to improve app-development security.
