Yup. You like supporting COBOL? FORTRAN? How about some PL/1 running on AIX or something equally as byzantine... M&A can ruin your will to live.

Your modern z/OS mainframes are just unix.

The problem is the average IBMer will not know how to secure your zOS server. If you ask them how to configure, or how to manage files they'll tell you their aren't any. This is simply amazing double speak because they are, and are not correct. When you first log into this systems you see the old zOS stuff, which looks and feels like MTS system360-67M/70 (its a long story). All your files are data sets, which aren't files, see MTS didn't have files, it had data sets.

But it isn't. Its just a mainframe layer running on AIX. Its called something dumb like encom, unicom, in MTS . That brings you into proper unix mode. Which you may think is running inside MTS, but it isn't. MTS is running inside AIX. Because keeping MTS up to date with modern hardware would be impossible. So we just trick it into thinking its processor is running at the Plank frequency. Not 200 PowerPC chips or what ever IBM shoves in these things today.

Then your in a standard unix environment. If you attack these things from the outside (and get in), you'll see and feel what looks like a BSD/SysV (ish) system. Because that's what it is. Its a unix system.

But nobody configures this crap because the mainframe dudes can just say, "Oh no there are no files on a mainframe, just data sets, they're different." But if I steal a data set in unix mode, its a file. So no, your wrong.

Nobody really goes into Unix mode half the time. They just care about keeping the system360 stuff working. Nobody cares about security because "Its a mainframe, they don't have security issues." Well they do, just like every other unix box on the planet. But unlike every other unix box we pretend they don't need security.

I don' quiet buy your assertion that z/os is an emulation layer over AIX. When I used to while away the days poking around on a z/os machine, it was not that cut and dry. I couldn't just access a dataset from the shell, and the mainframe permissions model was pretty effective at locking down what I could get too. Do you have any references to back that ie an IBM red book?

I was thinking the same thing - I knew that z-series mainframes could run Unix, but I didn't think they always did - but it looks like valarauca is correct (assuming this Wikipedia article is reasonably accurate: http://en.wikipedia.org/wiki/UNIX_System_Services). Wow, that's a whole new attack vector I'm going to have to look into now. Exciting! Thanks valarauca!

Defcon21 there was an hour long talk. (I'm not 100% sure it was 21, could have been 20).

I look at MTS on a nearly a weekly basis. I want to say z/OS's mainframe OS is based on MTS. I don't know this for sure.

This is how I arrived at this conclusion:

(This is all ancient ~6-8 years Pre-Unix System 1)

See the big draw of of the System360 was Michigan University shoe horned in memory visualization (which allowed for concurrent time shared processing). This was released as the System360-67M (M for Michigan), these things exploded off the shelves. IBM received roughly 100 orders for these systems, not requests to lease time, but cash in hand gimme that.

They rolled out the System360-70 which was just the System360-67M, but under a different name. These are going to ship with TSS/360 (Time Sharing System 360). But ya know it never got done in time, and UofM had already finished MTS. Which did explode.

Also OS/360 was batched based. You couldn't have multi-user, multi-process. Which famously modern System360 emulation can do. So who knows.

I honestly don't know. But I'm 90% sure z/OS is just AIX with MTS in some kind of BSD-esque jail. I think MTS is open-ish sourced. It had a big community up until it was mothballed universally in the mid to late 90's.

:.:.:

I certainly can't afford a z/OS system to sit around and pentest myself :P

:.:.:

Also as I stated nobody configures the security of the underlying unix on IBM mainframes. So they maybe fairly easy to own.

I think he is saying that a lot of these companies have a mainframe emulator running z/OS on unix rather than a true mainframe. I'm not sure if that's true or not, but I believe that's why he is saying you can attack from the unix side.

z/OS itself is most certainly not an emulation layer over AIX. It's a complex operating system with 50 years of history behind it.

Bah, at least PL/1 is still maintained by IBM.

Come back when the language you are running on that AIX system is completely dead since before 1990 and there is no online documentation for it. ;)

ALGOL

Fair enough :)

Could be personal preference, but that actually sounds more fun than a lot of things in tech. Software archaeology on ancient and possibly broken systems? Probably has lots of annoying parts, but also sounds pretty interesting. Is it really less annoying to do "modern" work, like learning the Nth new Javascript framework, dealing with piles of Chef scripts, extending Enterprise C++ codebases, spending weeks testing browser compatibility, etc.?

My experience is that it's a lot less fun in practice than it is in theory. Uncommented spaghetti COBOL code is about as hard to reverse-engineer as an x86 disassembler dump done without debug symbols, IMO.

I used to know someone making a pretty good living doing COBOL for banks. Some people really do enjoy that sort of thing. Also a bonus of less (or even positive) age discrimination, since he was an older guy.

Failing to migrate after a M&A is failure to invest in IT. It's a stupid, short sited, and expensive failure, but good luck finding banks willing to pay for it.

Banks will only become willing to pay after experiencing expensive, massive disasters like what JPMorgan is experiencing. Maybe.

Migrating and/or killing large legacy enterprise applications is monstrously expensive, so the decision makers often decide against it. Relatively speaking, there haven't been enough very large companies that have been burned by that sort of decision, so executives at these companies (and the government) are less likely to see how badly it can go.

Then there's the very real challenge of justifying a big IT spend on retiring legacy applications to the shareholders. And the high chances of large enterprise IT projects going wildly over budget.

As much as we like to point the finger at the c-suite guys who keep doubling down on technical debt until there's a disaster, it's not an easy to make the case for paying to fix the problem. At least not until there are plenty of negative case studies out there like this one.