On March 19th, news broke that researchers uncovered more than 19.8 million plaintext credentials publicly exposed through instances of Google's Firebase. Firebase is a popular app development platform used by over 3 million developers worldwide and nearly 4,000 enterprises.

In mid March, three security researchers, mrbruh, xyzeva and logykk, discovered the secrets while checking more than 5 million websites for security flaws. This was a follow-up to previous research, in which they were able to gain "superadmin" permissions due to misconfigurations.

This new round of research unveiled 916 websites that had either no security rules implemented or where security was misconfigured. Not only were plaintext secrets discovered, but more than 125 million sensitive user records containing emails, names, phone numbers, and billing information with bank details were also discovered. According to the original reporting summary "These numbers should be taken with a grain of salt. They are likely larger than shown here."

Improperly stored credentials

This incident is consistent with the conclusions we have drawn from our research released in the State of Secrets Sprawl Report 2024: developers are increasingly improperly storing plaintext credentials, and secret sprawl is only getting worse.

The passwords uncovered were stored as plaintext inside the application databases. This is especially alarming because Google provides Firebase Authentication. This end-to-end identity platform can make it unnecessary to store user passwords in the first place through the use of OpenID Connect or integration with any custom authentication service.

If a developer does need to store passwords in a database for some reason, there are very well-established patterns of using salted hashes or other encryption methods to ensure that if the database is exposed, the password entries will be useless. For these sites in question, it seems this was not a consideration. The researchers reported that, to them, "companies must have gone out of their way to store [the password] in plain text."

Researchers report showing the counts of records with unhashed credentials Source: env.fail

IaC means misconfiguration at scale

These findings also show that misconfigurations continue to provide an attack vector for malicious actors, as we have seen with other reports, such as a researcher finding GitHub admin credentials at a major car company and Microsoft leaking 38 TB of records. The issue is only compounded when deploying at scale, as a misconfiguration in one instance can easily mean misconfigurations in hundreds of incidents, all by changing one variable.

This is why GitGuardian developed Infra as Code Security. The GitGuardian platform can scan for over 100 of the most common IaC misconfigurations. We can help developers detect issues like using HTTP instead of HTTPS or Unrestricted ingress traffic, which can lead to attackers from unknown IP addresses accessing your internal DBs. Security and development teams can shift left with GitGuardians IaC scanning thanks to ggshield, our CLI, which can detect and prevent IaC misconfigurations before a commit is made.  

Multifactor authentication is vital for applications

Unfortunately, if security researchers could easily uncover this many passwords, it is likely that malicious actors also discovered them. As we saw in other recent attacks, such as the one at Cloudflare, it is likely only a matter of time before these passwords will be used in a future attack. It is more vital than ever for developers to keep plaintext passwords out of their code, databases, and environments.

One way developers can protect users is by implementing multifactor authentication, MFA. As Microsoft is fond of reporting, "MFA can prevent 99.9 percent of attacks on your accounts." If properly implemented, even if a malicious actor does get your password, they will still not be able to gain access unless they also have access to your other authentication method. While it is not a completely foolproof system for advanced persistent threat actors, as we saw with incidents like the one at MGM, it will deter the most common attacks.

Leverage available security tools early in development

It is easy from the outside to say, "If they had just done X, this would not have happened." Hindsight is 20/20. The truth is security is challenging to get right at every step, especially if you are under pressure and up against tight deadlines. Developers don't need additional steps or forced "best practices" mandated on top of their workload. What they need are better tools that integrate as seamlessly as possible into their flow.

At GitGuardian, we believe in meeting the security challenge at every step of the software development lifecycle. With ggshield, developers can set pre-commit hooks to double-check for common IaC misconfigurations and for any secrets they might have added in plaintext. We can also scan at the pull request step or as late as the CI/CD pipeline, meeting you where you are on your security journey.