How to remediate – ThoughtWorks GoCD Web interface detection

1. Introduction

ThoughtWorks GoCD Web interface detection identifies instances of ThoughtWorks GoCD running and accessible via its web interface. This matters because GoCD is a CI / CD server which, if compromised, could allow attackers to modify build pipelines and deploy malicious code. Systems usually affected are those used for software development and continuous integration. A successful exploit could lead to loss of confidentiality, integrity, and availability of the software delivery process.

2. Technical Explanation

The vulnerability occurs because GoCD is detectable via its web interface without authentication. An attacker can identify a running instance simply by accessing it over HTTP or HTTPS. There is no specific CVE associated with this detection, but it represents an information disclosure risk that could lead to further attacks. An attacker might use this information to target the server with credential stuffing or exploit known vulnerabilities in GoCD itself. Affected versions are all those where the web interface is publicly accessible.

• Root cause: The web interface responds predictably, identifying it as a ThoughtWorks GoCD instance.
• Exploit mechanism: An attacker sends an HTTP request to the server and analyses the response headers or content for GoCD-specific identifiers. For example, accessing the root URL might reveal version information.
• Scope: All publicly accessible ThoughtWorks GoCD instances are affected.

3. Detection and Assessment

Confirming vulnerability involves checking if the web interface is reachable and identifiable. A quick check can be done via a browser, while thorough assessment requires network scanning.

• Quick checks: Access the GoCD server’s URL in a web browser. Inspect the page source or response headers for “GoCD” strings.
• Scanning: Nessus plugin ID 163895 can identify ThoughtWorks GoCD. This is an example only, and results should be verified.
• Logs and evidence: Web server access logs will show requests to the GoCD URL.

curl -I https://your-gocd-server.example.com

4. Solution / Remediation Steps

Fixing this issue involves restricting network access to the GoCD server. This prevents external attackers from identifying and targeting it.

4.1 Preparation

• Ensure you have documented roll back procedures in case of issues. A simple roll back is to restore access rules.
• Changes should be made during a planned maintenance window with appropriate approval from IT management.

4.2 Implementation

1. Step 1: Configure the firewall to allow only trusted IP addresses or networks to access the GoCD server on ports 80 and 443.
2. Step 2: Verify that external access is blocked by attempting to connect from an untrusted network.

4.3 Config or Code Example

Before

# Allow all access on ports 80 and 443 (example iptables rule)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

After

# Allow access only from trusted IP address (example iptables rule)
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -j DROP

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege is key, as it limits the impact of exposure. Network segmentation also helps isolate vulnerable systems.

• Practice 1: Implement least privilege network access rules to restrict who can connect to sensitive services like GoCD.
• Practice 2: Use network segmentation to isolate development and CI / CD environments from production networks.

4.5 Automation (Optional)

# Example Ansible playbook snippet to configure firewall rules
- name: Configure GoCD firewall rules
  firewalld:
    zone: public
    rich_rule: 'rule family="ipv4" source address="192.168.1.0/24" port protocol=tcp port=80 accept'
    permanent: true
    state: enabled

5. Verification / Validation

Confirming the fix involves verifying that external access is blocked and GoCD remains functional for trusted users.

• Post-fix check: Attempt to connect to the GoCD server from an untrusted network. The connection should be refused or time out.
• Re-test: Repeat the quick check (browser access) from an untrusted network. It should no longer resolve the web interface.
• Smoke test: Verify that users on trusted networks can still log in and run builds as expected.
• Monitoring: Monitor firewall logs for blocked connections to ports 80 and 443, indicating attempts to access GoCD from untrusted sources.

curl -I https://your-gocd-server.example.com # Should return connection refused or timeout

6. Preventive Measures and Monitoring

Updating security baselines and incorporating checks into CI / CD pipelines can prevent similar issues. Regular patch reviews are also important.

• Baselines: Update your network security baseline to include restrictions on access to CI / CD servers.
• Pipelines: Add static analysis or vulnerability scanning steps in your CI pipeline to identify exposed services.
• Asset and patch process: Implement a regular review cycle for server configurations and network rules.

7. Risks, Side Effects, and Roll Back

Blocking legitimate users is the main risk. Incorrect firewall configuration could disrupt service. Roll back involves restoring the original firewall rules.

• Risk or side effect 2: Service disruption due to incorrect firewall configuration. Mitigation: Test changes in a non-production environment first.
• Roll back: Restore the original firewall rules by removing the new rules and re-enabling any previously disabled ones.

8. References and Resources

• Vendor advisory or bulletin: https://www.gocd.org/