In the world of enterprise communication, IBM MQ is a backbone for message queuing, ensuring reliable message delivery between applications. However, vulnerabilities can shake even the strongest foundations, and one such flaw is CVE-2022-22325, found in IBM MQ for HPE NonStop 8.1.. This CVE highlights how sensitive information could leak through stack traces, potentially giving away secrets to local users who shouldn’t see them.

Let’s break down this vulnerability, show how it can be exploited, and discuss how you can protect your system.

What is CVE-2022-22325?

CVE-2022-22325 is an information disclosure vulnerability discovered in IBM MQ for HPE NonStop version 8.1.. When certain types of errors occur, IBM MQ might generate a detailed stack trace that accidentally includes sensitive information. If a local user has access to these stack traces, they could obtain:

Other confidential data tied to MQ processing

While this does *not* allow remote code execution or privilege escalation, it can significantly aid in further attacks, such as privilege escalation or lateral movement.

How the Stack Trace Information Leak Happens

Under certain error conditions—such as misconfiguration, bad input, or failed operations—IBM MQ logs a stack trace that’s more verbose than intended. If the log files storing these traces are accessible to local users, anyone on the system might peek into these traces.

Here’s what typically happens

1. An application triggers an exception/error within MQ.

Example Code Snippet: Stack Trace Log Extract

Below is an anonymized example of what a problematic stack trace might look like (for illustration only):

[15:15:27] MQQueueManagerConnection failed at /mqsource/qmconn.cpp:530
Exception: MQJE001: An MQException occurred: Completion Code 2, Reason 2035
MQJE036: Queue Manager rejected connection attempt
	at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:319)
	at com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:1152)
Caused by: java.lang.SecurityException: Not authorized to connect
	User: mqmuser
	Host: /export/home/mqm/scripts/connect.sh
	Password: SuperSecretPass123

Notice how the username and even a (dummy) password appear? Such information should *never* be present in logs.

Exploiting the Vulnerability (for Learning Purposes Only)

While CVE-2022-22325 does not allow a remote attacker direct access, here's how a local user might "exploit" the issue:

`

cd /var/mqm/qmgrs/QMGRNAME/errors/

Harvest Sensitive Data:

Any secrets present are visible. A persistent attacker might automate this process using a simple script.

For example, a bash command to scrape possible secrets

grep -E 'user|password|secret|token' /var/mqm/qmgrs/QMGRNAME/errors/AMQERR*.LOG

> Important: This scenario assumes the attacker already has local login and file-read privileges on the host. Strict file permissions and auditing can mitigate much of this risk.

Upgrade to a version where IBM has patched the exposure of sensitive data in stack traces.

IBM Security Bulletin for CVE-2022-22325

`shell

chown mqm:mqm /var/mqm/qmgrs/QMGRNAME/errors/AMQERR*.LOG
  chmod 640 /var/mqm/qmgrs/QMGRNAME/errors/AMQERR*.LOG

Configure Logging Levels:

Lower the verbosity of logged errors if possible. Do not include sensitive information in error output.

Regularly Audit Logs:

Scan logs for presence of secrets or unexpected stack traces and remove / redact these where appropriate.

References

- IBM Security Bulletin: Sensitive information exposure due to verbose stack trace in IBM MQ for HPE NonStop (CVE-2022-22325)
- CVE Details: CVE-2022-22325
- X-Force Exchange: 218853
- IBM MQ Documentation

Summary

CVE-2022-22325 is a good example of how even "simple" logging can become a risk. If you run IBM MQ for HPE NonStop 8.1., review your log file access, clean out sensitive traces, and patch your system immediately.

Stay secure, follow IBM’s advisories, and always consider what’s hiding in your logs!


*This write-up is exclusive and aims to make technical content digestible for all IT practitioners. Share responsibly and ensure your systems—and logs—are safe from snooping eyes.*

Timeline

Published on: 05/13/2022 17:15:00 UTC
Last modified on: 05/23/2022 19:04:00 UTC