This document summarizes the findings from research into security behaviors when using IBM MQ's password authentication (CONNAUTH) feature. It identifies five distinct behaviors exhibited by the interaction between CONNAUTH and CHLAUTH access control rules. The document provides recommendations for mandatory and avoid configurations when using CONNAUTH. It also warns that applying fix packs can cause failures or silently over-authorize users. The summary concludes by thanking two people for their contributions to testing and improving the tools and research presented.

1. (and if you aren't careful may not work at all)
T.Rob Wyatt, Senior Managing Consultant
t.rob@ioptconsulting.com
Follow on Twitter: @tdotrob
MQ Blog: https://t-rob.net
11/30/2016Presented by IBM Middleware User Community, https://imwuc.org

2. This deck is expected to change frequently
over the course of the project. Please check
back for the latest version. Although it will be
posted on IMWUC and Slideshare, the
authoritative source is https://t-rob.net/links
This is v1.0, published on Dec 1, 2016
Known to-do’s as of Dec 1:
 Re-test to eliminate any false results based on lack of backstop rule.
 Re-test to eliminate results of possible MQ Explorer bug re:
Compatibility Mode in early releases.
 Write command-line tools to eliminate dependence on Explorer.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
2

3.  All tools for this project are maintained on GitHub. Please
don’t be shy about sending pull requests.
https://github.com/tdotrob/IBMMQ-passwd-auth
 In consideration of corporate firewall blocking, the research
and results matrix are posted in multiple formats on Google
and for direct download. These are indexed from on my links
page https://t-rob.net/links and will also change frequently.
 Don’t let the fact that I provide consulting services stop you
from contacting me informally to talk about this stuff. I am
not participating in the community to promote my business.
My business arose out of and exists to serve the MQ
community, not the other way around.
@tdotrob, LinkedIn, call 704-443-TROB(8762), or email:
t.rob at IoPTConsulting dot com
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
3

4. Native MQ password authentication (CONNAUTH)
introduced in IBM MQ v8.0 has gotten off to a
rough start. As of Fix Pack 8.0.0.5, the interaction
between CONNAUTH and CHLAUTH has exhibited
5 distinct behaviors. After applying Fix Packs some
of these cause hard failures while others silently
over-authorize client users, leaving the queue
manager exposed.
This webcast will present findings from our
CONNAUTH/CHLAUTH security research as well as
recommendations for MQ users and the audit
community.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
4

5. T.Rob Wyatt is an independent consultant who has
been working with IBM MQ for over 20 years.
Professionally he spends about half his time designing
MQ architectures, clusters and HA solutions, and the
other half focusing on security and figuring out how to
break MQ.
His latest project is mapping out MQ's security
behaviors when using password authentication, which
produced the findings presented in this webinar. T.Rob
is a frequent speaker at IBM conferences and MQ Tech
Conference, a prolific blogger, and was recognized as
an IBM Champion in 2016 for his contributions to the
MQ community.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
5

6.  I’m going to make some claims about what are safe
and unsafe practices regarding CONNAUTH
configuration.
 I’ll justify those with real-life examples.
 There will be a Q&A at the end where any questions
will be answered and I’ll defend any challenges to the
claims.
This is only a checkpoint and new information was
coming to light right up to the webinar deadline. After
the webinar, I’ll post this on my site and keep it up to
date over time. CHECK BACK before distributing or re-
presenting to make sure you have a current copy:
https://t-rob.net/links
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
6

7. Based on my research, I consider the following to be mandatory
configurations when using CONNAUTH.
 ADOPTCTX(YES) in all cases.
 ChlauthEarlyAdopt enabled in all cases.
 Use a version of MQ at which Early Adopt is supported.
 Define Morag’s “Backstop Rule” to establish a deny-by-
default CHLAUTH policy.
 Set PasswordProtection=always in the qm.ini Channels
stanza.
 Use TLS channels.
 Use CHCKCLIENT(REQUIRED)
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
7

8. At the opposite end of the scale are things to
never do with CONNAUTH and CHLAUTH.
 Don’t use permissive ADDRESSMAP rules.
 Don’t use generic PEERMAP rules.
 Don’t patch or upgrade without extensive
testing.
 Don’t disable CHLAUTH.
 Don’t use a USERSRC(NOACCESS) mapping
rule where a BLOCKUSER rule will work.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
8

9. Mandatory configurations
11/30/2016Presented by IBM Middleware User Community, https://imwuc.org 9

10.  With ADOPTCTX(NO) there is no meaningful
connection between the ID authenticated by the
password and that used for mapping and
authorization.
 With ADOPTCTX(NO) it is the client and not the
MQ Admin who decides which ID the QMgr will
act on.
 ADOPTCTX(YES) is the only option that enforces
the authenticated ID be used for OAM
authorization.
 Unfortunately, ADOPTCTX(YES) does NOT enforce
that connection for CHLAUTH rules.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
10

11. As noted in the prior section, ADOPTCTX(YES)
does NOT enforce that CHLAUTH rules operate
against the password-authenticated ID.
 IBM added ChlauthEarlyAdopt to enforce this
behavior.
 Requires the MQ Admin to explicitly alter the
default configuration to obtain relief from a
bug.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
11

12.  Implied by the previous slide.
 Listed here in hopes that a mob of MQ Admins
wielding pitchforks and torches will storm the
castle and demand that the Knowledge Center
track this and other Fix-Pack-specific features
down to the Fix Pack level so that we can
ascertain which provides the minimum level of
support.
(The KC entry for ChlAuthEarlyAdopt keeps disappearing and
reappearing like the palace in Krull. It is currently on this page and
has no mention of which MQ version first delivered it. It does say “To
have the queue manager use this new behavior…” which makes no
sense if you don’t know which Fix Pack delivered it since CONNAUTH
was itself new in v8.0, the version for the page in question.)
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
12

13. The (almost) secure-by-default CHLAUTH posture
originally was to allow connections of non-admin
users from all addresses. Since a new QMgr did not
know about non-admin groups or users they could
not sign on, even after defining new SVRCONN
channels.
The fact that CONNAUTH is set to IDPWOS by
default breaks this assumption!
Now when you define a new SVRCONN the other
defaults allow anyone who can sign onto the MQ
host (and if it uses AD, NIS+, LDAP, etc. that may
be the entire corporate user database) to connect
and nominate mqm as the MCAUSER.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
13

14.  QMgr by default points to IDPWOS AUTHINFO.
 IDPWOS enables password validation by default,
requires it for Admins.
 ADOPTCTX(NO) by default allows the client to set
a user ID other than the one they authenticate
with their password.
 MQ Admin defines SYSTEM.ADMIN.SVRCONN and
a BLOCKUSER that omits *MQADMIN and
suddenly ANYONE can become mqm.
 D’oh!
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
14

15. MQ will encrypt your password when using a v8.0
or higher client and a v8.0 or higher QMgr, but…
 Credentials are in the clear when using clients <
v8.0 in all cases.
 Credentials are in the clear even with clients at
v8.0 and higher in compatibility mode!
Your apps and users will still transmit their ID and
password over the network willy-nilly, but at least
the connection refusal will encourage them to
disable compatibility mode.
This also reduces (but not eliminate) variance in
CHLAUTH behavior across versions and fixes.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
15

16. 11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
16

17. This way when your apps and users are
transmitting their ID and password over the
network willy-nilly in the clear, the MQ Admin can
show steps taken to prevent sniffing them on the
wire.
 TLS encryption protects the credentials.
 Anonymous clients support encryption without
having to provision personal certs at each client.
 Unfortunately, this removes the restriction on
Compatibility Mode so the CHLAUTH behavior
variance you must account for in your CHLAUTH
design more than doubles.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
17

18.  With ADOPTCTX(YES), CHLAUTH rules cease to
perform any mapping whatsoever. This requires
a significantly different CHLAUTH security model
versus when mapping is available.
 The security models that are effective under
mapping and under ADOPTCTX(YES) are
antagonistic toward one another.
 With CHCKCLIENT(OPTIONAL) the client gets to
choose whether to authorize under CHLAUTH
mapping, not the MQ Admin, and it is likely the
CHLAUTH model fails to adequately secure at
least one of these modes.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
18

19. Avoid these like the plague
11/30/2016Presented by IBM Middleware User Community, https://imwuc.org 19

20. Because ADOPTCTX(YES) disables all mapping, rules that filter
on addresses effectively whitelist all IDs that can authenticate
with a password. They may be blocked later by OAM but the
connection itself is whitelisted and hardcoded MCAUSER
values are overridden.
Example: You have a B2B gateway and before CONNAUTH you
used ADDRESSMAP rules to designate some channels as
internal-facing and some as external-facing. Applying that
to a QMgr with CONNAUTH converts those rules so they now
whitelist all password-validated IDs for all internal-facing
and external-facing channels.
They still restrict the channels to the IDs intended only now
the attacker has the means to sign on to any account if they
can obtain the password. Better get your asbestos raincoat
on, the forecast calls for 80% chance of spearphishing attack.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
20

21. Because ADOPTCTX(YES) disables all mapping, rules that filter on
generic certificate Distinguished Names effectively whitelist all IDs
that can authenticate with a cert and a password. They may be
blocked later by OAM but the connection itself is whitelisted and
hardcoded MCAUSER values are overridden.
Admittedly, this is MUCH better than permissive ADDRESSMAP rules,
but if you have something like PEERMAP(“O=YourCompany”) it is
still a much larger population of whitelisted ID than you probably
intended.
Note that even if you use a fully qualified DN, mapping is disabled
and the ID that is authenticated need not have anything to do with
the certificate presented. So if I’m a business partner whose cert
you trust, I can still sign on as you if I know your password.
Did we mention spearphishing attacks?
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
21

22. When I first undertook this research, I got a v8.0.0.0
virtual machine working with several accounts and
CHLAUTH rules, then cloned it 5 more times, once for
each Fix Pack.
All of the resulting VMs worked except for v8.0.0.1.
Although it had worked before the Fix Pack, after the
maintenance and with no modifications to the MQ
Explorer channels, stored IDs or passwords, it refused
to authenticate under CONNAUTH.
Hence the subtitle, “and if you aren't careful may not
work at all”
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
22

23.  To commit to CONNAUTH is to commit to extensive regression
testing after every maintenance or upgrade.
 Due to the increased overhead, it may not be feasible for
auditors and QSAs to enforce the 30/60/90 day security patch
discipline called for by PCI and generally considered Best
Practice.
 If the 30/60/90 day deadlines are to be enforced, consider
disabling CONNAUTH altogether.
 Please consider contributing to the post-patch regression
testing toolset being built on Github:
https://github.com/tdotrob/IBMMQ-passwd-auth
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
23

24.  Because ADOPTCTX(NO) allows the client to
nominate any ID to run under.
 Because ADOPTCTX(YES) overrides the hard-coded
MCAUASER.
 Because SSLPEER doesn’t affect either of the above.
 Because at this point you just ran out of security
controls.
I’d like to think this one didn’t need any justification.
Please try not to disabuse me of that notion.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
24

25.  These rules sometimes operate against the
MQCD user, sometimes against the MQCSP user,
sometimes both.
 When there is any variation at all in behavior, it is
the client and not the MQ Admin who decides
which ID is presented.
 The exact behavior changes across versions and
fixes, and by ChlauthEarlyAdopt settings.
 Whichever ID is ultimately used can be
overridden by an exit.
BLOCKUSER rules are evaluated after all other
rules. Their behavior has not been seen to vary.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
25

26. A Secure By Default CONNAUTH design would immediately
on receipt of the connection request overlay the asserted
User ID with the MQCSP User ID if present, then proceed with
mapping and password validation as usual.
There is no valid use case to implement MQ’s strongest-ever
authentication and then fail to enforce that the authenticated
ID be used for authorization.
The use case that was given (migration) is better handled by
forcing the password-authenticated user ID, and preserving
mapping functionality so the MQ Admin (NOT the client!) can
map the authenticated ID back to wasadmin or whatever it
had been using before.
With that in mind…
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
26

27. …if you can think of even ONE valid use case for
ADOPTCTX(NO) tell me!
Otherwise, please join me in telling, no begging,
IBM to abandon backward compatibility in this
case, make CONNAUTH enforce the authenticated
ID, restore mapping functionality, and return MQ
to a Secure-By-Default posture.
If this is done I can use the improved controls to
duplicate any functionality you currently use
ADOPTCTX(NO) for and will do so, under contract,
for free.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
27

28. More people deserve thanks than can be mentioned but
a couple have gone the extra mile-and-a-half in
support of this particular presentation…
Josh McIver seems to find more security and other bugs
than anyone else I know and has provided extensive
documentation and verified many of the results.
FJ Brandelik (you know him as fjbsaper) dove right into
the code about 30 seconds after it hit Github and gave
it a good test, bug fix, and upgrade.
My eternal thanks to both of you for the assistance and
high expectations for the project.
11/30/2016Presented by IBM Middleware User Community
https://imwuc.org
28