- CWE-22: Path Traversal
- CWE-78: OS Command Injection
- CWE-79: Cross-Site Scripting
- CWE-89: SQL Injection
- CWE-90: LDAP Injection
- CWE-91: XML Injection
- CWE-94: Code Injection
- CWE-98: PHP File Inclusion
- CWE-113: HTTP Response Splitting
- CWE-119: Buffer Errors
- CWE-130: Improper Handling of Length Parameter Inconsistency
- CWE-193: Off-by-one Error
- CWE-200: Information Exposure
- CWE-211: Information Exposure Through Externally-Generated Error Message
- CWE-236: Improper Handling of Undefined Parameters
- CWE-276: Incorrect Default Permissions
- CWE-284: Improper Access Control
- CWE-285: Improper Authorization
- CWE-287: Improper Authentication
- CWE-297: Improper Validation of Certificate with Host Mismatch
- CWE-306: Missing Authentication for Critical Function
- CWE-312: Cleartext Storage of Sensitive Information
- CWE-345: Insufficient Verification of Data Authenticity
- CWE-352: Cross-Site Request Forgery
- CWE-384: Session Fixation
- CWE-427: Uncontrolled Search Path Element
- CWE-434: Unrestricted Upload of File with Dangerous Type
- CWE-476: NULL Pointer Dereference
- CWE-521: Weak Password Requirements
- CWE-601: Open Redirect
- CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
- CWE-613: Insufficient Session Expiration
- CWE-618: Exposed Unsafe ActiveX Method
- CWE-671: Lack of Administrator Control over Security
- CWE-798: Use of Hard-coded Credentials
- CWE-799: Improper Control of Interaction Frequency
- CWE-822: Untrusted Pointer Dereference
- CWE-835: Infinite Loop
- CWE-918: Server-Side Request Forgery (SSRF)
- CWE-942: Overly Permissive Cross-domain Whitelist
CWE is a trademark of the MITRE Corporation.
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: January 10, 2019
Table of Content
- Potential impact
- Attack patterns
- Affected software
- Severity and CVSS Scoring
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:
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:
- 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.↑ Back to Top