LetsDefend — 𝗣𝗛𝗣 𝗖𝗚𝗜 𝗩𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗶𝗹𝗶𝘁𝘆 (easy)

This is an unofficial guide to complete the PHP-CGI(CVE-2024-XXXX) challenge on Let’sDefend.

Challenge Details:

You will confront an attempted exploitation of a newly discovered and unpatched vulnerability (CVE-2024-XXXX) in a critical software component within your organization’s infrastructure. The CVE allows for remote code execution, posing a significant threat if successfully exploited. At 12:05 PM UTC, an alert is generated by the Intrusion Detection System (IDS) and Intrusion Prevention System (IPS), indicating an attack on one of your web servers. Your task is to analyze the provided artifacts, confirm the exploitation attempt, and answer the provided questions.

Let’s get started!
The first thing I will do is get the malicious file onto my own VM (this is just a personal preference, as it’s more comfortable for me this way). However, you can use the VM provided by LetsDefend if you prefer.

Before we start analyzing the question, let’s set ourselves in the position we are currently in:
We don’t know much about the attack exploitation (yet).
The artifacts folder contains the following:

Apache24: Contains the files associated with the Apache Web Server, such as configuration files, access logs, and error logs.
php: Stores files and resources related to the PHP runtime, including executables, configuration files, logs, and temporary files.
prefetch: Holds files that track information about previously executed applications, including their file paths, execution history, and timestamps. These files are used to speed up program startups.

Let’s start with the questions and analyze the exploitation!

1 — What version of PHP was running on the server during the incident?
Answer: 8.2.19

We have two options to get the PHP version of the server.
The first one is, since we have the php.exe file, to execute the command “php.exe -v”

The second option is to open the “snapshot.txt” file in the php folder

2 — When PHP is configured to run as CGI, which directive in httpd.conf specifies the scripts that handle requests for PHP files?
Answer: Action

To answer this, we will go to Apache24 > conf > httpd.conf and scroll down. We will see the following directive

This line configures Apache to use “php-cgi.exe” as the handler for PHP files. When a file with the MIME type application/x-httpd-php-cgi (a PHP file) is requested, Apache will execute php-cgi.exe to process the PHP code and return the output to the client. This setup indicates that PHP is running as CGI on the server.

3 — What is the IP address of the attacker who attempted to exploit our server?
Answer: 192.168.110.1

To answer this question, we will go to Apache24 > logs > access.log

In the log, there are requests from multiple ips, But we can clearly see here that the IP 192.168.110.1 is the one making the malicious requests to the server, such as “POST /upload.php?%ADd+allow_url_include%3D1+-d+auto_prepend_file%3Dphp://input HTTP/1.1”

4 —The attacker targeted a specific page on the server with malicious payloads. Which page did the attacker target with malicious payloads?
Answer: upload.php

As we can see in the log above, the attacker sent the malicious payloads to the “/upload.php ”page

5 — What version of Apache is running on the server?
Answer: 2.4.59

Now, we’ll move on to the error.log. So, Apache24 > logs > error.log.
Once we open it, we’ll see the following at the beginning:

Get 𝐌𝐚𝐭𝐞𝐨 𝐏𝐚𝐩𝐩𝐚’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

6 — The attacker managed to execute commands on the server. What was the first process initiated by the attacker’s commands during their successful attempt?
Answer: whoami.exe

First, let me apply a quick filter so we can have more organized logs.

To answer this quiestion, we’ll need to correlate timestamps, so here a quick explanation of what we’ll do:
The attack took place on 12/Jun/2024:XX:XX:XX +0300. +0300 means it’s 3 hours ahead of UTC (or UTC+3).
My country is on UTC-3 (3 hours behind UTC), so, for example, 12/Jun/2024:14:48:29 is equivalent to 12/Jun/2024:08:48:29 in my timezone.
With this in mind, we’ll check the Prefetch folder (as we mentioned earlier, it contains information about previously executed applications) and compare the executed commands with the attack timestamps.

For the first part of the request, there is nothing significant shown. Let’s keep looking

Here, we can see that the “whoami” command was executed on the target system at the same time as the second part of the attack (12/Jun/2024:15:03:07 +0300), meaning the attack was successful

7 — Before the attacker was detected and blocked, they executed another command, launching a new process. What process was launched by this command?
Answer: calc.exe

As we can see in the logs above, the ‘calc.exe’ process was launched before the attacker got blocked. This is a simple and harmless way for the attacker to confirm that their exploit worked and that they now have control over the target system

8 —What is the CVE number of the exploit used by the attacker?
Answer: CVE-2024–4577

Besides the title spoiling this part, we can perform a Google search with the information we have gained to discover what type of CVE we’ve dealt with.
“CVE PHP CGI 8.2.19 RCE Window”
https://www.vicarius.io/vsociety/posts/php-cgi-os-command-injection-vulnerability-cve-2024-4577

How the attack worked?

The attacker exploited a vulnerability in the PHP server, specifically a misconfiguration of the “allow_url_include” and “auto_prepend_file” directives, to execute malicious code on the server. The attack began with a series of HTTP requests to the “upload.php” file, containing parameters in the URL such as “allow_url_include=1” and “auto_prepend_file=php://input”. These parameters effectively configured the PHP server to execute the content sent in the body of the POST request.

It’s important to understand that the body of the request is where the actual malicious code the attacker wanted to execute resides. While Apache access logs record the URLs and parameters of requests, they do not log the content of the POST request body. This means that although the logs show the attacker sending parameters to “upload.php”, the actual malicious code they executed is not directly visible in those logs.

POST /upload.php?­allow_url_include=1 -d auto_prepend_file=php://input HTTP/1.1
Host: victim.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 1234

<?php system('whoami'); ?>

In this case, the attacker injected malicious PHP code (<?php system(‘whoami’); ?>) into the body of the request. This code was then executed by the PHP server because of the misconfigured parameters. As a result, the attacker was able to execute commands like whoami to retrieve information about the server, and potentially more malicious actions such as launching calc.exe.

URL-Encoded Parameters Used to Bypass Filters:

As we can see in the Apache logs, the attacker used URL-encoded characters to modify the URL and potentially bypass security filters.
The following is an example from the log:

POST /upload.php?%ADd+allow_url_include%3D1+-d+auto_prepend_file%3Dphp://input HTTP/1.1

When dedoced, it might look like this:

POST /upload.php?­allow_url_include=1 -d auto_prepend_file=php://input HTTP/1.1

By using encoded characters like “%AD”, that is a soft hyphen (a non-printable character) and “%3D” (equal sign), the attacker was able to obfuscate their request and bypass filters or validation mechanisms that could otherwise detect and block the attack. Properly configuring server parameters like “allow_url_include” and “auto_prepend_file” and ensuring that URL-encoded requests are properly validated is crucial to preventing such attacks.

TARAAA!
See you on the next one!
Feel free to ask me anything you need 🤠