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, Synopsys 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.
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.
Secrets leak often. Here are just a few recently reported large-scale incidents.
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.
There are various types of hard-coded secrets, including usernames, passwords, keys, and access tokens. Let’s explore the details and implications of some of these types of secrets, and how the Synopsys Rapid Scan Static engine detects them within Synopsys Code Sight™.
Explicit password strings within source code in variable assignments, string comparisons, or for any type of manipulation in code will cause them to leak in the final executable or app. Passwords in infrastructure-as-code (IaC) configuration files, scripts, and other locations are also security risks because the underlying storage can potentially be accessed by a determined attacker, through vulnerabilities in open source components, unsecure source code, or other methods.
Figure 1: Synopsys Code Sight in VS Code detecting a hard-coded password inside an IaC config file
SSH keys are widely used to authenticate users to systems (and systems to users) via public key cryptography. The broader SSH protocol has strong encryption to protect traffic and is commonly used on the internet for system access and file transfer. Leaking admin SSH keys could mean allowing an attacker full access to that system.
This example provides some context into how an SSH key could be revealed within source code.
Figure 2: Synopsys Code Sight in VS Code detecting a leaked SSH key in a Java source file
Access tokens are often used in API, HTTP, and RPC calls on the internet to authorize access to a service on behalf of a user. The token contains credentials and other pertinent information (e.g., the resources being accessed) and as such, is a secret. On the server side, if a resource or service for a user is allowed for a given token and that particular token is presented in a request, the call will succeed. It’s not hard to envision how a hacker could leverage access tokens embedded in source code to propagate an attack.
Figure 3: Synopsys Code Sight in VS Code detecting a leaked access token in a Java source file
Rapid Scan Static identifies generic hard-coded secrets and looks for specific ones from cloud providers such as
Dropbox, Facebook, Google, Instagram, LinkedIn, PayPal, Slack, Square, Stripe, Twitter, Uber, Urban, Vonage Webex, WeChat, WePay, Yahoo, Yandex, Yousign, Zendesk, Zillow, Zoom, and more. (50+ in total)
Java, JS, TS, Swift, JSON, XML, YAML, Terraform, properties, .conf, Dockerfile, HTML, and more
Source code often contains many hard-coded values that are used during testing and that do not make their way into the shipped product. Because such test code is not included in the shipped product, issues reported in these sections of the codebase are generally considered false positives. It’s important to define the context in which the presence of a secret within source code may not manifest a risk in production. For example, security, DevOps, and engineering teams can configure Rapid Scan Static to explicitly include or exclude specific files or directories for scanning.
To increase accuracy, Rapid Scan Static does not rely only on regex pattern matching to detect hard-coded secrets. Certain secrets require semantic understanding of variables, values, and other context in source language and configuration files in order to detect them without false exclusion from analysis. The approach that Synopsys takes avoids the up-front work of specifying any regex pattern or configuration. This simplifies secrets detection and eliminates potential points of failure due to misconfiguration or deviation from established patterns. Conversely, regex-only solutions can be noisy when pattern matching is the only technique.
Secrets are typically introduced by individuals writing source code or configuration files, but there are many stages in the software development life cycle (SDLC) where they can be inadvertently added as well. For example, during a deployment build or while deploying to a staging environment for final test, an automation script may inadvertently copy a set of files that contains secrets. It’s important to account for these late-stage scenarios before final deployment into production.
The following diagram illustrates the different stages in the CI/CD pipeline. The stages when secrets can be introduced should be tested with the most appropriate tools within the context of that stage. In this example, we’ve configured Synopsys AST tools to help secure the entire pipeline and range of digital assets.
When, or in what context, is it optimal to detect embedded secrets? It’s best to minimize the risk of pushing secrets downstream. As such, detecting secrets while working inside the IDE can both minimize the risk of publishing secrets as well as reduce the remediation effort. Late-stage detection creates more work for everyone, including for yourself as you close out tickets and make additional commits. With Code Sight running inside IDEs like VS Code and IntelliJ, secret detection occurs in real time. Developers can quickly review a detailed description of the issue and get remediation advice to help mitigate or eliminate the risk.
Figure 5: Code Sight running Rapid Scan Static in VS Code detects secret leakage as the developer codes
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.
Black Duck® Binary Analysis (BDBA) scans final shipping products, or in the case of cloud applications, the contents of a container. At this stage, the container will contain JARs, IaC, and binary executables. BDBA can take apart archives and binaries to look for secrets.
Some source code may also be present within the shipped product or container. With Rapid Scan Static, BDBA will automatically scan IaC, JavaScript (node.js and other frameworks), and any other type of supported source language files
Figure 6: Black Duck Binary Analysis displaying a leaked password in a JavaScript file
Seeker® is an interactive application security testing (IAST) solution that includes Rapid Scan Static. Seeker looks for vulnerabilities that manifest during runtime, and it is often incorporated into QA tests, effectively transforming functional tests into security tests. For example, a web server may send JavaScript code to a mobile app on iOS as part of a personal banking application. In such a scenario, Seeker can route this code through Rapid Scan Static to look for leaked secrets.
Figure 7: Seeker shows a secret leaked via JavaScript code to an App or Web browser
Black Duck software composition analysis (SCA) is used by security and legal teams to manage open source vulnerabilities (e.g., CVEs) and support open source license compliance. This enables security teams to identify open source components that contain secrets and prioritize them for remediation.
Figure 8: Black Duck showing a list of hard-coded secrets leaked in IaC configurations
The quickest way to experience Rapid Scan Static’s secrets detection capabilities is via Code Sight. Download Code Sight from the VS Code Marketplace or from the JetBrains Marketplace (IntelliJ) and jump in with a free trial, or import your team’s license if you are already a Coverity or Black Duck user.