 Welcome, everybody! This talk is called MQ Jumping. For those of you who are not aware of what it's about, I'll be talking about IBM's WebSphere MQ software. For those people at DEFCON last year, I talked about some crazy IBM networking attacks, looking at some old-fashioned protocols. I was intending to continue looking at them, but as any pentesters out there will know, a client comes along with a request to look at software, cyn ei eилсяu dyma. I曲wch ar y cyfnodd gyda'r cyfnodd ac eisiau wneud teithio eu gwwyl yn ymddangos bwysig. Felly cyfnodd i ddefnyddio ei wneud ymddangos at weld eu cyfnodd ymddangos bwysig. Roedd yn oed yn ymddangos dunol y flynedd y byddwyr mae'n gweithio ar eich cyflodd yr Cody i BMW ac mae'n gweithio i dda i fynd? Roedd nid goeth am ymddangos gyhoedd, ar ôl NWROX. Rydyn ni'n bwysig o'u swydd dechreuu ar eich gweith. I don't have a background in IBM computing at all. I've approached this subject purely as a pentester and a security consultant. I got asked by our clients to look at some software and then just started taking it apart the same way that I'm sure many of you guys out there would do. Just to try and understand what kind of audience I've got here, can I get a show of hands as to who here has MQ on their network, admins it, runs it? Okay, cool. How many of you have had a pentest of your MQ environment? Okay. Did any of you guys get a clean bill of health or do you think that your systems are all okay? So okay, cool. What I'm going to do today is I'm going to talk through some of the background to MQ for those guys that don't know about their technology. Talk through some of the features that it has with regard to security and then talk about a few little issues I've discovered that may well put your installation at risk. So I'm going to try and cater to a few different audiences today. Try and keep some of the stuff high level for security management out there. Also try and talk to a sufficiently techy level for anyone out there who's a pentester or security consultant and also anybody that's developing applications for MQ. Hopefully you'll get someone out of this as well. Now anybody that knows MQ will know it's an absolutely massive piece of software can be configured in a whole lot of different ways in a whole lot of different environments. And I've not got time to go through every single aspect of security here. What I am going to focus on is MQ from a network perspective in a TCP IP environment. And most of the research I've done has actually been against Windows and Unix systems. Although in the last couple of weeks I was actually fortunate enough to look at this running on an i-series system. And most of the code that I've written worked actually straight out the box on that as well. So why did I actually decide to look at MQ? Well the reason why I did that is because the client sort of running it and the way they're using it is actually mission critical. People are using this to pass their trade data, their share dealings, their retail transactions, healthcare information. Using it to pass that around the business between various applications. When I started looking at this there were also no tools out there for me to really kind of get stuck into. And they want me to test an installation and say to the client, yes you're secure, no you're not. And what I've found generally is that when there aren't such tools out there people often have installations that are not properly secured. Because people don't know how to test them or to evaluate them. And generally with any application if you actually own the middleware you normally own that business process. So a quick history lesson from or as I've managed to find out what the history of this thing is. MQ started back in 93 as a kind of collaboration between SSI systems and IBM. And over time IBM has kind of gradually adopted the code and taking it on themselves. Produced a set of versions for their core operating systems as they were AIX, OS2 and AS400. And then used them as a kind of template to then portal their code to other platforms. The kind of latest version of the software that I've seen our clients running is version 6. And people tend to have been running that for either the last year, year and a half. Although some people are still at start there running anything from 5.1 up to 5.3. I've never found anyone running anything before that but that's not to say that they aren't out there. So if you're a business why have you actually put MQ into your environment? Normally you need some component there that's going to manage all your messaging that can pass information accurately and reliably from one part of your infrastructure and your environment to another. People choose MQ because it's pretty stable enterprise technology. I hear clients that are passing millions of messages through their systems every minute. They need something that's going to be reliable and not start dropping messages. They need something that's going to be scalable. They need something that's going to be able to run on a whole lot of different technologies. And MQ will run on Windows, Unix, it will run on mainframes. And that gives an enterprise an awful lot of functionality in how it actually uses its MQ installations. When you couple with that the whole lot of APIs that IBM have produced to help you build applications that gives you an awful lot of power in interfacing with these systems. Various other bits of enterprise functionality in there make this a very attractive piece of software for an awful lot of companies out there. I've already mentioned the type of data that goes across these systems. It's the stuff that's really core to people's businesses. So a really bad diagram for you to have a look at. If you're not sure of what MQ looks like and how it's actually set up this is a reasonable attempt to describe that. What we can see is we essentially have two sets of queues on different machines which is essentially a way of packaging up the data and keeping them in a nice tidy format. We then have the ability to transfer that data across a network and we have these entities called queue managers which are then responsible for managing this information and making sure it gets to where it needs to go to. There's a bit of terminology involved in the MQ world and we'll talk about some of this today. I've already mentioned a queue manager. We also have different concepts like channels, queues. We have two things like triggers and monitors. As I said we'll run into these over the course of the presentation. So what's a queue manager? Obviously it's an application that's responsible for managing all the queues within which the data sits. As far as I'm aware, and please correct me if I'm wrong you can only have one queue manager that listens on one TCP port. Each queue manager itself is an independent entity that has access to its own queues. But you can set up an environment where these queue managers can talk to each other and therefore exchange data across a network. In the environments I've been working in we often find multiple queue managers on a single system. So someone will be running a production MQ server on the same box as a development MQ installation and because they manage separate queues they think that's a suitable way of running things. As we'll find out a bit later on there's reasons why that might not be such a good idea. Channels. I'll mention them briefly. The best way to think of a channel is some kind of conduit or pipe that enables you to get to the queues themselves. You can then apply various controls to that channel that restrict how access is actually gained to those queues themselves. So different people can access the queues down different channels and you can apply different security features to each one of those channels. There are various different types of channel but again this is something we've really not got time to get into today. And then we have a queue. A queue is essentially what it sounds like it's a container where your data goes. MQ is really designed to operate on a queue basis where everything works with queues. There are first in, first out structure generally. The message you put onto the queue first is the one you're going to recover off there first. There are some exceptions to that. You can use priorities in order to pull off urgent messages first. Again these are some of the bits of functionality that make it so attractive to the enterprise market. Now the real elegance with MQ is that everything is really a get or a put. You're either getting data from a queue or you're putting data onto that queue. There's obviously some more complexity to the way the software works but the real essence of what I'm going to show you today revolves around those two operations. So let's talk about the MQ protocol. As far as I'm aware there's no actual official public disclosure of the protocol but if you look in Etherreal or Wireshark you will actually find some dissectors in there that enable you to get a pretty good understanding of what the protocol is doing. And when you look at the protocol you'll see there's a series of different sections in each packet that depend on what purpose that packet is actually for. So a packet that is getting data will have sections like the get message options and message descriptors that are not necessarily in other types of packet. All packets will have a transmission segment header and if you see the letters TSH at the top of your packet you're pretty certain that you're actually dealing with MQ. So you might not be able to see that diagram particularly well but that's essentially what a packet looks like in Etherreal. At the top of the packet here we can see the letters TSH which is where this transmission segment header actually begins. This type of packet is actually a reply from a get request. So we've requested to get data from a Q and this is the reply that's come back to us. So we can see some of the various different sections that are included in the packet. And down the bottom here we have one thing that's known as PCF, Programmable Command Format, which is essentially a type of administrative packet and we'll come on and talk about that in a little bit. So what is PCF? As I've said it's essentially admin packets. It's a way you can actually manage the Q manager itself. And the way we use these is we actually put a particular data structure into a get or a put message and we put them on specific Qs on the Q manager and then we can read data back from other Qs. Now the PCF data structure is well documented. There are some IBM guidelines out there about exactly what this data looks like, what format it's in and that's what I've been able to use to put together some of the tools I've been writing. So one of the things we're going to talk about a bit later on is how we actually execute a PCF command and how we can use that for our own purposes. And if we're going to issue a PCF command essentially what we need to do with the following steps. First of all we need to establish a connection to the Q manager. If we're running on a TCP IP network that's essentially a TCP connection needs to be opened and then a number of different handshakes need to occur to actually connect to the Q manager. We then need to open what's known as the admin Q on the software and that is essentially a Q where we're going to put our data. Now as I said everything on MQ works on Qs. So if we're issuing a command we put data onto a Q and it gives us the reply back on another Q. And what we actually need is another Q for us to put the reply to that first query onto. So we open what's known as a dynamic or a model Q. That essentially generates a new dynamic Q for us that we can then use to put the data back onto. So the sequence event is we put our PCF data onto the admin Q and we need our response back off the dynamic Q. So what security features does MQ have? Well essentially there are three types of security feature and I'm going to talk through each one of these in turn. We have an MCA user which is essentially a user ID on a particular channel. We have a security exit which is an external program that can be called to enforce authentication. And we have SSL and TLS support including the use of client certificates and some basic user filtering from that as well. So we start with the MCA user and this is not a particularly simple concept to get your head around and I haven't got time to go into all the complexities of how it works. Essentially though it's a tag in the packet that says which user has this data come from. And a lot of the API calls you'll find there actually read the username of the logged on user on their machine and put that value into the packet. There's an awful lot of confusion out there about exactly what that means in terms of a security feature. I'm sure anybody here is aware that if you're reading the local user off a machine then that's not really a security control. We can also apply an MCA user to a particular channel and in the simplest form that is essentially the user that that channel and those communications are going to run under if no other user is specified. As I say there's a lot more complexity to that so let's talk about some of the real showstoppers when we're actually talking about MCA users. So the limitations of this and the first thing that anybody who has come across WebSphereMQ security will know is that by default there will be a blank MCA user on all your channels when you take this thing out of the box. And a blank MCA user means everybody has access to that channel. So by default if you've installed WebSphereMQ and you've not set the MCA user your system is wide open. I've already mentioned that the MCA user is essentially a client-side parameter that is being passed from the client. If we can construct our own packets we can construct a packet with any MCA user we wish in there. If you look at the news groups and people talking about MCA security you'll see that there's a lot of people that really don't understand what this control actually means. And one lesson that you should take away from today's presentation as we'll see is you should never rely on an MCA user as your sole security measure and we'll see a really good reason for that a bit later on. So we move on to a security exit. A security exit is essentially an external program that MCA can call and that can do authentication for you. Now there are a number of commercial security exits out there and the other clients of ours actually write their own. And usually what you do is you get that security exit to check a username and password that has been submitted from the user and if the username and password is correct you can send back the right return code to MCA and that says yeah this guy's authenticated. There's lots more you can actually do with that security exit. You can enforce IP address restrictions you can in theory do anything you want to. But essentially the lesson of a security exit is that it's enforcing access control for you. Now what are the limitations on it? Again with any protocol if you're sending that username and password over a clear text channel that's just the same as using telnet, FTP any of those other protocols. If you write your own security exit or buy one that's written insecurely that code is essentially now the front door to your system. If that code is insecure you could get your system owned and therefore it's very important to actually look at what code you're using for that security exit. Another limitation and this may not be an obvious one is that MQ actually has to make sure that that exit is called for you. You literally kind of tick a box on MQ and say yeah use this exit but you have to then have trust that MQ is actually going to call your exit for you. So what about transport security? Well MQ has good support for SSL and TLS. Unusily MQ will actually accept an SSL handshake on the same port as it will accept a standard MQ clear text handshake. Unlike a web server where you can negotiate a Cypher suite to use a particular channel will be set with one Cypher one SSL version. There's no negotiation actually permitted on that. If you're thinking about building your own tools OpenSSL has had good support for the majority of the Cypher that MQ supports for quite a while now. Something in the UK we don't really have much call for is FIPS compliance and I believe that MQ can actually be set up to be FIPS compliant if that's what you actually require. You can do that in the software on digital hardware accelerators. So what are the limitations of SSL? Well if you think that by putting a particular Cypher on a particular channel that's going to stop someone talking to you. Again that's a false assumption we can just cycle through all the Cypher and see which one we get a proper handshake from. By default if you put SSL on a channel you're not going to get any authentication control. Hopefully everyone here is completely aware of that one. Limitation again is that if you think that just because we're using SSL it's going to be difficult for guys to write tools. Using Python which I've used to write most of my tools it's just a couple of lines extra to do that SSL handshake. Also you have to be aware that if you're using SSL there's obviously a certain amount of trust with regard to who you're actually talking to. That's based on the certificate authorities that are actually repository on either end of the communication. You need to be very careful about how you set that up. I also mentioned we can do client authentication using MQ. We can actually set it so that MQ only accepts communications from someone who is using a certificate issued by our trusted CA. We can also filter users based on the values in that certificate and if we lock down our repositories on either end so that only trusted CAs are in there then we can actually make sure that only the right people are connecting. The problem is by default there's a whole load of trusted CAs in those key repositories when you create them. If you don't actively remove them that means that someone with a key from a trusted CA, for example from Verisign or Thought they will also be able to gain access to your Q Manager. Again it's really easy to add support for a certificate using Python it's a couple of lines of code. Another limitation with the actual filtering client authentication controls is that it only works from the start of the pattern match. If I have a pattern match that I'm matching cn equals admin then cn equaling admin one admin two administrator are all going to be allowed. We don't have to actually specify a trailing wild card on the end of that filter. That is it there by default and implied. If we're not careful about who we're issuing certificates to and what the names are in those certificates we could find ourselves in trouble again. So now let's move on to talk about actually testing MQ. If we want to connect to MQ we need to know a number of things and the success of our connection is essentially going to rely on a number of things. It's going to rely on us knowing the right port to connect to. By default MQ will listen on port 1414 but there's no reason why we can't change that. So we have to find it. We then have to know a channel to communicate with. Thankfully from our perspective if we're an attacker there are some default channels that we can find. In other circumstances people will publish the names of their channel on a wiki or on their internet or if they're using clear text communication we can sniff these values. We also the success of our connection will also depend on what's known as the MCA user. Most of the guide books out there tell us that we set an invalid user as the MCA user and that eventually locks people out of that channel. We'll come on to see why that might not be such a good control. Also depend on whether we've got a security exit defined but again as we'll come on to see that might not necessarily save us. And again if SSL is being used we need to know which cifers to use and whether particular certificates are trusted or not. The first one of those challenges is to actually find MQ. Easiest way of finding it is to just attempt an MQ initial data handshake on each port on the system that we think might be MQ. If we get it right we're probably going to get the Q manager name coming back in our packet. Well not necessarily. In most client instances I see we actually get some kind of data back that we can use to actually identify that MQ is on that port. And we'll see a demo of running that against an installation a bit later on. So the pattern of connection is essentially we can actually do an initial data handshake where we agree to various parameters that are going to be used by MQ. We then actually send a username and password packet. If no username and password is set up we still send that packet but we actually send it without any values in there. If no security exit is defined then we can just go ahead and try to connect. We get a connection response back if we're successful. And then we can try opening Qs and accessing data and doing all the things we might want to. So one thing that I've noticed that I've never actually seen anyone use but looks like it's quite an interesting feature is that you can actually set up a channel auto definition whereby connecting to a channel that doesn't exist MQ will quite happily set up a new channel for you based on a particular template that you've defined. I'm sure you can imagine that connecting with lots of different invalid channel names could cause a few issues if we're able to actually talk to the MQ port itself. If someone's actually set that up and used an administrative template as the channel definition we might find ourselves gaining access straight away. And once we're actually connected what do we actually want to do? Well there are a number of things we can do we can issue these PCF commands we can administer the Q manager itself we can open and actually look at the Qs themselves look at the information on them we can pull data off those Qs maybe put more data on them also we can execute operating system commands if the conditions are right So what PCF commands might be useful to us? Well there are some that enable us to enumerate the version of MQ some that allow us to dump out a list of all the channels on the system a list of all the Qs and how they're configured there's also a Q there that contains the information regarding the MCA users of particular channels So if an attacker actually isn't interested in your Q data and wants to start executing commands what do they need to do? Well from version 6 onwards MQ supports something called services and this is essentially a way of defining an external program that can be run through the execution of PCF So if we're able to gain access with enough ability to execute PCF commands we can define ourselves a new service which is essentially an application to run and start that running Another method and this method works before version 6 is that on MQ you can set up triggers this is essentially an application that will sit there and listen for data on a particular Q when it receives it and then execute a particular command for you Administrators like to use this say a particular say at the end of day for a retail organisation a message gets sent to a Q to say all the TILs have closed and that actually then gets fired on to a Q and a trigger fires to tell the administrator that all the Qs have closed for the day I mean there are lots of things you can do with a trigger one kind of really one just really kind of made up example now if we want to execute commands using that trigger there are a few different things we need to do first of all we need to define a new process now the process is essentially the command that we're going to execute we then need to change the Q definition to actually turn the trigger on and tell it to use that particular process when it fires we then need to put a message on to the right Q so that our trigger fires trigger monitor application reads that information and runs that command now the one caveat to this is a trigger monitor needs to be running so in this particular installation we need to have that actual application running before version 6 I'm not aware of any way of actually starting that remotely but that last method actually requires us to execute PCF commands now if we don't have permission to execute PCF then there is a slightly easier way for us to do it now what happens when a trigger fires is essentially MQ puts a particular type of message on to what's known as an initiation Q and that's what's read by the trigger now rather than go through the hassle of defining a new process or to a Q definition if we know the format of that message we can just put that message directly on to that Q now if we put a message on to initiation Q and the trigger monitor isn't using and our expiry time isn't set to a low value that message will actually sit there so the next time an administrator fires up a trigger on that Q that will actually run now you can imagine that as being almost a kind of very unstealthy backdoor so that a particular person has gained access to an MQ installation drops a particularly malicious message on to that Q and then when an administrator decides they're going to start running a trigger monitor that fires and if they're not particularly familiar with the use of a trigger the actual message they get on their screen they might not understand the actual importance of that and the fact that it's just executed a command so if you're familiar with MQ and all the features I've been talking about then it's probably not much that you're too worried about so far you've probably got all these things in place you've probably got your whole system set up and secured but when I actually started testing this and software I actually discovered two new vulnerabilities that actually exposed some pretty serious holes now I went through the process of reporting these to IVM back in January and another one in May this year I actually talked to the MQ development guys in the UK and reported these issues through the centre for the protection of national infrastructure in the UK and for various reasons I'm not going to tell you exactly how to exploit these vulnerabilities today but I'm going to tell you what they are what they mean for your environment and how you can protect against them once everyone's had a chance to digest that and actually protect their systems and at the right time then I'll actually release some more information about these issues so what's the first one of these issues I was actually testing an installation where the security measure was a security exit they'd correctly protected channels it was actually with a security exit that would take a username and password check that against a database and then if that was actually correct would log you in I was able to actually bypass that completely so that I managed to get MQ not to call that exit meaning that MQ did not know to kick me on behalf of the software I was able to gain access to that installation the systems I tested were versions 5.1 to 5.3 on a Solaris platform others may be vulnerable I know that the version of MQ I have which is version 6 on Windows is not vulnerable to that issue as far as I've been able to tell I'm aware of rumours that say that this issue has been fixed somewhere down the line but I'm not aware of any documentation or I can actually tell you at what point that got fixed or what patch you need to actually apply to to essentially mitigate that the next one is actually an invalid MCA user bypass now a lot of the books out there on security MQ will say as soon as you get this thing out of the box put an invalid user into the MCA user channel agent that means anybody connecting to the box is going to get a reason code back saying you're not authorised to connect I actually found a way of bypassing this meaning that if you essentially have protected your administrative channels or any other channels by setting an invalid user it is still possible to gain access to that system and every version I've tested so far has actually been vulnerable to this issue so if our objective is to actually test the security of an installation there are a number of tools we actually need we need somewhere to find the MQ services on our network we need a way of finding the channels on these systems so we can communicate with them we need the ability to test what SSL settings are in place so we know how to communicate with those channels we'll also be good to recover information from the Q manager that tells us things like operating system version what processes are defined and whether there are any triggers running we'll also be good to be able to test whether we can read data from a Q whether we can write data to a Q and we'll also be good to test whether we can actually execute operating system commands through both of the methods I've just talked about so what I've actually done is written some tools that will help us to perform these tasks I've actually written them in actually a set of Python classes that enable you to then build pack it up and fire these in whichever order you want it's not a finished tool by any means and what I'm actually releasing is some sample tools that enable you to do some of the enumeration of your systems for MQ and actually enable you to dump out some information I'm also in the process of putting together a white paper on MQ security I've only been looking at this subject for about six months so I don't know everything about this software yet and what I'm trying to do is distill down what I've actually found from a security perspective into one document that enables people to look at their installations in a realistic manner and I'm going to put lots of information in there today I've had to skip over an awful lot of stuff I'm going to put some more information in there that's available through our company's website hopefully in the next month or so so now we're going to get to the fun bit and have a look at actually exploiting some of these vulnerabilities to look at how we can actually gain access to a system running MQ and I've got a very basic setup here I've got my laptop it's essentially a VMware partition that's going to talk to an MQ server our objectives on the demo we're going to scan a box look for MQ services our support is on the channels on there we're going to recover some information using some PCF commands and I've also got Netcat on that system and all I'm going to do is execute a command to start that running so we can actually see that we have an ability to actually execute a command obviously your your method of exploitation out there in the wild is going to be dependent on the architecture and the environment you find yourself in so I'm going to flick over to the demo now if you can't see anything, please give a shout I've tried to use a reasonable font size and what I'm going to do quickly is just show you a quick look at the actual MQ software itself set up in a configuration that we've actually seen out there that our customers are using and for those people that haven't come across MQ before this software is called MQ Explorer it's essentially a GUI tool that enables you to manage your Q manager and you can see here I have a number of channels actually set up and the one I'm actually going to demonstrate attacking is this channel here called Defcon 15 admin if we look at that we can see we've got SSL set up on that channel we've also got it set up to only accept certificates with this particular string in the distinguished name and we're only going to accept connections from people we trusted certificates we've also been paranoid on this channel and put an invalid MCA user on there so technically no one should be able to gain access to that channel now I'm just going to show you quickly also why my certificate that I'm going to try and talk to the Q manager where it actually works and this is essentially the view you get from the key repository manager on MQ and by default we have a whole load of certificate authorities that are in there by default so if I've got a certificate that's signed by one of these CAs because I haven't removed them from there actively removed them I'm going to be able to gain access and the last thing just to show you quickly is that we've also got a trigger monitor running that we're going to use to demonstrate executing a command so that's just our trigger monitor sat there waiting, listening on the default initiation queue waiting for a message to come along I'm logged on to this box as an administrator so that trigger monitor is running as an administrator and we'll see why that's a really foolish idea so the first thing I'm going to do now is just run a quick M-map scan against that system to see what services are listening I'll try and get that in the right place if we look down here at the bottom we can see that our default port 1414 is actually listening on this system what we're actually going to do is run a quick tool against that system just to make sure that is actually MQ I'm just going to try and resize this window a bit to let you see the bottom of the screen a bit easier ok so the next thing I'm going to run this is essentially going to take my M-map output in greppel format it's just going to try doing a handshake against each one of those ports on that box and that will take a little bit of time to go through so essentially that's firing an initial data handshake at the box all those ports as we expect on MQ and these ones eventually we'll get to port 1414 and we'll see that we've got a nice handshake back from there and that's actually giving us the actual name of the Q manager for us next thing we're going to do now is actually I've got a text file on the machine here with a number of default channels and also the channels that we saw in the actual MQ software I'm going to run an SSL check against those it's going to essentially check it's going to run through a whole list of different cyphers to see which cyphers sweets are actually supported on those channels so we can see our Defcon 15 channel there's SSL version 3 with a Nolshar we've then got some of the system channels and they've all been set up without any SSL protection on them I'll notice that one thing that's actually missing from there is our Defcon 15 admin channel and that's because of a little bug in this tool at the moment we need to re-run this in verbose mode we actually find that on a channel that has SSL set up but actually requires a client certificate we get a slightly different error message back you can see there for AES 256 we've got a reply that says invalid client certificate rather than bad remote cypher so we now know which cyphers we can actually use to talk to those channels next thing we're going to do now is actually just using one of these insecure default admin channels we're just actually going to dump out some information just to show you what kind of things we can get out of this so if we work down we can see the various different packets that I'm actually sending and the responses we're getting back from them so I complete a handshake, I connect I open my admin queue, I open my model queue to get my data back I then actually submit and inquire queue manager, PCF command and that returns as a whole lot of information about that queue manager most of which we're probably not going to be interested in but there are some some values in here of interest to us we see there we're at WebSphereMQ version 6 and a bit further down we can see that our operating system type is Windows so we've already got a fairly good idea about what kind of system we're attacking and how we actually need to go about that so now what we'll actually try doing is executing command to start that netcat that's listening on that and just to show you that I'm not cheating hopefully that's not listening there at the moment what we're going to do is we're going to create a service that actually is going to start netcat that we're going to start that service running as you can see we've specified which channel we're connecting to what cipher we're going to be using and we're also using our certificate that's been signed by our trusted TA so you can see that's gone through all okay and there we go, we've started netcat running in this case though as you can see we're only running as the restricted privileged mq user so we've still got some work to do if we actually want to get admin on this box but at least we've got a a foothold on to that system now next thing we're going to look at now is actually executing command using that trigger monitor that we saw previously now what this is going to do is going to execute the command you can see down the bottom of the screen there maybe which is starting that cat listening on 6969 again let's just try to turn it in to make sure that our services died and see an interesting thing here we've got a response back from our q-mayor and we're not authorized but let's see whether we are or not yep this time because we started our trigger monitor as administrator we're now running as admin so it all looks pretty bad at this point is there anything we can do to actually protect ourselves well the answer is yes at a technical level there's a whole heap of things we can do we need to make sure we protect all the default on admin channels don't leave them wide open we need to have a defence in depth approach that means we're not just relying on security measure if we actually combine some of these techniques of using SSL client certificates we use security exits that have been properly audited we can actually put together a much better security model for our installation now we've been able to execute PCF commands because something called the command servers running which enables us to manage the command server remotely we can turn that off we can do all our admin on the console itself so again turning that on is going to it's not going to stop an attacker gaining access to the message data but it might stop them executing commands and actually altering your Q manager itself another recommendation don't use channel auto definition I'm not sure in what circumstances people would use that I've never actually seen that turned on make sure you're using SSL to protect your data over the network make sure you go through that key repository and remove all non-trusted CAs be very specific with your user filtering strings that you're using with your certificates and make sure the people that are issuing the certificates know what the limits are so for example if you need to grant the user admin access make sure they're not then issuing a whole load of other admin related certificates if you're particularly paranoid make sure you always clear the initiation queue before you start a trigger monitor running and if you're using trigger monitors make sure you run them with the lowest possible privileges so at a high level there's also a number of things we need to do we need to make sure we look at the middleware make sure that the guys we get into test our systems don't just know about the web server and the database or the actual client application make sure that they can test this system properly make sure you use all the security features don't use one feature and say ok that's it, that's me protected use access control and encryption and when the security fixes out there make sure you apply them and make sure the testing you have done is thorough, make sure someone doesn't turn up with a scanner just scan your box and say yep that's ok and look at the whole environment a lot of clients of mine have different queue managers running on different systems they'll have transmission queues and remote queues set up to allow different people access to queues on production systems because they have incompatible software or other bits and pieces like that make sure that when you're testing it you're looking at the whole environment there isn't some other route to get to your queue manager you've not looked at now I've talked about running a development and a production queue manager on the same system the problem with that is if we're running them under the same user on the local system if we manage to gain access to the operating system through our insecure development environment we're then running with the privileges with which our production queue manager is running so we might find that someone has circumvented all the controls on our production queue manager simply by using that development queue manager there's also been a whole other load of things I haven't talked about today cluster security and a whole load of other things you need to make sure you look at those as well that's something I haven't looked at in great detail thus far that's probably something I'm going to move on to look at next as I've just mentioned are we safe now what we can be reasonably safe if we put the right controls in place there's still more to look at it's a very complex state machine and protocol therefore there's probably a whole load of bugs out there that we can find by fuzzing we've done some limited fuzzing and we've found a couple of crashes we've not had time to go and look at exactly what caused them and if we do find that there's any issues with those we'll certainly be reporting those to the right channels I haven't had a chance to look particularly at MQ on i-series and ZEDOS they're two particularly interesting targets we also get IBM recommending that we use Tivoli for all our remote administration maybe that's something that we can have a look at and how do other messaging solutions compare to WebSphere MQ are these issues in isolation or do we find the same kind of issues across different bits of software that's something we really need to find out so in a three line summary do everything that it actually tells you to do with regard to security features don't just use a couple as with anything new vulnerabilities could expose your environment, can expose your software and if you're using multiple layers of defence you're obviously going to be more protected there's a few references in the back of this talk that you can have a quick look at some excellent reading out there and that's just about me done I think we're going to go over to the QA room now so if anyone's got any further questions and follow me over there and we'll go through them there