okay.  This, this talk is going to be a lot of fun.  There's a lot of old stuff out there that's still running.  The tire shop that I go to was, they, their database was in an AS400 until, you know, about, actually, it was about a year ago, and then they never migrated any of the data.  So they were still running that and another system terrible, terrible.  So these guys are going to talk about old stuff and problems with old stuff.
Let's give them a big hand.
[ Applause ]
>> Thank you.                                                                                
>> Thanks for coming out.  I will see in, in follow-up to that, that is a great, that -- that is absolutely the, um, that is absolutely what a great number of the, the number that we meet and talk about, and talk to about this kind of stuff, ah, have to say when we talk about these kind of things and there's a lot of truth to that.  This, this, this platform, the mainframe platform, specifically we're talking about IBMs, system Z, Z-series platforms have been around for a long time.  So it's absolutely what you would consider legacy.  However, but, um, it's very modern.  Right?  The, the, the most recent incarnation of it is as bad ass as just about and maybe more so than anything you can buy in terms of what it does and what it's good at.  And so what we're talking about today and the things that Phil and I are going to talk about today are done on the very newest systems, fully updated, fully patched, all this kind of stuff, um --
>> So we'll go from there.
So who can relate to this scenario?  Wake up in the middle of the night, deep sleep, freaking out, cold sweat, you thinking to yourself, holy shit, who's doing security research on mainframes?  Show of hands.  All right.  So both of you, excellent.  Thank you for doing that.  I appreciate it.  I'll pay you afterwards.  So this happened to me about 18 months ago, I have vacation in my, in my business life, and not, I'm not here on behalf of my employer, this is just, standard disclaimer, research I'm doing in my free time, um, but I had occasion in my business life to care about mainframe availability.  More so I have occasion just as a human living in a civilized world -- somewhat civilized.  In a modern world to care about mainframes.  And wanting them to be secure.  So 18 months ago I had this, I had this idea, like, well, I wonder who's doing the security research?  Who's doing the stuff that you guys do for Linux, Windows, all of this kind of stuff, who's doing it on mainframes?  So I tried Googling it and I'm looking to see what I can find out about exploit development, mainframes, vulnerability research, get a couple of companies, but as individuals go, really, there were like maybe two.  And one of them's right here.  And so, ah, I reached out to Phil, my cospeaker here, at the last DEF CON and said, hey, let me buy you are beer and I would like to talk about the work you are doing.  So he told me all about the work he was doing and I said, this, this is fantastic stuff, but -- I had recently been very much involved in like malware reversing, exploit development, that kind of stuff, I said, well he's doing this kind of stuff?  Right?  Who is fuzzing the binaries?  Who is testing to see if there is buffer overflows?  You know, the basic like meat and potatoes at this point of, of security vulnerabilities and that kind of stuff.  I said, I don't know.  I, I, I don't know that anybody is.  He looked at me, he was like you are.  I was like, well I'm not.  I mean, I'm not a mainframer.  I've, I've worked around mainframes for, for 10 years, but, you know, it doesn't make me a mainframer more than being in my garage make me a car.
So I said, well, I'll give it a shot.  So I, ah, got a mainframe and ah, I started doing some research on this stuff and the first thing I did was I want on Google and I said what, what's already out there?  Right?  What vulnerabilities are available?  What publicly available proof of concepts are out there for, for vulnerabilities, exploit code, shellcode, all of this kind of stuff, and just by way of example, I went to cvedetails.com.  So Windows in the last 10 years has had about 5,000 documented CVEs.  No surprise there, Mac, OS X about 2200.  ZUS, which is the mainframe also known as MVS or used to be known as MVS, none.  What?  That, that can't be right.  I know for a fact that there have been security vulnerabilities on the mainframe.  Why aren't their publically documented vulnerabilities, proof concepts, shellcode, exploits, this kind of stuff?  If you ask the, ah, the, the everybody, if you ask the people that have been working this for a while you'll hear everything from like, well, you can't have, you can't have exploits on the mainframe.  You can't have buffer overflows, it doesn't work.  It's a secure platform.  And it is a secure platform if configured correctly and running code with no bugs in it, which is totally possible.  Right?  Not, not really.
So, so why aren't there any, why isn't any of this out there?  There's two reasons in my opinion, there's two reasons of this.  And the first one and probably the biggest one is that IBM has a special relationship with our customers and that they know all of their customers.  You can't buy this without working with IBM.  You can't get one of these systems without working with them.  Legally.  And so they know all of their customers.  So by knowing all of their customers, they can release the, ah, they can release security vulnerabilities when they find them and give them to their customers and say, hey, we found a security vulnerability, it's pretty bad, right?  Let me rank it for you, and here's kind of the area.  It's like, maybe it's program-based or network-based or something like that.  That give you like a -- a vector light, if you will.
And so and these are for their paying customers.  They have a secure portal where they give them this information.  And can then the customer can decide if they want to put it on or when they want to put it on.  These things on here that I've showed you, those, those are direct copies from kind of their policy around this vulnerability discloser on this platform.  And they -- it is -- it is a benefit, based on this ah, document, did not providing the vulnerability details is that both external attackers and internal personal threats don't have access to that.  Could put the -- enterprise at undue risk.  So you and I know this as security by obscurity, right?  That's basically what that is, right?  Lots of, a lot of vendors and people who have tried this over the years and done this differing degrees of success.
So that's reason one.  A second reason is, um, is summed up in this slide.  And so, this is a picture of the Ferrari that DEF CON bought me for being a speaker.  Thank you.  And I think that mainframes, or, ah, businesses treat their mainframes much like this Ferrari.  This is a -- Ferrari, this is a million and a half dollar Ferrari, the guy who owns this -- the person who owns this Ferrari is that talking it out and pulling a trailer with it.  And they're not bringing it home and practicing their shade tree mechanic skills on it, cutting their teeth on it, and not taking the engine a part and saying, like, how does this thing work.  Right?  Neither is the enterprise that owns the mainframe doing this stuff, because this is their pride and joy, right?  And not only their pride and joy, but this runs their most critical workloads.  Most enterprises that run mainframes, if you pull the mainframe out, they don't do whatever their core functionality is much well or at all.
So who I am?  And why am I here?  Um, basically I'm here as kind of the call to arms.  Ah, I want to get people, I got excited about this, because I felt a need, I felt it was a place to make a difference, not just breaking it something, but making it better.  And I, I want to do a call to arms to the people out there that are ah, own pen testing company or enterprises that own mainframes and say, hey, you can afford to have a mainframe and if you rely on it, you ought to have a group of people that are smart enough to pen test it, really pen test it.  Not just port scan it and not just go through and make sure everything is configured the best way possible.  But the kind of pen testing that key come to love and except for every other platform that we have.  Right?  Full on fuzzing, vulnerability discovery.  This kind of stuff.  And if you're a pen testing company and you do engagements for companies that have mainframes you ought to be, have somebody on your staff that knows how to do this.  You ought to go out and hire them.  Tell you what, there are not a lot of people that go out there and do this.  Not very many in fact, but you can train them, it is very, very, very much a trainable skill.  You got to be talking to those engagements that you have about, hey, maybe the mainframes out of scope, but should it really be out of scope?  I mean, here's some examples of why maybe this should be in scope.  Try to make it a little bit, a little bit better ecosystem.
So I grew up, I've been doing computers since I was old enough to type.  I like solving problems.  I like not taking no for an answer.  This kind of stuff.  Mostly I grew up, though, bust by -- of my background is Linux and Windows.  I started doing mainframe, like -- maybe 10 years ago, but only really in Earnest, like maybe a year and a half, two years ago.  So that's a little bit about me, I will let Phil tell you a little bit about himself.
>> Thanks, Jeff.  So my name is Phil or, you may know me as soldier of poor trend.  I run a couple of blogs about mainframe security.  I really got interested in this stuff maybe a handful of years ago working as a company, um, it wasn't until I got really my own mainframe that I started sort of messing around with it.  Um, I probably connected to some mainframes when I was messing around on X25 networks back in my teens, but basically I got my own, started just doing things with it.  And saying well, what's -- maybe not as good as people have said there, thank you, yeah.  There you go.  So I got my own mainframe, did my own stuff, released a couple of tools, I spoke at DEF CON last year, did all that kind of stuff.
Now, I want you guys to think, so, so we sort of touched on this a little bit, but when people think mainframe, 'cause, it happened right before our talk, this is what they think of -- all right?  If you can't see that, that is a dinosaur with a pay phone in its stomach.  All right?  That's like two dead things.  And that's what people think a mainframe is when we're talking about them.  Okay?
But the reality is, it's about 90% of fortune 100s are running these things.  Anything that matters to -- okay.  Let me do a quick poll, who here has used a credit card in like the last 48 hours?  All right.  All right.  Who here has used cash in the last 48 hours?  Yeah.  Okay.  So everybody.  Right?  Any time you did that transaction, a mainframe was involved at some point.  So I'm going to show you this slide.
Can't read it, somewhere on this slide is a company you give a shit about.  Okay?  Also on this slide -- I could have keep going with multiple slides -- okay?  There's banks in here, there's airlines in here, 911, states, all kinds of things that matter to you, to everybody, are on here.  They're on this platform.  So you don't think you need to care about this -- you definitely need to care about this platform?  Okay.  The whole reason I started talking about this because no one else was.
So the rest of this talk is going to be broken down into two parts.  I'm going to be talking about networking and a little bit about the tools and pen testing tools I'm releasing.  And then Chad's going to talk about, ah, exploit development, shellcode development, on the platform.  So on network, when you think about a mainframe, you usually think about a screen that looks like this, this is a classic TN3270 green screen.  It's horrible to write in.  When you write this, when you develop for this, it's written in assembly to make it look like this.  This took a lot of work to setup.  But you can sort of see on the screen here, if I type CICS, it will take me to CICS.  If I type TSO, it will take me to TSO.  This is one of those macros, but anyway, it is TN3270.  It's based on Telenet, yes.  That Telenet.  It's not really Telenet because it's not really an interactive protocol, it's got these beautiful colors, but what happens is you submit, you, you get a text full of stuff, you type in whatever, you hit enter, and then it processes what you did and then sends it back to you.  So you, it's not really happening in realtime.
Now, it's a buffer.  So that whole screen you saw a couple of slides ago, it's a buffer that's 109,020 bytes long and it graphs at the 80th common every single time, right?  Each byte is either going to be a character, like, like you saw, or it could be a field identifying an attribute that identifies that as the next character's going to be this color or the next character's going to be locked or unlocked, or the next thousand characters are going to be locked or unlocked.  And then it's going to say are these characters visible or invisible?  So on this screen, the only area you can actually touch and change is that little tiny square there.  Right?  So when you type in and you log-in -- that's the only place you can type stuff on that screen.  Now, when I started doing this, I just used the free tools that were available to me personally.  And Nmap, not so great.  Okay?  In fact, one time I did a scan, a couple years ago, and it identified a bunch of mainframes a microscope ISSSL.  So way off mark.  So I wrote my own Nmap script to take care of this.  This is what it looks like before.  Now, the problem with this, one it tells you that the services Telenet.  Well, technically true, it's not really.  It's TN3270.  The other challenge is IBM OS390 is 20 years old and was discontinued 20 years ago.  Like it's, it's gone.  No one uses it anymore.  But for some reason that's the version, and that's not even the version, it's not like a demon that's running, that's not what it looks like.  So what I did, I wrote an Nmap script to help you actually tell that you've connected to TN3270.  So now, and it will actually tell you if you're doing this excel or not.  So now when you're doing a scan of your networks and you're finding mainframes, you'll actually know you're finding mainframes.
But that wasn't really enough, right?  That just tells me it's, I want the banners.  And want more information.  I wanted to see this -- this is a real mainframe that's on the Internet.  Okay?  But I don't want to have to run an emulator every time I want to see these screens.  So I wrote my own TN3270 library for Nmap in Lua, it was rough.  Really hard to do, but it's available and it takes things like this -- this is what the banner now looks like when you do a scan against a mainframe with these two scripts.  It will show you the, that it is a TN3270 and then it will show you the actual screen or banner that it has.  So that's fun.
But now, because I wrote a fully functional 3270 emulator for Nmap I can do all kinds of cool stuff.  This is a CICS transaction idea numerator.  Anyone know what CICS transactions are?  Okay.  Good.  So you know why this is cool.  So this will go through and enumerate CICS transactions on a mainframe.  Multi-threaded -- this is on our test mainframe.  We actually have one.  This is only allowing 22 threads at the same time, because we only allow 22 TCP connections, but that's exactly what it looks like and it works fast.  But now we can do all kinds of cool stuff with the other things I know you can enumerate.  So V10 application IDs, which means nothing to almost everybody here except for one person.  I'm guaranteed.  The other thing, oh, great --
[ Laughter ]
Yeah!
>> Keep going with your stuff.
>> Oh, I want to see him take a shot.
>> Keep going.
>> Oh, damn.  I also, I'm going to.
>> Are these you?
>> Anyways.  V10 macros you saw me type TSO CICS on the first thing, well, you don't actually have to display those items.  You can just, you can just type in whatever you want and if it's a macro it will work.  So I wrote another one that does macro enumeration.
Now, you guys remember when I said it was hidden and protected?  Well that hidden and protection happens on the client side.  So what happens when you do sort of security type stuff on the client side?  You just ignore, yeah.  It's not secure, right?  So take a look at this, this is what the CICS transaction actually looks like.  And when you look at it, it's got a locked field --
>> Keep going, keep going.
>> Keep going?  All right.
Right here.  This is 8 bytes long.
[ Laughter ]
Are you all right?
>> Yeah.  I'm all right.  Keep going.
>> What happens if you ignore that?  What's happening if you ignore the 8 bytes of length?
>> What happens?
[ Laughter ]
>> I don't know.
>> All right.
>> I personally, I actually don't know because we've never done it, but I assume all the apps break.
>> They, the screen becomes blue.
>> No, probably does.  I mean, I don't know.
But also, what if you have hidden fields down here?
>> All right.  You guys know how this works.  So um, are these guys doing a good job?
[ Applause ]
>> Yeah!
[ Applause ]
>> All right.  That's pretty good applause there.  So new speakers, hard to get here, congratulations.  It is DEF CON.
[ Applause ]
>> And now let's find out what happens to the CICS field.
>> Yes.  Thanks.  Thanks for making it sound so exciting.
[ Laughter ]
But no lie, if you actually do care about this stuff and you all should, trust me, this is some crazy shit.  So oh, that's -- that's hard to do if you need to go and identify all the hidden fields by yourself.  This emulator ignores all the rules.  In the Nmap emulator just ignores them, it doesn't care.  If it is hidden it will show you.  If it is not modifiable, it doesn't care, it will just keep putting characters in there.  So you can do things like this and automate finding hidden characters in green screen applications on the mainframe.
Also you can just do fuzzing now.  You can just use this to fuzz mainframe applications which was not a thing you could do before.  But I wrote one in Lua, why not also do one in Python?  Same as Nmap.  It's the same thing.  But now I can do a script that I wrote called set N3270 if you don't give it any arguments it just create as fake TSO log-in screen, you trick, you know, trick users hidden it that will put in their user credentials.  It can mirror a target mainframe so you connect it, it does a bunch of stuff, and it will also do proxy man in the middle and it will also do SSL.  So if you have an SSL mainframe it will just, because the clients don't really care.
So this is what it looks like.  This I'm just going to show you the default mode here.  So here it's going to run.  That's why I record my demos.  They never work when I do them live.  I'm going to launch my 3270 emulator.
[ Laughter ]
Thank you.  Somebody got it.  Someone at least.
So this is the fake TN -- TN3270 TSO log-in screen.  This is what everybody uses when they log into the mainframe for the most part.  I'm going to log-in as date, give it a password, when I hit enter it's going to show up on the bottom and it's going to kick the user off and say, actually we shut this mainframe down, you can't use it anymore.
Now, there's other tools out there, so Dominick White, are you here?  Put your hand up if you're here.  All righty.  So he's actually given a talk at DerbyCon, I recommends that you see it, it's a great talk.  He also has some tools.  Big iron reconnaissance, opponents.  Once you see hidden fields and once you see those things and want to manipulate it, you can use his tools to do it, there is also mainframe brute, which is a tool he wrote based on a tool I wrote, so I don't know who owes who what kudos, but, all right.  So, that's TN3270.
You'd probably have heard of it if you work around mainframes, right?  This is something most people have never heard of because no one talks about it, but it's called network job entry.  I heard about it, maybe, um, a handful of years ago when I was doing a walk through of a mainframe and someone told me there, they were working on the DEV system got connected to any other system and they submit a job and it created a use in the production environment.  I was like, what the hell is this?  How is this possible?  I mean, it's nonchalantly, like oh, it is just NJE.  I mean, I'm like, I have never, nowhere in any security guide, in any book, nowhere does it talk about network job entry, but that's what this is.  Basically two mainframes share, share a secret handshake and after they had that handshake they are trusted nodes and they can send jobs and commanding control messages between them.  And they don't send passwords.  They don't send anything.  So kind of like this, this is an actual configuration from our mainframe, and so, my, my, this is my mainframe.  I'm going to say I have two nodes.  My node name is New York.  Chad's node name is Washington, D.C.  And this is the IP address I need to connect to when I'm connecting to his mainframe.  Now, he would do the exact opposite on this mainframe, he would switch New York and Washington, D.C. and then change the IP address.  It runs on port 175 or 2252.  It uses host names.  So those, those nodes which they call nodes in the configuration file, but they call host names in the documentation, I don't know why, it runs over TCPIP.  So that's good.  And it was developed in the '80s, we think?  Because it's not really clear.  There's a couple of ways you can break this.  But first I need to identify that it's even running.  Here's what happens when you do Nmap against an NJE port.  It has no idea what it's talking about.  So I wrote another Nmap script which will tell us that we're connected to an NJE port on a mainframe and that it's open accepting connections.
The next thing we need is the actual host name.  So what happens when they share that secret handshake is the mainframe says -- I'm New York, you're Washington, D.C., I want to connect to you.  And the mainframe says, that name checks out, my name checks out, we're going to connect.  And if you add a password, which you should, because if you add a password to this it breaks everything I'm going to talk about next, so do that, but the default is not to have a password.  Yeah.  So basically, if you say I'm New York and you're Cincinnati -- PPP -- it didn't allow you to connect.  So we can use that to brute force the node names ourselves.  So I wrote another, and I think this might be the last Nmap script.  I wrote another Nmap script to brute force that.  So now we have the node names for this system and we have the node name for the other system.  Now, there's an easier way, if you just steal the configuration file from one of the main frames you'll have them all anyways.  Right?  They all have to declare them all at the same time.  So we got the host name, we got the IP address, what I did was write an NJE library in Python in a program called injector.  What injector does is given the IP address and two host names and you can actually pass a password here and a command you want to execute, it will connect to the mainframe and execute that command as the other mainframe.  This is called -- so I'm just running a GES2 command here, that's all about you can run.  That's about what that looks like.  But I -- so -- that's amazing.  That's terrifying.  So put a password on it, please.
Now, that's the end of that stuff.  And one of the fun things when we, when we do this research, we encounter a lot of old guides that we have to use.  So all that stuff for NJE, and nothing special, I just read a couple of books that IBM has put out and wrote my tools.  It's not, it's not impossible to do.  So we use a lot of books in our research and we use a lot of stuff.  So I want everyone's hands to go up, everybody.  All your hands.  Everybody.  Now, if you were born, which help me out, because I will screw this up, if this book is older than you are, I want your hand to go down.  Okay?  So this first one 1992.  Okay.  A couple of hands went down.  Okay.  1988.  Okay.  A couple of hands went down.  1978.  Oh, wow!
[ Laughter ]
Wow!  Okay.  Still got some hands up, still got come hands up, good, good.  1964.  That's, oh, oh, a couple of people still left.  That's it.  We have nothing older than that.  So you can put your hands down.
[ Laughter ]
[ Applause ] I'm going to get Chad back up here, here's going to explain what that book meant and continue from here.
>> Thanks, Phil.
Yeah.  I was actually looking up, ah, an -- let me, a preassembler construct.  I was Googling it and the exact specification that I wanted came up in that PDF only so the instruction I was looking for and the way it works was in that document, which if you read the small print, was printed in like, on, you know, one of those big wide like green bar printers with the tractor feed, and then somebody took the time to scan it and put it on the Internet.
So um, I'm going to talk about exploit development.  And basically -- did that go blank?
>> Wrong button.
>> All right.
So I'm going to talk about exploit development for a second.  And basically what I'm going to talk about is, um, when I talk, when I had this conversation with Phil and wanted to know about who is doing the vulnerability scanning, anybody write exploits up real close.  He said no.  Not that he knew of.  And I did a lot of Googling, couldn't find anything.  And then there is this kind of, you know, mass herd knowledge of well, it is not even really possible.  So I hear statements like that and I'm probably like a lot of you, when I hear something like its not possible, I'm like, fuck, yeah.  Okay.  Media, right?  Yeah.  You know, like the rest of you.  So, so like okay.  I'm going to give this a shot.  But here's the deal, I can't mainframe, I spent a lot of time on mainframes, but I have never really gotten into this level of mainframes, right?  So I don't know, I don't know, JAS well, I don't know what PO1 is, or REX or Cobalt, and I heard about 3270 and NJE from Phil's talk right now.  So I have no idea what I'm doing basically.  But what I do know, and some of you probably fall into this category, what I do know is that mainframe is an amazing machine, runs all kinds of stuff and most of the stuff it runs are probably things that you know, probably know better than I, better than I do.
So some little known technologies, like this -- so what you're seeing here are all different types of technologies, right?  That run on a mainframe.  And there's at least one, if not more of these on here, that probably everybody in this room is some kind of expert at.  So I said, good, well I'm not going to start with all these things I don't really understand.  I'm going to start with one of the ones I do understand.  So I start -- so -- [clearing throat].  So first thing is first I had to learn about the architecture.  First question I get when I tell somebody we're talking about, well, what CPU is that.  It is it's on CPU.  It is Z architecture.  It is proprietor CPU that doesn't exist anywhere else, not in Telnet, not in Arm, it's its own thing.  So just to give you an example, this is a very, very, very brief, but, illustrative points about what's different about it.  So programs can run at one and three modes.  Right?  23, 31, or 64-bit modes.  Now, street sets are registers 48 registers on the CPU.  It's big NVM.  Three type of memory addressing.  Absolute memory, real memory, and virtual memory.  It is a big architecture.  Those that you know what that means, basically that you can store data and you can store instructions, kind of in the same memory space on and the CPU doesn't care.  It is just bytes.  It is what allows us to do pretty much like the core of exploits, buffer overflows, that kind of stuff, it's why that works.  So it doesn't work well on like microcontrollers or Harvard architectures, kind of a totally different beast.  It is kind of stack ways.  There is kind of a concept of stack.  And it has things you don't find on other systems.  So this idea of memory key protection.  So every four-K block of memory has a few bits that are the protection key on that memory.  Every instruction that gets executed also has, ah, protection key.  When, when the -- the CPU goes out and try to fetch the memory, tries to write the memory, compares these keys.  If a certain value is yielded on that comparison, it lets the fetch or write, or both happen.  If not, it doesn't.  It says invalid storage access, and that's it.  Shuts you down right there.  So that's at the CPU level.  So processes that get their address space can't write or read outside of those address spaces unless they have authority to do it.  That's a very different construct then what you see in a lot of stuff.
So where to start?  This is a massive system and it has tremendous numbers of differing technologies on it.  So like I said earlier, I was kind of at the time focusing on reverse engineering, buffer overflows, shellcode, that kind of stuff, I said, hey, it runs UNIX, UNIX is one of the main faces of the mainframe, there is the traditional MVS and the stuff that Phil was showing.  At UNIX services, which is like just another window into the mainframe, but it is compliant, it looks a lot like AIX.  If you know Linux, you can easily pick this up, or if you have just done UNIX, it's -- very much UNIX.
Ah, and C -- it compiles C, it compiles C++, but you know, based on C, where all good exploits begin, they're alive, I thought I will just start with C and start with UNIX.  It also has an assembly language that is entirely different from, ah, from the Intel uncallable language.  Different set of pneumonics.  There are thousands of instructions.  There is a CIST-based processor.  The C stands for complex.  Just as an example, there are 26 different possible instruction format for every instruction.  So you can have registered-mediate, register-register, register-memory, memory-to-memory, that sort of thing, in all the different bit modes.  Right?  23, 31, 64-bit.  So, so as an example like an add instruction, like a basic add instructions, there's 15 different kinds of add instructions.  There's a lot, there's a lot of -- a lot of options out there for assembly.
So I'm going to, and set it very, very, very -- narrow goal for this.  That was like what I really want to have, I want to write a vulnerable, vulnerable program, plausible, venerable program.  I want to write some shellcode that pops a shell and I want, I want to deliver that sort of like the hello world of, of shellcoding exploit development, buffer overflows.  And so the first thing I have to find out is can I actually execute strings as codes?  Right?  This is the basis of all good overflows.  Like, so I've got to buffer there, SC that's basically a bunch of hex bytes that represent valid mainframe instructions.  And if you do coding or exploit development, you'll recognize this stuff.  It is very common C stuff to test shellcode, which all it does is really create a, ah, function pointer to this string.  If this string is valid instructions and the CPU allows me to do this, this should work.
And it did.  So here it runs through, but I'll just skip to the end and show you, ah, what you've got here, right at the top their where it says dead beef, so the two instructions that I've created just basically take, clear out a register, take the dead beef hex string, put it in the register.  So those bytes right there, that say like -- CE1-dead beef and recognize below it, where it is O7 dead beef, those are the strings that I had in my buffer.  So this is the big deal.  Can I execute strings as code?  Yes.  I can.  I called Phil up, I was like, Phil, I can execute strings as code, I'm so excited.  This is like -- man.  Oh, this year.  Like this man! I was like, this is great.  This is like -- partway to the thing that we're talking about.
So the next thing is like, that's great, but this is obviously very staged.  If you write a program like that, ( laughter ) and it works great.  But really, you haven't done anything.  Um, so the next thing is like, well, can we overflow this buffer and can we do it in a meaningful way?  Right?  So worst case scenario is I get a denial of service.  I can overflow the buffer and maybe it crashes.  Best case scenario is I can overflow the buffer and maybe it lands something in some special register that I can control and then all the good stuff happens.
So this is the, this is the -- this is the sample program that I'm, that I'm going to be using for the rest of the demonstrations.  It's very symbol.  It is obviously vulnerable.  It uses a GAP string without any bounce checking.  Um, but there's been a million and one different types of, ah, exploits over the years that this very thing is at the core of.  Right?  This is, this is, this is how it starts.
So I take this, I take this code, and I compile it, and I'm going to run it in my debugger.  Say a word about the debugger for just a second.  So this, I don't know if you can see it up there, this is the DBX debugger.  This is the debugger that comes with the mainframe on UNIX system services.  It's a little bit analogous to GDB.  So I tell people when they ask me about this, I say, hey, if you love GDB and you know how to work in GDB because those of us who do kind of like it, then you will probably not like this or maybe hate it.
[ Laughter ]
It's, its very GDB-like, but it's just like enough to kind of make you angry about it.  Like it's got, it's got instructions that you -- oh, yeah.  I can do that in GDB-- no.  No.  To, to, to -- just kind of further make you angry, angry about it, um, DBX is a debugger that Oracle ships with some of its products.  Not the same debugger, but it has some of the same instructions.  So if you're Googling this and you're looking for like, something like, hey, how can I, ah, go in and edit memory?  What do I have to do to do that, and you find it on an Oracle site, and you enter this switch and this command, oh, great, no.  That one is not implemented, you can't do that one.  But it is enough.  It is enough.  As I show here, this is all used.  I -- my goal with this was only to use tools that were actually on the mainframe.  So I didn't write anything for it.  I didn't record anything to it.  I'm using the ones that come with it.  This is very simple and no magic here.  I just had a buffer that said hello word, I added to this and ran it in there.  On the bottom green box there, basically I can see where my string is stored in memory and I can start looking at the interesting bytes that come after it.  Say, hey.  Is there anything that is interesting.  And there is interesting things there.  Um, and oh, by the way, just, because I haven't mentioned it yet, so in a different to -- in addition to, ah, ah, different compiler, different operating system, different CPU, different instruction set, different debugger, it also, everything is in Ed stick.  It is a different character set.  It's not asking.  Right?  So that the end of this we're not going to get a 41, 41, 41, 41 in the IP.  Right?  It's going to be a C1, C1, but yeah.
So, so if you do any, anything you take between an Intel system and this, there has to be that ASCII to stick conversion, it is a whole different code page.  So this, taking that research further, the next step we could do when you're building this kind of stuff, it is like, okay.  Here's a valid buffer let's start sending it some extra characters and overflow it, see what happens.  This is usually where the magic happens.  This is the next major milestone.  I was like, if this works great.  If it doesn't -- this will be like a, like a five-minute DEF CON hallway talk.  Right?  Probably wouldn't get a free shot either.
So what happened?  Lots of crashing.  And since this debugger is really designed for people who are building programs, not people who are, you know, decompiling or disassembling programs, it failed and it failed in a way that was like really helpful.  Because I got a lot of these DDPI, DLEX, FSX, extra bad, 134 messages.  Which is super helpful.  What's below that, though, is storage access failed.  So if you remember when I was talking about memory key protection, storage access failed is saying to me, that you tried to access something from a, from a memory that, that your process doesn't have.  It might not be a valid memory address, but it doesn't matter because you don't have access to it.  I'm not going to tell you if it is valid or not valid, I'm just going to tell you, you can't have it.
What I found out later is that I was actually overwriting what, what would be kind of analogous to a base pointer, but there was nothing here when the program crashed that I could find that out.  So I did some more digging and went back to the manuals and, and, and -- when all of you, you start to get into mainframes, like I know all of you will, because I can tell, I can see it, ah, any time you research something you, about five manuals open that are about a thousand pages each.  I'm not exaggerating at all.  Because you want to find out, like something very simple -- but you have to read three different manuals.  So you go from configuration manual, you have a reference manual, you have a user's guide, and you have maybe like a setup manual and then maybe a red book.  Right?  And it took all of them to find out something easier, because -- not because they're of -- about, ah, us to, but because they are so comprehensive.  They are so comprehensive that if you want to do something simple, it's never easy.
So one day I'm going to start reading about like how does the function call work?  So using the Intel world, like how, house the, ah, the frame, the stack frame setup, right?  Does the caller set it up?  Does the caller set it up?  Who manages the base pointer?  Who manages the stack pointer?  Right, if you do this kind of work you know what I'm talking about it.  If you don't, just nod your head.  Like who does that and where is it?  Because it is a very standard calling convention.  So I did a little research on that and then I want back to my proof of concept and I figured out that what I needed to do was take one of these things I was overwriting and instead of overwriting that part of it I needed to actually send that back through and then I could keep on writing.  So it's kind of, it's not meant to be, but it kind of works like a stack canary.  Right?  Like -- a stack canary.  So if you compile a program on a Linux system that has stack canaries enabled and you do a buffer overflow and it overwrites that canary what happens, right?  The program crashes and it says, hey, you modified your memory you can't go on, but if you are able to put that very canary back in the right spot, you can continue exploiting that program, just like you would if it wasn't there.  So I did.
And what happened next, besides this screen going dark, was, there we go ah, was lo and behold, ah, I was able to not only continue execution, I had, the program crashed, but it crashed awesome.  So if you look at this, at the top there, the C1s are As, C2s are Bs.  So on and so forth.  There's my base pointer.  So if I took this buffer and I put it in that memory I got one of these.  So for those of you who do this out there, you know what this means, right?  This is my instruction pointer with a bunch of ASCII test or absent test in it. Those are Cs.  Right? So outstanding.  I put that there, right?  I made the computer now go to where it thinks the next instruction should be because of something that I just passed it as a string.
So I called Phil up.  And Phil, Phil, Phil.  Like, you got to believe this, like I got to send this out, like I'm going to tweet this and like the six people in the world who know what this means are going to be so excited.
[ Laughter ]
And Phil was really excited, he was like that is great, that is great, now go back and finish this.  I was like, okay.  So this is like the end of June.  By now we've been accepted our DEF CON talk and I would have been content, like that's pretty good like right there.  You know that's pretty good.  But I'm not happy taken that as like, you know, the end of this.
So next thing is I got to build a working, I got to build some shellcode, right?  I need something that actually does something.  So back to the drawing board.  Earn myself some assembly.  Started doing it in C, but as you know, when you compile it, the compiler does all kinds of unholy things to your code.  Moves stuff around.  And that doesn't work really well for shellcode.  You want relative addresses, relative jumps.  You went maybe, you want to control the nulls or that kind of stuff.  So I, so I wrote it all in assembly.  The assembly here is very similar to when you write assembly on an Intel platform, different pneumonics, but the same ideas about how things work.  You got your setting up your frame.  Find your exact function.  That, that bit right there, that red, that red arrow, that's important.  So the mainframe has, has something called you -- ah, assembly callable services.  So this is like in Linux where you can do a CIS call, you can get EXEC or some of those things that are like so ubiquitous that every process has access to them, you just got to find them in memory, right?  And Windows has it, too.  Like the WS32, like, some of these things are in, part of every process you can find them, like you want to open a port, you want to listen, you want to bind, that kind of stuff.  It has it, too.  So I'm going to EXEC and I'm going to pass it as string that is, you're in the constant section that has been SH.  All right?  So this is no shock.  I, I, once I got this working I got it to run, you can see I created, ah, the, you know, this, this is no magic here.  This is just me being able to actually write a program that runs.
So my program at the end, writes shell and it launches a shell.  Outstanding.  So and the steps are the same as, as those steps that you would use on any other platform, you assemble, link, execute.
All right.  So we got, we got a working shell.  Now, we got to convert it to shellcode.  And see if that works.  So I was able to take the debugger again and it does have a couple decent features in it, but when you create shellcode you basically are cutting out that portion of the binary that actually does the stuff.  Right?  You're not worrying about setting things up.  You're not worrying about tearing things done.  You just want that part of the binary that does this stuff.  And this stuff in this case is like launching a shell.  That's all I want.  I don't care about any of the forward, I don't care about any of the cleanup, I just want the stuff.
So back in the debugger I'm able to get the offsets that I want.  So that's my first instruction.  There's my last instruction.  I'm going to get those offsets and the link to the shellcode.  Print it out.  There's some idea of what it will look like when I format it.  And now I need to format it into a string that I can use in C or into assembly.  So I wrote a little, I wrote a little Python script that you can basically just pass you binary to, pass the beginning offset, pass the length, and it will kick you out some super nice formatted shellcode that you can just drop into C.  It will also kick out assembly code if you want to drop it into your assembly on the mainframe, and it will, if you want it to, create encoded code.  So if you're going to pass, ah, shellcode as a string it can't have any nulls, it can't have any move lines in it, so this, this simple little Python script will go through, find a valid character, X over everything and give you a good, ah, give you a good string with no nulls and no new lines.
So that's great.  So next thing was test this out.  So I took the, I took the shellcode, put it back in the same buffer, execute the program, and now I know not only can I, not only can I exercise the strings as instructions, but I can do something that actually matters.  Right?  I get, I got a shell now from nothing but shellcode.  And the last thing that I had to do with it is what I was just talking about which encode it and remove the bad characters.  So if you guys, Metasploit or whatever you use, MS code, or MS payload, or MS venom, whatever does this for you, this is doing it by hand.  I wrote a script to do it because none of that stuff exists.  Um, by the way, the Python that I'm talking about is Python on the mainframe.  So you can run Python on the mainframe, which is a godsend, that did help a great deal in a lot of this, automating a lot of this stuff.
So there I just generated the same buffer but it did it in assembly and it was the encoded version.  So it doesn't have any nulls, it doesn't have any new lines it.  Put it in this program which is a subprogram that goes through and decodes it and then adjustments to it.  This is how a lot of exploits, malware, that kind of stuff works.  Right?  There's a tiny little header that's the coder, or an encoder or an encryptor, it may be decodes or decrypts the payload and then it jumps to it and executes.  So it's like one stage, two stage, that's exactly what's here.
And then I'm going to take that now, tested it, compiled it, works great, convert that into shellcode, now I got my final shellcode.  Right?  So this is what I'm going to take, I'm going to package it altogether with the offsets.  I'm going to build a Python delivery vehicle that kind of concatenates everything.  I'm going to pipe it in.  We're going to see what happens.  It's exciting.  I don't know what's going to happen.
So this is the same vulnerable echo program that I had before, which is a little bit bigger buffer.  So I have a little room to move.  The shellcoded ended up being like 450 bytes, which isn't too bad for, for popping a shell.  I think I could have made it a little bit smaller, but 450 bytes is pretty reasonable.
This is the, this is just the high level of the Python script right here.  So your return address that I mentioned before that has to be there.  And oh, by the way, that address was the same every time.  I'm going to let that sink in for a second.  Okay?  Through reboots on different systems, okay?  The jump address of my buffer where, where the buffer gets memory.  A few other filler variables.  There's the same shellcode.  Going to put it altogether.  Pipe it out to, ah, standard output.  Let's see what happens.  So this is just, the program being executed show that it works.  Right.  So take a string through standard input, take it back to you.  Now, what I did in this, what I did with this is instead of, I, I took the echo binary and I made it a sued binary.  Right?  So that's the concept of suedes.  I made it a sued binary and I made it owned by IBM user, which is like the root user.  The 0ID0 user to see if not only could I execute it, but could I inherit those permissions -- authorities as well.  So what happens here, I'll blow it up just a little bit.  So first we've got my restricted user.  My restricted employee, who doesn't have access to anything.  He can't SU.  He can't cat, or super-secret file, because it is only owned and reasonable by, by the root user.  We'll run this on the command line.  And now we can SU, we can cat that file, and we're, root.
So from start to finish, success.
[ Applause ]
So I think, I think that was like a three-hour call to Phil.  I'm like Phil, you're not going to believe this, you're going to print this out and put it on your fridge and tell your friends about it.  I'm sure they care.  They, like this, this is exciting.  So this opened a whole number of doors.  Um, because we know that a lot of the traditional things that we know how to do work here.  And what we're up here doing is making it, is trying to make it so that, that those of you who want to get involved in this, or those of you who own company ass on a higher people to get involved in it.  Or have companies want to get people involved it don't have to do quite the learning curve.  We don't need to maybe make you a mainframe expert to kind of do this stuff.  You don't have to spend the nine months getting up to speed like I did on this, because I'm releasing, you know, tools and how-tos and facts and that kind of stuff, I blogged to get you the answers faster so you don't have to do that kind of research.  So what's next?  We got a huge pool of stuff we're just talking over lunch like we added like 30 more things to the list of what might happen next.  Right?  Things like NSF integration.  What we really need is a custom debugger/disassembler which I'm working on, if any of you have worked with like the radar, ah, framework, that is on my shortlist of making work on this system.  Ah, more privileged escalations.  Different kinds of deployment, modules and that sort of stuff.  If we peaked your interest -- ah, we have started a mailing list of which there are now two members.  Right?  Because Phil, you signed up.
>> Yep.
>> So there's both of us on there.
[ Laughter ]
, but honestly, like it's a public mailing list.  Anybody can sign up.  I encourage you to sign-up.  You can ask questions, you can ask them anonymously.  There are mailing lists like this, but they're all associated with the company.  This one's not.  So everything should sign-up for it.  We put all the code, the tools, the proofs of concept, the exact things that ran, that made this demo are out on the get hub right now.  Both of our blogs -- soldierportrait.org and bignamefalls.com have lots of good information.  Will continue to have lots of good information as we go down this journey.  But what we really need is you guys to add to the body of knowledge.  So with that, and just want to say thanks to DEF CON to let us talk about this.  Thanks for IBM for having this cool platform because it really is a hoot.  And we are really enjoying it.  Thanks again to Dominick, ah, for the work that you've done and everybody else, really, who's kind of allowed this to happen.  Because it needs to happen and, and we're having a ball with it.
So there's our contact info.  I appreciate it.  I know we're out of time, but we'll be around if you guys have any questions or, you can absolutely contact us, talk about it, because -- we'll talk about it forever.  So be, be, be warned.  All right?  Thank you very much.  Thanks for everybody who came and showed up.  Really appreciate it.
[ Applause ]