How to remediate – HTTP Proxy Arbitrary Site/Port Relaying

1. Introduction

The HTTP Proxy Arbitrary Site/Port Relaying vulnerability allows a remote proxy server to connect to arbitrary ports, potentially enabling attackers to bypass firewalls and access sensitive internal services. This poses a risk to the confidentiality, integrity, and availability of systems behind the proxy. Systems commonly affected include web proxies and application delivery controllers. A successful exploit could allow an attacker to establish connections to internal resources they shouldn’t be able to reach.

2. Technical Explanation

The vulnerability occurs because the remote proxy does not adequately restrict which ports it allows connections to. This means that anyone using the proxy can request connections to any port, including those used by sensitive services like SMTP (port 25) or database servers. An attacker could exploit this by crafting a malicious HTTP request through the proxy to connect to an internal service directly.

• Root cause: Missing access control lists (ACLs) preventing connections to unauthorized ports.
• Exploit mechanism: An attacker sends an HTTP GET request via the vulnerable proxy, specifying an arbitrary port and hostname. For example: ‘GET http://cvs.nessus.org:110’.
• Scope: Web proxies, application delivery controllers, and any system acting as a forward proxy without proper ACL configuration.

3. Detection and Assessment

To confirm vulnerability, check the proxy’s configuration for port restrictions. A thorough assessment involves attempting to connect through the proxy to known internal ports.

• Quick checks: Check the proxy’s documentation or UI for settings related to allowed/blocked ports and access control lists (ACLs).
• Scanning: Nessus plugin ID 30829 can identify this vulnerability. Other scanners may have similar checks.
• Logs and evidence: Examine proxy logs for requests attempting connections to unusual or sensitive ports. Look for entries showing successful connections to internal services from external sources via the proxy.

# Example command placeholder:
# No specific command available, check proxy configuration files directly.

4. Solution / Remediation Steps

Implement access control lists (ACLs) on the proxy server to restrict connections to authorized ports only. This prevents unauthorized access to internal services.

4.1 Preparation

• Ensure you have a rollback plan in place by keeping a copy of the original configuration file.
• A planned maintenance window may be required to minimize disruption. Approval from relevant IT teams might be needed.

4.2 Implementation

1. Step 1: Edit the proxy’s configuration file (e.g., squid.conf, Apache httpd.conf).
2. Step 2: Add ACL rules to explicitly deny connections to unauthorized ports. For example, block access to ports below 1024 unless specifically allowed.
3. Step 3: Restart the proxy service for the changes to take effect.

4.3 Config or Code Example

Before

# No specific ACL rules defined for port restrictions.

After

acl disallowed_ports port <1024>
http_access deny disallowed_ports
http_access allow localhost
http_access allow 192.168.1.0/24 # Example allowed network
http_access deny all

4.4 Security Practices Relevant to This Vulnerability

Implementing least privilege and input validation are key practices for mitigating this type of vulnerability. Regularly patching the proxy server is also essential.

• Practice 1: Least privilege – restrict access to only necessary ports and services, reducing the impact if exploited.
• Practice 2: Input validation – validate all user-supplied input to prevent malicious requests from being processed.

4.5 Automation (Optional)

# Example Ansible snippet:
- name: Configure proxy ACLs
  lineinfile:
    path: /etc/squid/squid.conf
    regexp: '^acl disallowed_ports'
    line: 'acl disallowed_ports port <1024>'
  notify: Restart Squid
handlers:
  - name: Restart Squid
    service:
      name: squid
      state: restarted

5. Verification / Validation

Confirm the fix by attempting to connect through the proxy to a blocked port and verifying that the connection is denied. Then, re-test connectivity to allowed ports.

• Post-fix check: Attempt to connect to port 25 via the proxy using telnet or netcat. The connection should be refused. Expected output: “Connection refused”.
• Re-test: Run the earlier detection method (attempting a connection to an internal port) and confirm that it is now blocked.
• Smoke test: Verify that legitimate users can still access allowed websites and services through the proxy.
• Monitoring: Monitor proxy logs for denied connections to unauthorized ports, which could indicate ongoing attempts to exploit the vulnerability.

# Example post-fix command and expected output:
telnet  25
Trying ...
Connection refused

6. Preventive Measures and Monitoring

Regularly update security baselines to include port restriction policies. Implement checks in CI/CD pipelines to ensure that proxy configurations adhere to these standards. Maintain a consistent patch management process for the proxy server.

• Baselines: Update your security baseline or policy (for example, CIS control 5) to require explicit ACLs on all proxy servers.
• Pipelines: Add checks in CI/CD pipelines to scan proxy configurations for missing or incorrect ACL rules.
• Asset and patch process: Implement a regular patch review cycle of at least monthly for the proxy server.

7. Risks, Side Effects, and Roll Back

Incorrectly configured ACLs could block legitimate traffic. A rollback plan involves restoring the original configuration file.

• Roll back:
  1. Stop the proxy service.
  2. Restore the original configuration file from backup.
  3. Restart the proxy service.

8. References and Resources

• Vendor advisory or bulletin: Nessus Plugin 30829
• NVD or CVE entry: CVE-2010-4675
• Product or platform documentation relevant to the fix: Squid Proxy Documentation