Jan 11 ’10

Mainframe Hacking: Fact or Fiction?

by Stan H. King in z/Journal

In the early days of computing, everything was easier to secure. The data center was behind a wall of glass and secured behind locked doors opened only by those chosen few with the magic key. Data security was rudimentary compared to today; RACF was in its infancy; and data theft, destruction, and alteration did occur, but always as an inside job. Even in those early years, tools existed to tighten controls on data access, but it was up to systems programmers to use them.

Data communications, based on Binary Synchronous Communications (BSC) or Systems Network Architecture (SNA)/Synchronous Data Link Control (SDLC), used analog circuits. These were so difficult to hack that they were never seriously considered as a major point of entry for illicit activity. That is quite the opposite of today, where the common backbone network—the Internet—links everyone to everything, creating a tremendous number of possibilities for attack. In the ’60s and ’70s, establishing a high-speed circuit with conditioning from New York to Los Angeles required coordinating with several telephone companies across the continent, and waiting six months or longer. Now worldwide connectivity is as close as your local ISP and the wall jack in your office.

A widely held opinion is that computers are computers; thus, they’re all subject to the same security issues. This is true to some extent, but all computers aren’t created equal; you get what you pay for, and the combination of an extensive, feature-rich hardware architecture coupled with a mature, stable operating system can provide a formidable fortress. Programmers who properly use tools such as RACF can enshroud applications in effective security and stop an unauthorized application from accessing prohibited resources.

If you want proof of this claim, consider what you can find by searching news archives and trade journals, looking for references to mainframes and data loss, hacking, security breaches, and similar topics. Recent research included checking the archives of ComputerWorld, InformationWeek, and The Wall Street Journal for reports of unauthorized access of any traditional mainframe environment via userid/ password exploitation, corruption of a mainframe-based networking resource, or contamination of a mainframe sys- tem software component.

This list may sound decidedly short, but it represents the basic foundation of mainframe safety, security, and integrity. This isn’t to trivialize security implications of online transaction processes such as CICS or IMS, but these application environments interface with the underlying system security components and can provide programmed security with or without additional authorizations from the system security manager component. Application security within a transaction processing collection is dependent upon the designer and programmer. Poor design will beget a poor application with poor control. RACF will stop an unauthorized application from accessing prohibited resources, but it must be correctly applied.

Browsing the archives was an interesting endeavor. When it came to unauthorized mainframe access by outside hackers, there wasn’t a single published report among nearly 850 full-text documents published over the last decade. Many reports concerned data theft and data loss in which a mainframe was the primary processor but not the focus of the hacking. In those cases, peripheral networking equipment or intermediate servers were successfully targeted; the mainframe was never touched. Theft of data in this manner was the most prevalent and damaging due to Personally Identifiable Information (PII) involved, such as credit card information, medical data, membership records, etc.

Next most frequent was theft of media containing sensitive data. This category includes tapes, optical media, flash drives, laptops, and desktop computers. Physical control of removable media and equipment seems to be the easiest security method to implement but the alarming rate of theft occurrences reported suggest that by itself, it’s insufficient.

Although no news items mentioned failed mainframe security, that doesn’t mean there were no intrusions. A random hacker may not be able to squeak past a properly configured RACF user- id/password challenge, but a disgruntled employee or other insider might.

Several news accounts described unauthorized data access by employees, but this type of security violation is more difficult to thwart due to the attacker’s access to internal information. Proper procedures development and enforcement can significantly mitigate this type of problem.

VM experts Melinda Varian, Dave Jones, and Phil Smith III recounted one infamous example of mainframe hacking that took place in 1987—the IBM XMASCARD EXEC procedure written in Rexx that was sent to VM/CMS users. The program displayed a “Merry Christmas” message on the 3270 display and then proceeded to read in the user’s address book and automatically send itself to every address it found. The resulting traffic overloaded IBM’s internal VNET and the BITNET.

Varian described a DIAG 128 hole that was exploited in early releases of VM, but said these types of exploits have long since been closed.

VSE expert Rich Smrcina stated that although he doesn’t recall or know of any VSE hacking, that doesn’t mean there haven’t been any instances, as some incidents may not be reported because of the impact of negative publicity.

z/OS and UNIX guru Bob Puppa remembers only one case where a Time Sharing Option (TSO) account was accessed by guessing the owner’s pass- word (one of his children’s names), and even then it was an internal situation. z/OS is a brick wall without easy exploits for most software, as it was architected to protect itself; but integrity exposures in a class of privileged software called authorized programs can still cause damage. By far the largest supplier of authorized pro- grams is IBM, but others exist as vendor products and customer-written utilities.

Ray Overby of Key Resources, Inc., who specializes in security penetration testing and monitoring, explained that bypassing system integrity requires first identifying an integrity exposure, since that will allow a program to perform one or more actions not authorized by a mechanism under installation control. The most critical exploits are those that obtain the ability to do the activities detailed in IBM’s Statement of System Integrity.

Overby says that, “Only a single integrity exposure need exist for your system to be at risk. The larger the shop, the larger the risk due to the number of authorized programs. The integrity exposure is the vulnerability.”

IBM is proactive regarding security and system integrity. z/VM and z/OS have effective security models and z/VSE is continuing to evolve with security enhancements. IBM publishes a strong statement regarding system integrity for z/OS and z/VM (see the accompanying sidebar).

Recently, on the IBM-MAIN discussion list, David Cole commented: “It is acknowledged by both IBM and the mainframe community that authorized programs have the power to corrupt the operating system in arbitrary ways, creating an exploit to gain access. It would certainly be possible to manually build a DEB (system-level structure that potentially could allow access to unauthorized data), and no, it would not be APAR-able (vendor-acknowledged problem to be fixed).” Obviously, if you can install authorized programs, you can compromise the system.

Noted RACF expert Bob Hansel of RSH Consulting summed it up by saying: “I’m not personally aware of any instance where a mainframe has been hacked. However, I think the scarcity of such incidents is due more to a lack of technical expertise by would-be perpetrators than to the sound implementation of controls. We have found serious security holes in all our reviews, but most require a moderate degree of technical skill and knowledge to exploit them. Unlike Windows and UNIX, there are no z/OS ‘script kid- die’ routines that an unskilled user can use to penetrate a z/OS system. However, we’re currently facing new challenges. It used to be that only those relatively few users with TSO or ROSCOE could manipulate system files and execute routines that could harm the system, but with the introduction of OpenEdition MVS (now z/OS UNIX) and common TCP/IP-based network applications, many organizations, some unknowingly, have opened their systems to a much broader user base, including clients and business partners. This increased connectivity is unfortunately coupled with a lack of upkeep on RACF controls. Newer z/OS capabilities either aren’t being protected or fall under the scope of older, less stringent control settings. Both of these factors contribute significantly to the underlying cause of the vast majority of the vulnerabilities we find.”

Examples of insider hacking were even harder to locate; this can be attributed to the difficulty in implementing an internal security exploit and to the desire to avoid negative publicity from acknowledging a security breach.

At a California bank in 1975, an application programmer modified a savings account interest calculation module to move the rounding amount from each account to his personal account during the monthly run. Everything always balanced, so he got away with skimming hundredths of a penny from each account, month after month, until the size of his account balance caught the eye of a branch manager; those small amounts had accumulated into several hundred thou- sand dollars! Technology and internal testing procedures failed to catch this criminal. That was 34 years ago, but the same problem could occur today if proper procedures aren’t followed.

As Walt Kelly’s “Pogo” comic strip character eloquently stated in 1970, “We have met the enemy and he is us.” The responsibility for security rests complete- ly within our collective laps. We can be proactive and fix security holes before they are exploited, or we can ignore the situation while waiting for the inevitable.

The threat of hacking mainframes should be taken seriously. While it appears System z systems are protected quite successfully, we can’t rest on our laurels or think we’re invincible. IBM has done an excellent job of providing an environment with high system integrity along with a set of tools to protect us from ourselves, but we must use them to maintain a secure future.