How to remediate – WAS Target Scanning for PCI

1. Introduction

The WAS Target Scanning for PCI vulnerability reports http and https addresses of a scanned system. This means information about your web server’s endpoints is being exposed, potentially aiding attackers in identifying targets. It affects systems running any web server accessible via HTTP or HTTPS. A successful exploit could lead to information disclosure.

2. Technical Explanation

This vulnerability isn’t a traditional flaw but rather the result of standard scanning activity revealing system details. An attacker doesn’t actively exploit this; they simply gather information from the scan results. There are no specific CVEs associated with this report type, as it is an informational finding. A simple example would be an attacker using the reported URLs to identify potential entry points for further attacks like cross-site scripting or SQL injection.

• Root cause: The web server is accessible via HTTP and HTTPS, allowing scanning tools to enumerate its endpoints.
• Exploit mechanism: An attacker uses a scanner to discover http and https addresses of the system. This information is used for reconnaissance.
• Scope: Any web server running on platforms supporting HTTP or HTTPS.

3. Detection and Assessment

You can confirm exposure by reviewing scan reports from your vulnerability management tools. A quick check involves simply browsing to the reported URLs in a web browser.

• Quick checks: Use a web browser to access the listed http and https addresses.
• Scanning: Nessus plugin ID 64378 can identify this issue, as an example.
• Logs and evidence: Web server logs will show requests to these URLs.

curl -I 

4. Solution / Remediation Steps

The solution involves reviewing the necessity of exposing all endpoints via HTTP and HTTPS, and potentially restricting access or removing unnecessary services.

4.1 Preparation

• Ensure you have a rollback plan to restore the original configuration if needed. A change window may be required depending on service criticality.

4.2 Implementation

1. Step 1: Review all http and https endpoints listed in the scan report.
2. Step 2: Identify any unnecessary or unused endpoints.
3. Step 3: Remove or restrict access to those identified endpoints via your web server configuration (e.g., using .htaccess files, firewall rules, or application settings).

4.3 Config or Code Example

Before

# Allow access to all URLs
Allow from all

After

# Only allow access from specific IPs or networks
Allow from 192.168.1.0/24
Deny from all

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this type of information exposure. Least privilege is important, as limiting access reduces the attack surface. Regular vulnerability scanning helps identify exposed endpoints.

• Practice 1: Implement least privilege principles by restricting web server access to only necessary IPs and networks.
• Practice 2: Conduct regular vulnerability scans to identify all publicly accessible endpoints.

4.5 Automation (Optional)

If using infrastructure-as-code, you can automate endpoint restrictions.

# Example Ansible task to restrict access via firewall
- name: Restrict web server access
  firewalld:
    zone: public
    rule: add
    source: 192.168.1.0/24
    service: http
    permanent: true
    state: enabled

5. Verification / Validation

Confirm the fix by re-running your vulnerability scan and verifying that unnecessary endpoints are no longer reported. A simple smoke test involves accessing key web pages to ensure functionality remains intact.

• Post-fix check: Re-run the initial curl command; it should return a 403 Forbidden error for restricted URLs.
• Re-test: Run your vulnerability scanner again and confirm that the reported endpoints have been removed or reduced.
• Smoke test: Access key web pages (e.g., homepage, login page) to verify they are still accessible.
• Monitoring: Monitor web server logs for unexpected access attempts to restricted URLs as an example.

curl -I  # Expected output: 403 Forbidden

6. Preventive Measures and Monitoring

Update your security baselines to include endpoint restrictions. Incorporate vulnerability scanning into your CI/CD pipelines.

• Baselines: Update your web server security baseline to enforce least privilege access controls.
• Pipelines: Add a SAST or DAST scan step in your CI pipeline to identify exposed endpoints during development.
• Asset and patch process: Review web server configurations regularly as part of your asset management process.

7. Risks, Side Effects, and Roll Back

• Roll back: Restore your web server configuration from the pre-change snapshot.

8. References and Resources

Link only to sources that match this exact vulnerability.

• Vendor advisory or bulletin: Check your web server vendor’s documentation for endpoint restriction guidance.
• NVD or CVE entry: Not applicable, as this is an informational finding.
• Product or platform documentation relevant to the fix: Refer to your web server’s documentation on access control configuration.