Another Tale of IBM i (AS/400) Hacking

Our next journey takes us into the infrastructure of a bank. One element of the infrastructure was an IBM i (AS/400) server, and the only piece of information we got to conduct the penetration test was its IP address. We had been collecting a list of common application and service users during previous pentests, so we could check their existence on this host using 5250 and POP3 protocols. By the way, the server exposed 63 remote services – are all of them really necessary? Our first step may seem ridiculous, but it works most of the time in IBM i Land: “does the username equal the password?”. We had discovered one account with Hydra, let’s call it AKELA. The user’s initial menu was *SIGNOFF, meaning that in theory, the only action the user could perform after login was to log out. Setting initial program or menu on the signon screen was not possible because of limitations we will discuss later.

The previous blog post described the ATTN key technique to get command line, which worked in this case too, because setting the initial menu to *SIGNOFF doesn’t really perform a logout, just displays a screen with no functionality to use, but ATTN still works as usual. A minor change had to be made to the previously described procedure: we had to select the menu number 2 (“Work with jobs”) as getting a command line with F9 was not allowed, because of the restrictions on the user profile we will discuss shortly:

The next screen shows that the upcoming “Work with user jobs” display allows providing additional parameters to selected options. For example, if we wanted to end a job immediately, we could type OPTION(*IMMED) as a parameter after typing 4 next to the target job. Conveniently, the same input allows issuing arbitrary commands too. At this point we had command line access, but immediately realized the user is “limited” and we could not run CL commands with 5250:

The above error is a typical symptom of the Limited capabilities (LMTCPB) setting being enabled in the current user profile. According to the documentation, with Limited capabilities, only programs with the parameter “Allow Limited User” set to *YES can be executed. This configuration is common in IBM i environments: users who work with 5250 are set up with a single predefined application and can use only the menu-based functions of this application. This restriction is the reason initial program or menu couldn’t be specified, and F9 did not provide a command line.

Setting the user profile “to limited” is the recommended way to restrict users from using the command line, so this must be secure, right? WRONG. The limited user profile setting only applies to some protocols, like 5250 and FTP:

This is when the high number of exposed ports came handy. IBM i exposes the Remote Command API over port 8475 to allow programmatic access (not requiring terminal emulation) to system commands from regular PCs over the network. We can use this protocol to run CL commands to overcome the limitations of the 5250. A drawback of this protocol is that the API implementation only informs you of the success/fail result, but you can’t access the command output. We wanted interactive command execution, and taking the VPN connection we used to access the system into account (no connect back allowed by the firewall), we decided to use a bind shell. Every IBM i has Java installed that we can use to create a simple app to attach a shell to port 4444.

This shell provides access to the UNIX subsystem of IBM i called PASE. At this point we have at least two options to inspect the security of the system in more detail: first, the “system” shell command can be used to run CL commands from PASE:

The second option, the SQL interface allows accessing system configuration in bulk, and with complex filtering, ideal for hunting for misconfigurations. The usual “db2” shell command can be used to execute arbitrary SQL queries. The database service (port 8471) that can be used to run arbitrary SQL queries was protected by an exit program, therefore we used this technique. The following SQL query could be used to enumerate the system users with *ALLOBJ special authorities:

We can also check, whether we can *USE other profiles – the following screenshot summarizes the result:

If there is a match between the two SQL results we win. In our case, the current AKELA user was able to switch to an *ALLOBJ profile that we shall call ROB. Due to the customer request, we had to demonstrate that we had unlimited access to the system, without adding new users to the system. We decided to modify the Limited capabilities profile setting of our AKELA profile from *YES to *NO, took a screenshot for the report and switched back. We used our IBM i pentest tool to perform the profile switching described in the previous blog post:

This worked as expected, we reached our goal:

Summary

The restrictions bypassed in this blog post are mostly part of “menu security”. This concept is based on the old assumption that restrictions on the presentation layer (the menu-based UI displayed on a 5250 terminal) is sufficient for access control. This may have been true for some time, but as functionality grew, and network services came into play, the significance of this control diminished. Of course, IBM recognized this too, but the relevant documentation is either vague, or just casually mentions the known gaps of security controls that are commonly used as primary defenses.

We also saw another example of misconfigured user profiles that can be exploited for privilege escalation through profile swapping. It’s worth noting that this system was operated by a different team than the one discussed in our previous post, demonstrating the prevalence of such configurations.

We must work hard to get these problems that are carried over from legacy environments out of the way, so we can see what IBM i really has to offer when it comes to security.