The state of WebSphere MQ security today
As part of IBM's Software Services for WebSphere (ISSW), I travel to various customer sites and help them with WebSphere MQ. Although it is rarely listed in my requirements, I always ask to perform a security assessment. After all, if someone thinks their installation is more secure than it actually is, this is definitely something they should know about. In some cases, the WebSphere MQ network was unsecured by choice because the data was not mission critical or sensitive. But most of the time, the administrator had configured OAM authorization profiles (and in many cases SSL as well) believing the messaging network to be secure, when in fact it was quite easy for me to gain access. If my experience is representative of even the smallest proportion of WebSphere MQ installations out there, then we all need to take a second look at our WebSphere MQ security.
So what happened?
This is too broad a question to provide a definitive answer, but I can tell you what I've seen.
One customer I visited had taken great pains to document that any SVRCONN channel that was created should have a low-privileged ID coded into the channel's MCAUSER. They even documented that the SYSTEM.DEF.SVRCONN should be disabled with an invalid ID in the MCAUSER. But they mistakenly left SYSTEM.AUTO.SVRCONN unprotected everywhere, including in production. The user knew how to authorize the client channels, but not enough about what to authorize and why. It is not good enough to learn security by rote; the underlying principles must be understood and applied beyond the textbook examples.
Another administrator had created several client connection channels and configured them using SSL. Developers could connect through an SSL tunnel, with their access controlled by OAM profiles. But this system trusted whatever ID was presented and so it was a simple matter to for the developer to present a different ID, even an administrative one. The reference manuals explain that the ID presented by the client channel must be known to the target QMgr to gain access, and they also describe SSL configuration in detail. This administrator had done exactly what the manual said, but did not achieve the desired result because he did not fully understand the interactions between these two systems.
To address this concern, we need to do a little myth-busting to clear up some common misconceptions and apply these lessons-learned to real-world situations. But before forging ahead, a quick review.
Basic security concepts
Authentication provides some level of assurance that an identity is genuine. Many degrees of authentication are possible:
At one end of the spectrum lies anonymity, or lack of authentication: we don't know who you are and we don't care.
Above that is simple assertion, which is where you tell me who you are and I accept your claim at face value. Think of this as the "honor system."
Further up the chain is the ubiquitous challenge/response that requires both an ID and a password.
Finally, there is strong authentication in which an identity is verified using two or more methods, such as a password and a cryptographic key.
An authentication domain provides a context within which an ID can be verified. A standalone UNIX® server is its own authentication domain. User IDs and passwords stored in its local files and are meaningless in any other context, such as on a different server. There can be larger authentication domains comprised of multiple servers, and some examples of these include UNIX NIS and Microsoft® Windows® Active Directory.
Cross domain authentication is when an identity is authenticated outside the domain that contains the resource and is then passed inside. This technique is most effective when the remote domain is trusted and can itself be authenticated.
The purpose of authorization is to control access to resources on a per-ID, per-role, or per-profile basis. Authorization is an absolute concept where either a "Yes" or "No" answer is returned for any access request. A given resource may support many different functions (CONNECT, OPEN, CLOSE, and so on) and many different options (INPUT, OUTPUT, BROWSE, INQUIRE, and so on), but the response to an authorization request always boils down to "Yes" or "No."
The most common mistakes in configuring WebSphere MQ security lie in not understanding the difference between authorization and authentication, or making incorrect assumptions about how these functions are implemented. Now that we have working definitions for these terms, let's look at some of the misconceptions that lead to vulnerabilities.
Myth #1: WebSphere MQ API calls are authenticated
WebSphere MQ provides only authorization during API calls. In the case of local processes, authentication is performed by the underlying OS. This is usually sufficient, as long as root access is not widely available. But when messages originate on a different QMgr and arrive over a channel, the ID is authenticated remotely, if at all. The trap here is in failing to recognize that cross-domain authentication is taking place.
With the default channel settings of PUTAUT(DEF)and MCAUSER(' '), messages arrive with full administrative authority. For this to be secure:
- The authentication and the authorization must occur on the remote system, and
- We must trust the remote system.
For example, if a low-privileged ID on the remote system has been authorized to place messages directly onto the transmit queue, then that user can address the messages to any arbitrary queue on our local QMgr and no further authorization takes place. Removing authorization to the transmit queue forces the user to put messages only onto QRemote definitions, thus limiting messages to specific authorized destinations.
We can set PUTAUT(CTX) in the channel to force local authorization, but this requires every authorized ID to be registered in the local authentication domain. For many users of WebSphere MQ whose networks include a mix of platforms, such as Windows, UNIX, and mainframe systems, this is simply not practical. But if your shop is one using PUTAUT(CTX), let me tell you how I usually break in during a security assessment: I define an SDR channel on my laptop with the same name as your RCVR and send messages using a commonly used administrative ID. This takes advantage of the fact that the remote QMgr where authentication was to have taken place is trusted but not authenticated. Cross-domain authentication only works if you can both trust and authenticate the remote domain.
Address this problem by configuring SSL to authenticate channel connections so that messages arrive only from trusted systems. Using PUTAUT(DEF), set MCAUSER to a low-privileged non-login ID that is owned by the WebSphere MQ administration team, then authorize that ID to the application queues and the DLQ. This is equivalent to using a blank MCAUSER, in that only one authorization profile is used, but at least it is a low-privileged profile. If clustering is used, you must also authorize the low-privileged MCAUSER to the SYSTEM.CLUSTER.COMMAND.QUEUE. Do not authorize it to any transmit queues. Instead, if multi-hop routing is required, use QRemote definitions.
Myth #2: Using SSL in combination with OAM provides strong security
Configuring SSL to filter on the distinguished name in a certificate provides an effective form of authentication. The authorization policies defined to the Object Authority Manager (OAM) control access based on user IDs and group membership. The trap here is to believe that the combination of the two will provide a secure configuration. What many people do not realize is that the two functions never interact! While it is an essential tool in limiting who we let connect to a channel, SSL functionality does not extend to API calls, nor does it guarantee that the ID in the MQMD corresponds to the owner of the certificate.
Consider the case that a certificate is issued to developer "Joe" who uses a client channel to connect to the QMgr. The administrator creates OAM profiles to allow Joe to connect to the QMgr and access specific queues. This is a common configuration to enable the use of WebSphere MQ Explorer from developer desktops. Unfortunately, SSL does not check that the ID Joe uses to connect is his own. In fact, there is no association whatsoever of Joe's user ID to his SSL certificate. Joe can easily change the ID that is presented when he connects, and if he uses an administrative ID he will obtain full administrative privileges.
Now that we understand that SSL authentication does not extend to API calls, let's clarify exactly what it does do with regard to OAM:
- When configured to filter on certificate distinguished names, SSL assures that inbound connections originate from trusted systems (although we probably still need to set MCAUSER to a low-privileged value).
- SSL enables us to use PUTAUT(CTX) when those trusted systems are in a compatible authentication domain.
- When communicating with untrusted systems such as a B2B interface, SSL assures that connections originate from a specific untrusted system.
The security configurations mentioned in Myth #1 all apply when using SSL. You still need a way to enforce a low-privileged access policy on inbound messages, and that is usually through MCAUSER.
Myth #3: Remote systems can only connect through the prescribed channels
OK, this is not really a myth in the sense that people think about it and believe it to be true. The problem here is that many people just haven't stopped to think about it at all. I know of a case where a vendor had set up each of their customers with dedicated SSL protected SDR/RCVR channel pairs. The idea was that no client would be able to impersonate another because each channel had a unique low-privileged MCAUSER which restricted inbound messages to specific queues.
But the vendor had made a faulty assumption about how WebSphere MQ works: that the customers would use only the channel assigned and that this would be guaranteed by SSL. In fact, SSL authenticates only the channels where it is configured and does nothing to prevent users from connecting to any channels left unprotected. The vendor was very surprised one day to find that a client had connected to their QMgr with full administrative authority using WebSphere MQ Explorer and the SYSTEM.ADMIN.SVRCONN channel. Having configured SSL for their customers and believing them to be secure, the vendor had overlooked the fact that SSL does not restrict which channel the client can use.
Any QMgr that accepts connections from systems not under local control is by definition untrusted, and untrusted systems should be locked down tighter than most. When allowing connections from untrusted systems, disable all SYSTEM.* channels and protect the remaining channels -- even internal ones -- with both SSL and MCAUSER. If a channel is required for remote administration, configure it with SSL to filter the certificate DN and accept connections from administrative users only.
Be aware that data thieves are becoming more sophisticated every day. Assume that they know these techniques and will use them against you. Many shops start with a baseline of an unsecured trusted network and make business cases for exceptions where greater security is required. Making security the exception rather than the rule means that it will occasionally be overlooked. Whether it happens accidentally or intentionally to meet timelines and budgets is irrelevant if the vulnerability is exploited. Instead, the baseline configuration should call for a completely secure system with the additional cost in time, administration, or tools factored into the project up front. If you then overlook something and accidentally secure low-risk data, so what?
What you should not do is use these techniques to perform a security test without permission. You are subject to the same laws as would a data thief. The fact that you caused no damage and did not steal any data is not only irrelevant, it may actually be hard to prove! Make sure your company or business partner knows you plan to perform a security test before you do it.
But do take the time to asses your security. While it is impossible to cover this topic adequately in this limited space, the most common problems I've seen can be addressed using these examples, and with them you should be able to plug the most glaring security holes. If you need additional help, consider taking a class, attending a WebSphere conference or engaging assistance from ISSW.
- WebSphere MQ documentation library
- WebSphere MQ Security (SC34-6588-01)
- WebSphere MQ System Administration Guide (SC34-6584-01)
- WebSphere MQ Script (MQSC) Command Reference (SC34-6597-01)
- WebSphere MQ Clients (GC34-6590-01)
- WebSphere MQ Intercommunication (SC34-6587-00)
- IBM developerWorks WebSphere