IBM published a security bulletin called IBM i is vulnerable to an attacker executing CL commands due to an exploitation of DDM architecture on 2023.06.30, fixing an unauthenticated remote code execution vulnerability reported by us.

This blog post contains the technical details of the discovery and exploitation processes.

DDM forms an integral component of the IBM i licensed program. IBM i DDM allows application programs or users to retrieve data files from remote systems or execute CL commands after authentication. When authorized, any client system that supports the DDM architecture can access data from other connected systems. For more information see IBM’s overview!

When I try to discover security vulnerabilities in a network service, my first step is to use dumb fuzzing. It requires minimal effort, allowing me to quickly identify any low-hanging fruits. The jt400.jar library provided by IBM includes a Java API to create a simple DDM client - the relevant part is only 2 lines in my code:

DDMConnection ddmConn = DDMConnection.getConnection(serverAddress, userName, password);   
List<Message> messages = ddmConn.executeReturnMessageList(cmd); /* or use execute method */

These two lines authenticate to the DDM service and execute a command through it.

When I discovered the vulnerability, I didn’t have a debugger to track the behavior of the target service, therefore, I used a create (source physical) file command CRTSRCPF FILE(QGPL/DDMSPLOIT) to monitor possible authentication bypass issues.

Recording the network traffic of the DDM client was the last step - this can be done with any usual network sniffer on the client system. The jt400.jar library uses the as-signon (8476/TCP) service for authentication. If successful, DDM starts using port 446/TCP. I saved only the DDM traffic in a PCAP file.

I am not a big fan of reinventing the wheel, so I used a slightly modified version of Blaze Information Security’s PCAP fuzzer (thanks Julio!) to generate fuzzed traffic. After running the fuzzer for a couple of minutes, the QGPL/DDMSPLOIT file appeared on our test server.

Checking the authority of the DDMSPLOIT source file object reveals that the owner is not my test user, but QUSER:

QUSER is a workstation user without special authorities. IBM i Host Servers, such as the File Server, Database Server, DDM Server, and Sign-on Server, are started under the QUSER user profile. I will get back to this topic a bit later, when we discuss the CVSS score assigned by IBM.

At this moment, I realized that unauthenticated CL command execution is possible. Now, the question arises: why and how is this possible?

Upon investigating the modified traffic, I noticed that if the username or password fields are corrupted, the DDM server still handles the command request. The DDM server responds with a SECCHKRM packet with ERROR 0x17 (Invalid GSS-API server credential) but the command sent by the client still gets executed.

At this point, I decided to send the original PCAP without modifications and observe the outcome. The authentication server does not accept the original authentication information - indicating the presence of replay protection on this interface - but our custom client doesn’t care about this. When we send the replayed request to DDM, the same error condition is observed, but again, the CL command is executed. We suspect that the root cause of the vulnerability is a “GOTO fail”-style bug in the error handling code of the service, allowing replay attacks. We are working on improving the reverse engineering tooling for the POWER architecture (especially regarding its AS extensions) to gain a better understanding of the patch and support our future research.

The vulnerability allows arbitrary CL or PASE command execution as QUSER without authentication.

The following video shows a bind shell popping up on our test server in the PASE environment. At the end of this video, there is a little teaser for our upcoming research too!

Creating the full exploit based on the provided information is left as an exercise for the reader.

When handling new vulnerability reports it is important to perform proper risk assessment considering both the technical parameters of the vulnerabilities and the business roles of components affected by them. In this section we provide additional technical details that should help assessing the exploitability and impact of CVE-2023-30990.

The CVSS vector published along with the vendor bulletin is this, resulting in a base score of 5.6: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L)

This score is unusually low for an unauthenticated RCE, so what’s going on here? As we see, most of the vector is reasonable, however we don’t know on what basis was Access Complexity scored to High. The exploit is 100% reliable and we successfully demonstrated it against multiple systems without any further work. While there may be some configurations that prevent exploitation, CVSS 3.1 explicitly says that this can’t increase the Complexity component, and our work was also based on default configuration.

It should also be noted that while the QUSER user profile doesn’t have special authorities (so Low Confidentiality and Integrity scores are reasonable), several Jobs related to other services also run under this profile. The ENDJOB command allows ending jobs running under the same profile as the invoker, so availability can be impacted - the following output shows the services that can be ended on our test system by default:

TCP/8470	as-central - Central server
TCP/8471	as-database - Database server 
TCP/8472	as-dtaq - Data Queue server
TCP/8473	as-file - File server
TCP/8474	as-netprt - Printer Server
TCP/8475	as-rmtcmd - Remote command server
TCP/8476	as-signon - Sign-on server
TCP/8477	as-netdrive - Network Drive Server
TCP/8478	as-transfer - Transfer Function Server
TCP/8479	as-vrtprint - Virtual Print Server

The following video shows the shutdown of the DDM service:

Based on this information we can generally recommend IBM i system owners to consider the installation of official patches as high priority. The risk can be mitigated by attack surface reduction, for example via strict firewall restrictions. It should be noted that DDM service exit programs don’t seem to be effective against this particular exploit.

The discovery and resolution of this vulnerability is an important milestone in our efforts to direct more public security research to the IBM i platform. As you could see, further research results are in the pipeline for publication - subscribe to our blog feed and social media accounts to get notified as soon as they’re published!

Our vetted customers can receive preliminary notification and mitigation guidance about the vulnerabilities we discover as part of their iCompliant product licenses. If you are interested in hardening your IBM i systems and accessing exclusive vulnerability information, don’t hesitate to contact us!

• 2023.04.25 - Sent technical details to IBM PSIRT
• 2023.04.25 - IBM PSIRT assigned ADV0084539
• 2023.06.30 - IBM published Security Bulletin with CVE-2023-30990 assigned
• 2023.07.03 - Published technical details