T 3.72 Incorrect configuration of the z/OS security system, RACF
In the z/OS operating system, a special security system is responsible for the protection of access to resources. Here RACF (Resource Access Control Facility) is often used. The configuration of RACF as supplied does not, as a rule, match the security requirements in the related operational scenario.
The problem areas most often found in the RACF configuration are described in the following.
Validity rules for passwords
Using the SETROPTS command, it is possible to define security settings applicable across the z/OS system in RACF, in particular for passwords. The parameters include the minimum password length, the number of login attempts allowed, the maximum period of validity, the password history, audit settings and the class activations.
Misuse of standard passwords
As supplied, there are standard passwords in z/OS for the ID IBMUSER and the RACF command RVARY. Even in operation, the system monitors with functions critical for security are often still accessible using standard passwords.
The ID IBMUSER is used as an initial ID for setting up a new system and has Special and Operations privileges. As the IBMUSER ID is not allocated to any specific user, it is almost impossible to find out who is using or has used this ID.
Using the RACF command RVARY, the RACF database can be activated and deactivated, i. e. also changed.
The standard passwords are given in the product documentation and therefore generally known.
Warning mode
RACF resources can be protected in the warning mode. This means that access to the resources is always granted, even though the RACF definitions would actually deny access to the resource. As a result of the warning mode, in certain circumstances considerably more messages are written to the syslog and, in addition, more SMF records (System Management Facility) generated. As a consequence the amount of disk space required can increase significantly.
Erroneously granting access to resources via the warning mode can result in a loss of data confidentiality.
Protection of z/OS system commands
The z/OS system commands are protected using special classes in the RACF. If these classes are inadequately defined, it is possible for users to issue system commands that could degrade stable system operation in certain circumstances. Examples here are the starting and stopping of started tasks or placing disk systems online.
Global Access Checking table
If files are entered in the Global Access Checking table (GAC), access is not checked using the RACF database. The user has direct access as per the rules defined in the GAC. If incorrect files are entered in the GAC, they will no longer be protected by the RACF profiles. These files can, e.g., be read by all users if they are entered in the GAC with READ.
RACF databases
The RACF database contains, in encrypted form, all user passwords and must, like any other file in the z/OS operating system, be protected using appropriate definitions. If the access protection to the database is defined such that every user can read (and therefore also copy) the file (e.g. using the definition Universal Access(UACC) = READ), a brute force attack on the passwords is possible.
Examples:
- It is possible to change the RACF database using the RVARY command. A system programmer found that the password for the RVARY command was still the same as the standard password as supplied. The programmer was then able to place a different, specially prepared RACF database in the system and activate it. The programmer then had access to data that he could not view before.
- After setting up a new RACF database, an operator forgot to disable the ID IBMUSER. A clerk discovered this carelessness and was able to copy, from the system, data to which he was not allowed to have access.
- The backup copy of an RACF database was only protected using the definition UACC(READ) due to an administration error. An attacker utilised this error to copy the database to his PC. On the PC he used freely available programs to carry out a brute force attack on the passwords in the RACF database and was successful in several cases. The attacker then used the other users' IDs and passwords so obtained to change production data. The suspicion fell initially on the owner of the ID logged for the access to the log files, and not on the person responsible for the damage.