One of the most disturbing types of cyber-attacks are those involving privilege escalation. The most common form is when a threat actor gains elevated access or administrative rights to a system by exploiting security vulnerabilities. Even the most secure operating system can be poorly configured opening up vulnerabilities which allow bad actors to elevate their access as a systems administrator or similar privileged account, this is considered a vertical attack. A horizontal attack is one where an attacker gains elevated access but under a different userid. Typically, this is a case where credentials are stolen. Privilege escalation can open new attack vectors on a system which can then lead to catastrophic breaches or intrusions. For this reason, vigilance and robust security measures must be taken.
One of the ways z/OS customers can guard against vertical privilege escalation is by implementing ACEE Modification Detection. The Accessor Environment Element or ACEE is a control block which contains the attributes of a user’s security. The ACEE is created when an address space is created, for example a TSO user or started task. The ACEE is constantly referenced by RACF whenever command and resource checking takes place to determine is a user is authorized to access a resource or perform an action protected by the security product. If a user or application is running in an authorized state, it can then make modifications directly to their ACEE control block, potentially elevating access. So how can z/OS customers detect if a bad actor maliciously updated their ACEE, potentially enabling SPECIAL or OPERATIONS?
APAR OA56851 was introduced in z/OS 2.3 allowing a new feature called ACEE modification detection (see https://www.ibm.com/support/pages/apar/OA56851). This new function is designed to detect changes made to an ACEE control block. After OA56851 is applied (or when upgrading to z/OS 2.4 and above) a new ACEECHK class can be activated in RACF to enable this feature. This class requires no profiles, it is simply a switch. Once the class is activated (on a test system first!), you may start to see IRR421I messages. This message is quite wordy since it displays a call chain which describes the flow of control for all programs leading up to the currently running program which triggered the IRR421I. For example:
IRR421I ACEE modification detected 037
for user DFHSMA in address space ID 0x0000007B running under user
DFHSMA and job name DFHSM while program ARCCTL is running. The RACF
function detecting the modification is IRRRCK00. Rsn=0x28000000.
(ACEESPEC is ON) (ACEEOPER is ON). Occurrences 1.
Resource=CPISYSR.DFHSMA.DFHSM.STC10627.D0000101.?(JESSPOOL). Call
chain: ARCCTL
IRR421I ACEE modification detected 040
for user DFHSMA in address space ID 0x0000007B running under user
DFHSMA and job name DFHSM while program ARCILOG is running. The
RACF function detecting the modification is IRRRCK00.
Rsn=0x28000000. (ACEESPEC is ON) (ACEEOPER is ON). Occurrences 1.
Resource=HSM.HSMLOGX1(DLFCLASS). Call chain: ARCILOG <- ARCCTL
One thing to be aware of is that an application running in an authorized state can make modifications directly to the ACEE in storage after its creation. One example is DFHSMShsm as shown in the message above. DFSMShsm's legacy code has been setting the ACEESPEC and ACEEOPER attributes for decades, when building its internal ACEE. There are times HSM will turn off Trusted or Privileged to ensure it gets valid return codes back from the SAF call, but those will require DFSMShsm to have the Special/Operations attribute to be on to complete its processing.
The suggestion to add the SPECIAL and OPERATIONS attributes to the user ID of the started task profile for HSM, is a way to eliminate the IRR421I notification or to have DFSHShsm excluded in the RACF ACEECHK function (if you do not want to add these attributes to DFSMShsm). RACF exception checking is performed for every program in the displayed call chain, starting at the currently running program and ending with the job step program, until a matching exception is located. Therefore, it is important to understand the application environment before adding an exception. A bypass profile name is of the format: IRR.EXCLUDE.program-name[.user1[.user2]]. For example:
- "IRR.EXCLUDE." is a constant prefix
- program-name is the name of a program in the chain of execution
- user1 is the user ID from the address space ACEE
- If user1 is a server running work on behalf of a different user, then user2 is the user ID from the end user ACEE that is being checked (the task-level, 2nd or 3rd party ACEE). This case applies only to RACROUTE REQUEST=AUTH processing (ACEEs cannot be passed to RACF commands. The command issuer's ACEE will always be located environmentally; from either the TCB or ASXB).
RACF will look for a matching profile in the following order. If the ACEE being checked is the address space ACEE:
- IRR.EXCLUDE.program-name.user1
- IRR.EXCLUDE.program-name
If the ACEE being checked is not the address space ACEE:
1. IRR.EXCLUDE.program-name.user1.user2
2. IRR.EXCLUDE.program-name.user1
3. IRR.EXCLUDE.program-name.user2
4. IRR.EXCLUDE.program-name
Once you are confident that you have addressed all exceptions and where necessary added the IRR.EXCLUDE.* profiles it is possible to request that RACF abend a program when a modified ACEE is detected. This can be done by defining the IRR.ABEND.ON.FAILURE profile in the ACEECHK class. When this profile is in effect, a 4C6 abend with reason code X’ACE’ will be issued. This abend will only occur is an exception was not found for the program call chain. Thoughtful testing must be done before adding this program in a production environment.
If you are currently ingesting SMF data for a SIEM solution such as QRADAR, you may prefer to have ACEE modification events generate an SMF record. If this is of interest, I would encourage you to vote on an idea to have these events written to SMF - see ACEE Modification | IBM Z Hardware and Operating Systems Ideas Portal