Let's talk about the bug hidden in plain sight: CVE-2022-3191, found in the Linux version of Hitachi’s Ops Center Analyzer, specifically its “Virtual Storage Software Agent” component. This vulnerability, discovered in versions from 10.8.1-00 up to (but not including) 10.9.-00, allowed any user with local access to browse through log files—and sometimes find gold: *system secrets and credentials*.

What’s Going On?

Some applications are careless when it comes to handling secrets and debugging. In this case, the “Virtual Storage Software Agent” part of Hitachi Ops Center Analyzer was logging *too much*, resulting in sensitive information—like passwords for monitoring connections—printed in log files.

According to Hitachi’s security notice and JPCERT’s advisory, this bug let regular users on the box (Linux OS) read critical data.

Where’s the Danger?

If you have shell access (even as a low-privileged user) on a system running a vulnerable version, these log files are often world-readable. You could simply cat or grep around and pick up admin passwords.

Repositories such as /opt/Hitachi/Analyzer/agent/logs/ (or a similar path) store multiple log files. When software is too chatty, log entries end up looking like this:

2022-09-25 19:11:45,789 INFO  [MonitorThread] Login attempt user=admin password=SuperSecretPass connect=storage01
2022-09-25 19:11:47,123 ERROR [Collector] Failed login for user=admin password=SuperSecretPass connect=storage02

Here’s a red flag: the password appears unmasked.

By default, logs are at

/opt/Hitachi/Analyzer/agent/logs/
# (or check your customized install directory)

Many log messages contain the word “password”. Let's extract them

cd /opt/Hitachi/Analyzer/agent/logs/
grep -i password *.log

Output may look like

Monitor.log:2022-10-04 11:00:00,001 INFO  Login attempt user=admin password=DemoPass connect=prod-storage

Here's a bash script that collects potential hits in one go

#!/bin/bash

LOG_DIR="/opt/Hitachi/Analyzer/agent/logs/"
cd "$LOG_DIR" || exit

# Grep password lines and output context (username, host, timestamp)
for file in *.log; do
    grep -i --color=always "password=" "$file" | tee -a /tmp/hitachi_password_leak.txt
done

echo "Leak results collected in /tmp/hitachi_password_leak.txt"

Scans every .log file for the string password=

- Collects matches in /tmp/hitachi_password_leak.txt (review there!)

Why Is This Bad?

- Horizontal Privilege Escalation: Low-privileged users leapfrog to admins by using stolen passwords

Credential Reuse: Many admins reuse passwords across different services or environments

- Persistence: If logs are long-term archived or shipped off-host, attackers can later snatch credentials from backups

Responsible Disclosure and Fix

- Patched in: *Version 10.9.-00 and up* (Hitachi security site)
- Mitigation: Upgrade the Software Agent component ASAP. If you can’t, lock down log directory permissions:

`bash

chmod 700 /opt/Hitachi/Analyzer/agent/logs
   chown root:root /opt/Hitachi/Analyzer/agent/logs -R

References (Original Sources)

- Hitachi Security Advisory HIRT-2022-0408
- JVN#13540613: Hitachi Security Bulletin
- NVD entry for CVE-2022-3191

Final Words

CVE-2022-3191 shows how careless logging can break security, even in mature enterprise products. Always upgrade, audit your logs, and never store secrets in plain text—even between trusted services.

If your Hitachi Ops Center Analyzer lives on a multi-user Linux box, use this check. You might be surprised what’s hiding in your logs!

Timeline

Published on: 11/01/2022 03:15:00 UTC
Last modified on: 03/01/2023 15:43:00 UTC