ibm mq connauth/chlauth doesn't work like you think it does (and if you aren't careful may...

(and if you aren't careful may not work at all)

T.Rob Wyatt, Senior Managing [email protected]

Follow on Twitter: @tdotrobMQ Blog: https://t-rob.net

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

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 Communityhttps://imwuc.org

2

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


3

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.


4

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.


5

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


6

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)


7

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.


8

Mandatory configurations

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

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.


10

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

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


12

The (almost) secure-by-default CHLAUTH postureoriginally 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.


13

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!


14

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.


15


16

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.


17

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.


18

Avoid these like the plague

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

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.


20

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?


21

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”


22

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


23

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.


24

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.


25

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…


26

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


27

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.


28

ibm mq connauth/chlauth doesn't work like you think it does (and if you aren't careful may...

Technology