CWE-259 Use of Hard-coded Password: Inbound, Outbound and the Fix

CWE-259 describes a product that contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components. MITRE lists it as not language specific, with ICS/OT called out.

A hard-coded password is a secret that thousands of copies of your software share. Once one person finds it, everyone with a copy is exposed.

How it happens

MITRE separates two variations, and the fix differs for each.

Inbound. The product has an authentication mechanism that checks for a hard-coded password. A support login, a diagnostic mode, a default admin account.

Outbound. The product connects to another system and carries a hard-coded password to do it, such as a database account.

MITRE's inbound example:

int VerifyAdmin(char *password) {
    if (strcmp(password, "Mew!")) {
        printf("Incorrect Password!\n");
        return 0;
    }
    printf("Entering Diagnostic Mode...\n");
    return 1;
}

Every instance of this program enters diagnostic mode with the same password. If it ships as a binary only, changing that password or disabling the feature is very hard.

MITRE's outbound example, in Java, passes a literal user name and password to the database driver. The code runs fine, but anyone with access to it has the password. Attackers with the bytecode can disassemble it, for example with javap -c, and read the string constants directly. Once the program has shipped there is no going back short of a patch, and a devious employee with access to the code has what they need.

A sketch of the fix for the outbound case:

// Vulnerable
Connection c = DriverManager.getConnection(url, "scott", "tiger");

// Better: read the credential from the runtime environment or a secret store
String user = System.getenv("DB_USER");
String pass = System.getenv("DB_PASSWORD");
if (user == null || pass == null || pass.isEmpty()) {
    throw new IllegalStateException("database credentials not configured");
}
Connection c = DriverManager.getConnection(url, user, pass);

MITRE also shows cleartext passwords inside Java properties files and ASP.NET connection strings, which is the neighbouring problem covered by CWE-260.

What an attacker gains

MITRE lists access control: gaining privileges or assuming an identity. If hard-coded passwords are used, it is almost certain that malicious users can gain access through the account in question.

There is a second cost. A hard-coded password typically causes a significant authentication failure that can be difficult for the system administrator to detect. It can allow hiding activities, and it reduces maintainability: once detected it can be hard to fix, so an administrator may be forced to disable the product entirely.

MITRE's observed examples are all devices:

• CVE-2022-29964: a distributed control system with hard-coded passwords for local shell access.
• CVE-2021-37555: a Telnet service on an IoT feeder for dogs and cats with a hard-coded password.
• CVE-2021-35033: router firmware that used a hard-coded password for a BusyBox shell, allowing authentication bypass through the UART port.

How to find it

MITRE lists three approaches.

• Manual analysis, such as penetration testing and threat modeling. MITRE says these may be more effective than automated techniques for weaknesses tied to design and business rules.
• Black box monitoring. Attach a monitor to the process and perform a login. With disassembled code, look for instructions that compare the input to a fixed string or value.
• Automated static analysis, which MITRE rates high effectiveness for this entry.

You can also run a secrets scan across the repository and its history. A password that was committed once stays in history even if a later commit removes it.

How to fix it

MITRE's mitigations, all in Architecture and Design, split by use.

1. Outbound: store passwords outside the code, in a strongly protected, encrypted configuration file or database that is protected from all outsiders, including other local users on the same system. Protect the key properly. If you cannot use encryption, make file permissions as restrictive as possible.
2. Inbound: instead of a default user name and password for first time logins, use a "first login" mode that requires the user to set a unique strong password.
3. Perform access control checks and limit which entities can reach the feature that needs the password. For example, enable it only through the system console, not over a network connection.
4. Inbound: apply strong one way hashes to passwords and store the hashes with appropriate access control. On login, hash the incoming password and compare. Use randomly assigned salts for each hash, which raises the work needed for brute force and limits rainbow table attacks.
5. Front end to back end connections: MITRE says three solutions are possible, though none is complete. Use generated passwords that change automatically and are held in memory for limited time intervals. Limit the back end account to the actions the front end needs. Tag and checksum messages with time sensitive values to prevent replay.

If a hard-coded credential has shipped, rotate it and treat the old value as public.

Try it yourself

Scan a sample project and see how an embedded credential is detected.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE CWE-259