Network
How to detect Apache HTTP Server Exploitation
With recent news of the critical, zero-day vulnerability Apache Log4Shell, we explore how to detect and protect your Apache HTTP servers.
Save to Folio
On December 9, news that a vulnerability in Apache Log4j, a commonly used logging package for Java, was found. If exploited, the vulnerability, officially identified as CVE-2021-4428 and dubbed Log4Shell, can result in remote code execution (RCE) by sending crafted log messaged. If you’re using any of the affected products (Apache Struts, Apache Solr, Apache Druid, Elasticsearch, Apache Dubbo, and VMware vCenter), you can use our Log4j vulnerability tester to identify any vulnerable server applications.
Similar sever, unauthenticated vulnerabilities (CVE-2021-41773, CVE-2021-42013, CVE-2021-40438) in Apache HTTP Server were found in October. Like Log4Shell, these flaws allowed for RCE when Common Gateway Interface (CGI) scripts were enabled for aliased paths for files outside of the alias-like directories, as well as server side request forgery (SSRF) attacks. Trend Micro Research also reported on the abuse of GitHub and Netlify platforms for mining XMR cryptocurrency on vulnerable hosts, targeting a slew of products with widely circulated public exploits.
As Log4Shell news continues to develop, this blog looks at how to detect and protect against Apache vulnerabilities from October using a unified SaaS platform.
Vulnerability Brief
CVE-2021-41773 and CVE-2021-42013:
These CVE IDs track the path traversal vulnerabilities found in Apache HTTP Server which allow attackers to map URLs to files/directories outside of the web root. In certain configurations where CGI scripts are enabled for these paths, one can achieve RCE on the vulnerable server. Using CGIs, compiled programs and scripts on the server (eg. /bin/sh) can be used to handle users’ requests. The ‘mod_cgi’ module processes the URI and executes it as a child process. The POST data of the request is processed as the input arguments to the called function.
Inherently, the default configuration of Apache HTTP Server doesn’t allow for exploitation of these two vulnerabilities.
In the above two requests and responses, we see the attacker fingerprinting vulnerable servers by running the ‘echo’ command. We observed successful exploitation attempts which led to cryptominers raking up compute on the vulnerable hosts.
CVE-2021-40438:
This CVE tracks the vulnerability posed by the ‘mod_proxy’ module in Apache HTTP Server (versions before 2.4.49). In CWE-918 Server-Side Request Forgery (SSRF) attack, a malicious actor can forward the request to an origin server of their choice
In this attempt, we observe attackers attempting to fetch Amazon Elastic Compute Cloud (EC2) instance meta data from the instance meta data service (IMDS) on the link-local IPv4 address 169.254.169.254. Had this attempt successfully returned the different fields from IMDS if the usage was not restricted to IMDSv2, attackers could have enumerated permissions for the API keys and could go on to exploit security misconfigurations (if any) in the AWS account.
This vulnerability in Apache HTTP Server has also been recently highlighted by the German cybersecurity authority Bundesamt fur Sicherheit in der Informationsyechnik (BSI) for active exploitation in the wild.
Detection of CVEs
To detect critical flaws before they’re exploited, we use Trend Micro Cloud One™, a security services platform for cloud builders. Composed of seven services, this platform enables developers to build quickly and securely, granting security teams peace of mind that security is baked in from build time to runtime. Trend Micro Cloud One is integrated with Trend Micro Vision One™, which leverages its industry-leading XDR capabilities to collect and correlate across multiple security layers.
Think of Trend Micro Cloud One as your security camera system, and Trend Micro Vision One is the security app on your phone. Although you have multiple cameras, the app consolidates all your notifications and streams into one feed, making it easier to see your total security picture. Similarly, Trend Micro Cloud One services scan files, images, containers, and even open source code in your cloud environment of choice, and Trend Micro Vision One ties everything together in one straightforward dashboard. You can even choose how your team and security teams receive alerts by integrating with preferred communication channels.
In this scenario, we used Trend Micro Cloud One™ – Network Security and Trend Micro Cloud One™ – Workload Security to make detections. Network Security adds a layer of protection between the vulnerable Apache HTTP Server, while Workload Security ensures your valuable containers and datacenters are secured. Network Security continually scans and inspects ingress and egress traffic while leveraging protocol analysis, anomaly detection, indicators of compromise (IoC) blocking, and other methods to detect malware.
After a detection is made by Workload Security, you can customize post-scan actions to quarantine and further investigate the detected threat. The following is a list of Network Security and Workload Security filters for detecting vulnerabilities:
Workload Security –
Intrusion Prevention module:
- 1011171 - Apache HTTP Server Directory Traversal Vulnerability (CVE-2021-41773 and CVE-2021-42013)
- 1009040 - Identified Directory Traversal Sequence In URI
- 1011183 - Apache HTTP Server Server-Side Request Forgery Vulnerability (CVE-2021-40438)
Network Security –
- 1125: HTTP: ../.. Directory Traversal (covers both CVE-2021-41773 and CVE-2021-42013)
- 40421: HTTP: Apache HTTP Server Long UDS Path Name Proxy Request
In the above triggers, we observe the detections from Workload Security for the vulnerabilities.
Ok great, Trend Micro Cloud One has detected the vulnerabilities, but what’s next? That’s where Trend Micro Vision One comes into play. By correlating the Apache HTTP Server detections into the Trend Micro Vision One Workbench, security teams can see the entire chain of attack and narrow-in on affected components.
In this Workbench, we observe the exploitation of the Apache HTTP Server vulnerability which is followed by identification of a dropped malware on the same host. Here we have the Intrusion Prevention and Antimalware modules in action, which are triggered right after the initial access attack attempt.
The second Workbench displays the identification of HTTP requests to known malicious URLs, which are detected by the Web Reputation Services module. In cases where the malware sample is unseen or is downloaded using a helper script, this Workbench can indicate the alerts that need attention first.
This Workbench shows observed outbound connections to cryptocurrency mining pools after exploitation of a server-side vulnerability (in our case, Apache HTTP Server). As we can see here, there are multiple events for outbound connections to mining pools since there are multiple cryptomining samples running on the compromised host post-exploitation.
Root-Cause Analysis (RCA)
You can also perform RCA from Workbench/Search App/Threat Hunting App for further investigation.
In the above RCAs, we observe three processes establishing outbound connections to cryptocurrency mining pools. Prefer to see the info in graphs? We got you. Using such RCAs, security analysts can understand and get answers to the right questions in just about the right time.
Using the Observed Attack Techniques, one can filter out the triggers in their environments based on severity, MITRE ATT&CK Techniques and Tactics, CVE IDs and endpoints. This enables security and development teams to prioritize and determine which hosts need to be investigated first.'
Next steps
Keep up to date on developing Log4Shell news here. You can also start a free trial or check out our extensive documentation library to see how Trend Micro Vision One powers layered detection and response for our cloud-builder security platform, Trend Micro Cloud One.
