Is Your IBM i (iSeries/AS400) Security Vulnerable To Privilege Escalation And Lack Of Proper Access Controls?

IBM system security it a hot topic these days, as is security in general. Bruce Bading has give me permission to repost this blog to highlight these two key exposures: 1) Privilege Escaltaion and 2) Lack of Proper Access.

Disclaimer: IBM i is an operating system. iSeries and AS400 are servers. I use these terms interchangeably to make it easier for folks to find this kind of information on the web.  

IBM i is one of the most securable application servers in the industry -- as long as QSECUTY is set to 40 or 50. Their object-oriented architecture‘s technology integrity isn’t found in file-based systems such as Unix, Linux, and Windows

However, it does not exclude the IBM i from security risks if your development teams are not practicing (DevSecOps | CSRC (nist.gov)) and (Zero Trust Architecture | NIST).

Two of the biggest vulnerabilities on the IBM i are privilege escalation and lack of proper access controls.

Let’s define authentication and authorization.

Authentication is the process of identifying and validating users through their credentials or tokens (generally passwords). Authorization happens after authentication through access controls to resources such as databases, user profiles, and other security sensitive objects. In terms of security threats, exclusionary access to sensitive objects is cybersecurity 101 and non-exclusionary access is a risk to the business.

Google “iSeries Profile Hijacking” (Stealing User Profiles!) or “iSeries Profile Hacking” (Hacking an IBM i (linkedin.com) and you will come up with multiple hits on why *USRPRF Security is vitally important.

On the IBM i, user profiles are the keys to the kingdom. Without them, no one could authenticate. The CRTUSRPRF command has many security-related parameters like PASSWORD, which should be a quality passphrase 14 characters or more, USRCLS should be *USER, SPCAUT should be *NONE, and AUT should always be *EXCLUDE.

Below are Secure *USRPRF Authority Standards:

 Additionally, QSECOFR should be the owner of all user profiles and can be controlled through an exit program registered to the QIBM_QSY_CRT_PROFILE Exit Point (Create User Profile Exit Program). The *USRPRF should have authority to itself, the *PUBLIC should be *EXCLUDE and no other authorities should exist.

Many web services and other processes may require jobs that run under another profile, which is fine as long as you use PoLP (Principle of Least Privilege), and don’t *PUBLIC or Privately authorize your *USRPRF objects.

To perform a secure profile swap and maintain profile security and ownership, program swaps (DevSecOps) should encapsulate access to *USRPRF objects programmatically to limit the swap within the program and prevent ad-hoc access to the *USRPRF object outside of the designed program architecture.

Granting access to *USRPRF objects outside of a secure swap process allows ad-hoc access to *USRPRF objects outside of designed processes that may lead to malicious activity. Below is one example of how an authority to a *USRPRF may be used maliciously from a remote command prompt.

Note in the above example, no authentication is required, only authorization.

Remote commands run from a Windows CMD shell or other sources such as DB2 connect, can create profile QSECOPR (actual incident – note spelling to conceal) with all eight Special Authorities, and will be owned by XXXXXX. Vulnerable systems often have multiple private and *PUBLIC authorized profiles with Special Authorities. Note that a single authorized *ALLOBJ profile can obtain access to any other profile to obtain *SECOFR authority.

Remote commands may also bypass limited capability and can run from a Windows CMD prompt, Linux or UNIX remote shell, ODBC, SSH, and many other remote locations or from another IBM i. Some remote protocols, like SSH may not have an associated exit point. Reliance on Limited Capabilities (LMTCPB) and exit programs alone is not nearly enough.

As we know in cybersecurity, SIEM administrators can only defend/detect what they know (see You Can’t Defend What You Can’t See: Why Visibility is Critical for Improving Cyber Defense from SecurityWeek).

To prevent the ad-hoc security exposure of private or *PUBLIC authorized profiles, use a secure programmatic swap, move the swap APIs into a separate service program that adopts *ALLOBJ and *SECADM special authorities and call this service program within your main program to perform the swap without the need for AUT to the profile:

Be careful not to put your main application code into the service program that performs the swap.

Some important points to consider:

·        What are your current profile authorities and ownership?

·        Always use the Principle of Least Privilege (PoLP) -- Regulatory Requirements

·        Ensure the swaps are limited to only authorized functions and data sets. One example: PCI DSS 8.7 – Only database administrators have the ability to directly access or query databases.

Know and follow your compliance requirements. Bring in a Subject Matter Expert with the tools (BFB Security) and knowledge to guide you through finding and remediating vulnerabilities.

Bruce Bading is a senior security consultant with more than forty years of information security experience and 25 years of corporate c-suite experience. He is an expert on IBM i security and has helped some of IBM’s largest clients meet their security and compliance requirements in today’s complex technology and business environments. Bruce has exceptional communications skills, has worked with diverse audiences at all business levels to provide training and education and has led dozens of large enterprise risk management projects for the world’s largest organizations. He is a member of the Information Systems Audit and Control Association, a CIS benchmark author, and professional threat hunter.