How to remediate – IBM WebSphere Application Server Liberty Detection

1. Introduction

IBM WebSphere Application Server Liberty is a web application server running on the remote host. This software provides a platform for building and deploying Java-based applications. A publicly accessible instance could allow attackers to identify the version and potentially exploit known vulnerabilities. Confidentiality, integrity, and availability may be impacted if exploited.

2. Technical Explanation

IBM WebSphere Application Server Liberty is running on the remote host. Attackers can remotely identify the software and its version. While this does not represent an immediate compromise, it allows them to target known vulnerabilities in specific versions of the application server. There are no publicly available CVEs associated with simply detecting the presence of the software.

• Root cause: The web application server is accessible from a network.
• Exploit mechanism: An attacker can use tools like `curl` or `nmap` to identify the service and version. This information is then used to search for known vulnerabilities.
• Scope: IBM WebSphere Application Server Liberty instances running on any platform are affected.

3. Detection and Assessment

Confirm whether a system is vulnerable by checking if the application server is accessible and identifying its version.

• Quick checks: Use `curl -I ` to check for the presence of the Liberty header.
• Scanning: Nessus plugin ID 16847 can detect IBM WebSphere Application Server. This should be used as an example only, and results verified manually.
• Logs and evidence: Examine web server logs for requests to application paths associated with WebSphere Liberty.

curl -I https://example.com/wasliberty

4. Solution / Remediation Steps

The following steps outline how to address the detection of IBM WebSphere Application Server Liberty.

4.1 Preparation

• Dependencies: Ensure you have access to the application server configuration and web server settings. A roll back plan involves restoring from the pre-change snapshot.
• Change window: Coordinate with relevant teams if necessary, especially for production systems.

4.2 Implementation

1. Step 1: Review network access rules to restrict external access to the application server.
2. Step 2: If external access is required, ensure the application server is running behind a web proxy or firewall.

4.3 Config or Code Example

Before

# Web server configuration allowing direct access to Liberty application paths
location /wasliberty {
    proxy_pass http://localhost:9080;
}

After

# Web server configuration restricting direct access, proxying only from internal networks
location /wasliberty {
    allow 127.0.0.1/32; # Allow access from localhost
    deny all;
}

4.4 Security Practices Relevant to This Vulnerability

List only practices that directly address this vulnerability type. Use neutral wording and examples instead of fixed advice.

• Least privilege: Restrict network access to the application server to only authorized users and systems.
• Network segmentation: Isolate the application server from public networks whenever possible.

4.5 Automation (Optional)

# Example Ansible playbook snippet for firewall rule update
- name: Update firewall rules
  firewalld:
    zone: public
    rule: deny
    port: 9080/tcp
    permanent: true
    state: enabled

5. Verification / Validation

Confirm the fix worked by verifying that external access to the application server is restricted.

• Post-fix check: Use `curl -I ` from an external network and confirm a connection timeout or error message.
• Re-test: Re-run the initial curl command to verify that the Liberty header is no longer accessible externally.
• Smoke test: Verify internal access to the application server remains functional.
• Monitoring: Monitor firewall logs for blocked connections to port 9080 or other relevant ports.

curl -I https://example.com/wasliberty # Expected output: Connection timed out

6. Preventive Measures and Monitoring

Suggest only measures that are relevant to the vulnerability type.

• Baselines: Update security baselines to include network access restrictions for application servers.
• Pipelines: Integrate network configuration checks into CI/CD pipelines.
• Asset and patch process: Regularly review asset inventories and ensure all systems are properly configured.

7. Risks, Side Effects, and Roll Back

List known risks or service impacts from the change.

• Risk or side effect 1: Restricting network access may impact legitimate users if not properly configured.
• Roll back: Restore the original web server configuration or firewall rules.

8. References and Resources

Link only to sources that match this exact vulnerability.

• Vendor advisory or bulletin: https://developer.ibm.com/wasdev/websphere-liberty/