The Hidden Depths of Mainframe Application Testing: More Than (Green) Screen-Deep

Introduction

Mainframe applications make up the core transaction processing backbone of the world. However, when they are assessed, they are far too often only looked at from a front-end perspective – and it’s our firm belief that mainframe security assessments should be more than just screen deep.

Our goal with this blog post is to highlight that the attack surface of mainframe applications goes far beyond just the front-end “green screen” components, and to demonstrate the benefits of taking a wider, more holistic approach to mainframe application security assessments. We will cover three high-level categories that we feel describe and encompass the most common mainframe application vulnerabilities, misconfigurations and findings we have observed across multiple client engagements.

The primary focus of this blog post is on mainframe environments using z/OS and the Resource Access Control Facility (RACF); however these topics and themes can be applied to any platform.

Mainframe Applications Overview

At a high-level, mainframe applications can be grouped under one of two categories: “Batch” and “Online”.

Batch applications typically run in the background, at set times or intervals, and operate mostly independent of direct user input. These applications are used to process large quantities of data or files, and are commonly used within the financial sector to perform processing of payment information. Batch applications are used when instantaneous responses are not required, and can range from a single job to thousands of jobs being executed in a pre-defined order. These job configurations can be managed using either native or third-party batch scheduling software.

Online applications run in the foreground, and provide users with an interactive interface or "screen". These applications are often referred to as "green screen" applications, a term that derives its name from the original 3270 P1 display and printer terminals introduced by IBM in 1971 that used a green text color. These applications provide users with instantaneous responses and are typically employed to read or write data and manage transactions. While they can be accessed directly from the mainframe, they are also commonly exposed over alternative mediums such as HTTP.

Despite the sensitive nature of the information and functionality these applications have access to, they are often only reviewed from a front-end or "green screen" perspective. We’re going to run through three common insecure configurations that we see when reviewing online and batch applications.

Application Breakouts

One common attack against online applications is to attempt to "break out" of the interactive session or environment. This is often achieved by exploiting application logic flaws, submitting unexpected input, or by interacting with error messages in unexpected ways. As an example, the Customer Information Control System (CICS) application below expects the user to provide an insurance policy number and then press ENTER or PF5:

                    WSEC POLICY ENQUIR

01  ABCDEFGHIJKLMNOPQRS100000F              WSEC HOME                       
02  ABCDEFGHIJKLMNOPQRS200000F              WSEC VEHICLE MERGED               
03  ABCDEFGHIJKLMNOPQRS300000F              WSEC PRIVATE D.A               
04  ABCDEFGHIJKLMNOPQRS400000F              WSEC VEHICLE NO FUNDS          
05  ABCDEFGHIJKLMNOPQRS500000F              WSEC HOME INVALID PIN           
 
PLEASE KEY POLICY NO OF YOUR CHOICE 00, OR PF5

However, if the user does not enter a policy number and instead presses ENTER or PF5, the application responds with the following error:

                    WSEC POLICY ENQUIRY                                     
                                                                                
01  ABCDEFGHIJKLMNOPQRS100000F              WSEC HOME                       
02  ABCDEFGHIJKLMNOPQRS200000F              WSEC VEHICLE MERGED            
03  ABCDEFGHIJKLMNOPQRS300000F              WSEC PRIVATE D.A                   
04  ABCDEFGHIJKLMNOPQRS400000F              WSEC VEHICLE NO FUNDS              
05  ABCDEFGHIJKLMNOPQRS500000F              WSEC HOME INVALID PIN             
                                                                                
PLEASE KEY POLICY NO OF YOUR CHOICE 00, OR PF5                             
DFHAC2016 05/04/2023 15:47:36 WSECA11A Transaction ABCD cannot run 
because program ######## is not available.

The returned error message indicates that the ABCD transaction could not be run because the required program was not available. This is often indicative that the application may be failing in an unsafe manner, or that user supplied input (or the lack thereof) is being processed in an unintended way. If the user then positioned their cursor at the end of the error message and appended a CICS transaction such as the CICS Execute Sign On (CESN) and pressed ENTER, they would be presented with the CICS logon screen, as shown below:

                    WSEC POLICY ENQUIRY                                     
                                                                                
01  ABCDEFGHIJKLMNOPQRS100000F              WSEC HOME                       
02  ABCDEFGHIJKLMNOPQRS200000F              WSEC VEHICLE MERGED                
03  ABCDEFGHIJKLMNOPQRS300000F              WSEC PRIVATE D.A                   
04  ABCDEFGHIJKLMNOPQRS400000F              WSEC VEHICLE NO FUNDS              
05  ABCDEFGHIJKLMNOPQRS500000F              WSEC HOME INVALID PIN             
                                                                                
PLEASE KEY POLICY NO OF YOUR CHOICE 00, OR PF5                             
DFHAC2016 05/04/2023 15:47:36 WSECA11A Transaction ABCD cannot run 
because program ######## is not available. CESN

Signon to WSEC CICS              APPLID WSECA11A
                                                                                
WELCOME TO CICS TRANSACTION SERVER FOR ZOS                                                                              
                                                                                
Type your userid and password, then press ENTER:                               
                                                                                
          Userid . . . .             Groupid . . .                              
          Password . . .

This behavior demonstrates successfully breaking out of the application and gaining access to the underlying CICS subsystem. It should be noted that the extent of this attack would depend on the configuration of the underlying CICS region and that an attacker would only be able to access transactions that the application’s service account had been granted access to.

These types of breakouts can often be exploited by an unauthorized user. In the example below, an unauthorized user attempts to access a CICS application by specifying its APPLID. As they have not been granted access, the user is presented with the following error screen:

WSEC POLICY
ERR9704 WSEC authorities for the user were not defined in WSM.
MSG2695 End of SEC session, 06.05.2023

By then interacting with the returned error message and overtyping (submitting user input to replace the text on screen) WSEC POLICY with the word TEST, the following error was returned:

WSECA11A Transaction ‘TEST’ is not recognized. Check that the transaction name is correct.

This indicates that a breakout condition exists and, by interacting with the error message in an unexpected way, the user can invoke native CICS transactions such as the CICS Execute Master Terminal (CEMT) by overtyping commands, as shown below. Using CEMT, an attacker would be positioned to potentially read and alter CICS parameters.

CEMT I FILE (AB*
ERR9704 WSEC authorities for the user were not defined in WSM.
MSG2695 End of SEC session, 06.05.2023
 
CEMT I FILE (AB*
STATUS:     RESULTS - OVERTYPE TO MODIFY
    Fil(AB       )   VSA Ope Ena Rea Upd Add Bro Del     Sha
            Dsn( HLQ.MLQ.LLQ.ABDIC                           )
    Fil(ABCAT    )   VSA Ope Ena Rea Upd Add Bro Del     Sha
            Dsn( HLQ.MLQ.LLQ.ABDCAT                          )        
    Fil(ABCMN    )   VSA Ope Ena Rea Upd Add Bro Del     Sha
            Dsn( HLQ.MLQ.LLQ.ABDCMN                          )
...

The impact of this vulnerability will differ depending on the type of application and the environment it runs in. As shown above, finding an application breakout within a CICS application can result in the ability to invoke other CICS transactions. At this stage of the attack, the attacker will no longer be subjected to application-specific security controls. The impact of this finding will be determined based on the limitations placed on CICS transactions, which may very well fall outside the control of the application team.

This approach further helps to enforce the notion that security controls should be applied in layers and highlights how the attack surface of online applications expands beyond just the screen elements. Remediation of these findings will often need to be approached from both an application and environment perspective. Application controls can be implemented to prevent users from leveraging these misconfigurations to achieve the breakout. These controls should then be complemented by reviewing the environment, in this case CICS, and ensuring all access controls adhere to the principle of least privilege. If properly configured, these controls should limit the actions an attacker could perform, should an application breakout be discovered.

Surrogat Chaining

To ensure users can interact with privileged resources, mainframe applications will often leverage SURROGAT SUBMIT profiles. The purpose of SURROGAT profiles is to grant a RACF user the ability to perform tasks in the context, and with the permissions, of another user. Using these profiles, a single batch user ID can be created and granted the ability to submit jobs as multiple other batch users. We typically observe that individual batch users will be created for environments of differing privilege levels, i.e., TEST, UAT, PRE-PROD, PROD etc. These users are often also further divided should an organization have multiple brands or subsidiaries. 

Due to the complexity of these environments, we often find that it is possible that multiple users' surrogate access can be chained together, in a process known as surrogate chaining, to bypass segregation controls between environments. In the following example, two groups of batch users have been defined, one for production (PRDBATCH) and one for development (DEVBATCH). The production group's information is shown below:

INFORMATION FOR GROUP PRDBATCH                                                  
             
     INSTALLATION DATA=PRODUCTION GROUP FOR THE SUBMISSION OF BATCH
                       JOBS. 
     USER(S)=      ACCESS=      ACCESS COUNT=      UNIVERSAL ACCESS=            
       SURGUSR       USE           000000               NONE                    
          CONNECT ATTRIBUTES=NONE                                               
          REVOKE DATE=NONE                 RESUME DATE=NONE                     
       ABCDE01       USE           000000               NONE                    
          CONNECT ATTRIBUTES=NONE                                               
          REVOKE DATE=NONE                 RESUME DATE=NONE                     
...

Reviewing the members of the PRDBATCH group, it can be seen that the SURGUSR user has a SURROGAT SUBMIT profile and that the OPSUSRS group had been granted READ access to it.

CLASS      NAME                                                                
-----      ----                                                                
SURROGAT   SURGUSR.SUBMIT                                                      
                                                                                
LEVEL  OWNER      UNIVERSAL ACCESS  YOUR ACCESS  WARNING                       
-----  --------   ----------------  -----------  -------                       
  00    OPS            NONE               NONE    NO                           
                                                                           
...                                                                                
USER      ACCESS   ACCESS COUNT                                                
----      ------   ------ -----                                                
OPSUSRS    READ        000000
...

Reviewing the members of the OPSUSRS group it can be seen that the OPSUSR1 user had a SURROGAT SUBMIT profile, and that both the PRDBATCH and DEVBATCH groups had been granted READ access to it.

INFORMATION FOR GROUP OPSUSRS                                                   
                              
     USER(S)=      ACCESS=      ACCESS COUNT=      UNIVERSAL ACCESS=            
       OPSUSR0       USE           000123               NONE                    
          CONNECT ATTRIBUTES=NONE                                               
          REVOKE DATE=NONE                 RESUME DATE=NONE                     
       OPSUSR1       USE           000123               NONE                    
          CONNECT ATTRIBUTES=NONE                                               
          REVOKE DATE=NONE                 RESUME DATE=NONE                     
...

CLASS      NAME                                                                
-----      ----                                                                
SURROGAT   OPSUSR1.SUBMIT                                                      
                                                                                
LEVEL  OWNER      UNIVERSAL ACCESS  YOUR ACCESS  WARNING                       
-----  --------   ----------------  -----------  -------                       
  00    OPS             NONE               NONE    NO                           
                                                                                
INSTALLATION DATA                                                              
-----------------                                                              
PROFILE TO ALLOW SUBMISSION OF JOBS BY THE OPS TEAM.                                                                                           
...  

USER      ACCESS   ACCESS COUNT                                                
----      ------   ------ -----                                                
PRDBATCH   READ        000000                                                   
DEVBATCH   READ        000000

The DEVBATCH group contained multiple batch user IDs related to the Development environment. This configuration creates a situation where any user in the development environment, which would typically be subjected to less strict security controls, could access data and functionality within the production environment by chaining together SURROGAT access permissions. This attack path is illustrated below:

Downstream misconfigurations

Due to the complex nature of mainframe applications, we often observe that certain functionality, features, or processes are handled or supported by multiple downstream components and products. As an example, consider an application where access to more privileged functionality and screens are assigned in a granular manner via an application specific security screen.

USERID    ACCESS   FT EDIT    OPS    SUPERVISOR    AGENT    RECONSIL
WSEC01      B         Y        _          Y          Y         _
WSEC02      U         _        Y          _          Y         _
WSEC02      A         _        Y          Y          _         Y

Additionally, in this scenario, assume that any settings configured via this screen would be stored in an on-host back-end Db2 table, with full access granted to all RACF users via the PUBLIC group.

DB2 Object ===> T                    Option  ===> UA
Table Name ===> APP_ACCESS_12345     Creator ===> OPS
Qualifier  ===> *                    Grantor ===> *
             TABLE/USER      ALT  DEL  INDX  INS  SEL  UPD  REF  REFC  TRIG
          APP_ACCESS_12345
              OPS             G    G    G     G    G    G    G           G
              OPSUSR0         Y    Y    Y     Y    N    N    Y           Y
              PUBLIC          Y    Y    Y     Y    Y    Y    Y           Y

A common misconception is that access to this type of administrative functionality need only be secured via application-specific authorization controls. However, if access to the on-host Db2 tables used to store access permissions is not secured, an attacker could alter these entries to grant themselves administrative access, bypassing application-specific authorization controls. This principle can be applied to any other supporting component that interfaces with mainframe applications, such as components reading from data sets. Attackers will always aim to identify the path of least resistance when going after an objective. Should the application prove too robust or secure, a motivated attacker will simply pivot to a downstream component or the environment that interfaces with the application and attempt to exploit any misconfigurations present there. This again highlights the importance of ensuring security controls are not only applied at an application level, but rather configured holistically across the environment and supporting components.

Conclusion

As demonstrated in the examples above, when looking at mainframe application security, it is important to ensure that a holistic view is taken. To this end, testing should always focus on more than just the front-end or screen components and should ideally incorporate the supporting environments and functionality. This approach enables organizations to apply layered security controls that greatly reduce the viable attack surface of these critical applications. These layered controls will further reduce the impact of front-end or screen specific vulnerabilities, as the overall environment has been hardened and aligns with security best practices.