Use of Hard-coded Credentials [CWE-798]

Use of Hard-coded Credentials weakness describes a case where hardcoded access credentials are stored within application code.

Created: June 11, 2018
Latest Update: December 28, 2020

Table of Content

1. Description
2. Potential impact
3. Attack patterns
4. Affected software
5. Severity and CVSS Scoring
6. Mitigations
7. References

Want to have an in-depth understanding of all modern aspects of
Use of Hard-coded Credentials [CWE-798]? Read carefully this article and bookmark it to get back later, we regularly update this page.

1. Description

This vulnerability is often referred to as a “backdoor”. The weakness exists due to presence in code authentication credentials that cannot be changed, e.g. hardcoded passwords, cryptographic keys, tokens, etc.

In case of web applications, there are two main variations of hardcoded credentials usage: to access the web application (e.g. inbound access) and to access the back-end application (e.g. outbound access).

The first variation creates a huge risk of web application compromise in case the attacker is able to recover access credentials (e.g. gain access to the web application source code or perform a brute-force attack). This technique is often used my malware writers to gain persistence.

A good example of such vulnerability is CVE-2017-14143. Kaltura server before 13.2.0 contained a code that allowed access to the web application to any user with pre-set "userzone" cookie equal to "y3tAno3therS$cr3T".

Presence of hardcoded credentials for outbound access is unfortunately a common practice for a variety of web applications. For example, any modern content management system is using database to store information. Access to the database is usually protected by login/password pair, stored in some file in clear text. If the attacker is able to gain access to those credentials and the database server is not properly secured, the attacker is able to use the obtained credentials to access the application’s database and compromise the web application.

2. Potential impact

The weakness allows a remote attacker to gain unauthorized access to web application. Usually it means that your web application is compromised.

3. Attack patterns

Use of Hard-coded Credentials weakness is associated with the following CAPEC patterns:

• CAPEC-70: Try Common(default) Usernames and Passwords
• CAPEC-188: Reverse Engineering
• CAPEC-189: Software Reverse Engineering
• CAPEC-190: Reverse Engineer an Executable to Expose Assumed Hidden Functionality or Content
• CAPEC-191: Read Sensitive Strings Within an Executable
• CAPEC-192: Protocol Reverse Engineering

4. Affected software

Any software that has management interface or scripting capabilities is susceptible to this issue.

5. Severity and CVSS Scoring

Hardcoded credentials pose a huge threat if they allow unauthorized access to the application. Therefore, this vulnerability should be scored as critical in most cases:
10.0 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H]

6. Mitigations

Immediate action is required if hardcoded credentials were detected in your web application that allow remote unauthorized access to the website. For applications where source code changes are hard or impossible to implement (e.g. credentials are stored within a .dll file in ASP.NET application) it is recommended to deny access to the affected URLs or scripts.

It is also possible to configure your Web Application Firewall (WAF) to deny access to website in case the hardcoded credentials are passed to the application via a request parameter. Below is an example of ModSecurity rule that will block the request if the "backdoorPassword" string is spotted in URL, arguments or any part of HTTP request:

7. References

1. CWE-798: Use of Hard-coded Credentials [cwe.mitre.org]

Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.