La seguretat i el MQ

Top

It worked out that I was able to go to Defcon 15, meet Martyn Ruks and attend his "Jumping MQ" session. The interesting thing is that Martyn is a security consultant and penetration tester and knew very little about WMQ going in. Instead of starting with the IBM-provided tools like the WMQ client code, he sniffed the network packets and reverse-engineered the protocol. He then wrote some Python code to simulate a client channel, including the SSL handshakes. With this Python code he was able to remotely connect to a QMgr, create a WMQ service to execute OS level commands and then put messages onto an initiation queue which also ran OS-level commands.

If you've never been to a Defcon, think of the "Lone Gunmen" guys from X-Files and then multiply by a few hundred. Then add in girls in short skirts, combat boots and pink hair. There were a few suits at the convention but they were the Feds giving the "Meet the Feds" sessions. Upstairs in the "WiFi Cafe" the intent was not to provide Internet access but rather they were having contests to see who could successfully exploit vulnerabilities in Wireless Equivalent Protocol and other such games of sport. Now that you have a picture of the crowd, know that the session on MQ was in one of two main tent rooms and it was packed. People started showing up 10 minutes prior to the end of the previous session to get seats and by the time Martyn started, they were stacked up along the walls. It was pretty scary to look over this particular crowd with the realization that there was so much interest in WMQ. If your shop has taken a relaxed stance on WMQ security, this would be a good time to assess and remediate.

In his research, Martyn discovered two interesting vulnerabilities working directly with the protocol. First, it was possible to bypass a server-side security exit and second that it was possible to bypass the MCAUSER setting in the channel. These are two things we rely heavily on for WMQ security so this was distressing news. The good news though is that he reported these to IBM and a new fix was released as of last Friday that addresses both issues. Go to...

http://www-1.ibm.com/support/docview.wss?rs=171&context=SSFKSJ&dc=D600&uid=swg21266976&loc=en_US&cs=UTF-8&lang=en ...for details.

There were no other exploits or recommendations that the community here does not already know about. Martyn talked about how the default configuration was vulnerable and advised folks to turn on security. He advised to use SSL, MCAUSER, low-privileged accounts for trigger monitors, not to use channel auto-definition and so forth. Because the target audience has almost no familiarity with WMQ, the session was fairly high-level. But Martyn did post links to the Infocenter, Perl classes and some tools so folks could get up to speed quickly.

Unlike many other products such as many web servers and operating systems, there are no publicly available WMQ security baselines or penetration test tools so security is still more of an art than a science - and a black art at that. Martyn's presentation positioned WMQ as running mission critical applications in large corporations. Outside of people who use it, WMQ has had a very low profile up to now. These three factors combine to make WMQ a very interesting product for this community. From their perspective, large attractive corporate targets use the software, there is a tremendous potential for harm (or gain), security is poorly practiced and unstructured, and the first hackers to publish tools, exploits and hacks in this space can make a name for themselves - and land jobs as security consultants. Who knows...by this time next year, the "WMQ Cafe"?

-- T.Rob & his excelent page

He is tentatively scheduled to speak at Defcon 16 in August 2008.

Typically the high-level review requires

• the WMQ object definitions,
• the output of amqoamd -m -s (dspmqaut? dmpmqaut?)
• and the contents of /etc/group and /etc/passwd (or the equivalent for the platform).

ObjType = the type of object on which to make the inquiry. Possible values are:

v6 v7

Use the setmqaut command to change the authorizations to a profile, object or class of objects. Authorizations can be granted to, or revoked from, any number of principals or groups.

"Table 24 shows the authorities that can be given to the different object types", MQ v6 System Admin Guide, page 386 [409/647].

On UNIX® systems, all authorities are held by user groups internally, not by principals. This has the following implications:

• If you use the setmqaut command to grant an authority to a principal, the authority is actually granted to the primary user group of the principal. This means that the authority is effectively granted to all members of that user group.
• If you use the setmqaut command to revoke an authority from a principal, the authority is actually revoked from the primary user group of the principal. This means that the authority is effectively revoked from all members of that user group.

url - thanks (again) T-Rob !

Alguns exemples :

• dump initial
• remove all
• allow few

[And-Sec, T42:\And\Seguretat\]

Top

The WebSphere MQ Explorer GUI provides a user-friendly way to administer your queue managers. With a little work, you can use it as a read-only 'viewer' instead. If you have some staff who don't have authority to make changes to the WMQ network, but need them to be able to monitor what is happening, this would let them use WMQ Explorer to do it. If your staff without authority to make changes are the ones with less WebSphere MQ experience, then this might be a useful approach.

In this post I'll walk through the steps required to set this up for a single queue manager, and highlight a couple of potential problems to watch out for.

Steps to carry out on the machine hosting the queue manager

1. Create a user - making sure that the user is not a member of the mqm group
2. Start a channel listener for the queue manager
3. Create a server-connection (SVRCONN) channel on the queue manager - setting the MCAUSER attribute to the username defined in step 1
4. Use setmqaut to specify which objects you want the user to be able to see

What permissions do you need to grant?

Firstly, you need permission to connect to the queue manager:

Next, you need to give permission to the queues that WMQ Explorer will need:

Then, you could give access to all objects of a certain type - such as being able to display all channels:

You might want to include additional permissions, such as the ability to browse messages on queues, or inquire their attributes:

Origin URL

Own code [T42:\MQ\CFG\SAG\Seguridad\QM2]

En una AIX, sorprenentment, les dues darreres sentencies es canvien per fer servir grups, i es converteixen (amqoamd -m -s) en :

Complementari de :

Per verificar la seguretat de una instalació, o per moure-la a una altra màquina, farem servir amqoamd -m %GESTOR% -s.

El fitxer de sortida es una llista de comandes SETMQAUT que podem llençar directament !

Top

I'd like to have a (Delphi ? NO - Java) program that allows me to do (via GUI) :

• MQ Client Connect, using User='ABCD' ;
• MQ Inquiry (DLQ name)
• put a command message into SYSTEM.ADMIN.COMMAND.QUEUE to alter DLQ to be "get(disabled)".
• MQ Inquiry (all Q's depth) = amqsailq.c
• MQ Open Q
• MQ Browse Q
• MQ Read Q
• MQ Create Q - MQCMD_CREATE_Q PCF command = amqsaicq.c
• MQ Write Q
• MQ Delete Q - MQCMD_DELETE_Q PCF command
• mind mqJexplorer !

By the moment (Ago 08) I have :

• T42:\MQ\Eines\Security_Scanner\SS.CMD that uses MQ samples to do it (few dont work).
  • \MQ\Eines\AMQSAILQ_Display_All_Queues_Depth\amqsailqc.exe using SYSTEM.DEF.SVRCONN channel {system object}
  • \MQ\Eines\AMQSAILQ_Display_All_Queues_Depth\amqsailqc.exe using SYSTEM.ADMIN.SVRCONN channel {explorer}
  • \MQ\Eines\AMQSAILQ_Display_All_Queues_Depth\amqsailqc.exe using SYSTEM.BKR.CONFIG channel {toolkit}
• Java working sample (improve to GUI via Eclipse ?)

T42 has MQ client, and we try SAVEQMGRC from VM : {"SS 1"}

Mind 2035 help.

A usual customer wants to prevent :

• [1] remote connection to a queue manager
• [2] remote admin : create/delete queue
• [3] remote put/get messages into/from a queue
• [4] to attach a queue manager to a cluster
• [5] full rights explorer (MQ or MQjExplorer)

[1-2-3] : MCAUSER @ SVRCONN.

[4] With SSL one can set up SSLPEER to prevent QMgrs from joining the cluster. You just have to have the cluster name in an OU so you can filter on it. Then only issue appropriate Distinguished Names to things you want in the cluster. Unfortunately, this requires the entire cluster to have SSL.

Sample : amqscnxc.c

• (*) MQCD.UserIdentifier[12]
• (*) MQCD.MCAUserIdentifier[12] -> surt el usuari de Guindous.
• (*) MQCD.LongMCAUserIdPtr & length
• (*) MQCD.LongRemoteUserIdPtr & length
• (*) User Data Exit -> problemes compilació MQ v 6.0.2.3

RogerLacroix diu de fer servir AlternateUserId url

Com omplir LongMCAUserIdPtr ? amqsspin.c :

Each command and its parameters are sent as a separate command message containing a PCF header followed by a number of parameter structures. The PCF header identifies the command and the number of parameter structures that follow in the same message. Each parameter structure provides a parameter to the command.

Sample : AMQSAICQ.C

Book : MQ Administration Interface Programming Guide and Reference, SC34-5390-01; search for "MQCMD_CREATE_Q".

Top

Chapter 8 - Keeping clusters secure, MQ v6 queue manager clusters, SC34-6589.

To prevent selected queue managers from sending messages to your queue manager, define a channel security exit program on the CLUSRCVR channel definition. Write a program that authenticates queue managers trying to send messages on your cluster-receiver channel and denies them access if they are not authorized. Channel security exit programs are called at MCA initiation and termination.

Stopping unauthorized queue managers sending messages to your queue manager, page 103/201, MQ v6 queue manager clusters, SC34-6589.

If you want to ensure that only certain authorized queue managers attempt to join a cluster, you must either use a security exit program on the cluster-receiver channel, or write an exit program to prevent unauthorized queue managers from writing to SYSTEM.CLUSTER.COMMAND.QUEUE.
Do not restrict access to SYSTEM.CLUSTER.COMMAND.QUEUE such that no queue manager can write to it, or you would prevent any queue manager from joining the cluster.

It is difficult to stop a queue manager that is a member of a cluster from defining a queue. Therefore, there is a danger that a rogue queue manager can join a cluster, learn what queues are in it, define its own instance of one of those queues, and so receive messages that it should not be authorized to receive.

To prevent a queue manager receiving messages that it should not, you can write:

• A channel exit program on each cluster-sender channel, which uses the connection name to determine the suitability of the destination queue manager to be sent the messages.
• A cluster workload exit program, which uses the destination records to determine the suitability of the destination queue and queue manager to be sent the messages
• A channel auto-definition exit program, which uses the connection name to determine the suitability of defining channels to the destination queue manager

Preventing queue managers joining a cluster, page 105/201, MQ v6 queue manager clusters, SC34-6589.

Top

I'd like to have a (Delphi ? NO - Java) program that allows me to do (via GUI) :

• create a queue manager
• enter my queue manager into a cluster
• display all queue managers in the cluster
• connect to a remote queue manager
• display its queue names and its depths
  See amqsailq.c (uses MQAI).
• create a local queue with a given (remote) name

The prescribed method here is to create an ID and group. The group has only the one service ID in it. The service ID is a non-login ID and it's primary and only group is the one we just created. So in UNIX terms you have ID:group = cms:cms. So far, so good.

The next thing is to set the permissions for the MCAUSER to connect:

In this case whether you use JMS has nothing to do with it because it is the MCA that is doing the inquire. That is how it finds out the name of the DLQ. Again, so far, so good.

Next you need permissions to put the message on the queue:

The +setall allows the MCA to set the fields in the MQMD such as the User ID and the time stamp to match the values from QM1. This is what I believe that you are missing.

To address another concern from the thread, as long as the MCAUSER is the *only* thing using the cms service account, we like +setall. It is the only way that the MCA can create the message header to match the values of the message on the originating QMgr. And we know that the MCA will never do anything but connect, inquire and put.

Java code:

JMS code:

See: WebSphere MQ Using Java, SC34-6591-02 (WMQ v6.0)

Original article.

• Mastering Eclipse V3.4, Part 1: the Eclipse workbench
  VM 6.0.2.5,c:\> java -version java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)

• Eclipse FAQs

• Search developerWorks for Eclipse

• Java tutorial (SWING = GUI toolkit). Use "java + [swing | awt| swt | jface]"

• Swing tutorial

• how to verify OAM is not disabled ?

  See amqzfuma.exe is running.

• how to disable OAM ?
  windows : SET MQSNOAUT=yes unix : export MQSNOAUT=yes

  When an OAM is removed, it cannot be put back on an existing queue manager. This is because the OAM needs to be in place at object creation time. To use the WebSphere MQ OAM again after it has been removed, the queue manager needs to be rebuilt.

Preventing security access checks

• how to enable Security Events ?
  What queue will they use ?

• what data is needed to join a cluster ?
  detail

  How to manage :

  • Allowing only selected queue managers to join a cluster
  • Forcing unwanted queue managers to leave a cluster

  QM clusters, SC34-6589-00, chapter 8.

  Have a look : Enabling SSL in an existing MQ cluster

• 2035 MQRC_NOT_AUTHORIZED problems ? Use MQS_REPORT_NOAUTH ! Insert in ".profile" of "mqm" user (probably in /var/mqm/ dir), and make sure qmgr runs under "mqm" user.
  export MQS_REPORT_NOAUTH=TRUE

  URL

  This is the behavior when this variable is enabled :

  • When the userid exists in the local server host and does NOT belong to a group listed as valid:
    The error log of the queue manager shows 2 error messages:
    AMQ8077: Entity '<insert one>' has insufficient authority to access object '<insert two>'. EXPLANATION: The specified entity is not authorized to access the required object. The following requested permissions are unauthorized: <insert three> AMQ9209: Connection to host 'ipAddress' closed.

  • When the userid does NOT exist in the local server host:
    the error log of the queue manager shows 1 error message:
    AMQ9209: Connection to host 'ipAddress' closed.

    Note that AMQ8077 is not written.

Top

• si fem servir SSL en un cluster, why tots els gestors han de tenir el mateix certificat ?

  Resposta : per poder establir canals tots contra tots.

Top

• when you first create the queue manager's objects, change
  ALTER CHANNEL(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('nobody')