Finding hard-coded secrets before you suffer a breach

The most severe vulnerabilities in a system or application can be caused by an easily overlooked issue—for example, a leaked hard-coded secret can allow an attacker to steal data or compromise a system. To help combat this, Black Duck has enhanced its Rapid Scan Static engine, which analyzes source code for security and quality risks, and detects embedded secrets and sensitive information.

Let’s explore what hard-coded secrets are, how they can be leaked, and how to detect them before pushing software into production.

Understanding hard-coded secrets

Hard-coded secrets include any type of sensitive information, such as usernames, passwords, SSH keys, and access tokens. They can be easily leaked to an attacker if an application’s source or configuration contains them. To help understand why this happens, consider the following Java code snippet:

[php]private bool isAdmin (String username, String password)
{
if (username.equals(“admin”) && password.equals(“letmepass”))
return true;
else
return false;
}
[/php]

A developer might insert such a block of code for local testing purposes and forget to remove it. When this Java source code is compiled, the resulting executable JAR file will contain the strings “admin” and “letmepass.” Wherever this executable is placed, whether downloaded into a mobile device through app stores, deployed into a server, or dropped into any type of system, the strings can be scraped if a hacker gets access to their underlying storage.

Often, the easiest route to gain access to records is simply to log into a system using these easily obtained leaked passwords or access tokens.

Seeing the scope of the problem of leaked hard-coded secrets

Secrets leak often. Here are just a few recently reported large-scale incidents.

• In this August 2, 2022 article, it was revealed that Twitter API keys were leaked through 3,207 mobile apps. This type of leak allows an attacker to access various categories of sensitive information, including direct messages sent between Twitter users through associated apps.
• On September 1, 2022, Symantec published an article showing 1,859 apps (iOS and Android) contained AWS tokens, 77% of which allowed access to private AWS cloud services, and 47% allowed access to files, often in the millions, in S3 buckets.
• On September 15, 2022, Toyota noticed it had inadvertently leaked keys in source code that it uploaded to GitHub, which allowed an attacker access to 296,019 customer records with email addresses. Upon discovering the leak, Toyota immediately notified affected customers to be careful of phishing attacks.
• One of the most high-profile data breaches was Target, which had 40 million of its shoppers’ credit and debit card records stolen. As a result, at least five lawsuits were filed seeking millions of dollars in damages across several states, and Target’s sales dropped by up to 4% compared to the prior year period. To minimize damage, the store offered a 10% discount and free credit monitoring services to affected customers. When the dust finally settled few years later, Target ended up spending $202 million in legal fees and damages, according to The New York Times.

A burning question at this point is, “Why didn’t these companies catch the leaks before they put the software into production or a public GitHub repo?” If steps and mechanisms had been put into place to detect embedded secrets—scanning developers’ code within the IDE, during pull or merge requests, or in nightly scans—it’s quite likely that the leaks would have been caught. Doing this earlier in DevOps workflows helps to ensure that secrets are not pushed downstream and helps to reduce the cost and delays associated with remediation.

Figure 1: Code Sight in VS Code detecting a hard-coded password inside an IaC config file

Figure 2: Code Sight in VS Code detecting a leaked SSH key in a Java source file

Figure 3: Code Sight in VS Code detecting a leaked access token in a Java source file

Figure 5: Code Sight running Rapid Scan Static in VS Code detects secret leakage as the developer codes

Detecting secrets during static tests using Coverity SAST

Coverity® already had secrets detection capabilities. With Rapid Scan Static, it now has the ability to detect secrets across a broader range of file types, specific service provider formats, and IaC formats. Best of all, Rapid Scan Static runs automatically inside Coverity, and the vulnerabilities it finds automatically become part of the existing remediation workflow.

Figure 6: Black Duck Binary Analysis displaying a leaked password in a JavaScript file

Figure 7: Seeker shows a secret leaked via JavaScript code to an App or Web browser

Figure 8: Black Duck showing a list of hard-coded secrets leaked in IaC configurations