We all worry that our usernames and passwords will be exposed to hackers, right? So why do so many developers still use embedded credentials in their software?

Password/credential hardcoding refers to the practice of embedding clear text (unencrypted) credentials (account passwords, SSH Keys, DevOps secrets, etc.) into source code. Manufacturers and software companies commonly hardcode passwords into hardware, firmware, software, IoT and other devices. They are also commonly used in Infrastructure as Code (IaC) templates, scripts, applications, and systems because it helps to simplify deployments at scale. Developers and other users may also embed credentials into code, for easy access as part of their workflow.

As an example, the following code uses hardcoded username and password to setup authentication for viewing protected pages with Android's WebView.

This code will run successfully, but anyone who has access to the code will have access to the password. To see more examples of hardcoded credentials, visit Fortify’s Vulnerability Categorization system, VulnCat.

Not only does hardcoding credentials allow all of the developers on a project to view the password, it also makes remediation extremely difficult. After the code is in production, the password cannot be changed without patching the software. As a result, the credentials are usually left unchanged. If the account protected by the password is compromised, the owners of the system must choose between security and availability. Thus, hardcoding credentials may make developer's jobs easier, but it is also an easy launch-point for hackers.

Hardcoded credentials are a favorite threat actor target. Often, the same hardcoded credential, or a limited number of them, is used across all applications (many that require elevated privileges to function) or devices produced by a manufacturer/software development company within a particular series, release, or model. So, once a hacker knows the default password, they can potentially compromise all similar devices or application instances.

Zyxel ran into this hardcoded issue this year when hackers discovered an undocumented user account with full administrative rights that was hardcoded into their firmware. As a result, hackers targeted multiple Zyxel device models that hundreds of thousands of individuals and businesses use as VPNs, firewalls, and wireless access points for exploit.

Moreover, developers and other IT personnel frequently embed passwords in code for easy access when they need it. However, sometimes these passwords are forgotten and remain embedded as plain text in code. When rotating credentials, if someone misses one of the locations where a set of credentials is manually entered, it can take down a mission critical service. Sometimes the code is even published in code repositories (such as to GitHub) with the plain text password easily discoverable.

Recall the Uber breach and cover-up in 2016/17 that exposed information of 57 million customers, plus roughly 600K drivers? It was widely reported that is what happened to them. Uber developers hardcoded their usernames and passwords on a private account within source code. This code was, at some point, posted on GitHub. Once hackers discovered the credentials they used them to gain privileged access on Uber’s Amazon AWS Instances.

Static application security testing with Fortify SAST can flag clear text credentials in source code. To flag a hardcoded password, Fortify SCA’s structured analyzer will find patterns similar to the following: “password=myPassword”, “pwd:UserPwd”, and “mainkey=admin”. Password leakage can occur if the pattern rule doesn’t align with what’s found in the code/comments. Also, the analyzer can be noisy with false positives, which can be a pain (mitigated with use of filters). BUT when you ignore discovery efforts completely because of the noise you can get a rude awakening of a breach. 

Eliminate the use of hardcoded credentials

Trying to discover whether hardcoded credentials are being used in code is a good first step. The use of clear text credentials also occurs in config files, Infrastructure as Code, and containers. In addition to being a potential security exposure, use of hardcoded credentials can impact cyber resilience. Beyond getting visibility into their use, it’s best to properly govern/protect credential usage to improve security and resiliency.

A best practice is to use a Secrets Server or a credentials vault to manage all types of secrets, like passwords and SSH keys. This approach provides an API that gives access to secrets based on policies and eliminates the need to store credentials in clear text in applications/config files/services.

NetIQ Privileged Account Manager (PAM)’s Application to Application Password Management (AAPM) feature, or AAPM Server, is our version of a Secrets Server. The AAPM Server helps improve application security posture by reducing human error, automating security related tasks and improving insight and governance. As for changing credentials, we can schedule the automatic rotation and enforce the use of strong and unique credentials without the need to manually intervene with every endpoint using them. The sweet spot for AAPM Server is during app development where an application can query PAM for the credentials using its REST API to secure credentials by tokenizing them. 

Thanks to our Interset data scientists, PAM now has the capability to evaluate the riskiness of a privileged session. The AAPM server leverages unsupervised machine learning to evaluate the use of credentials (especially service accounts) upon every access for risk and anomalous behaviours.

So. Expose where hardcoded credentials are in your code using Fortify SAST, but then go further by leveraging PAM to properly manage your credentials and eliminate this unnecessary risk. And avoid the data breach headlines.

More information:

Join our Fortify Community. Have technical questions about Application Security products? Visit the Fortify discussion forum.  Keep up with the latest Tips & Info about Application Security. We’d love to hear your thoughts on this blog. Log in or register to comment below.