How to remediate – Apache Struts 2 < 2.3.33 Remote Code Execution (S2-048)

1. Introduction

Apache Struts 2 < 2.3.33 Remote Code Execution (S2-048) is a critical vulnerability affecting Apache Struts 2 applications. It allows an attacker to execute arbitrary code on the server by sending a crafted message containing malicious field values. This impacts systems running vulnerable versions of the Struts framework, potentially leading to complete system compromise. Confidentiality, integrity and availability are all at high risk.

2. Technical Explanation

The vulnerability stems from an issue within the Struts 1 plugin where it fails to properly sanitize input data passed in ActionMessage objects. This allows for remote code execution when processing malicious payloads. An attacker can exploit this by sending a specially crafted HTTP request with a manipulated field value, triggering the execution of arbitrary commands on the server. The vulnerability is tracked as CVE-2017-9791 and has a CWE score of 20 (Improper Input Handling).

• Root cause: insufficient input validation in the Struts 1 plugin when handling ActionMessage objects.
• Exploit mechanism: An attacker sends a malicious HTTP request containing a crafted ActionMessage object with an exploitable field value, leading to remote code execution. For example, sending a raw message with a specially formatted OGNL expression.
• Scope: Apache Struts 2 versions prior to 2.3.33 are affected.

3. Detection and Assessment

To confirm vulnerability, check the installed Struts version. A thorough assessment involves reviewing application logs for suspicious activity related to ActionMessage processing.

• Quick checks: Check the Struts version using the following command if running from a shell within the application context: java -jar struts-console.jar --version
• Scanning: Nessus plugin ID 99484 can detect vulnerable versions of Apache Struts 2.
• Logs and evidence: Examine application logs for errors related to ActionMessage processing or OGNL expression evaluation. Look for unusual activity in the servlet container logs.

java -jar struts-console.jar --version

4. Solution / Remediation Steps

Apply the recommended patch or upgrade to a secure version of Apache Struts 2. Follow these steps for remediation.

4.1 Preparation

• Ensure you have access to the necessary deployment tools and permissions. A roll back plan involves restoring from the pre-update backup.
• A change window may be required depending on your environment and approval processes.

4.2 Implementation

1. Step 1: Upgrade Apache Struts 2 to version 2.3.33 or later. This can typically be done through a package manager (e.g., Maven, Gradle) or by replacing the existing Struts JAR files with updated versions.
2. Step 2: Restart the affected application server(s) for the changes to take effect.

4.3 Config or Code Example

Before

<dependency>
  <groupId>org.apache.struts</groupId>
  <artifactId>struts2-core</artifactId>
  <version>2.3.32</version>
</dependency>

After

<dependency>
  <groupId>org.apache.struts</groupId>
  <artifactId>struts2-core</artifactId>
  <version>2.3.33</version>
</dependency>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this type of vulnerability. Least privilege limits the impact of successful exploitation. Input validation prevents malicious data from being processed. Patch cadence ensures timely updates and mitigates known vulnerabilities.

• Practice 1: Implement least privilege principles to restrict application access rights, reducing potential damage if exploited.
• Practice 2: Enforce strict input validation on all user-supplied data to prevent malicious payloads from reaching the Struts framework.

4.5 Automation (Optional)

# Example Ansible playbook to upgrade Struts 2
- name: Upgrade Struts 2 version
  hosts: webservers
  tasks:
    - name: Update Struts dependency in Maven pom.xml
      replace:
        path: /path/to/pom.xml
        regexp: '<version>2.3.[0-9]{1,2}</version>'
        replace: '<version>2.3.33</version>'
    - name: Restart application server
      service:
        name: tomcat
        state: restarted

5. Verification / Validation

• Post-fix check: Execute java -jar struts-console.jar --version and confirm the output shows version 2.3.33 or higher.
• Re-test: Re-run the earlier detection method (Struts version check) to verify that the vulnerable version is no longer present.
• Monitoring: Monitor application logs for any errors related to ActionMessage processing or OGNL expression evaluation.

java -jar struts-console.jar --version

6. Preventive Measures and Monitoring

Update security baselines to include the latest Struts version requirements. Incorporate static application security testing (SAST) into CI/CD pipelines to identify vulnerable code patterns. Implement a regular patch review cycle to address known vulnerabilities promptly.

• Baselines: Update your security baseline or policy to require Apache Struts 2 version 2.3.33 or later.
• Pipelines: Add SAST checks to your CI/CD pipeline to detect vulnerable code patterns related to input validation and OGNL expression evaluation.
• Asset and patch process: Establish a regular patch review cycle (e.g., weekly) to identify and address known vulnerabilities in Apache Struts 2 and other components.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 2: Unexpected behavior in existing code that relies on specific Struts features. Mitigation: Review and update any affected code to ensure compatibility with the new version.
• Roll back: 1. Restore the previous version of Apache Struts 2 from backup. 2. Restart the application server(s). 3. Verify that the application