 Hey, welcome folks. My name is Bart. I'll be talking about the legacy or AES-400. IBM ISystem, whatever you call it, the guys at IBM get I think pretty nice bonuses for changing the names every few years. I'll call it AES-400 for now on. Short introduction. I'm Google so you can check my LinkedIn profile, you can check my Twitter. I'm Polish national living in the Netherlands and whatever I present here is my personal views and not always or not necessarily those of my employee. So why should we care about legacy or AES-400? It's legacy, but it's hard to get rid of. Usually if you're working in a finance institution you'll see you have a lot of data, a lot of customer data, a lot of old programs and it's very difficult with all that history. For example if you have insurance policies or bank accounts it's very difficult to migrate it to new environments. So what you see very often is that you have new shiny front ends and at the very back end you have still mainframe systems running because they are just good for what they do. So many times we do care about the front ends, we don't care about the back ends and that leads to the situation that the back ends are somewhat less secure than the front ends. So to my surprise a lot of AES-400 systems are accessible even via internet, SMTP servers for example, or sometimes if you go to retailer you can see a 50 to 50 screen somewhere. You can really find them everywhere I mean all banks, insurance institutions, if you just Google that you'll find a lot of AES-400 systems. And there was a great talk at Black Hat back in 2006 by Shalom Carmel talking about security of AES-400 systems and to be honest with you not much change from IBM perspective. I haven't seen too much changes in new measures or new implementations. There are still like this 1990s mentality, we have a green screen and it's secure enough. There is not too much new developments from IBM itself. There is some patching but I would say not too much from my perspective. So if you want to start your, well, some joy with AES-400, you can either buy one. I recently bought one on eBay for just 60 bucks. I couldn't find that cheap one now but every now and then you can find a cheap AES-400 system just to start. Or you can just hack one. If you go to Shod and IO you'll find a lot of AES-400 systems open. It's just an example from last week. I was able to get access to an Italian coffee maker AES-400 which was just fully exposed to the internet with default password for one of the system profiles. You could just log in and enjoy the system. And funny enough, most of the systems exposed to the web are like version 5 released which is outdated for years. But then somehow they keep it. They just put it on the web and forget it. All right. So again, going to the security of the AES-400 systems, there was a talk from Shalom about the 523 security. I want to talk about something else. I want to focus on Java. Why? Because it comes together with the AES-400 client access. And it gives you pretty much a lot of access to the system. If you look at the IBM toolbox for Java, it allows for remote system API calls or usage of comments. So you can basically compile your programs in Java externally. You don't have to write your programs in CL or RPG on a system. So you can basically, yeah, try whatever you wish, run it via Java, use the toolbox for Java, connect and make use of the system remotely. It bypasses some of the 50 to 50 limitations like the limited capability. So you basically get access to the command line or to the CL commands. It also bypasses the I-Series navigator restrictions. For example, if you have set up an I-Series navigator that the users cannot log in via 50 to 50 or they cannot download files or they cannot access LDBC, yeah, you can bypass that with Java, with your own Java functions. Again, it gives you the flexibility of working with AES-400 outside the system. So no need to access any development tools on the box itself. If you decompile the JT-400 given by IBM, it's generally poorly written. It's quite inconsistent. So sometimes they use API calls, sometimes they just use silly CL commands in the background. So I found some bugs in that. So basically I had to circumvent it by writing my own functions. So really, I encourage you to decompile and check. And what's most important, somehow Java handles the authorization on the server side differently than you would expect from a usual program. I will give you a short demo about the visibility. So first we're going to connect to the system. Okay, so that user does not have access to the commands. I have four profiles, four hot chicks. And then on the system, okay, that one has sign off. So you cannot even log in. And many admins I talk to, they say, hey, if you have sign off, you cannot connect interactivity to the system. Bullshit. Okay, so this one gives you already some more rights. We have access to the command line. So you can see basically that's all the profiles I can see with that system, with that user profile. I'll also go to, okay, so these are the libraries. We can see it's mostly the system libraries. Okay, so now let's switch to Java tool. So I'll connect with, it takes a while. All right, connect it. So I'm going to connect the system. When we go now to work with objects, and we say we want to see all objects from Q-SYS. And they are user profiles. You can see already more profiles than via 50 to 50. So basically the Java handles the authorizations in a different way. And although you're not directly authorized to some object, you can still enumerate them for further use. Also, if you try to enumerate libraries, you will also see that there are some additional libraries which were not visible via 50 to 50. So as you already can see, there is a difference in authorization handling between Java and 50 to 50. Okay, if I connect with the sign of profile, I can also get access to the system, even though it's sign of. So don't believe your admins if they say sign of means you cannot use the profile to access the system. All right, but that's only visibility. But we want to do something more. Namely, we want to escalate the privileges. And say, in the old times, you had to have a prof, you had to have a program that was compiled with adopted authority, or you had to use the APIs and still compile on the system to be able to escalate privileges. Now we can use Java. The thing is that if you use group profiles, which is typical for every larger application, you usually have like one common profile, which is just for all the business accounts, so to say. And many times you add privileges by just having supplemental group profiles. That's the setup I've seen in most business applications, both banking and insurance applications. Not sure about wholesale retail applications, but probably it will be the same. Many times what you see is that the ownership for the user is set to group profile. For one simple reason, you don't want to have the situation that if one user leaves and their account is deleted, all the objects will belong to that user, because that will mean a lot of problems. So many times you see a default setup that the ownership is within the group profile and the scripts from business applications, they also create profiles with the ownership of the group profile. So if you use that setup and you have a lot of users, it's likely that you will also have some admin users. It's also likely that you will have some users that switch between departments and they might have some extra rights you would not expect. And it's also likely that you not closely monitor the profile handle of swapping, why it's quite challenging to monitor. So again, using Java, there is no need to create and compile a program on age 400, so you can just jump remotely, you can just use the profile handle, API's, grab the profile handle, switch to the profile and then repeat until you're happy with your access level. The setup of this system for the presentation is as follows, we have one common group which is DEF CON 23. We have one group for hot chicks and one group for fat boys. We have a couple of hot chicks and we have a couple of fat boys which are the admins on the system. So what we're going to do, sorry, we also have hot chicks 69, which is an old admin, so migrated from the fat boys group. So let's try to escalate the privileges and since I like one-click solutions, I made some extra implementation. So let me log in with, say, hot chick 01, perhaps just to show you that there is no fake hot chicks here. That's a hot chick 01, so it has only the group profile DEF CON 23 and supplemental group hot chicks, no special authorities and hot chick user profiles cannot create any other profiles. So if I just log in with any of the hot chicks like hot chick 03, if I do create user profile, I'll get your message on. So let's log in with perhaps the same hot chick 03. Sorry, we already connected. All right, connected. So let's generate the user lists we can see and that's the list of users we can actually jump to. Not really to this queue profiles. That's locked by the system but we can switch to some of the other profiles. Let me switch to the hot chick 69, which is the admin profile that moved to the hot chick group. Okay, so I just click in hot chick 69 and click in escalate privileges and as you can see I actually escalated privileges. So if I go now to the system and I'll search for the job. Let me escalate from hot chick 69 now or since I escalated let me generate the user list once again. So you can already see that I have access to a much longer list of users and as you could expect, we love this one. So let's just click once again and as you can see we escalated now to Qsik offer. Okay, that's not handy. Can you see the whole screen now or no? I'll just reach. So I just run a comment and now using the Qsik offer I created the user profile. You cannot just see the, there is one button run. So it's on the right side. So if I go now back to the system, you can see the newly created user profile. So that's something you can do with Java. You don't need to have any extra program. All right. Okay, what's also interesting, I don't have a demo for that, but surely you can try on your systems. By the way, this tool link is already available online at the end of the presentation. There will be a link. Basically hack the legacy.org and there you can find a link to GitHub where the tooling is uploaded. I'll make some updates in the coming weeks, but you can always contact me if you have any questions. For part two, the nested comment use, again, using Java gives you a lot of, you know, a lot of possible options. You can run CO comments. You can run JDBC queries. You can also use the system APIs. And what's most fun is you can combine all of those. So many times what you see is you use commercial programs to like block access to all the BC via using exit points. Or you use your own exit points to limit accessibility to some system functions. Usually there is a lot of focus for external connections. But if you connect via Java and if you try, say, run a query from the system, it will not detect that there is any outgoing traffic outside the system because it will be basically rerouted internally from the system to the GVM and then outside. So in that way you can circumvent, for example, your ODBC limitation on connections. I put here a small example of what you do. You run the well-known Q comment exec. In that you go to Q shell. So you insert Q shell comment. And then inside that you do DB2 and then select. And then you put our file just to get some output on your printer device. And in that way basically the DB2 will connect to local host. Meaning the exit point that will be triggered will check, okay, is there any external connection from a host to DB2? No, there isn't. There is only one on local host. So okay. Go. So in that way you can nest the comments. And again you can circumvent some of the exit points if they are poorly written. And to be honest I checked a number of exit points, sorry, exit program software. And like Rosalie, for example, if that's, if it's known for you. And this program many times have some unknown vulnerabilities like their case sensitive, for example, for JDBC. So I would say use the tools to try the nested comments use and then depending on what protection use for exit points you might be able to circumvent or test whether you can circumvent the exit points. Okay. The next, and I think the perhaps most interesting part is the password security and hash grabbing. That's something which I was not known before. There was one API offered by IBM called QSirip Pwadi to grab the hashes. It's used for synchronizing hashes between or passwords between the systems. Basically using that API but also using from version six the comment to dump user profile. You can get hashes from a particular user. Well, the output format was proprietary and it was never published. I contacted IBM and what they said IBM was the best and IBM does not document the format of QSirip Pwadi nor do we plan to document the output format, obviously. So after a long exchange of emails with Rochester, well, there was no deny from their site to publish it. But so no, no word on whether they will fix it or they will change anything. If you go to the API, depending on your QS password level system value, you may be able to retrieve different hashes from the system. If you look at the security guide from IBM, somehow they still don't enforce the usage of QS password level three. So if you use QS password level zero, one or two, you'll still be able to get the dash hashes or the LIM hashes. You have to be second and all object though. So yeah, take the lesson and escalate the privileges first. But then afterwards you can grab the hashes using the QSirip Pwadi. Basically, if you look at the IBM documentation, the only state, what you get as output is the encrypted user password data. That's it. I looked closer into that format. And actually what you can see is the first eight bytes is the desk, 56 bits password substitute. So you can look at RFC 2877 to see how it's actually created. Then the third position is LIM hash, which is quite a bit of a problem, but interesting for us. And then there is a bunch of other hashes you can get. So based on that format, what you can do, again, use Java, use the API and grab some hashes and we'll try to do it now. Let me just, for the sake of time saving, I'll just use the FAT Boy O3 or O2. It makes no difference. Normally we could just escalate the privileges to FAT Boy or to use a cover. Okay, so let's generate the user list. And let's say, let's pick one profile. For example, Nioh's profile. And let's say, let's say, let's say, let's see. Since that guy is sitting here in the audience, he will know whether he has to change the password afterward. And, again, one click solution, grab the hash. So here you can see all of the hashes I was talking about. And, unfortunately, I cannot move the screen, move the screen. So what I can do is just with that LM hash, I just save it. And I run my favorite John 400. So the password is Paris 2015. Just to make the proof. Paris 2015. And locked. I just finished the demo. All right. So again, we talked to IBM on that and IBM was reactive. So I hope if there is any IBM representatives here, perhaps you want to talk after the talk. Okay. So I also have some other research based, well, focusing on the Java isolation. There was some change. Okay. Now stop talking. Okay. No, I'm kidding. Go back. All right. You guys know the drill. What are we going to do? Shot. This is called shot the noob. He's a noob. It's tough to be a speaker at Defcon. Was it tough? Oh, no. He's like, I just wrote some shit up and you accepted it. Beginners luck. All right. Well, listen, anyway, we want to thank you for making it as a speaker. And we have our little tradition. So to Defcon. Now let's see you talk. Yeah. Thanks. I was already getting thirsty. When I came in here, he did not have an accent. My accent is getting better with every shot. So, right. So I still have some research going on. Looking at Java isolation. There is some changes in version seven. Basically, IBM decided to put the GVM elsewhere. So I run some tests with the same tooling on version seven release and I could see the same box. So there is not too much lessons learned on the Java isolation. So I still want to look inside and at the moment I'm also analyzing the server side of the GVM to look whether there is still possibility for getting more access to the system. What I also created is a common shell for Ace 400 via WebSphere. So if you happen to have unsecured IBM WebSphere admin console, you can upload that war file and you will get a common line allowing you for again running some comments on Ace 400 and for example creating an account or escalating the privileges. I'm also doing some work on MI security. So the assembler level and the isolation between the more virtual part of the system and the hardware layer, so to say. The last research is 50 to 50 via FTP where they found sometimes I'm pentesting environments that are behind the firewall. And so you only get access via FTP. Still, FTP does allow you for running CO comments and for some other fancy stuff. So what I was thinking would be handy to make a kind of 50 to 50 proxy or Java proxy via FTP so that you can also access firewall environments via the open FTP hall. So that's something I'm working on and probably in few months you'll see some tooling on the website. All right, just a short summary. Don't trust the 50 to 50 security measures only. So there is a lot of information on the hardening of, say, green screen. You can also look at the book of Shalom Carmel. But don't trust this measures only. Look also on Java and be skeptical of IBM red books. Many times what you see is like, yeah, they promote QPAS for the level of zero one and two. So take it with common sense and say after this presentation, look on whether you need to improve your security measures. And visit hackthelegacy.org. Yesterday I uploaded the latest version of the tool. It's GPO version three license. You're free to change it. The whole Java project, NetBeans project is included there so you can freely use it. I also included already compiled jar so you can just click and open and enjoy. All right, you can find me on Twitter and you can also approach me via the hackthelegacy.org website. And now it's time for questions. Can you repeat the question? The public authority is excluded. The only thing is that the group profile, if you use the ownership, if you use one common profile and if you use, I'll just show you. The question is what's the object authority of the profile I was swapping to? So the problem is if you use the ownership for the profile as a star group profile, it will still have access via the stop group profile. And as long as you don't have access to the profile, you can exclude on the list to the profile object, you're not able to mitigate it. No, it's not an emulator, it's port forwarding. The question was whether I'm running an emulator. It's just port forwarding to the Netherlands. Sorry? Okay, the question was whether Java is installed by default? Yes, it is. It's a standard, if you install client access, you get the JT400 jar you can use. And the problem is all the tooling used by IBM, so the whole client access pack, including iSeries navigator, is Java based. So it has to be enabled because otherwise you wouldn't be able to use iSeries navigator. I tried only Java, so. Okay, guys, if there are any other questions, I'm sorry? Okay, the question was what ports is Java using? There is a number of ports. There's like two or three ports used. So please refer to the IBM website. I don't know them by heart. There are like three ports starting with 2000 and then depending on whether you use SSL or not, there are also different ports. The question was where I found any mitigations for that kind of hacks. It's difficult. Either you have to have good object security with a lot of excludes. To be honest, if you have a legacy environment with this group profiles, usually you should just limit access to the Java ports. Because most of the times the regular users don't need to have access to iSeries navigator. So you can pretty much limit the access to 50 to 50. And then depending on whether you use the IBM tooling, which is like extra ports for this initial, for the signed on server, or you use external tooling, like just simple telnet 50 to 50, you could pretty much limit the ports to 992 for secure connection. Okay. I'm available at the whole conference. So if you have any questions, feel free to approach me. I'll be somewhere around here. And anyway, you can just send me an e-mail or Twitter or just look on the website. All right. Thanks a lot.