Mainframe Insecuritites or Hack the Gibson. No, Really!

You can hack a toaster, a TV and a car… but a mainframe? Isn’t everything on Windows and Linux? Who still uses mainframes (specifically IBM’s flagship System Z running Z/OS)?

They’re obsolete, specialized and cumbersome, just like the stuff that runs on them: TSO, JES, Walker, CICS, VTAM, MVS, IMS. And they’re pretty much sequestered from all the fun and games on the Internet – or so you would think. But hackers like to ask the questions “What if…” and “How do I…,” and that’s where our story starts.

Both of these guys work with major financial institutions, and their job involves protecting mainframes, so they really, really know their stuff when it comes to the mainframe hacking world. You can follow these links to see demos and slides from their talks, plus other very cool stuff, here and on Chad’s site.

So Why Are We Still Using Mainframes?

Mainframes really do have an image problem, and it’s no wonder. As Chad said in his talk at DerbyCon 5.0:

“Why don’t you care about such a thing? Because you’ve been taught not to. Schools teach you that mainframes don’t matter, if they are mentioned at all. Well guess what! Not only do they matter, everything you do, your family does, your government does, relies on them.”

These babies are not antiquated relics; they’re sophisticated and modern, and they are built for reliability, power and speed.

We’re talking almost 100 percent uptime, insane amounts of storage and terabytes of RAM (yes, terabytes!). Then, there’s volume capacity. These machines can process unbelievable numbers of transactions per second. Think of banking, travel, government – where you need to process enormous volumes of data rapidly and reliably.

And should these fail – well, they are designed to be very modular and are highly resilient to failure.

Claire Bailey, Director of Federal, State and Local Solutions, at Compuware, says this in a recent online article for Government & Technology:

“The mainframe is a technically matchless platform. Its performance, scalability, reliability and security are far beyond that of any distributed or cloud infrastructure. In fact, despite the incalculable investments made in these commodity platforms, they have never come close to delivering what the mainframe does. That’s why the most critical workloads in both the public and private sectors continue to run almost exclusively on mainframes.”

Or, as Chad summarized in his talk: “If it’s important, it’s running on a mainframe.”

What’s Really on Them and Why We Should Care

So, who uses them? Almost all Fortune 100s – 90 percent, according to IBM, who makes the platform (zSeries) and the flagship operating system z/OS. That would include airlines, hotels, banks and any major financial institutions; various levels of government (think taxes); healthcare; the infrastructure we see all around us. Yes, even 911 relies on an IBM mainframe.

Barry Schrager, the founder of Mainframe Data Security, has written numerous pieces on the subject. He cites these statistics in a recent LinkedIn piece:

71% of all Fortune 500 companies have their core business on the mainframe.

23 of the world’s top 25 retailers use a mainframe.

92% of the top 100 banks use a mainframe.

10 out of 10 of the top insurers use a mainframe.

More than 225 state and local governments worldwide rely on a mainframe.

9 of the top 10 global life and health insurance providers process their high-volume transactions on mainframe.

Barry says, “It certainly is a secure platform – the product I developed for MVS security, ACF2 (now CA-ACF2), has been used, and in many cases is still being used, at major government sites like the Office of the President, Senate, Federal Reserve System, CIA, NSA, much of the DoD, and many more outside of the US including MI-5 and the entire Australian government.”

So They’re Secure, Right?

In a word, maybe. One could infer that the lack of mainframe hacks in the news would imply they are unhackable; this would be a scary assumption.

Chad was struck by the scary thought that nobody, except maybe a select few (and all the folks at IBM, internally), were actually probing mainframes and their security, until he found Phil (I’m pleased to report there may be as many as 10 of them now). They discovered a disconnect between security culture and mainframe culture and that nobody was talking about that gap.

If you ask Phil Young, he’ll share this, a sentence from the IBM-MAIN mailing list that sums up what he has been trying to say and do over the last three years:

“Since security implementation on z/OS, independent of the tool, is the realm of either the sysprog (with little time to deal with it on a daily basis) or the security staff (where dedicated z/OS specialists are few and far between) – this can and does lead to potential gaps in coverage.”

It seems like folks are staring right past a giant potential vulnerability.

Can We Secure Mainframes the Way We Secure Other Stuff?

Let’s start here: while the high level principles all apply, most of the detailed tech stuff you know does not.

As Chad explained in his talk at DerbyCon, don’t go down this road. You can certainly exploit mainframes by traditional means, but (and it’s a big but) there are radical differences in: the architecture, the CPU, and the instructions. There is no tribal knowledge, no ready-to-reference FAQs in the traditional Open Systems sense. Below are some of the key obstacles we currently face:

Penetration Testing Tools: these need to be built or ported to the Z architecture.

Skilled Folks: There are increasingly fewer with the requisite skillset; even fewer who have the mainframe technical knowledge plus an information security background. As the experienced mainframers leave, the skills leave with them.

Unhelpful Attitude: good luck finding online support. Responses are often “You should not be doing this.” It’s a culture of keeping it between the people who need to know.

Complicated System: Manuals are thorough. Maybe too thorough. TCP/IP alone for Z/OS has 16 manuals, a total of 13384 pages or 59.39 MB worth of PDF files. Everything is documented to the nth degree. There are no quick and dirty FAQs.

And then there is a different character set for mainframe. EBCDIC. It doesn’t use ASCII. Everything must be translated.

“If installing the tool is the easy part of what you’re trying to do then you’re not doing it on a mainframe,” says Chad.

Yes Virginia, You CAN Hack a Mainframe

Most mainframers view their system as impenetrable, all safe and closed off. However, mainframes do have vulnerabilities, but that info isn’t made public. In fact, no details are released to the clients, only that a patch has been created and a CVSS score. IBM decides what users need to know.

Given that these systems should be walled off, Phil wondered if you could find mainframes on the internet, so he went hunting. He originally used Shodan and Google. Surprisingly, he found that there were mainframes online. The question was – how to connect.

Nmap was never meant for mainframes. In fact, according to Phil’s recent Skytalks talk, when it found them, a large majority came up as IIS/SSL? So, hacker that he is, Phil engineered it a bit. Phil wrote TN3270 Emulator for Nmap in LUA: tn3270lib. Which finally delivered the desired results. Which allowed him the ability to properly identify internet facing mainframes and take a screenshot of its beautiful TN3270 interface:

This new Nmap library also opened up entirely new avenues for testing mainframe security which had not existed before.

In addition, Phil developed a program called iNJEctor, which has the first and only NJE python library. It enables a user the ability to send JES2 commands using Network Job Entry (or NJE).Mainframes use NJE or Network Job Entry to set up a trust network. JCL, or Job Control Language, which lets the mainframes send jobs back and forth. It’s non-interactive. Users make changes and send them; the mainframe updates, processes and sends back.

Chad also recently demoed that simple information security primitives, like buffer overflows, work just fine on mainframes – using similar techniques, ported to the different Z architecture.

Finally, there was the not so trivial matter of bringing Metasploit into the tool chest. Chad learned the internals of how it works. And was very grateful for the huge helpful community that made it happen. Now he has a fully functional version on which a proper Gibson hacking platform can be built. Add to this that Phil has built multiple tools for platforms built into Nmap which can be used standalone and will eventually be ported into Metasploit as well.

We Need YOU!

Just ask them – Chad and Phil will both attest that a solid community of like-minded techno-elites such as yourselves are desperately needed to learn this dark art. As Chad says:

“Somehow I feel we need to increase the number of bodies on the ‘good guy’ side for both preventative/testing and incident response should the worst happen. The learning curve is steep. So my goal is to get folks excited about securing their or others’ mainframes (if that’s their job) AND flatten the learning curve by creating easy-to-use tools, integrating into existing frameworks, etc.”

Based on what was learned, here are the takeaways:

If you have a mainframe or access to one, you should be testing it

If you haven’t got direct access to a box, you can buy an emulator from IBM that will run a virtual mainframe on a Linux machine for a fraction of the cost of the real thing.

You need to invest time and money in the R&D to secure it

All kinds of third party software runs on mainframes like Java, HR, Web, accounting, and lots more. All these have exploits on x86 systems. How do we know what that looks like on the mainframe? (Hint: Many of the same vulnerabilities still apply)

Simply put: mainframes are neither obsolete nor unhackable. You can’t leave mainframe security for somebody else to support. You need to invest the time and money to know and understand your own systems. Because you can bet that somebody else out there who shouldn’t – already does.

About the Author:Cheryl Biswas is an InfoSec analyst, researcher and writer with JIG Technologies in Toronto, Canada. She loves working with her team to bridge the gap between those in tech and those who aren’t. In her role she handles communications; researches and delivers weekly InfoSec briefings; and advises on Disaster Recovery and security processes for clients.

Editor’s Note:The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.