In our previous article we dissected penetration testing techniques for IBM z/OS mainframes protected by the Resource Access Control Facility (RACF) security package. In this second part of our research, we delve deeper into RACF by examining its decision-making logic, database structure, and the interactions between the various entities in this subsystem. To facilitate offline analysis of the RACF database, we have developed our own utility, racfudit, which we will use to perform possible checks and evaluate RACF configuration security. As part of this research, we also outline the relationships between RACF entities (users, resources, and data sets) to identify potential privilege escalation paths for z/OS users.

This material is provided solely for educational purposes and is intended to assist professionals conducting authorized penetration tests.

RACF internal architecture

Overall role

z/OS access control diagram

To thoroughly analyze RACF, let’s recall its role and the functions of its components within the overall z/OS architecture. As illustrated in the diagram above, RACF can generally be divided into a service component and a database. Other components exist too, such as utilities for RACF administration and management, or the RACF Auditing and Reporting solution responsible for event logging and reporting. However, for a general understanding of the process, we believe these components are not strictly necessary. The RACF database stores information about z/OS users and the resources for which access control is configured. Based on this data, the RACF service component performs all necessary security checks when requested by other z/OS components and subsystems. RACF typically interacts with other subsystems through the System Authorization Facility (SAF) interface. Various z/OS components use SAF to authorize a user’s access to resources or to execute a user-requested operation. It is worth noting that while this paper focuses on the operating principle of RACF as the standard security package, other security packages like ACF2 or Top Secret can also be used in z/OS.

Let’s consider an example of user authorization within the Time Sharing Option (TSO) subsystem, the z/OS equivalent of a command line interface. We use an x3270 terminal emulator to connect to the mainframe. After successful user authentication in z/OS, the TSO subsystem uses SAF to query the RACF security package, checking that the user has permission to access the TSO resource manager. The RACF service queries the database for user information, which is stored in a user profile. If the database contains a record of the required access permissions, the user is authorized, and information from the user profile is placed into the address space of the new TSO session within the ACEE (Accessor Environment Element) control block. For subsequent attempts to access other z/OS resources within that TSO session, RACF uses the information in ACEE to make the decision on granting user access. SAF reads data from ACEE and transmits it to the RACF service. RACF makes the decision to grant or deny access, based on information in the relevant profile of the requested resource stored in the database. This decision is then sent back to SAF, which processes the user request accordingly. The process of querying RACF repeats for any further attempts by the user to access other resources or execute commands within the TSO session.

Thus, RACF handles identification, authentication, and authorization of users, as well as granting privileges within z/OS.

RACF database components

As discussed above, access decisions for resources within z/OS are made based on information stored in the RACF database. This data is kept in the form of records, or as RACF terminology puts it, profiles. These contain details about specific z/OS objects. While the RACF database can hold various profile types, four main types are especially important for security analysis:

1. User profile holds user-specific information such as logins, password hashes, special attributes, and the groups the user belongs to.
2. Group profile contains information about a group, including its members, owner, special attributes, list of subgroups, and the access permissions of group members for that group.
3. Data set profile stores details about a data set, including access permissions, attributes, and auditing policy.
4. General resource profile provides information about a resource or resource class, such as resource holders, their permissions regarding the resource, audit policy, and the resource owner.

The RACF database contains numerous instances of these profiles. Together, they form a complex structure of relationships between objects and subjects within z/OS, which serves as the basis for access decisions.

Logical structure of RACF database profiles

Each profile is composed of one or more segments. Different profile types utilize different segment types.

For example, a user profile instance may contain the following segments:

• BASE: core user information in RACF (mandatory segment);
• TSO: user TSO-session parameters;
• OMVS: user session parameters within the z/OS UNIX subsystem;
• KERB: data related to the z/OS Network Authentication Service, essential for Kerberos protocol operations;
• and others.

User profile segments

Different segment types are distinguished by the set of fields they store. For instance, the BASE segment of a user profile contains the following fields:

• PASSWORD: the user’s password hash;
• PHRASE: the user’s password phrase hash;
• LOGIN: the user’s login;
• OWNER: the owner of the user profile;
• AUTHDATE: the date of the user profile creation in the RACF database;
• and others.

The PASSWORD and PHRASE fields are particularly interesting for security analysis, and we will dive deeper into these later.

RACF database structure

It is worth noting that the RACF database is stored as a specialized data set with a specific format. Grasping this format is very helpful when analyzing the DB and mapping the relationships between z/OS objects and subjects.

As discussed in our previous article, a data set is the mainframe equivalent of a file, composed of a series of blocks.

RACF DB structure

The image above illustrates the RACF database structure, detailing the data blocks and their offsets. From the RACF DB analysis perspective, and when subsequently determining the relationships between z/OS objects and subjects, the most critical blocks include:

• The header block, or inventory control block (ICB), which contains various metadata and pointers to all other data blocks within the RACF database. By reading the ICB, you gain access to the rest of the data blocks.
• Index blocks, which form a singly linked list that contains pointers to all profiles and their segments in the RACF database – that is, to the information about all users, groups, data sets, and resources.
• Templates: a crucial data block containing templates for all profile types (user, group, data set, and general resource profiles). The templates list fields and specify their format for every possible segment type within the corresponding profile type.

Upon dissecting the RACF database structure, we identified the need for a utility capable of extracting all relevant profile information from the DB, regardless of its version. This utility would also need to save the extracted data in a convenient format for offline analysis. Performing this type of analysis provides a comprehensive picture of the relationships between all objects and subjects for a specific z/OS installation, helping uncover potential security vulnerabilities that could lead to privilege escalation or lateral movement.

Utilities for RACF DB analysis

At the previous stage, we defined the following functional requirements for an RACF DB analysis utility:

1. The ability to analyze RACF profiles offline without needing to run commands on the mainframe
2. The ability to extract exhaustive information about RACF profiles stored in the DB
3. Compatibility with various RACF DB versions
4. Intuitive navigation of the extracted data and the option to present it in various formats: plaintext, JSON, SQL, etc.

Overview of existing RACF DB analysis solutions

We started by analyzing off-the-shelf tools and evaluating their potential for our specific needs:

• Racf2john extracts user password hashes (from the PASSWORD field) encrypted with the DES and KDFAES algorithms from the RACF database. While this was a decent starting point, we needed more than just the PASSWORD field; specifically, we also needed to retrieve content from other profile fields like PHRASE.
• Racf2sql takes an RACF DB dump as input and converts it into an SQLite database, which can then be queried with SQL. This is convenient, but the conversion process risks losing data critical for z/OS security assessment and identifying misconfigurations. Furthermore, the tool requires a database dump generated by the z/OS IRRDBU00 utility (part of the RACF security package) rather than the raw database itself.
• IRRXUTIL allows querying the RACF DB to extract information. It is also part of the RACF security package. It can be conveniently used with a set of scripts written in REXX (an interpreted language used in z/OS). However, these scripts demand elevated privileges (access to one or more IRR.RADMIN.** resources in the FACILITY resource class) and must be executed directly on the mainframe, which is unsuitable for the task at hand.
• Racf_debug_cleanup.c directly analyzes a RACF DB from a data set copy. A significant drawback is that it only parses BASE segments and outputs results in plaintext.

As you can see, existing tools don’t satisfy our needs. Some utilities require direct execution on the mainframe. Others operate on a data set copy and extract incomplete information from the DB. Moreover, they rely on hardcoded offsets and signatures within profile segments, which can vary across RACF versions. Therefore, we decided to develop our own utility for RACF database analysis.

Introducing racfudit

We have written our own platform-independent utility racfudit in Golang and tested it across various z/OS versions (1.13, 2.02, and 3.1). Below, we delve into the operating principles, capabilities and advantages of our new tool.

Extracting data from the RACF DB

To analyze RACF DB information offline, we first needed a way to extract structured data. We developed a two-stage approach for this:

• The first stage involves analyzing the templates stored within the RACF DB. Each template describes a specific profile type, its constituent segments, and the fields within those segments, including their type and size. This allows us to obtain an up-to-date list of profile types, their segments, and associated fields, regardless of the RACF version.
• In the second stage, we traverse all index blocks to extract every profile with its content from the RACF DB. These collected profiles are then processed and parsed using the templates obtained in the first stage.

The first stage is crucial because RACF DB profiles are stored as unstructured byte arrays. The templates are what define how each specific profile (byte array) is processed based on its type.

Thus, we defined the following algorithm to extract structured data.

Extracting data from the RACF DB using templates

1. We offload the RACF DB from the mainframe and read its header block (ICB) to determine the location of the templates.
2. Based on the template for each profile type, we define an algorithm for structuring specific profile instances according to their type.
3. We use the content of the header block to locate the index blocks, which store pointers to all profile instances.
4. We read all profile instances and their segments sequentially from the list of index blocks.
5. For each profile instance and its segments we read, we apply the processing algorithm based on the corresponding template.
6. All processed profile instances are saved in an intermediate state, allowing for future storage in various formats, such as plaintext or SQLite.

The advantage of this approach is its version independence. Even if templates and index blocks change their structure across RACF versions, our utility will not lose data because it dynamically determines the structure of each profile type based on the relevant template.

Analyzing extracted RACF DB information

Our racfudit utility can present collected RACF DB information as an SQLite database or a plaintext file.

RACF DB information as an SQLite DB (top) and text data (bottom)

Using SQLite, you can execute SQL queries to identify misconfigurations in RACF that could be exploited for privilege escalation, lateral movement, bypassing access controls, or other pentesting tactics. It is worth noting that the set of SQL queries used for processing information in SQLite can be adapted to validate current RACF settings against security standards and best practices. Let’s look at some specific examples of how to use the racfudit utility to uncover security issues.

Collecting password hashes

One of the primary goals in penetration testing is to get a list of administrators and a way to authorize using their credentials. This can be useful for maintaining persistence on the mainframe, moving laterally to other mainframes, or even pivoting to servers running different operating systems. Administrators are typically found in the SYS1 group and its subgroups. The example below shows a query to retrieve hashes of passwords (PASSWORD) and password phrases (PHRASE) for privileged users in the SYS1 group.
select ProfileName,PHRASE,PASSWORD,CONGRPNM from USER_BASE where CONGRPNM LIKE "%SYS1%";
Of course, to log in to the system, you need to crack these hashes to recover the actual passwords. We cover that in more detail below.

Searching for inadequate UACC control in data sets

The universal access authority (UACC) defines the default access permissions to the data set. This parameter specifies the level of access for all users who do not have specific access permissions configured. Insufficient control over UACC values can pose a significant risk if elevated access permissions (UPDATE or higher) are set for data sets containing sensitive data or for APF libraries, which could allow privilege escalation. The query below helps identify data sets with default ALTER access permissions, which allow users to read, delete and modify the data set.
select ProfileName, UNIVACS from DATASET_BASE where UNIVACS LIKE "1%";
The UACC field is not present only in data set profiles; it is also found in other profile types. Weak control in the configuration of this field can give a penetration tester access to resources.

RACF profile relationships

As mentioned earlier, various RACF entities have relationships. Some are explicitly defined; for example, a username might be listed in a group profile within its member field (USERID field). However, there are also implicit relationships. For instance, if a user group has UPDATE access to a specific data set, every member of that group implicitly has write access to that data set. This is a simple example of implicit relationships. Next, we delve into more complex and specific relationships within the RACF database that a penetration tester can exploit.

RACF profile fields

A deep dive into RACF internal architecture reveals that misconfigurations of access permissions and other attributes for various RACF entities can be difficult to detect and remediate in some scenarios. These seemingly minor errors can be critical, potentially leading to mainframe compromise. The explicit and implicit relationships within the RACF database collectively define the mainframe’s current security posture. As mentioned, each profile type in the RACF database has a unique set of fields and attributes that describe how profiles relate to one another. Based on these fields and attributes, we have compiled lists of key fields that help build and analyze relationship chains.
User profile fields

• SPECIAL: indicates that the user has privileges to execute any RACF command and grants them full control over all profiles in the RACF database.
• OPERATIONS: indicates whether the user has authorized access to all RACF-protected resources of the DATASET, DASDVOL, GDASDVOL, PSFMPL, TAPEVOL, VMBATCH, VMCMD, VMMDISK, VMNODE, and VMRDR classes. While actions for users with this field specified are subject to certain restrictions, in a penetration testing context the OPERATIONS field often indicates full data set access.
• AUDITOR: indicates whether the user has permission to access audit information.
• AUTHOR: the creator of the user. It has certain privileges over the user, such as the ability to change their password.
• REVOKE: indicates whether the user can log in to the system.
• Password TYPE: specifies the hash type (DES or KDFAES) for passwords and password phrases. This field is not natively present in the user profile, but it can be created based on how different passwords and password phrases are stored.
• Group-SPECIAL: indicates whether the user has full control over all profiles within the scope defined by the group or groups field. This is a particularly interesting field that we explore in more detail below.
• Group-OPERATIONS: indicates whether the user has authorized access to all RACF-protected resources of the DATASET, DASDVOL, GDASDVOL, PSFMPL, TAPEVOL, VMBATCH, VMCMD, VMMDISK, VMNODE and VMRDR classes within the scope defined by the group or groups field.
• Group-AUDITOR: indicates whether the user has permission to access audit information within the scope defined by the group or groups field.
• CLAUTH (class authority): allows the user to create profiles within the specified class or classes. This field enables delegation of management privileges for individual classes.
• GROUPIDS: contains a list of groups the user belongs to.
• UACC (universal access authority): defines the UACC value for new profiles created by the user.

Group profile fields

• UACC (universal access authority): defines the UACC value for new profiles that the user creates when connected to the group.
• OWNER: the creator of the group. The owner has specific privileges in relation to the current group and its subgroups.
• USERIDS: the list of users within the group. The order is essential.
• USERACS: the list of group members with their respective permissions for access to the group. The order is essential.
• SUPGROUP: the name of the superior group.

General resource and data set profile fields

• UACC (universal access authority): defines the default access permissions to the resource or data set.
• OWNER: the creator of the resource or data set, who holds certain privileges over it.
• WARNING: indicates whether the resource or data set is in WARNING mode.
• USERIDS: the list of user IDs associated with the resource or data set. The order is essential.
• USERACS: the list of users with access permissions to the resource or data set. The order is essential.

RACF profile relationship chains

The fields listed above demonstrate the presence of relationships between RACF profiles. We have decided to name these relationships similarly to those used in BloodHound, a popular tool for analyzing Active Directory misconfigurations. Below are some examples of these relationships – the list is not exhaustive.

• Owner: the subject owns the object.
• MemberOf: the subject is part of the object.
• AllowJoin: the subject has permission to add itself to the object.
• AllowConnect: the subject has permission to add another object to the specified object.
• AllowCreate: the subject has permission to create an instance of the object.
• AllowAlter: the subject has the ALTER privilege for the object.
• AllowUpdate: the subject has the UPDATE privilege for the object.
• AllowRead: the subject has the READ privilege for the object.
• CLAuthTo: the subject has permission to create instances of the object as defined in the CLAUTH field.
• GroupSpecial: the subject has full control over all profiles within the object’s scope of influence as defined in the group-SPECIAL field.
• GroupOperations: the subject has permissions to perform certain operations with the object as defined in the group-OPERATIONS field.
• ImpersonateTo: the subject grants the object the privilege to perform certain operations on the subject’s behalf.
• ResetPassword: the subject grants another object the privilege to reset the password or password phrase of the specified object.
• UnixAdmin: the subject grants superuser privileges to the object in z/OS UNIX.
• SetAPF: the subject grants another object the privilege to set the APF flag on the specified object.

These relationships serve as edges when constructing a graph of subject–object interconnections. Below are examples of potential relationships between specific profile types.

Examples of relationships between RACF profiles

Visualizing and analyzing these relationships helped us identify specific chains that describe potential RACF security issues, such as a path from a low-privileged user to a highly-privileged one. Before we delve into examples of these chains, let’s consider another interesting and peculiar feature of the relationships between RACF database entities.

Implicit RACF profile relationships

We have observed a fascinating characteristic of the group-SPECIAL, group-OPERATIONS, and group-AUDITOR fields within a user profile. If the user has any group specified in one of these fields, that group’s scope of influence extends the user’s own scope.

Scope of influence of a user with a group-SPECIAL field

For instance, consider USER1 with GROUP1 specified in the group-SPECIAL field. If GROUP1 owns GROUP2, and GROUP2 subsequently owns USER5, then USER1 gains privileges over USER5. This is not just about data access; USER1 essentially becomes the owner of USER5. A unique aspect of z/OS is that this level of access allows USER1 to, for example, change USER5’s password, even if USER5 holds privileged attributes like SPECIAL, OPERATIONS, ROAUDIT, AUDITOR, or PROTECTED.

Below is an SQL query, generated using the racfudit utility, that identifies all users and groups where the specified user possesses special attributes:
select ProfileName, CGGRPNM, CGUACC, CGFLAG2 from USER_BASE WHERE (CGFLAG2 LIKE '%10000000%');
Here is a query to find users whose owners (AUTHOR) are not the standard default administrators:
select ProfileName,AUTHOR from USER_BASE WHERE (AUTHOR NOT LIKE '%IBMUSER%' AND AUTHOR NOT LIKE 'SYS1%');
Let’s illustrate how user privileges can be escalated through these implicit profile relationships.

Privilege escalation via the group-SPECIAL field

In this scenario, the user TESTUSR has the group-SPECIAL field set to PASSADM. This group, PASSADM, owns the OPERATOR user. This means TESTUSR’s scope of influence expands to include PASSADM’s scope, thereby granting TESTUSR control over OPERATOR. Consequently, if TESTUSR’s credentials are compromised, the attacker gains access to the OPERATOR user. The OPERATOR user, in turn, has READ access to the IRR.PASSWORD.RESET resource, which allows them to assign a password to any user who does not possess privileged permissions.

Having elevated privileges in z/OS UNIX is often sufficient for compromising the mainframe. These can be acquired through several methods:

• Grant the user READ access to the BPX.SUPERUSER resource of the FACILITY class.
• Grant the user READ access to UNIXPRIV.SUPERUSER.* resources of the UNIXPRIV class.
• Set the UID field to 0 in the OMVS segment of the user profile.

For example, the DFSOPER user has READ access to the BPX.SUPERUSER resource, making them privileged in z/OS UNIX and, by extension, across the entire mainframe. However, DFSOPER does not have the explicit privileged fields SPECIAL, OPERATIONS, AUDITOR, ROAUDIT and PROTECTED set, meaning the OPERATOR user can change DFSOPER’s password. This allows us to define the following sequence of actions to achieve high privileges on the mainframe:

1. Obtain and use TESTUSR’s credentials to log in.
2. Change OPERATOR’s password and log in with those credentials.
3. Change DFSOPER’s password and log in with those credentials.
4. Access the z/OS UNIX Shell with elevated privileges.

We uncovered another implicit RACF profile relationship that enables user privilege escalation.

Privilege escalation from a chain of misconfigurations

In another example, the TESTUSR user has READ access to the OPERSMS.SUBMIT resource of the SURROGAT class. This implies that TESTUSR can create a task under the identity of OPERSMS using the ImpersonateTo relationship. OPERSMS is a member of the HFSADMIN group, which has READ access to the TESTAUTH resource of the TSOAUTH class. This resource indicates whether the user can run an application or library as APF-authorized – this requires only READ access. Therefore, if APF access is misconfigured, the OPERSMS user can escalate their current privileges to the highest possible level. This outlines a path from the low-privileged TESTUSR to obtaining maximum privileges on the mainframe.

At this stage, the racfudit utility allows identifying these connections only manually through a series of SQLite database queries. However, we are planning to add support for another output format, including Neo4j DBMS integration, to automatically visualize the interconnected chains described above.