During a recent penetration test of an IBM AIX environment, I uncovered two critical vulnerabilities, including one that had gone unnoticed for almost 30 years. The identified flaws in the AIX Network Installation Manager (NIM) allow for remote command execution with root privileges — potentially compromising entire AIX infrastructures.
In this blog post, I will walk you through the discovery of CVE-2024-56346 and CVE-2024-56347, the impact of these vulnerabilities, and the steps you should take to secure your systems.
Note: If you are only interested in the official disclosure documents, please follow these links: CVE-2024-56346, CVE-2024-56347. For information on common concerns, refer to the Q&A section of this blog. If you own or maintain an AIX environment and have not yet applied the latest patches, we strongly recommend to check the IBM Security Bulletin immediately and install the patches.
Table of contents
How It All Began – Even Before the Test
For a penetration test engagement in December 2024, I was tasked with testing an AIX environment. After setting up different tools from the AIX Toolbox on an AIX logical partition (LPAR) server to prepare the actual test, I wanted to run a test to check if network traffic was captured correctly. I started tcpdump and executed the “nimclient -l master” command to trigger network traffic with the NIM server (“nimesis”). The result was as follows:
The network capture worked, and all my penetration tester alarms started ringing. The NIM communication was in plaintext. And it seemed as if a complete command line was sent to the NIM server! Unfortunately, I had to wait a couple of days to verify these issues, as the scheduled date for active testing had not yet arrived.
CVE-2024-56346: Ancient Behavior From 30 Years Ago
When the first day of testing arrived, it only took a few minutes and some Python to verify that this NIM master protocol indeed allowed executing arbitrary commands on the NIM server with root privileges!
Some further analysis revealed that there are only very few parameters in these requests that have to be correct for the attack to work. For example, the “root” value in the request can be an arbitrary value. The only validation performed is that the hostname in the request matches a known NIM managed server – however, the actual network connection does not need to originate from that hostname.
Based on the nature and structure of this protocol, it seemed to be a product of the 90s or early 2000s. Internet archeology pointed to AIX 4.1 and the year 1994 for the introduction of the NIM server, which matched my assumption and made this the oldest (still active) vulnerability I have ever discovered: about 30 years old.
What makes this problem worse is that the NIM server is a management system and by default and design has the ability to execute arbitrary commands on all managed (AIX) servers. This means that this vulnerability can be exploited by an attacker to compromise the entire AIX environment.
What Else Is There? – NIMSH Communication
In the next step, I checked the connections from the NIM server to the “nimsh” service on the connected managed servers. The configuration and documentation indicated that “NIMSH over SSL” was in place, which means it was expected to be more secure. The first inspection revealed a similar general protocol flow. Although there was some cryptography going on, the actual payload seemed to be in plaintext.
This behavior is described in more detail here: NIMSH over SSL
However, it is important to read the page carefully, as it states that “an encrypted handshake for any NIM push operations” is carried out. Note that it does not mention encryption or a TLS connection. It also explicitly says that “data packets are not encrypted”.
Further investigation revealed the following:
- A standard TLS handshake is indeed executed.
- This handshake is not bound in any way to the parameters or actions.
- Everything except this TLS handshake is sent in plaintext, including the command to be executed on the server.
While this would already be a vulnerability in itself, a deeper look at the TLS handshake uncovered more issues. The keys used in this handshake are stored in the “/ssl_nimsh/certs” folder, a globally readable location. These files contain multiple PEM-encoded parts, and the file name includes the NIM server’s hostname. What is critical is that each file includes the root certificate (used by both the NIM server and local nimsh), the nimsh server certificate, and its unencrypted private key – all in a world-readable file. The same file is distributed to all connected managed servers and can be accessed remotely from the NIM server without authentication, via TFTP or the nimesis registration port.
CVE-2024-56347: How to Use TLS Wrong
At this point, I had identified the following issues:
- TLS authentication uses a private key that is by no means private,
- all systems use the same key,
- and other (plaintext) protocol information is not bound to the TLS handshake.
Although this is serious, an attacker would only be able to impersonate a NIM managed server and not the NIM server. At least that’s what one would think. Unfortunately, this is not the case, as there is more.
As mentioned before, the root certificate is shared between the NIM server and the nimsh daemon – and looking at the certificate for the nimsh daemon, there is not restriction regarding the possible uses of the certificate, so it can be used for client authentication.
But clearly, the certificate common name (CN) must match the hostname or IP of the NIM server? Again: this is not the case. No direction on this handshake checks for matching peers.
However, there is one implicit check to overcome to authenticate with a nimsh daemon using a stolen key: for each connection, the nimsh daemon executes a reverse DNS lookup on the connecting IP using the resulting hostname as the base for the filename to find the correct certificate bundle in “/ssl_nimsh/certs”. This means that an attacker either must be able to intercept the DNS traffic of the target or “massage” the DNS system to return the hostname of the NIM server for the attacker IP. While this is not trivial, it is possible depending on the actual attacker and target environment setup.
Note: I would like to clarify that this certificate setup is not some bad configuration in our customer’s specific setup. This is the default setup and is recommended by AIX documentation. There is no easy, supported way to improve this through manual intervention.
Take Aways From the AIX NIM Penetration Test
The vulnerabilities uncovered in AIX’s NIM nimesis and nimsh components show how long-standing, overlooked design decisions can pose serious security risks decades later. From plaintext communication and unauthenticated command execution to an easily extractable private key used across systems, these issues combine into a high-impact threat capable of compromising entire AIX environments. While IBM has issued patches, this is a strong reminder that even “mature” infrastructures require regular and thorough security testing.
Frequently Asked Questions About CVE-2024-56346 & CVE-2024-56347
To help clarify the key points and next steps, we have compiled answers to the most frequently asked questions about the AIX NIM vulnerabilities.
What does this mean for AIX operators?
If you are running an AIX environment and have an active NIM server, your entire AIX environment could be compromised with very little effort and the attacker could gain root privileges on all AIX systems (NIM, LPAR, etc.). If you do not have an active NIM server and also do not use one during provisioning (i.e. the “/ssl_nimsh/certs” directory is empty or not existing on all your systems), you should be safe from these vulnerabilities. However, you should carefully verify whether this is actually the case and apply the patches as soon as possible anyway to be on the safe side.
What should I do now?
If you are running an AIX environment, apply the patches developed by IBM as soon as possible.
In general, you should never assume that a system is secure until it has been properly tested – and re-tested over time. Security is only as strong as its weakest link, and even small changes can quietly introduce new risks. In addition, these can add up over time, weakening previously secure environments. And that’s without accounting for undiscovered vulnerabilities in software you already trust – as this case clearly shows.
Where can I find more information about CVE-2024-56346 & CVE-2024-56347?
You can find more detailed descriptions of the discovered vulnerabilities, including proof of concepts to verify if you are vulnerable, in our disclosure reports: nimesis (CVE-2024-56346) & nimsh (CVE-2024-56347)
If you have further questions, please feel free to get in touch with us.
Have these AIX vulnerabilities been fixed?
IBM took our security report very seriously and developed patches within 102 days (which is fast in AIX time!).
Unfortunately, due to time and access constraints we have not been able to inspect the patches in depth or in a live environment so far.
How were these findings reported?
As these findings were discovered during a customer engagement, we first coordinated with the customer and received permission to start our responsible disclosure process. As part of this process, the findings were reported to the IBM PSIRT. The full details of the vulnerabilities were published in coordination with the IBM PSIRT about 30 days after the release of the patches to allow affected customers to fix their systems before the details become publicly available.
