1. Introduction
StruxureWare SCADA Expert ClearSCADA is affected by a remote security bypass vulnerability. This means an attacker could gain unauthorised access to the web server without valid credentials. Systems running StruxureWare SCADA Expert ClearSCADA are at risk, potentially leading to loss of confidentiality, integrity and availability of industrial control systems.
2. Technical Explanation
The vulnerability occurs because the default guest account on the remote web server is not restricted. This allows an attacker to bypass authentication and access sensitive information or functionality. The affected versions are StruxureWare SCADA Expert ClearSCADA prior to version 2010 R3.2 / 2014 R1.1, or versions from 2013 R1 to 2013 R2.1. CVE-2014-5412 describes this issue. An attacker could simply access the web server without providing a username and password, gaining control of the system.
- Root cause: The default guest account has unnecessary privileges.
- Exploit mechanism: An attacker connects to the ClearSCADA web interface without credentials. If the guest account is enabled with access to DBServer, authentication bypass occurs.
- Scope: StruxureWare SCADA Expert ClearSCADA versions prior to 2010 R3.2 / 2014 R1.1 and 2013 R1 – 2013 R2.1 are affected.
3. Detection and Assessment
You can check if a system is vulnerable by confirming the ClearSCADA version and guest account status. A thorough method involves attempting to access the web server without credentials.
- Quick checks: Check the ClearSCADA version in the administration interface or using the command line tools provided with the software.
- Scanning: Nessus vulnerability ID 4755812c and a8f8e976 may detect this issue, but results should be verified manually.
- Logs and evidence: Review ClearSCADA logs for successful logins from the guest account or failed authentication attempts followed by successful access without credentials. Log locations vary depending on configuration.
4. Solution / Remediation Steps
To fix this vulnerability, change the default policy and remove guest account access to DBServer. Follow these steps carefully.
4.1 Preparation
- No services need to be stopped for this remediation.
- Roll back is possible by restoring the backed-up configuration file. A change window may be required depending on your organisation’s policies.
4.2 Implementation
- Step 1: Log in to the ClearSCADA web interface as an administrator.
- Step 2: Navigate to the Security Policies section.
- Step 3: Edit the default policy.
- Step 4: Remove guest account access to DBServer.
- Step 5: Save the changes and restart the ClearSCADA service if prompted.
4.3 Config or Code Example
Before
// Default policy allows guest access to DBServer
AccessRights = {DBServer: true, ...}
After
// Default policy denies guest access to DBServer
AccessRights = {..., //DBServer: false}
4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent this type of issue. Least privilege reduces the impact if an account is compromised. Safe defaults minimise initial exposure. Regular patch cycles ensure systems are up-to-date with the latest security fixes.
- Practice 1: Implement least privilege to limit user access and reduce the potential damage from a successful attack.
- Practice 2: Use safe defaults, such as disabling guest accounts or requiring strong passwords by default.
4.5 Automation (Optional)
5. Verification / Validation
Confirm the fix by checking that guest access to DBServer is disabled. Attempting to log in without credentials should now fail. A simple service smoke test involves verifying core ClearSCADA functionality remains operational.
- Post-fix check: Log in as a standard user and verify you cannot access DBServer.
- Re-test: Repeat the detection steps from section 3; authentication bypass should no longer be possible.
- Smoke test: Verify that data acquisition, alarm handling, and historical trending continue to function correctly.
- Monitoring: Monitor ClearSCADA logs for failed login attempts or unauthorised access attempts.
6. Preventive Measures and Monitoring
Update security baselines to include this configuration change. Consider adding checks in your CI/CD pipeline to prevent the reintroduction of default settings. A regular patch or config review cycle is essential for maintaining a secure environment.
- Baselines: Update your security baseline to require disabling guest access to DBServer on ClearSCADA systems.
- Pipelines: Add checks in your CI/CD pipeline to scan for default configurations and flag any instances of enabled guest accounts.
- Asset and patch process: Implement a regular patch or configuration review cycle (e.g., monthly) to ensure all systems are compliant with security standards.
7. Risks, Side Effects, and Roll Back
Changing the default policy may impact existing integrations that rely on guest access. Ensure these integrations are updated accordingly. If issues occur, restore the backed-up configuration file.
- Roll back: Restore the ClearSCADA configuration from the backup created in step 4.1.
8. References and Resources
- Vendor advisory or bulletin: http://www.nessus.org/u?4755812c
- NVD or CVE entry: CVE-2014-5412
- Product or platform documentation relevant to the fix: http://www.securityfocus.com/bid/69840