How to remediate – Hazelcast Wire Protocol Detection

1. Introduction

A listening data clustering service was detected, specifically the Hazelcast Wire Protocol. This means a system is running Hazelcast and accepting connections over its network protocol. While not directly exploitable in itself, it indicates a potential attack surface if exposed to untrusted networks. Confidentiality, integrity, and availability could be at risk if an attacker gains access to the cluster.

2. Technical Explanation

The Hazelcast Wire Protocol is used for communication between nodes in a Hazelcast data clustering environment. The vulnerability occurs when this protocol is exposed without appropriate network restrictions. An attacker gaining access could potentially execute arbitrary code within the cluster, leading to data breaches or denial of service. There is no known CVE associated with simply listening on the port; however, exploitation relies on vulnerabilities within Hazelcast itself.

• Root cause: The Hazelcast service is configured to listen on a network interface accessible from outside its intended environment.
• Exploit mechanism: An attacker could connect to the exposed Hazelcast instance and attempt to exploit known vulnerabilities in the Hazelcast software or configuration.
• Scope: Systems running Hazelcast versions 3.x, 4.x, and 5.x are affected if configured to listen on publicly accessible interfaces.

3. Detection and Assessment

You can confirm whether a system is vulnerable by checking for the listening service and identifying its version. A thorough method involves network scanning and analysis of Hazelcast configuration files.

• Quick checks: Use netstat -tulnp (Linux) or netstat -ano | findstr "LISTENING" (Windows) to check for a process listening on port 5701, the default Hazelcast port.
• Scanning: Nessus plugin ID 16289 can detect exposed Hazelcast instances. This is an example only and may require updates.
• Logs and evidence: Check system logs for Hazelcast startup events indicating the listening interface.

netstat -tulnp | grep hazelcast

4. Solution / Remediation Steps

Fixing this issue involves restricting network access to the Hazelcast service or disabling it if not required. These steps should be small, testable and safe to roll back.

4.1 Preparation

• A change window may be required depending on the impact of stopping the Hazelcast service. Approval from system owners might be needed.

4.2 Implementation

1. Step 1: Configure the Hazelcast firewall to allow connections only from trusted IP addresses or networks.
2. Step 2: If the service is not required, stop and disable the Hazelcast service.
3. Step 3: Restart the Hazelcast service to apply the changes.

4.3 Config or Code Example

Before

# hazelcast.xml (default configuration)
<network auto-detection="true" >
  <join>
    <tcp-ip/>
  </join>
</network>

After

# hazelcast.xml (restrict network access)
<network auto-detection="false" >
  <interfaces>
    <interface name="*">
      <inbound-ports>5701</inbound-ports>
      <allowed-connections>
        <ip-address>192.168.1.0/24</ip-address>
      </allowed-connections>
    </interface>
  </interfaces>
</network>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege is key, limiting the impact if exploited. Network segmentation reduces exposure and input validation prevents unsafe data from reaching the service.

• Practice 1: Least privilege – run Hazelcast with a dedicated user account with minimal permissions.
• Practice 2: Network segmentation – isolate Hazelcast within a restricted network segment, limiting external access.

4.5 Automation (Optional)

# Example Ansible playbook snippet to configure firewall rules
- name: Configure Hazelcast Firewall Rules
  firewalld:
    zone: public
    port: 5701/tcp
    permanent: true
    state: enabled
    source: 192.168.1.0/24

5. Verification / Validation

Confirm the fix by checking that only trusted IP addresses can connect to Hazelcast. Re-run the earlier detection method to verify the service is no longer exposed. A simple smoke test involves verifying core cluster functionality.

• Post-fix check: Use netstat -tulnp (Linux) or netstat -ano | findstr "LISTENING" (Windows) and confirm Hazelcast is listening only on the expected interface.
• Re-test: Re-run the initial netstat command to ensure no unexpected interfaces are listening on port 5701.
• Smoke test: Verify that applications relying on Hazelcast can still connect and access data.
• Monitoring: Monitor firewall logs for blocked connection attempts from untrusted sources as an example alert.

netstat -tulnp | grep hazelcast

6. Preventive Measures and Monitoring

Update security baselines to include Hazelcast network restrictions. Add checks in CI/CD pipelines to prevent exposing the service unnecessarily. Implement a regular patch or configuration review cycle.

• Baselines: Update your security baseline with a requirement for restricted network access on Hazelcast instances.
• Pipelines: Include static analysis of infrastructure code (IaC) to detect exposed ports and services.
• Asset and patch process: Review Hazelcast configurations regularly as part of your asset management or vulnerability scanning program.

7. Risks, Side Effects, and Roll Back

Restricting network access could disrupt applications relying on Hazelcast if not configured correctly. Incorrect firewall rules can lead to service outages. To roll back, revert the firewall changes or restore from a snapshot.

• Risk or side effect 1: Disrupted application connectivity – ensure trusted IP addresses are included in the firewall configuration.
• Roll back:
  1. Step 1: Revert the firewall changes.
  2. Step 2: Restart the Hazelcast service.
  3. Step 3: If necessary, restore from a system snapshot.

8. References and Resources

• Vendor advisory or bulletin: http://www.hazelcast.com/