Mainframes: Legacy and Longevity

The humble mainframe is often mentioned in the same breath as the word “legacy”. When we consider the speed at which new technology emerges, it would be easy to assume that these systems should have quickly become extinct in the face of things like cloud, DevOps, and AI, let alone modern-day security requirements. In this blog we consider why organisations continue to invest in a mainframe future, despite skill shortages and the ever-present push to modernise older systems. We also examine the security challenges in the mainframe environment and how common vulnerability categories translate into this space.

The Real Legacy

Each time you do some shopping, access government services, buy insurance, or book an overseas holiday, there is a good chance that a mainframe has facilitated that transaction behind the scenes. This is because when it comes to reliable large-scale, resource-intensive processing, mainframes are still hard to replace.

Many have only heard about mainframes in passing, either in the context of ancient computing systems or as part of a cool (and definitely realistic…) hacking scenes in film.  Certainly, some components of the ecosystem rightfully deserve the legacy title – think unencrypted communications, decades-old user applications, and 8-character alphanumeric passwords – but there has long been no reason for security to fall under this umbrella.

The latest edition of the IBM mainframe is intended to take aim at optimising processing for AI and hybrid cloud integration.  This already does not match up to the “legacy” brand. The modern mainframe generally supports all the trending “tech stuff”, like cloud, containers, and DevOps (and is naturally also affected by security issues in these technologies). Fortunately, mainframe security capabilities have also evolved to offer modern access and auditing controls, advanced logging capabilities with SIEM integration and pervasive encryption. Mainframes are typically a goldmine of personal and payment (i.e. PII and PCI) data, and therefore robust security controls are essential to the longevity of these systems.

Security and Obscurity

It might be easy to make assumptions about how (in)secure mainframes are. Few mainframe breaches are reported in the media, access to the platform is tightly controlled (and very much paywalled), and there is often a lack of communication between mainframers and non-mainframers. It is also worth noting that a search of IBM Z in the CVE database will yield no results. This is because IBM opts out of public disclosure for OS vulnerabilities in preference of circulating important security information via the IBM Security Portal. This portal is only available for verified IBM Z customers, unlike their general security bulletin, which covers CVEs for all other IBM products.

Mainframe enthusiasts typically experiment with mainframe architectures on the well-known emulator, Hercules. This provides a way to run the few mainframe operating systems that reside in the public domain. While Hercules can emulate the z Architecture upon which the modern z/OS is built, IBM’s licensing restrictions allow no free and legal way to run it on a home computer. This means that only organisations with “real” mainframes tend to have access to an up-to-date z/OS and its associated software and security features.

A Penetration Testing Perspective

Mature organisations incorporate regular security testing of their mainframe environments and applications, but in lieu of an official OWASP-style list of common vulnerabilities, it may be unclear what findings to expect. Although mainframes may seem wildly different from the systems most people are familiar with, the same vulnerability categories still apply.

Below, we explore five types of vulnerabilities that can often be observed in z/OS environments. Most of these could be considered well-known or low-hanging fruit, largely in thanks to the contributions of mainframe security researchers that have published public resources and tools that assist with offensive security assessments.

Insufficient Access Controls

Access control problems can be the root cause of many vulnerabilities, including some of the others discussed in the proceeding sections. The External Security Manager (ESM) - RACF, ACF2, or TopSecret - provides access control and auditing within the mainframe environment. It is common to observe misconfigurations that allow users excessive permissions to resources. For example:

• WARN mode profiles: these allow users to bypass all security restrictions on specific datasets, may be in use even if they are no longer required.
• Default Universal Access Authority (UACC) of READ: allows users access to read datasets including those not required for the their job function.
• Access to modify SYSPROC/SYSEXEC datasets: potentially allowing unauthorised commands to be run by unsuspecting users.

Privilege Escalation

The Authorized Program Facility (APF) is used to provide permissions to utilise sensitive system functions. APF-authorised supervisor calls (SVCs) or libraries can be abused to escalate permissions to a Root/Administrator level equivalent, such as SPECIAL, or copy the permissions of any other logged-in user.

Another way to escalate privileges could be via surrogate permissions. Surrogate (SURROGAT) permissions authorise specific users to run jobs under the context of another specified execution user akin to SUID binaries in Linux. It follows that a user that can modify and submit these jobs can also perform unintended actions under the context of the surrogate user.

 Remote Command Execution

If mainframes can be boiled down to doing one thing, that thing is running jobs. Jobs are defined by a series of instructions that tell the mainframe what tasks it needs to perform. If you can write and submit a job, then you can likely achieve command execution. Depending on the configuration of different services it may be possible for attackers to run jobs through various methods, including (but not limited to):

• Submitting to FTP: users may be able to use the SITE command to enter Job Entry Subsystem (JES) mode, allowing users to upload and submit jobs for execution.
• Using Network Job Entry (NJE): NJE lets mainframes remotely run jobs and transfer outputs to one another. By impersonating a trusted node (i.e. another mainframe) it may be possible to submit jobs under the context of different user permissions.
• Abusing CICS: Some administrative CICS transactions can be leveraged to write JCLs and submit them using the Spool (SPOOLOPEN) or Transient Data Queue (TDQUEUE), which is used for task scheduling.

Cryptographic Failures

Cleartext Telnet and FTP are still amongst the most common ways to communicate with mainframes. As demonstrated on the now-defunct Internet Mainframe Project blog, organisations may still expose their systems over cleartext connections on the internet. When mainframes are only internally facing, it is not uncommon to see organisations risk accept cleartext communications until they can undertake the work to implement SSL/TLS.

Weak Password Policy

Mainframes often still suffer from the weak password policies. Although it’s entirely possible to enforce complex passphrases, the ability to do so can be limited based on whether other integrated systems or applications can also support this change. Organisations also may not have the drive or resources to accommodate stronger passwords across the board, particularly when the affected systems may appear on the decommissioning roadmap.

In our experience, we have also often encountered cleartext credentials in datasets. Sometimes these may be used to authenticate to other services or applications, or they may be leftovers from retired functionality. For example, some jobs may still have passwords in the job card statements. These can be used in subsequent brute-force attacks, even if they are no longer valid for the original account.

 In Conclusion

Mainframes remain a reliable technology due to their processing power and efficiency as a critical system. However, like any system, they are also susceptible to well-known security risks and vulnerability classes through their configuration, software, or exposed services. Regular security assessments and proactive vulnerability management are essential to maintaining the integrity and resilience of the mainframe ecosystem while securing their attack surface.