 Okay, 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, their database was in an AS 400 until, you know, 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. Thank you. Thanks for coming out. I will say, in follow-up to that, that is a great, that is absolutely the, that is absolutely what a great number of the people that we meet and talk about, and talk to about this kind of stuff have to say when we talk about these kind of things. And there's a lot of truth in it. This platform, the mainframe platform, specifically we're talking about IBM's system Z series platform, has been around for a long time. So it's absolutely what you would consider legacy. However, but it's very modern, right? The most recent incarnation of it is as badass 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. 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 think in yourself, holy shit, who's doing security research on mainframes? Show hands. All right, so both of you, excellent. Thank you very much for doing that. I appreciate it. I'll pay you afterwards. So this happened to me about 18 months ago. I had occasion in my business life and I'm not here on behalf of my employer, this is just a standard disclaimer. Research I'm doing in my free time. But I have 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 idea, well, who's doing the security research? Who's doing the stuff you do for Linux and Windows and all this kind of stuff? Who's doing it on mainframes? So I started 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, they were like, maybe two. One of them is right here. And so I reached out to Phil, my code speaker here, at the last Defconn and said, hey, we buy a beer and like to talk about the work you're doing. So he told me all about the work that he was doing and I said, this is fantastic stuff. But I had recently been very much involved in malware reversing, exploit development and that kind of stuff. I said, well, who's doing this kind of stuff, right? Who's fuzzing the binaries? Who's testing to see if there's buffer overflows? The basic meat and potatoes at this point of security vulnerabilities and that kind of stuff. I said, I don't know. I don't know that anybody is. He looked at me like, you are. I was like, well, I'm not. I mean, I'm not a mainframeer. I've worked around mainframes for 10 years, but it doesn't make me a mainframeer anymore than being in my garage makes me a car. So I said, well, I'll give it a shot. So I got a mainframe and I started doing some research on this stuff. And the first thing I did was I went out and googled and I said, what? What's already out there, right? What vulnerabilities are available? What publicly available proof of concepts are out there for vulnerabilities, exploit code, shell code, all this kind of stuff. And just by way of example, I went out from CVEDetails.com. So Windows in the last 10 years has had about 5,000 documented CVEs. No surprise there. Mac OS X about 2200. ZOS, which is the mainframe also known as MVS or used to be known as MVS. None. What? That can't be right. I know for a fact that there have been security vulnerabilities on the mainframe. Why aren't there publicly documented vulnerabilities proof of concepts, shell code, exploits, this kind of stuff? If you ask 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 exploits on the mainframe, 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 really. 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 IDM has a special relationship with their customers in 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. And so they know all of their customers. So by knowing all of their customers, they can release the, they can release security vulnerabilities when they find them and give them to their customers and say, hey, found a security vulnerability. It's pretty bad, right? They can rank it for you. And here's kind of the area. It's like a, maybe it's program based or network based or something like that. They give you like 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 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 are direct copies from kind of their policy around this vulnerability disclosure on this platform. And they, it is a benefit based on this document. They're not providing the vulnerability details is that both external attackers and internal personnel threats don't have access to that. Could put the enterprise it on due risk. So, you and I know this as security by obscurity, right? I mean that's basically what that is, right? Lots of, lots of vendors and people have tried this over the years and done this, differing degrees of success. So that's reason one. A second reason is, it's summed up in this slide. And so, this is the picture of the Ferrari that Def Con bought me for being a speaker. Thank you. And I think that mainframes, or businesses treat their mainframes much like this Ferrari. This is a million and a half dollar Ferrari. The guy that owns this, the person that owns this Ferrari is not taking it out and, you know, pulling a trailer with it. And they're not bringing it home and practicing their shade tree mechanic skills on it and cutting their teeth on it. They're not taking the engine apart 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 joy, right? And not only their pride 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 am I? And why am I here? Basically, I'm here as kind of a cult arms. I want to get people, I got excited about this because I felt the need. I felt it was a place to make a difference. Not just breaking something but making it better. And I want to do a call to arms to the people out there that own pen testing companies or enterprises that own mainframes and say, hey, if you're going to 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, not just go through and make sure everything is configured the best way possible. But the kind of pen testing that we've come to love and expect 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. I tell you what, there are not a lot of people out there that do this. Not very many at all as a matter of fact. But you can train them. It's very, very, very much a trainable skill. You ought to be talking to those engagements that you have about, hey, maybe the mainframe is out of scope but should it really be out of scope? I mean, here's some examples why maybe this should be in scope. You try to make it 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, like not taking no for an answer, this kind of stuff. Mostly I grew up though just by way of my background is Linux and Windows. I started doing mainframe 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'll let Phil tell you a little bit about himself. Thanks, Chad. So my name is Phil or you may know me as Soldier of Fortran. I run a couple of blogs about mainframe security. I really got interested in this stuff maybe a handful of years ago, working at a company. It wasn't until I got really my own mainframe that I started sort of messing around with it. I probably connected to some mainframes when I was messing around on X-25. Now it's back in my teens. But basically I got my own, started just doing things with it and saying, well, it's maybe not as good as people have said there. Thank you. Yeah, there you go. So I've 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 we sort of touched on this a little bit. But when people think mainframe, because it happened right before our talk, this is what they think of. If you can't see that, that is a dinosaur with a pay phone in its stomach. That's like two dead things. And that's what people think a mainframe is when we're talking about them. But the reality is it's about 90% of Fortune 100s are running these things. Anything that matters to you. 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? Anytime 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 kept 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 if 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 exploit development, shell code development on the platform. So on network, when you think about the mainframe, you're usually thinking about a screen that looks like this. This is a classic TN3270 green screen. It's horrible to write in. This, 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 set up. You can sort of see on the screen here, if I type kicks, it will take me to kicks, if I type TSO, it will take me to kicks. But anyways, it's TN3270. It's based on Telnet, yes, that Telnet. It's not really Telnet because it's not really interactive protocol, it's got these beautiful colors. But what happens is you submit, 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 it's not really happening in real time. Now, it's a buffer. So that whole thing, it's a buffer that's 1,920 bytes long and it wraps at the 80th column every single time, right? Each byte is either going to be a character, like you saw, or it could be a field identifying, that is an attribute that identifies that as the next character is going to be this color, or the next character is going to be locked or unlocked, or the next 1,000 characters are going to be locked or unlocked, and then it's going to say, are these characters visible in 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. In fact, one time I did a scan a couple years ago, and it identified a bunch of mainframes that I used to do this. 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 service is telling that, while technically true, it's not really, it's TN3270. The other challenge is IBM OS 390 is 20 years old and was discontinued 20 years ago, like it's gone. No one uses it anymore. But for some reason, that's the version, and 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'll actually tell you if you're doing SSL 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 TN32. I want the banners, I want the banners on the Internet. 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 the mainframe with these two scripts. You can do the TN3270 and then it'll 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 Kix transaction ID enumerator. Anybody know what Kix transactions are? So you know why this is cool. Enumerate Kix 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 allowed 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 that I know you can enumerate. So VTAM application IDs, which means nothing to almost everybody here except me. The other thing, oh, great. Yeah. I want to see him take a shot. Oh, damn. I also am going to. Anyways, VTAM macros, you saw me type like TSO Kix on the first thing. Well, you don't have to actually display those items. You can just type in whatever you want and if it's a macro, it'll work. So I wrote another one called 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 yeah, it's not security, right? So take a look at this. This is what a Kix transaction actually looks like and when you look at it, it's got a launch field. All right. Right here. This is 8 bytes long. You all right? Yeah. What happens if you ignore that? What happens if you ignore the 8 bytes of length? I don't know. I personally actually don't know because we've never done it but I assume all the apps break. The green screen becomes blue. Probably does. What if you have hidden fields down here? So are these guys doing a good job? All right. That's pretty good applause there. So new speakers, hard to get here. Congratulations. Here's Defcon. And now let's find out what happens to the Kix field. Thanks for making it sound so exciting. But no lie, if you actually do care about this stuff and you all should, trust me, this is some crazy shit. So. 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 end map emulator, it ignores them. It doesn't care if it's hidden, it'll show you. If it's not modifiable, it doesn't care. It'll 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 end map, it's the same thing. But now I can do a script that I wrote called setN3270. If you don't give it any arguments, it just creates a fake TSO login screen to trick you, you know, you trick users into hitting it, they're going to put in their user credentials. It can mirror a target mainframe so you connect it, does a bunch of stuff. And it'll also do proxy man in the middle and it'll also do SSL. So if you have an SSL mainframe it'll just because the clients don't really care. So this is what it looks like. 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. Thank you, somebody got it. So at least. So this is a fake TN3270 TSO login screen. This is what everybody uses when they log on to the mainframe for the most part. I'm going to log in his date, give it a password. When I hit enter it's going to show up in the bottom and it's going to kick the user off and say, actually we shut this mainframe down and you can't use it anymore. Now there's other tools out there. So Dominic White, are you here? Put your hand up if you're here. So he's actually giving a talk at DerbyCon. I recommend you see it. It's a great talk. He also has some tools. Once you see hidden fields and you want to manipulate them you can use his tool to do it which is based on a tool I wrote. So I don't know who owes who. So that's TN3270. You probably have heard of it if you work around mainframes. This is something most people have never heard of because no one talks about it. It's called network job entry. I heard about it maybe a handful of years ago when I was doing a walkthrough of a mainframe and someone told me they were working on a dev system not connected to any other system and they submitted a job and it created a user in the production environment. I was like what the hell is this? How is this possible? It's just NGE. I have 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 a secret handshake and after they've had that handshake they are trusted nodes and they can send jobs and command and control messages between them and they don't send passwords they don't send anything. So it kind of works like this. This is an actual configuration from our mainframe and so 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 DC 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 his mainframe. He would switch New York and watch DC and then change the IP address. It runs on port 175 or 2252 he uses hostname so those nodes which they call nodes in the configuration file but they call hostnames in the documentation I don't know why it runs over TCP IP 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 this is what happens when you do Nmap against an NGE port has no idea what it's talking about so I wrote another Nmap script which will tell us that we're connected to an NGE port on a mainframe and that it's open accepting connections the next thing we need is the actual hostname so what happens when they share that secret handshake is the mainframe says in New York, you're Washington DC 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 so basically if you say I'm New York and you're Cincinnati you can use that to brute force the node names ourselves so I wrote another I think this might be the last Nmap script I wrote another Nmap script to brute force that so now we've got the node names for this system we've got the node name for the other system now if there's an easier way if you just steal the configuration file from one of the mainframes you'll have them all anyways because they all have to declare them all at the same time so we've got the hostname we've got the IP address was write an NJE library in Python in a program called Injector what Injector does is given an IP address and the two host names and you can actually pass it a password here and a command you want to execute it'll connect to the mainframe and execute that command as the other mainframe this is called so I'm just running a jes2 command here but that's about what that looks like right 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 do this research is 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 impossible to do we have a lot of books in our research so I want everyone's hands to go up everybody all your hands everybody now if you were born if this book is older than you are I want your hand to go down so this first one 1992 couple of hands went down 1988 1978 oh whoa still got some hands up 1964 that's the right couple of people still left we have nothing older than that so you can put your hands down I'm going to chat back up here he's going to explain what this book meant and continue from there I was actually looking up mainframe assembler construct I was googling it 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 one of those big wide green bar printers with a tractor feed and then somebody took the time to scan it and put it on the internet so I'm going to talk about exploit development and basically did that go blank alright so I'll talk about exploit development for a second and basically what I'm going to talk about is when I had this conversation with Phil and wanted to know about who's in the vulnerability scanning anybody write exploits blah blah blah nothing new of I did a lot of googling and couldn't find anything and then there's this kind of like mass herd knowledge I hear statements like that and I hear something like it's not possible I'm like fuck yeah you know like the rest of you so I'm like okay I'm going to give this a shot but here's the deal I can't mainframe it's been a lot of time on mainframes but I've never really gotten into this level of mainframe right so I don't know I don't know JCL I don't know what PL1 is or REX or COBOL and I just 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 is and some of you probably fall into this category what I do know is an amazing machine runs all kinds of stuff and most of the stuff that it runs are probably things that you know better than I do so some little known technologies like this so what you're seeing here are all different types of technologies 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 things I do understand so first things first is I had to learn about the architecture first question I get when I tell somebody we're talking about is what CPU is that it's its own CPU it's a Z architecture it's a proprietary CPU that doesn't exist anywhere else it's not Intel, it's not ARM it's its own thing so just to give you an example this is a very brief but illustrative point about there's three modes 23, 31 or 64 bit modes there's three sets of registers 48 registers on the CPU it's big endian there's three types of memory addressing there's absolute memory, real memory and virtual memory it is a von Neumann architecture so those of you that know what that means basically that you can store data and you can store instructions kind of in the same memory space and the CPU doesn't care it's pretty much like the core of exploits, buffer overflows it's why that works so it doesn't work well on microcontrollers or hardware architectures it's a totally different beast it's kind of stack based there's kind of a concept of stack it has some things that you don't find on other systems so this idea of memory key protection so every 4k block of memory has a few bits that are the protection key on that memory every instruction that gets executed protection key when the CPU goes out and tries to fetch the memory tries to write the memory it 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 sends it 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 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 verse engineering, buffer overflow, shell code that kind of stuff I said hey it runs Unix, Unix is like one of the main faces of the main frame there's the traditional MVS and the stuff that Phil was showing and there's Unix system services which is basically just like another window into the main frame but it's POSIX compliant, 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 and C it compiles C Compiles C plus but you know based on C where all good exploits begin their lives I thought well I'll just start with C and I'll start with Unix it also has an assembly language that is entirely different from the Intel assembly language different set of mnemonics which stands for complex just as an example there are 26 different possible instruction formats for every instruction so you can have register to immediate register to register memory memory to memory that sort of thing in all the different bit modes you have 23, 31, 64 bit 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 of options out there for assembly so I'm going to I set a very, very, very narrow goal for this and that was like what I really want to have is I want to write a vulnerable program plausible, vulnerable program I want to write some shell code that pops a shell and I want to deliver that sort of like the hello world of shell coding exploit development buffer overflows and so the first thing I have to find out is can I actually execute strings as code right this is the basis of all good overflows so I've got a buffer there SC which is basically a bunch of hex bytes that represent valid main frame instructions and if you do shell coding or exploit development you'll recognize this stub it's a very common C stub to test shell code which all it does is really create a function pointer to this string the string is valid instructions and the CPU allows me to do this this should work so here it runs through but I'll just skip to the end and show you what you've got here right at the top where it says dead beef so the two instructions that I created basically just take clear out a register take the dead beef hack string put it in the register so those bytes right there that say like C01 dead beef and right below it where it's 0, 7 FE those are the strings that I had in my buffer so this is a big deal can I execute strings as code yes I can I call fill up I can execute strings as code this is like of this year I was like this is great part way to the thing that we were talking about so the next thing is like that's great but this is obviously very staged if you write a program like that and it works great but really you haven't done anything so the next thing is like well can we overflow this buffer and can we do it in a meaningful way best 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 and some special register that I can control and then all the good stuff happens so this is the this is the sample program that I'm going to be using for the rest of the demonstrations it's very simple it's obviously vulnerable it uses a get string without any bounce checking but there's been a million and one different types of exploits over the years that this very thing is at the core of this is how it starts so I take this I take this code and I compile it I'm going to run it in my debugger I say a word about the debugger for just a second so this I don't know if you can see it up there but this is a dbx debugger so this is a debugger that comes with the mainframe on Unix system services it is a little bit analogous to gdb so I tell people when they ask me about this I say hey 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 it's very gdb like but it's just like enough to make you angry about it it's got instructions that you say oh yeah I can do that gdb no no to kind of further make you angry about it dbx is a debugger that Oracle ships with some of its products this is not the same debugger you're googling this and you're looking for like you know something like hey how can I go in and edit memory what do I have to do to do that and you find it on an Oracle site and says you enter this switch and this command is like oh great go in now that one's not implemented you can't do that but it is enough it is enough as I show here this is all I used my goal with this was only to use tools I just had a buffer that said hello world and I catted it to this and I ran it in there and then 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 and say is there anything that's interesting there and there are interesting things there and oh by the way just because I haven't mentioned it yet so in addition to a different compiler different operating system bugger it also everything is in EBSDIC it's a different character set it's not ASCII so at the end of this we're not going to get a 41, 41, 41, 41 in EIP it's going to be a C1 so if you do anything you take between an Intel system and this there has to be that ASCII to EBSDIC conversion it's a whole different code page so this taking that research further kind of stuff it's like okay there's a valid buffer let's start sending it some extra characters and overflow it and see what happens this is usually where the magic happens and this is the next major milestone and I was like this works great if it doesn't this will be like a five minute DEF CON hallway talk probably won'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 building programs it failed and it failed in a way that was like really helpful because I got a lot of these DDPI DLE XFS X for bad 134 messages just super helpful what's below that those storage access failed so if you remember when I was talking about memory key protection storage access failed thing to me you tried to access something from a memory that your process doesn't have it might not be a valid memory address not valid I'm just going to tell you can't have it what I found out later is that I was actually overwriting 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 I went back to the manuals and when all of you start to get into mainframes like I know all of you will because I can tell I can see it anytime you research something you have about five manuals open that are about a thousand pages each do you want to find out something very simple but you have to read three different manuals configuration manual you have a reference manual you have a user's guide and you have maybe a setup manual and then maybe a red book and it takes all of them to find out something easier not because they're obtuse because they're so comprehensive they're so comprehensive that if you want to do something simple it's never easy so I went back and I started reading about how does the function call work do you think the Intel world does the the stack frame setup does the caller set it up does the call E set it up who manages the base pointer who manages the stack pointer if you do this kind of work you know what I'm talking about if you don't just nod your head like who does that and where is it because it's a very standard calling convention so I did a little research on that and then I went back to my proof of concept and I figured out what I needed to do and when I was doing 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 overwrite that canary what happens right program crashes and says hey you modified your memory can't go on it wasn't there so I did and what happened next beside the screen going dark was there we go was lo and behold I was able to not only continue execution but I had the program crashed but it crashed awesome if you look at this at the top there those C1's are A's, C2's are B's so on and so forth there's my base pointer so if I took this buffer and I put it in that memory 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 text in it those are C's right so that's outstanding I put that there 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 it's like fill up fill fill fill like you gotta believe this I'm gonna tweet this and the six people in the world who know what this means are gonna be so excited and fill is really excited it's like that's great that's great now go back and finish it this is like the end of June by now we've been accepted to our DefCon talk and I would have been content that's pretty good right there you know what that means pretty good but I'm not happy taking that as the end of this so next thing is I gotta build a working I gotta build some shell code I need something that actually does something so back to the drawing board learn myself some assembly all kinds of unholy things to your code move stuff around and that doesn't work really well for shell code you want relative addresses, relative jumps maybe you want to control the nulls or that kind of stuff so I wrote it all in assembly the assembly here is very similar to when you write assembly on an Intel platform different mnemonics but same ideas about how things work you've got your setting up your frame find your exact function that bit right there important so the mainframe has something called assembly callable services so this is like in linux where you can do assist call right you can get exe c or some of those things that are so ubiquitous that every process has access to them you just gotta find them in memory and windows has it too like the ws32 some of those things are in they're part of every process you can find them you want to open a port, you want to listen it has it too so I'm gonna exe c and I'm gonna pass it a string that is in the constant section that has been sh right so this is no shocker once I got this working I got it to run you can see I created this is no magic here this is just me being able to actually write a program that runs so my program at the end launches a shell name is those steps that you would use on any other platform assemble, link, execute alright so we got a working shell now we gotta convert it to shellcode and see if that works so I was able to take the debugger again and it does have a couple of 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 down you just want that part of the binary that does the stuff and the stuff in this case is like launching the 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 there's my first instruction this is my last instruction I'm gonna get those offsets and the length of 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 and see or into assembly so I wrote a little python script that you can basically just pass your 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 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 shellcode as a string, it can't have any nulls, it can't have any new lines in it so this simple little python script will go through, find a valid character X or everything and give you a good give you a good string with no nulls and no new lines so that's great so the next thing was test this out so I took the shellcode put it back in the same buffer execute the program now I know and not only can I execute strings as instructions but I can do something that actually matters right, I got a shell now from nothing but shellcode and the last thing I'm going to do with it is what I was just talking about which encode it and remove the bad character so if you guys use metasploit or whatever, use MSF encode or MS payload or MS venom or whatever does this for you this is doing it by hand, I wrote a script to do it because none of that stuff exists by the way the python that I'm talking about send 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 I did it in assembly and it was the encoded version so it doesn't have any nulls, doesn't have any new lines in it put it in this program which is a stub program that goes through and decodes it and then jumps to it, this is how a lot of exploits malware that kind of stuff works there's a tiny little header that's a decoder or an encoder or an encryptor it maybe decodes or decrypts the payload and then it jumps to it and executes one stage two sage, that's exactly what's here I'm going to take that now tested it, compiled it works great, convert that into shellcode now I've got my final shellcode so this is what I'm going to take I'm going to package it all together with the offsets, I'm going to build a python delivery vehicle that kind of concatenates everything, I'm going to pipe it in I'm 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 just a little bit bigger buffer so I have a little room to move the shellcode ended up being like 450 bytes which isn't too bad for popping a shell I think I could have made it a little bit smaller but 450 bytes is pretty reasonable this is just the high level of the python script right here so if you return address that I've mentioned before that has to be there and oh by the way that address was the same every time just going to let that sink in for a second through reboots on different systems okay the jump address of my buffer where the buffer gets stored in memory a few other filler variables there's the same shellcode going to put it all together, pipe it out to standard output I'll see what happens so this is just the program being executed so that it works 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 took the echo binary and I made it a suid binary right so there's a concept of suids I made it a suid binary I made it owned by IBM user which is like the root user the zero ID zero 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 you've got my restricted user my restricted employee who doesn't have access to anything you can't cat our super secret file because it's only owned and readable by the root user we'll run this on the command line and now we can su we can cat that file and your root so from start to finish success so I think that was a three hour call to fill 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 because I'm sure they care this is exciting so I've been a whole number of doors 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 those of you who want to get involved in this or those of you own companies who want to hire people get involved in it or have companies want to get people involved in it don't have to do quite the learning curve we don't need to maybe make you a mainframe expert to do this kind of stuff you don't have to spend the nine months on tools and how to's and facts and that kind of stuff I blog 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 were 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 slash disassembler which I'm working on if any of you have worked with like the radar framework that is on my short list of making work on this system more privileged escalations different kinds of deployment modules and that sort of stuff if we've piqued your interest we have started a mailing list of which there are now two members right because Phil you signed up so there's both of us on there but honestly 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 everybody should sign up for it we put all the code, the tools both of our blogs www.soldierfortran.org www.vegettingmansmalls.com have lots of good information we'll 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 I just want to say thanks to Defconn let's 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 Dominic 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 warned alright thank you very much thanks for everybody who came and showed up really appreciate it