Random mainframe anecdote: I remember a client in the early 2000s who had a non-IBM mainframe that when originally implemented and designed predated the wide availability of Ethernet and TCP/IP. Everyone knew it was a piece of junk by the time I got involved, but their whole manufacturing system ran on it.
In order to bring it up to some semblance of modernity and allow it to print to their shop printers, which were IP-driven, they had to get a third-party to procure and install (or build?) an ethernet interface for the machine, and fired up the TCP/IP stack. It kept crashing when they put it on the network, until they finally figured out that the issue was that the TCP/IP stack didn't understand multicast packets, and so whenever a stray multicast packet hit the interface, the whole thing threw up its hands and gave up.
The solution was to keep the mainframe on a private network segment behind a firewall, not for security's sake, but because it was the only way to insure no multicast packets would hit it and halt production in three different factories
I managed to crash the TCP/IP stack on z/OS during my training with a runaway Perl script that inadvertently had turned into a fork bomb. Luckily, it was just a testing/development system, and SNA kept working, so the only person to notice was the monitoring guy. And that system was IPL'ed on a regular basis (with the next one scheduled one or two days from that incident), so it was no biggie. I was really freaking out, though, until the others assured me that it was not a problem - "This is exactly why we don't let trainees on the production systems", as my supervisor put it.
Since that day, I only use fork() very, very cautiously. :)
For the security researchers out there, mainframes are really under-researched. There just aren't many people that have the expertise in the platform required for security research. And most of the people who do have expertise in the platform are often oblivious to technologies outside of the mainframe. (If you've ever dealt with mainframe people, you might know what I am talking about.) It's unfortunate, but too often true. Our best mainframe guy is brilliant. I've never met anyone more technically skilled in his platform. But ask him a basic Windows or a Linux question? Forget it.
With today's complex stack of multiple platforms in most enterprises, a good security researcher, IMHO, should be fluent with both worlds. Mainframes are where some of our most critical data is stored. When you pull up your account balance through your bank's website, there's a good chance that value was read off a mainframe.
Mainframers are old-school. They don't believe in public disclosure or open security models or public audits. If you go through the DEFCON and BlackHat archives, there's not much mainframe research out there. There's just a small community of mainframers on the Internet, but it's a significant part of the world's infrastructure. The mainframe world is a crazy alternate reality. (I know, because it's my day job.)
Phillip Young, the guy who owns this Tumblr project, has made some waves in this community. His talks are a great place to start. Here's a few resources to get you started:
Funny thing is that mainframes might have earned their reputation for security if architectures such as Burroughs or i432 won out. Instead, IBM dominates the market and we know S/360 architecture was optimized for performance not security. That along with IBM backward compatibility seems to be how it won. The obscurity of almost every aspect of it along with barrier-to-entry is why it got less scrutiny.
So, it all adds up to a platform that should be very easy to smash and have literally decades worth of vulnerabilities built in. Should be some horrid design decisions in there, too, which might not be just a patch job. Mainframe hacking is literally a goldmine people should get into. Plus, those that prefer a boring, 8a-5p job with good pay and excellent job security will benefit from learning mainframe (or COBOL). Do the daily grind, play with shit on the test/dev partitions (LPARS?), and have fun hacking after work.
And you're right that the Redbooks are good. My only disagreement is that, if looking for mainframe, the SEO actually is too good in that all I get are Redbooks and IBM articles. That's when I'm looking for independent assessments of it. It's like Google wanted to drown me in their shit while I was actually looking for an independent assessment of Channel I/O, TCO, etc. Found some of it but it was work.
EDIT: Only thing that confused me was when the presentation said he bought a mainframe. How the hell did he buy a mainframe? I thought you had to be rolling in cash to even get an entry-level model with z/OS and z/VM. Re-edit, I found two answers to that question for people with some cash and who want to hack mainframes. See below:
> For the security researchers out there, mainframes are really under-researched.
I suspect it has to do with the price tag. For Windows/Linux, I can just install the system on a random PC I have lying around, or at least buy a PC for very little money (in the grand scheme of things). With mainframes, few companies have one just standing around for you to tinker with.
If IBM were willing to license z/OS (and their other mainframe OSes) to run on Hercules for such purposes, that might go a long way. But so far they seem to have no interest in that.
Casual exploration of the platform becomes very hard when a small mainframe is... what? $/€ 100,000?
And the complexity of the platform encourages specialization. (Try asking a competent Windows/Linux guy a mainframe question, they will probably give you a blank stare as well. FWIW, I am a Windows/Linux guy, too, I just was lucky enough to have a brief stint in a mainframe team during my training.)
Are there any places online to play with things like this? I used to admin Solaris machines back in the day and always wanted to learn more about mainframes. I'm not sure if there are any spots where you can get a free sandbox account on these types of things or not...
[+] [-] mattzito|10 years ago|reply
In order to bring it up to some semblance of modernity and allow it to print to their shop printers, which were IP-driven, they had to get a third-party to procure and install (or build?) an ethernet interface for the machine, and fired up the TCP/IP stack. It kept crashing when they put it on the network, until they finally figured out that the issue was that the TCP/IP stack didn't understand multicast packets, and so whenever a stray multicast packet hit the interface, the whole thing threw up its hands and gave up.
The solution was to keep the mainframe on a private network segment behind a firewall, not for security's sake, but because it was the only way to insure no multicast packets would hit it and halt production in three different factories
[+] [-] krylon|10 years ago|reply
I managed to crash the TCP/IP stack on z/OS during my training with a runaway Perl script that inadvertently had turned into a fork bomb. Luckily, it was just a testing/development system, and SNA kept working, so the only person to notice was the monitoring guy. And that system was IPL'ed on a regular basis (with the next one scheduled one or two days from that incident), so it was no biggie. I was really freaking out, though, until the others assured me that it was not a problem - "This is exactly why we don't let trainees on the production systems", as my supervisor put it.
Since that day, I only use fork() very, very cautiously. :)
[+] [-] danners|10 years ago|reply
https://isc.sans.edu/forums/diary/The+80s+called+They+Want+T...
[+] [-] aus_|10 years ago|reply
With today's complex stack of multiple platforms in most enterprises, a good security researcher, IMHO, should be fluent with both worlds. Mainframes are where some of our most critical data is stored. When you pull up your account balance through your bank's website, there's a good chance that value was read off a mainframe.
Mainframers are old-school. They don't believe in public disclosure or open security models or public audits. If you go through the DEFCON and BlackHat archives, there's not much mainframe research out there. There's just a small community of mainframers on the Internet, but it's a significant part of the world's infrastructure. The mainframe world is a crazy alternate reality. (I know, because it's my day job.)
Phillip Young, the guy who owns this Tumblr project, has made some waves in this community. His talks are a great place to start. Here's a few resources to get you started:
[0]: http://mainframed767.tumblr.com/
[1]: http://bigendiansmalls.tumblr.com/
[2]: https://media.blackhat.com/us-13/US-13-Young-Mainframes-The-...
[3]: http://www.slideshare.net/bigendiansmalls/security-necromanc...
[4]: https://defcon.org/images/defcon-22/dc-22-presentations/Youn...
[5]: https://www.youtube.com/watch?v=Xfl4spvM5DI
[6]: https://www.youtube.com/watch?v=5Ra4Ehmifh4
Also, IBM.com has a wealth of documentation. (They have terrible SEO though.) Checkout the z/OS RedBooks and manauls there.
[+] [-] zatkin|10 years ago|reply
[+] [-] nickpsecurity|10 years ago|reply
So, it all adds up to a platform that should be very easy to smash and have literally decades worth of vulnerabilities built in. Should be some horrid design decisions in there, too, which might not be just a patch job. Mainframe hacking is literally a goldmine people should get into. Plus, those that prefer a boring, 8a-5p job with good pay and excellent job security will benefit from learning mainframe (or COBOL). Do the daily grind, play with shit on the test/dev partitions (LPARS?), and have fun hacking after work.
And you're right that the Redbooks are good. My only disagreement is that, if looking for mainframe, the SEO actually is too good in that all I get are Redbooks and IBM articles. That's when I'm looking for independent assessments of it. It's like Google wanted to drown me in their shit while I was actually looking for an independent assessment of Channel I/O, TCO, etc. Found some of it but it was work.
EDIT: Only thing that confused me was when the presentation said he bought a mainframe. How the hell did he buy a mainframe? I thought you had to be rolling in cash to even get an entry-level model with z/OS and z/VM. Re-edit, I found two answers to that question for people with some cash and who want to hack mainframes. See below:
http://www.informationweek.com/ibm-debuts-lower-cost-$75000-...?
http://www.eweek.com/servers/new-ibm-zenterprise-bc12-entry-... (Says you can get one as low as $1,965 a month. Bet it can't do shit but that's affordable.)
[+] [-] krylon|10 years ago|reply
I suspect it has to do with the price tag. For Windows/Linux, I can just install the system on a random PC I have lying around, or at least buy a PC for very little money (in the grand scheme of things). With mainframes, few companies have one just standing around for you to tinker with. If IBM were willing to license z/OS (and their other mainframe OSes) to run on Hercules for such purposes, that might go a long way. But so far they seem to have no interest in that.
Casual exploration of the platform becomes very hard when a small mainframe is... what? $/€ 100,000?
And the complexity of the platform encourages specialization. (Try asking a competent Windows/Linux guy a mainframe question, they will probably give you a blank stare as well. FWIW, I am a Windows/Linux guy, too, I just was lucky enough to have a brief stint in a mainframe team during my training.)
[+] [-] res0nat0r|10 years ago|reply
[+] [-] joeshaw|10 years ago|reply
Most of them seem to be interfaces to network switches.
[+] [-] hellbanner|10 years ago|reply
[+] [-] emersonrsantos|10 years ago|reply
[+] [-] sp332|10 years ago|reply
[+] [-] ExpiredLink|10 years ago|reply
[+] [-] yarrel|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] knieveltech|10 years ago|reply