Use of Hard-coded Credentials

Draft Base

Structure: Simple

Description

This vulnerability occurs when software contains built-in, unchangeable authentication secrets like passwords or encryption keys within its source code or configuration files.

Extended Description

This flaw typically manifests in two primary scenarios. The first, often called 'inbound authentication,' involves the software checking user logins against a fixed, default set of credentials—like a universal admin account with a simple, embedded password that's identical across every installation. This password usually cannot be changed or disabled through normal administrative controls, requiring a code patch instead, and it can be extremely difficult for system owners to even detect its presence. The second scenario, 'outbound authentication,' happens when an application (like a front-end service) needs to connect to another system (like a back-end database) and has the connection credentials permanently written into its code. Developers might hard-code these backend passwords for convenience, but this makes them easily discoverable by anyone who can access the application's code or binaries, exposing the connected system to unauthorized access.

Common Consequences 2

Scope: Access Control

Impact: Bypass Protection Mechanism

If hard-coded passwords are used, it is almost certain that malicious users will gain access to the account in question. Any user of the product that hard-codes passwords may be able to extract the password. Client-side systems with hard-coded passwords pose even more of a threat, since the extraction of a password from a binary is usually very simple.

Scope: IntegrityConfidentialityAvailabilityAccess ControlOther

Impact: Read Application DataGain Privileges or Assume IdentityExecute Unauthorized Code or CommandsOther

This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code. If the password is ever discovered or published (a common occurrence on the Internet), then anybody with knowledge of this password can access the product. Finally, since all installations of the product will have the same password, even across different organizations, this enables massive attacks such as worms to take place.

Detection Methods 11

Black BoxModerate

Credential storage in configuration files is findable using black box methods, but the use of hard-coded credentials for an incoming authentication routine typically involves an account that is not visible outside of the code.

Automated Static Analysis

Automated white box techniques have been published for detecting hard-coded credentials for incoming authentication, but there is some expert disagreement regarding their effectiveness and applicability to a broad range of methods.

Manual Static Analysis

This weakness may be detectable using manual code analysis. Unless authentication is decentralized and applied throughout the product, there can be sufficient time for the analyst to find incoming authentication routines and examine the program logic looking for usage of hard-coded credentials. Configuration files could also be analyzed.

Manual Dynamic Analysis

For hard-coded credentials in incoming authentication: use monitoring tools that examine the product's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the product was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic. Attach the monitor to the process and perform a login. Using call trees or similar artifacts from the output, examine the associated behaviors and see if any of them appear to be comparing the input to a fixed string or value.

Automated Static Analysis - Binary or BytecodeSOAR Partial

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis

Manual Static Analysis - Binary or BytecodeHigh

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Dynamic Analysis with Manual Results InterpretationSOAR Partial

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Network Sniffer Forced Path Execution

Manual Static Analysis - Source CodeHigh

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review (not inspections)

Automated Static Analysis - Source CodeHigh

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer

Automated Static AnalysisSOAR Partial

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Configuration Checker

Architecture or Design ReviewHigh

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.) Formal Methods / Correct-By-Construction

Potential Mitigations 5