Guru: IBM i *USRPRF Security
May 23, 2022 Bruce Bading
IBM i has long enjoyed a reputation of being one of the most securable application servers in the industry. IBM i object encapsulation or object-oriented architecture achieves a level of technology integrity not found in file-based systems such as Unix, Linux, and Windows – as long as QSECUTY is set to 40 or 50.
This advanced technology however 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).
Let me remind what one of the lead signatories on the Agile Manifesto, Robert Martin, states in his book, Clean Agile: Back to Basics: “Agile is a small idea about the small problem of small programming teams doing small things. Agile is not a big idea about the big problem of big programming teams doing big things.”
Two of the biggest vulnerabilities on the IBM i are privilege escalation and lack of proper access controls. First, 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.
Simply 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 and examples 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:
Object . . . . . . . : XXXXXX Owner . . . . . . . : QSECOFR
Library . . . . . : QSYS Primary group . . . : *NONE
Object type . . . . : *USRPRF ASP device . . . . . : *SYSBAS
Object
User Group Authority
*PUBLIC *EXCLUDE
QSECOFR *ALL
XXXXXX USER DEF
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.
As you develop your applications, 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.
rmtcmd /SYSTEM=systema /CMD=”SBMJOB CMD(CRTUSRPRF USRPRF(QSECOPR) PASSWORD(passw0rd) USRCLS(*SECOFR)) USER(xxxxxx)”.
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 also not have an associated exit point. Reliance on Limited Capabilities (LMTCPB) and exit programs alone is not nearly enough.
Further, SIEM administrators can only detect what they know and every time we detect profile security exposures, we rarely find anyone who knows why they have been authorized and as we know in cybersecurity, (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:
/* Call QSYGETPH to get a profile handle for a user. */
/* NOTE: Change XXX to the user who you want to swap to. */
CALL QSYS/QSYGETPH ('XXX' '*NOPWDCHK' &HNDL)
/* Call QWTSETP to swap to the profile. */
CALL QSYS/QWTSETP &HNDL
Your specific requirements may require changes and additional code and variables, among other things, but 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 (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 and find a Subject Matter Expert with the tools (BFB Security) and knowledge to guide you through finding and remediating these and many other vulnerabilities. You can only defend what you know. For those at risk, the time to remediate is now. For those that have been breached, the time to remediate was yesterday.
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.
Editor’s Note: Bruce is one of a number of new Guru experts that we are working with to keep the Guru column going within The Four Hundred. We look forward to the coming in-depth security coverage that Bruce can give as you work to secure your IBM i platforms in these interesting times.
RELATED STORIES
Guru: SIEM Is Only Part Of IBM i Cybersecurity
Guru: Would You Rather See a Fire Marshal or a Fire Fighter?
