Aug 31
WebSphere MQ security
icon1 Niklas | icon2 Tags: , . | icon4 08 31st, 2007| icon32 Comments »

With all the recent fuzz on WebSphere MQ security I thought that I should try to collect the current thinking on the best way of securing your WMQ environment.

Lately, T-Rob and Martyn Ruks has held two separate presentations on WMQ security and the following posts will reflect a lot of what they presented. This combined with my experiences from securing WMQ environments make up most of the content. I hope to collect feedback from the community to improve over time.

Please note that these posts are my current understanding and should not be regarded as the final answer. I will continue to update these posts as I learn more on the topic. Any feedback is crucial so feel free to comment on any of these posts or send me an email directly. My experience is on the distributed platforms, so you’ll find very limited specifics on how to secure your z/OS environment, hopefully the community can help fill these gaps.

Most of the topics listed below are placeholders for future posts I intend to write, and this list will most likely be heavily modified before I’m done.

How to create a secure WMQ environment

  • Why secure?

  • Keep up to date

  • Policy

  • Secure by default

  • Securing channels

  • Securing queues

  • Publish/subscribe

  • Triggers and services

  • Securing applications

Breaking in to WMQ

Technorati Tags: , , , ,

Aug 31

This post is part of a series I’m doing on WebSphere MQ security.

As described in my previous post of in this series, this method of spoofing messages in WebSphere MQ should be fully attributed to T-Rob, famous from the WMQ mailing list for his deep knowledge of most odd corners in the WMQ world.

The exploit described below does not use any bug in WMQ. WMQ in this case works as documented, this is exploit relies on weakly secured WMQ environments.

As before, I’ll update this post as I learn new details around this attack or ways of protecting against it.

Description

WMQ has a feature called report messages. These are usually used by a sending application to get a receipt on whether the sent message has arrived, ended up a exception queue or was expirered. To use it is quite simple. The MQMD header (available in all WMQ messages) contain a Report attribute. Set this to the appropriate value and provide a reply queue and you will get receipts for your sent messages. You can also decide on what you want the report message to contain, either just an empty message, the first 100 bytes or the full data of the original message. In all of these, the report message will have a MsgType (in the MQMD) attribute set to the value Report (4) and a non-zero Feedback attribute (also in the MQMD).

One type of report message is the “confirm on arrival” (COA). This report message is sent by WMQ itself when a message successfully arrives on its target queue. As WMQ sends it, it is put using administrative authority.

This attack could also be done using other report types, like expiration, but COA is the attack the requires the least effort.

Now, if we get access to putting messages on any queue, for example using a hacked application or a badly secured queue manager, we can easily put a spoofed message with a Report attribute requesting a COA with the full message data. We can provide a reply-to queue and reply-to queue manager for any queue in the entire connected WMQ network. Now imagine that this message contains a spoofed message for some application on the WMQ network. An easy and effective attack unless the receiving application knows to defend itself.

Protect yourself

There is, as far as I know, no way of shutting of report messages in WMQ. It would be a good addition to WMQ security if we would be able to shut of reports on a queue manager and queue basis.

Sign your messages. Let the sending application digitally sign all messages it send and let the receiving application verify these signatures against known senders. Message with unknown or invalid signatures must be ignored, put on an exception queue and an alert raised.

Receiving applications should verify that they receive an expected message type. Normally, this would be a Datagram or a Request. All other types, and specifically Reports must be ignored, put on an exception queue and an alert raised. In fact, the built-in WMQ command server does this check and will ignore any messages which is not of the Request type. This shows that IBM is well aware of this exploit and are doing these checks themselves. Without this check in the command server, this exploit would have allowed administering WMQ.

If using JMS, here is some example code for how to check the message type:

if(!msg.propertyExists("JMS_IBM_MsgType") ||
    msg.getIntProperty("JMS_IBM_MsgType") == 1 ||
    msg.getIntProperty("JMS_IBM_MsgType") == 8) {
    // do your stuff
} else {
    // run screaming away from this message
}

Note that if you switch to another JMS provider, this code will still work as it first check for the existence of the specific IBM property.

If your using the Java Base API, this is what you could do:

if (message.messageType == MQC.MQMT_REQUEST
        || message.messageType == MQC.MQMT_DATAGRAM) {
    // do your stuff
} else {
    // run screaming away from this message
}

Code for most other WMQ API will work similarly to the Java Base example. If you got example code for any of the other APIs, feel free to send it to me and I’ll add it to this post.

Aug 30
Gave in
icon1 Niklas | icon2 Tags: , . | icon4 08 30th, 2007| icon3No Comments »

Somewhat reluctantly I started using Facebook a couple of weeks back. For me, joining Facebook meant leaving LinkedIn as I only have so many cycles to spare for social sites. Anyways, Facebook is a big advancement over LinkedIn, if nothing else but the fact that you can actually do something almost useful after linking up your friends. Facebook as a platform is the big hype right now, deservingly it seems.

In all its AJAX glory, one really neat interface feature at Facebook is the “Add To Friends” link.

Click it normally, and an AJAX popup opens in the same window allowing you to add a friend.

Click to open in a new tab or windows (like with Ctrl+click) and instead a new page will open with pretty much the same dialog. Giving the user the choice, very friendly and clever.

For someone who wrote AJAX like web sites at the time it was still called DHTML, the thing that truly stands out with the sites like Facebook, RTM and Gmail is how well the dynamic stuff fits in your normal work flow, rather than being show-offs like we used to do in the good old days.

Technorati Tags: ,

Aug 17

This post is part of a series I’m doing on WebSphere MQ security.

Security in WebSphere MQ is heavily reliant on applications only being able to put messages where we want them to. Otherwise, an hacked application can be used to send messages where it is not supposed to, for example inserting spoofed messages destined for some other application. As messages commonly contain very important business data and have a high-priviliaged route into applications, spoofing messages can be a very efficient way of hacking.

Over at the WebSphere MQ mailing list, I described a simple but somewhat inefficient way of spoofing messages using the dead letter queue. T-Rob followed that by outlining an even simpler attack using confirm on arrival reports. In this first post, I’ll try to describe the first exploit and will then follow up with a post describing the exploit described by T-Rob. Please note that none of these two methods rely on any bug in WMQ, the product is working as designed.

This post is in the interest of full disclosure, what you don’t know is hard to protect yourself against.

Spoofing messages using the dead letter queue

Description

WMQ uses a shared queue called the dead letter queue as the ultimate destination for messages that can not be delivered. This might be due to many reasons, but the case of interest here is for applications that can not handle a message (due to for example resource problems or data corruption). In many cases, such an application will choose to store away this message on the dead letter queue to be able to continue processing further incoming messages.

A message stored on the dead letter queue will usually contain a header containing the orginal target queue and queue manager. The purpose of this is to automatically be able to retry the message when whatever the original problem was. The target queue can include the administration queues, or a queue on any other reachable queue manager.

On a typical system, this queue will be named SYSTEM.DEAD.LETTER.QUEUE. On a queue manager that is shared by multiple applications, a very common practice, this means that this queue might be used by several different applications.

WMQ also has what is called dead letter queue handlers, a process running that monitors the dead letter queue for messages and then, using a rules table, decide on what to do with the message. The options includes to retry for a number of times, store it somewhere else, delete it, leave it on the dead letter queue, and so on. A message that can not be successfully retried or deleted will finally be handled by an administrator, for example by fixing the troubling application and the retrying the message.

Now, if applications has put authority on the dead letter queue, it can simply fake the header containing the original target queue. The dead letter queue handler or a unobservant administrator might then try to retry the message by putting it on the faked target queue.

Protect yourself

There are a few, more or less, efficient ways of protecting against this exploit. The methods described below are not mutually exclusive, investigate what the most reasonable solution is in your case.

Don’t give applications put authority on the dead letter queue. For applications that support it, instead create a specific exception queue for only that specific application. For applications that still requires using the dead letter queue, investigate their behavior if they get an security exception when accessing it. If their failure behavior (probably rolling back the message to the original queue) is acceptable, go with that.

Let the source application digitally sign its messages and let the target application confirm the signature. This is a efficient method, albeit sometimes hard to implement due to, for example, the use off-the-shelf applications without such support.

If using a dead letter queue handler, make sure the rules table confirm that the message contain the expected USERID. It should contain the user with which the real source application accesses WMQ. It must not contain the value of any other, possibly hacked application.

Don’t retry messages targeted for the command server or any other administrative funtion.

Let the target application confirm the USERID, in the same fashion as the dead letter queue handler.