Jan 8
The loss of an account
icon1 Niklas | icon2 Tags: . | icon4 01 8th, 2008| icon3No Comments »

Today I noticed that I could no longer sign into my ICQ account. Someone has hacked it, changed the password, the password reset questions and the account details. I’ve had the account since 1995 with the same lousy password all the time so I was probably begging for this to happen. Looking through the ICQ forum, hacking accounts for selling them back seems to be a common thing. Getting any help from the ICQ support seems unlikely:

Out of the view of an hacker it is to be expected for not being in his interest to have your customized data in the aquired ICQ account. Due to that a hacker at least will probably alter profile and contact list information or even erase it in it’s whole. Therefor you may not and in no means are warranted to reaquire any ICQ account you once owned and cannot proove ownership, aswell as ICQ won’t provide any help with reaquiring an ICQ account as you always may register a new one.

Of course, registering a new account also means figuring out who was on your old friends list and add those back. In my case, I have no clue. That means their users might get tempted into buying back their accounts from hackers. This in turn makes this a lucrative market for hackers. All in all it lowers the value of the ICQ network. Why the support would not help in getting hacked accounts back is beyond me. The ICQ support should be able have the old account details, including the security questions, available which would make it possible for them to prove the ownership. However, they chose not to. As I won’t be buying back my account, that means one less account to keep track of. And one less user for ICQ, not that I was a paying customer anyways.

Instead, feel free to add me on GTalk (protocol7@gmail.com) or MSN (niklas@protocol7.com).

Technorati Tags: , ,

Nov 28
Easier certificates for MQ
icon1 Niklas | icon2 Tags: , . | icon4 11 28th, 2007| icon31 Comment »

Update: I’ve posted a follow up to this post with an important addition to the script to create your CA certificate.

The last couple of days I’ve been hard at work with setting up SSL for WebSphere MQ for a customer. A major part of that is creating certificates. WMQ uses the IBM security toolkit, GSKit. My previous experience with GSKit is not the best, I’ve found that it works inconsistently between versions and platforms and contains frequent bugs. Working with this time, the inconsistencies seems to still be there, but at least many of the bugs are now gone. One of the problems is that some GSKits doesn’t work with keys/certificates created with the Java keytool which has previously been my weapon of choice (with the Keystore Explorer GUI).

Finally giving up on keytool, I retreated to using the GSKit command line tool, gsk7cmd. Working with gsk7cmd is not the most pleasant experience (almost as bad as OpenSSL). Therefore, I’ve created a set of Linux shell scripts targeted for a streamlined flow for creating certs for WMQ. They are made available under the ASL 2 license. This is how they work.

Create a directory on some server where you like to create your keys. Copy the scripts to your directory. Edit the scripts to update some generic configuration, currently the DN used and the expiration time for the certificates.

Now start out by running create-ca.sh:

./create-ca.sh mySecretPassword

Make sure you choose a strong password. The command will create a CMS key store containing your CA root certificate. Save it somewhere safe.

Then, for each queue manager (or client), run:

./create-key.sh MyQueueManager mySecretPassword
or
./create-key.sh MyClientApplication mySecretPassword

This will create a directory containing a key created for your queue manager. Its certificate will be signed by the CA root key previously created.

If, for some reason you can not create the keys this way, try creating them on the target platform. For example, I failed to get any externally created keys working on iSeries, instead I had to use the DCM tool on the iSeries box. In this case, create the key and export a certificate request (I’ll write down the details for doing this on iSeries if anyone is interested). Save the certificate request in your keys directory created at the begining of this howto. Name it <queue manager name in lower case>.p10. Run:

./sign-key.sh MyQueueManager mySecretPassword

It will create a certificate response in the file called <queue manager name in lower case>.p7r. Import this together with ca_cert.crt on your target platform.

If your client happens to be a Java client, you need the key store in JKS format. To convert it, run the following command:

./convert-to-java.sh MyQueueManager mySecretPassword

Note that the signing steps does make a huge assumption. A CA must use a unique serial number for each certificate it signs. I didn’t want the overhead of keeping track of this. Instead I use a random number for the serial number. This means that if you sign lots of certs with your CA, you might very well get collisions. If you got that many certs, you probably need a better tool :-)

These scripts uses some ideas from the scripts published by Dale Lane. Thanks! If you want to port these scripts to some other platform, I will happily accept them into SVN. Same goes for bugs and improvements of course.

Technorati Tags: , , , ,

Nov 27
Lousy password policy
icon1 Niklas | icon2 Tags: . | icon4 11 27th, 2007| icon3No Comments »

Today I received an account for checking my account status for a credit card. On first login I had to change to generated password they sent me to something of my own choice. However, their password policy seems a bit awkward to me. Translated from Swedish:

The new password must consist of at least 6 characters (a-z and 0-9) and may not have more than two of the same characters in a row. The password must contain at least one digit, but no more than three digits in a row. It must be no longer than 44 characters.

Having these onerous rules leads to two things, both reducing security:

  • None of my usual passwords match the rules (usually due to containing characters not oncluded in a-z and 0-9. That means I have to write down this password to have a chance of remembering it. In my case that means PasswordSafe, but for most people I suspecting it might mean a sticky note, and probably not in their wallet.

  • The rules actually reduce the number of possible passwords, leading to easier brute force attacks.

I don’t really understand the motivation behind them. If they has at least inhibited the common passwords people use, but no.

Sep 18
MQ broken on video
icon1 Niklas | icon2 Tags: , , . | icon4 09 18th, 2007| icon31 Comment »

The session at Defcon where Martyn Ruks describes his findings about WebSphere MQ security is now online at Google Video. I’ve previously covered the presentation, but it’s way more interesting to hear the presentation in addition to the published slides. Thanks to the anon commenter who pointed me to the video.

Technorati Tags: , , ,

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 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.

Jul 24
Defcon MQ sequrity session
icon1 Niklas | icon2 Tags: , . | icon4 07 24th, 2007| icon33 Comments »

Looks like there is going to be a very interesting session on WebSphere MQ security at Defcon. The presenter is Martyn Ruks who has a history of investigating IBM protocols. As WMQ and WMQ security in particular is of great interest to me, this session sounds like something really worth visiting. Too bad I won’t be anywhere near Vegas at the time, and I’m assuming Defcon won’t publish any video of the presentations. However, Martyn has published a presentation he held at Defcon 14 so I keep my hopes high.

Based on the published abstract, it doesn’t sound like any real new attack will be shown, but rather that Martyn will go through the usual, poor ways that WMQ are set up from a security standpoint. Fact is that at most places I’ve seen WMQ installed it has been wide open to any attacker. Most companies seems to think that it’s used internally and therefore is safe. Besides, it’s pretty invisible to most people, just humming along doing its work. Hackers on the other hand most surely know about it and how to attack it. And those of us consulting on WMQ really needs to learn the best ways of protecting an installation. And, I do think that IBM needs to do a better job of securing WMQ out of the box, currently it’s unsecure by default, something which should not be acceptable these days.

Update: this presentation is now available over at Google Video.

Technorati Tags: , , ,

Oct 22
OpenID in the news
icon1 Niklas | icon2 Tags: , , . | icon4 10 22nd, 2006| icon3No Comments »

Some exciting news on OpenID adoption the last couple of days (for me anyways). First of, Technorati is now supporting OpenID for claiming your blog with more stuff coming soon. The Techcrunch article about Technorati also mentions that the big players are participating in discussions on OpenID. I think it would make perfect sense for someone like Google or Yahoo do like Verisign and start providing OpenID identies to their already existing users.

The Technorati page contained a link to a new OpenID plugin for Wordpress. This one is way more clever than the one I previously used and requires no theme hackery what so ever (just install and you’r done). So, I reverted my hacked theme back to square one and installed the plugin. All done and OpenID authentication is working like a charm. At least that’s what my tests show, feel free to give me feedback on any troubles or improvements!

Last but not least, Normal Walsh seems to like OpenID as well. I’ll leave with his final words that perfectly well reflects my sentiments.

Next time you build a web application that needs a login, consider OpenID.

Aug 21
OpenID on protocol7
icon1 Niklas | icon2 Tags: , . | icon4 08 21st, 2006| icon31 Comment »

I spent last night working on OpenID support for comments on this blog. If you haven’t taken a look at OpenID yet, you probably should. OpenID is a truly distributed identification system. By providing a URL, an OpenID consumer can then verify with an OpenID server that you really ”are” that URL, the server will also provide you with the possibility of deciding which consumers you want to share your identity with. And, with the addition of the Simple Registration extension, you can also provide personal details (such as your nickname and email) if you so like.

Since I’m running Wordpress, I started googling for for plugins, finding quite a few different versions. After some messing around, I finally chose the version provided by Stephan Paul Weber, which in turn is based on the work of Alexander Nikulin. The changes I’ve done are miniscular in comparison with the work done by Alexander and Stephan, please give credit where credit is due.

The plugin provides both a consumer for use with post comments and an OpenID server. However, for the server there are multiple free options around the web which are more fully featured so I choose not to use that part of the plugin. Instead, I’m using the excellent service over at myopenid.com. Since the server is hardcoded into the plugin, this meant that I had to start hacking away at the source. And while I was at it I also fixed two other issues I had with it: didn’t work with my anti-spam plugin and most of all, didn’t support Simple Registration. The latter meant that any comment someone would add would use the OpenID URL for the name, instead of, well, the persons name. Also, it didn’t support getting the persons email either. No good. It also had some minor bugs that I really needed to fix.

Two hours later, the plugin now support Simple Registration, so adding a comment will now (granted that your OpenID server support Simple Registration and that you approve of providing this information) automatically retrieve your nickname and email and use those in the comment (of course, email is not actually published on the site). Very simple, very slick. Please try it out and give me feedback on how I can improve it! If your OpenID server does not support Simple Registration, the comment consumer should fall back to your URL. Or, you can still comment by only providing your name, email and site, just like before.

I won’t package up and release my version of the plugin just yet since I’m not that confident in that I’ve made all the necessary changes. Still, if you would like to play around with it, feel free to email me or leave a comment on this post and I’ll be happy to send it to you.

Next up, see if it’s possible to convince the K2 developers to include support for the OpenID plugin into the theme like they do for many other plugins. That would be outstanding as it would remove the need for hacking the theme as you have to do today.

« Previous Entries