 Os yw'r gweithio gynllun 2003, dwi'n cael ei gwaith ymlaen i Sydney Ayrport, ond rydyn ni wedi cael ei gwaith ddraethau sydd gennym fflaenau EDS, ac eisiau'r ymdweithio'r cymdeithasau ymddangos i ddweud i'r cyffredin gyda'r ddweud eich cyfaint o'r ddweud ei fod yn y bryd, yw'n ddweud i'r troli, ac mae'n ddweud i'r ddweud. Mae'n dweud eich ddweud o'r ddweud o'r ddweud o'r ddweud eich ddweud, ond rydw i rhaid i ni gweld ei ddweud i'r ddataeth mewn hanes. Ond ond roedd iawn o fewnhyn o'r Cymru, mynd i yn rhi'n mynd i'w gweithio. I am hynny y dyfodol wedi gwneud hynny. Daeth y laptop am y cossfarnol i uneddiad sy'n ddweud. Rhyw hwn yn fawr y ddweud i'ch hanes eich dweud yn cysylltu i'r ddweud. Ac y gallwn yn ddigon ni'n sylfaenol i'r ddweud, rydym ni'n rhan o receiptio o'r cyfansiwys ysgolol, a'r newid ydydd yn rhoi�도 gyda cyfnodau cyfanc yr oedd gan helpu a gwybod ymylwyr a'r biwydden nhw, yw'r cyflolau i'r bai gellyts ac maen nhw'n bwnt i amser yng nghymru, ac ydych chi'n gwrs iawn i chi'n sefydlu ar gwrs maen a'r cyflwydau a'i gwybod i'r bai gwsiannol gynghig yng Nghymru. Weithio ydych chi'n gennym ni a yw'n gŵr? Dwi'n ddwy i'r gŵr Martin. I'm a security consultant and I work with a company called MWR Info Security in the UK. I originally approached this subject as a penetration tester as I was asked to actually examine some systems running some IBM networking technologies. Having then found some interesting results on the test, I decided to do a bit more research on it. I do not have a background in IBM computing, I've only been in this subject for about five or six months. From the time I've spent investigating these technologies, I've actually come to the conclusion that there's probably two different types of issues that we're looking at here. These technologies are old and there's probably a lot of administrators that have learned security issues with their systems over the years and might not necessarily have written them down. And there's also going to be vulnerabilities out there purely because people haven't looked at aspects of the technology in a new way, haven't applied modern techniques to looking at them. So who's the intended audience of this talk? Well I think each of the four categories here will actually get something out of this talk. Security managers, if all you know about is IP and your IP networks, you may find that there's some interesting things I'm going to talk about. It's always important to understand how your network works, not just how the bits that are using IP work. If you're a pen tester like me when I came to first investigate this subject, there's not a great deal of information out there on this kind of thing. And so hopefully you'll learn something about it today. If you're a network or a security architect, you can only design a secure network if you know where the risks arise from and hopefully you'll learn some of those today as well. And if you're a mainframe operator, my experience is that the guys running the mainframes don't necessarily talk too much to the network guys, don't talk too much to the desktop guys. And therefore this talk aims to combine a few of these different issues and hopefully if you work with mainframes day in, day out you may learn a couple of things. The only real background you need is a basic understanding of networking and some common network architectures. So what is IBM networking? I'm sure IBM have their own definition for what it is. For the purpose of this presentation, it's as follows. It's a collection of protocols and networking technologies that allow IBM mainframes, AS 400s and user terminals to communicate with each other. That's literally the premise that I've taken at IBM networking to be when actually coming up with this presentation. The main protocol we're going to be interested in is called Systems Network Architecture, SNA. However this is the IP age and IBM certainly has lots of support for IP and in today's modern networks there will be both IP and SNA. So why look at IBM networking? Well if you've got a mainframe within your business, within your organisation, it normally contains your most critical data. And if it contains critical data then it's pretty good to make sure it's secure. Aspects of this technology might be old but they're still deployed in a large number of high value environments. We're talking about finance here, retail, defence, government. And it's also good to look at protocols, compare different vulnerabilities across technologies, see how we can learn lessons across all these different technologies, look at issues in IP and see if they manifest themselves in SNA. Look at SNA and see if we can find anything that we can then take back to the world of IP and other protocols. And in general IBM networking is not mentioned in security textbooks. If you open up hacky exposed you won't find a great deal about it. So let's do some technical background into SNA and some of the other protocols and technologies that we're going to be attacking today. A brief history of SNA, originally announced back in 1974, although the actual dates in question are hotly disputed still, it was really intended as a way of unifying different IBM technologies. Before this date different systems used to communicate with each other in different ways. And so SNA was an attempt to really try and tie together the ways of accessing systems in a way to make IT simpler. Traditionally a master-slave model, it was the mainframe responsible for everything. Everything else took its lead from the mainframe. Everything had to be configured. You had to get the IT guys in to set everything up. There wasn't a case of just plugging a laptop in and starting working. The architecture was designed with physical links in mind that were semi-secure. We're talking about point-to-point links. We're talking about pieces of equipment that were locked away from users. There weren't simply network cables on desks that people could plug into. It was a long time before the widespread adoption of land technologies. In the 1980s came peer-to-peer networking, APPN. This in itself is a vast topic and something that I won't really be talking much about today. There's certainly an awful lot of potential security issues lurking in there. Now as the PC continued to develop, more responsibility was offloaded from traditional hardware components and moved on to the PC. And in today's modern networks IP and SNA exist alongside each other in a number of different ways. What will come to find out is that the integration of these old technologies with the new ways of working is one reason why certain vulnerabilities can actually be exposed. So any talk of a protocol won't be complete without the OSI model. There it is. And if we look at SNA, it pretty much lines up against the components of that. Again we could stand there and debate exactly how each of those layers correlates with each other but we haven't really got time to talk about that today. Now if you're used to IP, the whole concept of an SNA session may come as a little bit of a shock to start with. If you're used to IBM networking then you might be used to diagrams like this. On the right hand side we have the mainframe. On the far right hand side of the mainframe we have the application subsystems that sit within it. Job entry system is jazz and time sharing option is TSO. And front-ending this we have VTAN, virtual telecommunications access method. This is the way that the application subsystems will actually interact with the network. And VTAN will also be responsible for controlling our network protocols. On the left hand side we have a user terminal. In today's modern world this will be a PC. Back in the old days this could be some form of cluster controller. A couple of items of terminology just to take care of first. You see PU and LU. Now these stand for physical unit and logical unit. There isn't really time to go into full detail of what exactly these terms mean but a quick overview of them is that a physical unit is essentially a physical piece of kit. It's a piece of hardware that is capable of communicating over the network. A logical unit then is more of an application running on that system. The old applications that used to run on the old green screen terminals essentially you can consider one of those as a logical unit. You can however have multiple logical units within a physical unit and that's where things start to get a bit complicated. So we're not going to go into this in too much detail. Now standing in front of the main frame is what's known as a front end processor. It used to be a piece of dedicated hardware that used to handle network path control. Used to be responsible for routing within the SNA environment. Now when we establish an SNA communication there are three different sessions that are going to be established. The first of these is going to be what's known as the SSCP to PU session. This is the system services control point talking to the physical unit. This is responsible for actually forming a network route to the physical device making sure that it's up. The next session is the SSCP to LU session. This is essentially where VTAM presents the user with the log on screen. And that session is responsible for passing the user credentials back across to the main frame. VTAM is then responsible for talking to the individual application subsystems to log you on to the application that you actually want access to. Assuming a successful authentication we then have a logical unit setup. In this case we have a session actually established to TSO within the main frame. Now all of these sessions it will exist at the same time. This is slightly different to the world of IP. So let's look at some basic architectures and network setups that we could find employing SNA. The first one of these is a basic SNA network that we might have found back in the 1980s. This is a very simplified version but we have the main frame on the right hand side. We have our user terminals on the left hand side. Essentially we used to take our terminals and plug them into the cluster controller node. This usually used to be via a piece of coax. Our cluster controller node was then connected to our communications controller node. Our front end processor sat in front of the main frame. And this used to be via a point to point link. Usually SDLC protocol was used at the link layer to manage this communication. And as I mentioned we need to define all our nodes within the main frame, within VTAN before they're going to work. Once IP came along people wanted to run SNA across their IP networks. And they had to come up with some novel ideas in order to do this. One of the first ideas to be for people to use was what's known as an SNA gateway. This is basically a device that is capable of translating IP traffic and turning it into SNA. The users of our applications run basically a client application on their PC. This will then communicate with the SNA gateway. It's usually a proprietary TCP protocol. The most common example is Microsoft's SNA server, now known as host integration server. Microsoft's SNA gateway, if you have a look at it out the box, has a number of interesting features. Or at least I think that's what Microsoft designed them as anyway. Where you can actually pull off the configuration of that SNA gateway without providing any authentication. If you can compromise the SNA gateway there are various ways that you may be able to then start attacking the main frame. But again these are subjects for another day. And in our SNA gateway example we still then have SNA traffic passing from the gateway to the main frame. Another way of actually communicating with the main frame using SNA is actually to bridge our traffic across our local network. Back in the days of token ring networks this could actually be done using LLC at the link layer. Now this used to run into some problems because if we started having one link somewhere on our network we were basically sending all the link layer control traffic across that one link and all our user data was not getting the bandwidth that it needed. If we actually did source root bridging we could actually use the RIF flag associated with token ring to actually root the traffic between rings on the network. However this again imposed the limit. Seven hops is possible to fit into the RIF field. So with all these problems we needed a better solution. In the 90s one was devised. It's known as data link switching. In this instance all our users actually ran SNA over LLC on their local subnet. Now this was bridged to a DLSW router. For example each remote office or each floor in an office could have their own network bridge and their own DLSW router. DLSW could then be used to encapsulate the SNA data in IP and actually transfer it across an IP network. Either that will be an internal one or if we are being particularly foolish we could do that across the internet. However as network administrators like to save time and effort what they like to do is actually set up the router in front of the main frame in what's known as promiscuous mode and we'll talk about this in a little bit more detail. What this essentially allows you to do is connect up new offices to the DLSW infrastructure and not have to change the configuration of the router. And of course there's IP. IBM mainframes have had IP support for a long time now. This is again one method we can actually use to actually talk to the mainframe. Users will typically run a terminal emulation application. We can actually connect our router in front of the mainframe directly to the mainframe using some kind of channel attachment. We can then run IP protocols across our network. TM3270 which is essentially telnet with formatting. We could either run FTP we could run SSH we can run any IP services at the mainframe support. But let's move back to talk about DLSW. And let's look at it in a bit more detail. It was originally designed by IBM and they released details of it in 1993 in an RFC. It's essentially used for packet switching. It can be used to encapsulate SNA on native net BIOS frames in the IP protocol. And also provides local termination at the link layer to actually reduce our bandwidth utilization. A number of improvements were made to the protocol and again these were released in 1995. Cisco then took the protocol and actually added some of their own extensions to it named it DLSW plus. These extensions essentially formed version two of the protocol and this was documented in 1997 in a further RFC. And version two of the protocol is the one that's most widely used today. As you can see by the dates this isn't modern technology but it's still being used by a large number of organizations in a large number of high value situations. So let's take a quick look at a DLSW packet. Essentially it's made up of two portions, the DLSW header and the DLSW data. As you can see here there's a basic ethereal screenshot showing a very simple DLSW packet. If you can make it out you might see the remote DLC value, the remote DLC PID. These are actually used to track DLSW circuits which we'll come on to talk about in a little bit. Also in the header we can see what type of packet this is. This seems to be a capabilities exchange packet and again we'll talk about this in a little bit more detail. Now I haven't got much time to talk about the DLSW protocol in much detail. If you look on the presentation on your DEFCON CD you'll actually find a few more slides talking about the format of the data that's actually used within the protocol. You can also go back to the RFCs and have a look that I'll provide you with some more information. So I talked about DLSW circuits so let's look at what those are and how they're established. When we're initially setting up the DLSW communication we'll actually do what's known as a capability exchange. I'll actually come on to look at that in more detail in a little while. But once you've established capabilities or you've exchanged capabilities you essentially have a TCP connection between DLSW capable routers. On top of this TCP connection we can then establish circuits. These circuits are essentially SNA sessions that are actually being used to communicate between individual hosts in the mainframe. Now multiple circuits can exist over that TCP connection and that TCP connection won't drop even if there isn't an active circuit. So let's just look briefly at the actual establishment of the DLSW circuit. The diagram here we have a user terminal on the left and the mainframe on the right. And in between them we have two DLSW capable routers. So the first thing that happens is our user terminal sends out what's normally an LLC test frame. It's essentially a ping at the actual link layer. Upon receiving this packet the first router will actually look in its cache to see whether it's had any traffic from this host before. If it hasn't it will then send out what's known as a can you reach message to each DLSW router it's aware of. The aim of this is to try and locate the DLSW router through which it communicates to the intended destination. If the MAC address isn't known by our remote router it's then sent out onto its local network bridge. And if it hits its target it will get a response back. The router will then send an icon reach packet back to the original router saying I know where this guy is and you can actually use me to establish a circuit. Then that packet is sent back to the user. So essentially in this process we establish what's known as a DLSW circuit. The remainder of the SNA communication can now pass over this circuit so we can encapsulate our SNA traffic in IP. And we can terminate this circuit as well. It's usually 15 minutes after the last activity that this circuit will be torn down. We can also send a whole data link packet if we want to tear down this immediately. So now given a brief overview of some of the protocols we're going to be attacking. Let's look at some ways we can actually attack our environments and try and gain access to some systems. Let's first look at the objectives. Why is an attacker going to actually be interested in these environments? Well first of all the data on the mainframe. It will usually be finance data, intelligence data, data that's of importance to competitors. Processing power of the mainframe. There's an awful lot of processing there and wouldn't be cool to run our own processes on it. And let's face it, if we can own an IBM mainframe then that's pretty cool. So what are we actually going to need to gain access to the mainframe? We're either going to need access to a log on service and some valid credentials. Or we're going to need to find a vulnerability or poor configuration in the mainframe. Now the easiest one of those is actually by gaining access to a log in service and finding some credentials. That way we don't have to discover any zero days, we don't have to start writing some ninja code to actually execute arbitrary code on the host. Let's just find some credentials and log on. So we've talked about DLSW environments and as any attacker will know the best thing to do first is to find out some information about the environment you're within. If we look at all the textbooks telling us how to set up a DLSW environment they'll tell us at least one of the routers is going to be in what's known as promiscuous mode. In none of the documentation does it tell us how dangerous promiscuous mode really could be. So let's look at what we can actually learn from a promiscuous mode router. And to learn something from the router we need to do what's known as a capability exchange. Here are we at the bottom as router A and there's router B or promiscuous mode router that we want to exchange capabilities with. So the first thing we do is open a TCP communication on port 2065. If the route is in promiscuous mode and supports the DLSW it will immediately open a TCP connection back to us. Once that connection has been established we can then send a request packet up to the target router containing a list of our capabilities. If the target router likes our capabilities it will send back a response saying yeah I can talk to you. The router will then send you its capabilities. And at which point if we send a response back saying yes I support those capabilities we've exchanged capabilities and are actually able to communicate with the remote router using DLSW. Now if we're using version 1 of the protocol we find that both of these TCP sessions usually stay connected. However with version 2 one of these connections is usually torn down. So as I've said once capabilities have been exchanged we can then start initialising some DLSW circuits. But let's not get ahead of ourselves. The information that was actually given to us in the capability exchange is pretty useful. What it will return to us potentially is MAC addresses of systems that it's been configured to communicate with. It will return as net BIOS names of systems that it's been set up to communicate with. It will actually return as the version string of the router. It will also let us know if there's any service access point filtering going on. Maybe the remote router is filtering IPX maybe it's filtering net BIOS. And in the capability exchange the router will actually tell us this information. Additionally it will also provide us information about whether it supports multicasting for DLSW. Whether it has support for peer groups. It also tells us information about pacing and the amount of data that it can accept. So how can we obtain this capability exchange information? On the DEFCON CD there's a small python script that you can use to obtain this information. You'll need to use the bitvector package to actually run it. You've actually written it as extension to Skapey. The reason being that eventually I'm going to release some DLSW classes which means you can easily build your own DLSW packets. At the moment the tool actually has some static arrays in them containing the DLSW data. But once I've got a bit further with the DLSW classes then I'll certainly release them and then you'll be able to use this tool as a true extension to Skapey. Alternatively if you have a DLSW router you can simply use this to start communicating with the system. The only problem is you can't control as many of the parameters as you can do if you use your own packet definitions. So here's a quick look at some sample output from the tool. As we can see it returns us some information concerning MAC addresses, net bias information. It also returns the vendor of the device which we can see in this case is Cisco. If you find some DLSW routers out there I'd certainly encourage having a play around with the tool and seeing what it can tell you. So now we've found out some information and our next objective is to actually reach the mainframe. It might not be running on IP stacks so if we're sat out on the internet how can we actually access it? In our security model if an attacker actually gains access to our logon screen have they breached our security model? As we've just discussed we now have a DLSW tunnel that we can use because of a promiscuous mode router. That means we have a method of encapsulating our SNA data in IP meaning we can communicate across an IP network which means if you've placed your DLSW router on the internet maybe someone can get to your mainframe from the internet now. So if we want to actually communicate using SNA with the mainframe we need to know a little bit about how an SNA session is set up and we'll specifically talk about how that is set up at the link wire. Now the first information we're going to need is the MAC address of the mainframe. Once we know that we can send our LLC test frame. If we get the MAC address right it will respond back to us. We can then send an LLC XID frame and exchange identifier packet. Again all we need for this packet is a MAC address of the mainframe. Now we get to the stage where we need to actually exchange an XID. This is actually used so the mainframe can tell that we actually configured to use its services. And quite fortunately if we get the information in our SNA XID packet wrong the mainframe can actually return us some information that tells us how we've got it wrong. It can also tell us some information about how we then need to change our communication to talk to it properly. Now assuming we get this information right the mainframe will return what's known as a SAVME packet. Set asynchronous balanced mode. We can then acknowledge this packet and the mainframe then proceeds to send and activate physical unit packet. And this is essentially how an SNA session is set up at the link wire. And if you remember back to the different sessions this is the first session we talked about when communicating with the mainframe. We can now move on to the SSCP to LU communication. So how can we find out some of this information that we need to actually start talking to the mainframe? Well for a start the capabilities exchange can actually provide us with a lot of information. In our LLC packet we obviously need some service access point types. And the capabilities exchange will tell us which ones are supported by the remote system. If we're lucky it'll also tell us the MAC address of the mainframe. If not then more often than not the MAC address will actually be in a token ring format. And so the first four digits will be 40000. If we then need to perform a brute force attack to find the MAC address this actually reduces our actual scope of brute forcing. We talked about the mainframe returning information in the XID exchange that can be of use to us. If you look here at this ether real capture we can actually see a control vectors used to tell us where in our SNA XID packet we made our mistake. It can also return information such as the control point name, the network ID and the node ID. Again we can use these to start to put together our SNA XID. So just to summarize what we're going to need to communicate with the mainframe. We're going to need the MAC address and there's lots of different ways we can get that information. Again we might need a CP name and a network ID. Again there are a number of ways we can start to obtain this information. And when we talk about social engineering is this the kind of information that's protected in your environment? Usually it's not. So if we're going to start talking SNA we need some tools to actually start communicating. Now there are some commercial tools out there that enable us to do this. PCOM and RUMBER are two examples. We can also use some homemade scripts and this is a game where a tool like Scapey comes in very handy. If we can come up with some SNA and some DLSW packet definitions we can actually start putting together some useful payloads to actually start testing our systems. So now we have all the information we need to actually get a log on screen up on our mainframe. So we've achieved half of our objective. Even if our mainframe is not running an IP interface thanks to DLSW and thanks to some of the information that's returning the capabilities exchange we can actually bring up the log on screen. Now all that we need is some log on credentials. So we need to find a way of getting them. Well firstly let's talk about memory padding issues. These are vulnerabilities that have been around for a long time now. Ethernet frame padding. Etherleak in Windows network card drivers. Microsoft Windows net bias information leakage. Even recently there was an information disclosure in MySQL and onmas handshake. And this all arises from reading from uninitialised memory when we're padding packets. And this is very useful when we're looking at SNA traffic. So let's look at SNA leak. Usually in our network environment packets on the local network are bridged up to the DLSW router. So if we have Etherleak on that router we can actually start using some of the older vulnerabilities to start getting some information out. So if our routers haven't been patched what we'll find is they actually leak information from other DLSW circuits that have been established through them. You might just find someone's password in your packet. So let's look at why that happens. The reason is that SNA packets can be less than the minimum Ethernet frame size which is 46 bytes. If we take the LLC header, the transmission header and request response headers which are part of the SNA packet they only come to 27 bytes. If we look at an instruction within SNA for example start data transfer this is only a single byte instruction. So the rest of that Ethernet frame core and back to us will be padded. If we can generate lots of small packets from the target we can start to get lots of leaked data core and back to us. Again, escapee is a brilliant tool for doing this, for setting up some little scripts to basically start communications with the main frame. And then to get some packets back that have padding involved. So what you need to do is write some SNA classes. I may well be releasing some of them if you speak to me nicely afterwards I may even be able to give you a copy of some of them. And one thing that's vitally important when you're talking about communicating with the main frame. Most of the data will be EBSIDIC encoded. So if you start seeing data that looks a little bit strange try decoding it you might actually find something useful in there. So we're still on the quest for our login credentials. What happens if the router is patched against the Ethernet frame padding vulnerabilities? Well if we can actually gain access to the router we might just be able to sniff the traffic. At this point it's worth noting that SNA actually has support for encryption built into it natively. And it's had that for a long time. However speaking to people that have written SNA stacks they certainly haven't actually implemented this feature of the protocol. Therefore a large number of people running SNA will be doing so in clear text. So if we can find a way of sniffing traffic we're going to be able to get hold of the credentials that we need. But don't complicate things. If the routers that the traffic is passing through are vulnerable then take advantage. When you're examining the routers if you see ports 2065 and 2067 the router more than likely is actually running DLSW. And in the course of the research I've been doing I've actually found out some interesting little things to do with DLSW on some common routers. And let's remember that in our mainframe environment it's usually high availability. Even small amounts of downtime can have huge financial implications. An investigating actually discovered one denial of service that will actually need investigating further. Not actually had time to come up with a full advisory for this and simply haven't had the time to investigate exactly why this is being caused. But if we're able to exchange capabilities with a Cisco router and pass it some parameters it's not expecting we can actually get that router to reload. Now if we actually look in the DLSW packets there's actually a parameter called peer type. And if we start playing around with that value then we start finding these conditions actually occur. I'll certainly be releasing full details of this vulnerability but I'll certainly be passing those to Cisco first. So let's find out some other ways of actually getting hold of these logon credentials. I've come up with two scenarios. One of which is a local attack. As we'll see it's very dependent on how the architecture is set up. This is very common on internal networks that are using SNA and then a DLSW environment to pass that traffic across an IP network. So our assumption obviously is that our SNA traffic is using LLC2 at the link layer on our local subnet. This attack will actually now allow us to intercept that network traffic if the systems communicating with it are plugged into the same switch. Now initially that might not sound too great after all we're all used to sniffing traffic on a local subnet. But when we're talking about SNA there are a few little things we need to think about first. And let's look at the basic network setup that we're talking about here. On the left hand side we can see our user workstation that's communicating using LLC2 up to the DLSW router. Then the data is encapsulated as that goes across the IP network. And we're sat on the same LAN as them. So we need to be able to intercept that LLC traffic. If there's other ways of attacking the switch that we're plugged into then by all means use them. Cam table overflows or any other vulnerabilities that enable us to sniff traffic are perfectly valid. If the workstation itself is not well protected again we can attack that. Always take the easiest path. However if these aren't possible we can't revert to our spoofing the same way we would do if we were talking about IP. So what about using port stealing? That might be one way of getting this to work. But if you're not familiar with port stealing it was essentially a technique that was demonstrated a few years ago when it was back and essentially involved stealing a target MAC address on a switch. Now obviously if we steal the target's MAC address and do nothing else it's a pretty effective denial of service. But what we don't want to do is actually cause a denial of service. We want to keep passing data to that target system so we can sniff it. Port stealing was basically documented as a way that we could use to bypass static art. Potentially it could work in this scenario. The problem is the way these attacks have been described. We actually need IP to be running on our target system because we need to use a spoofed art packet to give the target its port back on the switch. In this scenario therefore there's only going to be a half-duplex attack possible i.e. from the traffic passing from the mainframe back to our target workstation because we're going to assume that that is running an IP stack. The likelihood is that the mainframe is not going to be, it will not have an IP address that's associated with its MAC address and therefore we can't use port stealing to get the traffic passing from the user to the mainframe and after all it's in this direction which the user credentials will be passing. So this is where DLSW can help us. If we actually set up a system on the local subnet with the MAC address of the mainframe we're trying to intercept traffic to we can then use our laptop to establish a DLSW connection to the remote DLSW router. In this way we're essentially tunneling the LLC traffic over IP and we're avoiding the problems that would otherwise be associated with stealing the port on the switch. As I've said all the data we receive we encapsulate and pass over to the remote router. We can now sit on that local subnet and intercept all the credentials that are passing between our target and the mainframe. So that's essentially what our diagram looks like now. The traffic has been redirected to us and then we're passing that back across as DLSW traffic to our remote router. But that's a local attack. Let's look at doing this remotely because that would be really cool. Now this attack is dependent on the architecture. It depends on the way that the DLSW systems have actually been configured. But if we find that the people setting up our DLSW network have not done it correctly they may will have put more than one router into promiscuous mode. Our DLSW environment will still operate in this scenario. However we have exposed ourselves to an excessive amount of risk. So in this attack we're still assuming that our SNA traffic is actually using DLSW to traverse the IP network. We also need to find two routers that are in promiscuous mode. One in front of the mainframe and one in front of our user. So let's look at how things look beforehand. We can see the user again on their local subnet and a promiscuous mode router at either end of the IP network. We're then connected to that same IP network whether it be a WAN or whether it be across the internet. Again if there's an easier way of getting hold of the data let's use it. If we're set directly between those routers whether IP traffic is passing let's just sniff that traffic. But if not if we're off somewhere else where we can't actually sniff that data what we can do is actually open a DLSW connection to the router at either end. Now to do this our IP address must either be defined in the DLSW configuration or as I've mentioned both routers must be in promiscuous mode. Now if a circuit has already been established between the two hosts we want to intercept traffic for then this technique won't work. However as mentioned previously the circuit will drop after about 15 minutes. So what do we actually need to do to actually affect this attack? Well first of all we need to exchange capabilities with routers at either end of this DLSW tunnel that we're attacking. If we are actually the only one who's advertising MAC addresses in our capabilities exchange then we will automatically be intercepting the data and the reason is this. If a DLSW router in the capabilities exchange sees a MAC address that is configured if a request comes in to send data to that MAC address the can you reach packet that we talked about before will only be sent to the system who has advertised that MAC address in its capabilities. I mean if our network administrators have not actually defined the MAC address of their mainframe in their DLSW router we can simply advertise that MAC address in our capabilities exchange and then when the can you reach packet is passed on to the DLSW environment that packet will only come to us. Meaning that we can then send back an icon reach packet and essentially establish a DLSW circuit. In more complicated environments where we're using peer groups there's also possibilities that we could become a new border peer. Now this is very architecture dependent and there really isn't time to go into this today. Also something to be aware of is that you can actually send gratuitous icon reach packets. The routers don't actually think to themselves did I actually send the can you reach packet and by sending icon reach packet you will actually enter that MAC address into its cache. This won't actually override the capability exchange information but it's actually telling the router that we actually know where that MAC address is. So let's look at a quick diagram of how this looks now. As we can see we've advertised the mainframe's MAC address in our capabilities exchange with the promiscuous mode router at the user's end. We can then simply establish another DLSW tunnel with the promiscuous mode router in front of the mainframe. We can then establish another DLSW circuit with that router. Now the traffic will be re-routed down the two legs of our DLSW tunnels rather than across the original path meaning that we can intercept all the traffic. Just once like caveat to this, if the administrators have actually defined the mainframe's MAC address in the configuration on the router essentially we come down to a race condition. The promiscuous mode router in front of the user terminal will send the can you reach packet to both us and to the legitimate system but if we can get our icon reach packet back first we're the one with which the DLSW circuit will be established and again the attack can proceed. So essentially now we've come up with a number of ways that we can actually achieve our objectives. We've actually been able to communicate with the mainframe, access a logon service and we've found some ways of being able to gain access to login credentials. I'm sure you can imagine how dangerous that is if we've actually intercepted the communication of administrative logon to TSO. So how can we protect against some of this stuff? First of all there's some technical recommendations and as you can probably imagine the fairly obvious one is don't use promiscuous mode. Even if we have to define 15 IP addresses within our router configuration that's certainly a lot more favourable than people messing with our DLSW environment. As we've also seen, explicitly defining the MAC addresses of the mainframe in the capabilities data is also good. Also if we can actually use path costs, use the lowest possible path costs which means that if the router ever has a choice as to which path it's going to take when it's establishing a circuit it's always going to pick with a legitimate one. And then we need to start looking at ACLs to start protecting port 2065 and the other ports associated with DLSW. Whether that be filtering on firewalls or whether it be router ACLs. And again, try and protect the information that's passing across our network. Cisco actually had a paper on their website about how to use IPsec to protect DLSW traffic passing between their routers. Again, take every precaution you can. And that comes down to using end-to-end encryption for the data. Now we might find that if we're using SNA this isn't possible. So this is where we need to start looking at the actual requirements for our network looking at the sensitivity of the data and understanding the implications of the protocols we're using. If we need encrypted data why not use SSL and SSH support on the mainframe? Why continue to use the older protocols? You may need to continue using these SNA applications. It may not be cost-effective to migrate them and therefore IP might not be a solution. But it's always important to understand the risk you're exposed to. Again, just because these are high-value environments it doesn't mean we shouldn't patch things. Particularly the routers. We've already seen how old vulnerabilities to do with Ethernet padding has enabled us to sniff the credentials out of the actual padding in the packets. If we're using an SNA gateway we need to make sure that's hardened. Out the box Microsoft's host integration server is not the most secure system and we can certainly pull off a lot of information about its configuration. And let's look at the recommendations at a high level as well. This is where it comes down to looking at what you're using on your network. Understand the strengths and weaknesses of the protocols. Do they support host authentication? Can you use encryption with them? Are traffic redirection attacks possible? We've obviously demonstrated some traffic redirection attacks with SNA here. But remember, up spoofing again is another attack against IP. So understand which vulnerabilities apply to which protocols and understand how to best protect your network. Then deploy an architecture that actually meets the requirements. Make sure that you can maintain who has actual accessibility to the services on your systems. Make sure that patching can go ahead without causing disruption to users. Keep monitoring for suspicious activity. And make sure that your sensitive data remains private. And when you're getting these environments tested, make sure the testing's thorough. If you have pen testers that come in that just know about IP and you ask them to start looking at your SNA traffic, then they may start to panic a little bit. Make sure that you ask these guys some questions before you hire them. Make sure they understand the technology. Make sure they can communicate to you the risks that you're exposed to. And most importantly of all, make sure everyone within the company is talking to each other. Make sure the mainframe guys talk to the network guys. Make sure they talk to the desktop team, because if they don't, then there's going to be vulnerabilities that are exposed. If you want a security function, use your influence to actually bring these guys together and actually be proactive in making sure that security is being improved. So after all this, are we safe? Or maybe not. There's a whole lot more to be done here. There's lots of SNA stacks out there. I've certainly not got access to a mainframe and therefore I can't test these at the moment. I'm sure that once you start delving into the actual handling of the SNA protocol itself, we're going to find some vulnerabilities. Maybe someone wants to write a DLSW stack for Linux or for BSD. That would be really cool and would certainly help us if we're actually pen testing these systems. SNA type of service handling. I haven't even touched on that. Again, that's another area to look at. Something else I've talked about, host integration server. Network for SAA, which I do not believe is supported anymore. Basically, SNA gateway systems. There's a lot more work that can be done to actually determine any vulnerabilities in those systems. Again, peer-to-peer networking, APPN and APPC. Essentially, we have an entire method of communicating using peer-to-peer protocols between systems on our networks. There's a huge scope for attacks in these areas. Coupled in with that is then secure configuration of VTAM, making sure there are no unused definitions in there. Again, we need to look at how to actually investigate those configurations and make sure they're in line with best practice. As an overall summary, we really need to make sure that the topology and construction of the network are known to us and what the risks are actually exposed through that. As we've demonstrated today, there are weaknesses in the technologies that are used to access mainframes. Make sure you understand what they are and then put measures in place to mitigate against the risks. It's good information security practice. Now, a request for help. I don't have access to a mainframe at this point. Hopefully there's a few people that do. If anyone does and fancy getting involved with some of this research, then please let me know. I'd love to talk to people that actually run these mainframes on a day-to-day basis, that actually run these networks and are facing these challenges. As I've said, there's lots more work to do and I'd certainly love to work with other people in this subject. So certainly give me a shout if you're interested in doing this. Now, references and further reading. When I was actually investigating these technologies, it was made somewhat more difficult by the fact that a lot of the books that are out there on SNA are no longer in print. But if you search around, you can certainly find them. If you go back to the RFCs, you can find out some more information. Cisco have a lot of information on their website about DLSW and also about how Cisco routers can be used in SNA environments. So that's it for me. Any questions that anybody has? It's on. You mentioned in the presentation that SNA has inbuilt encryption capability. Do you know why people aren't using it? I believe that, I mean, the information I've had is basically from some guys that used to write SNA stacks themselves. And they just said that the applications that people were running for which they were commissioned to write these stacks simply didn't want to make use of it. And that was pretty much what their answers were. Other than that, as I said, I've not got a background in IBM so other than that, unfortunately I'm not sure. Thank you. Okay, thank you very much.