mirror of
https://github.com/splunk/security_content
synced 2026-06-08 17:32:49 +00:00
112 lines
6.8 KiB
YAML
112 lines
6.8 KiB
YAML
name: Apache Struts Vulnerability
|
|
id: 2dcfd6a2-e7d2-4873-b6ba-adaf819d2a1e
|
|
version: 1
|
|
date: '2018-12-06'
|
|
author: Rico Valdez, Splunk
|
|
status: production
|
|
description: Detect and investigate activities--such as unusually long `Content-Type`
|
|
length, suspicious java classes and web servers executing suspicious processes--consistent
|
|
with attempts to exploit Apache Struts vulnerabilities.
|
|
narrative: 'In March of 2017, a remote code-execution vulnerability in the Jakarta
|
|
Multipart parser in Apache Struts, a widely used open-source framework for creating
|
|
Java web applications, was disclosed and assigned to CVE-2017-5638. About two months
|
|
later, hackers exploited the flaw to carry out the world''s <a href=https://www.usatoday.com/story/tech/2017/09/07/nations-biggest-hacks-and-data-breaches-millions/644311001/>
|
|
5th largest data breach</a>. The target, credit giant Equifax, <a href=https://money.cnn.com/2017/09/16/technology/equifax-breach-security-hole/index.html>told
|
|
investigators</a> that it had become aware of the vulnerability two months before
|
|
the attack.
|
|
|
|
The exploit involved manipulating the `Content-Type HTTP` header to execute commands
|
|
embedded in the header.
|
|
|
|
This Analytic Story contains two different searches that help to identify activity
|
|
that may be related to this issue. The first search looks for characteristics of
|
|
the `Content-Type` header consistent with attempts to exploit the vulnerability.
|
|
This should be a relatively pertinent indicator, as the `Content-Type` header is
|
|
generally consistent and does not have a large degree of variation.
|
|
|
|
The second search looks for the execution of various commands typically entered
|
|
on the command shell when an attacker first lands on a system. These commands are
|
|
not generally executed on web servers during the course of day-to-day operation,
|
|
but they may be used when the system is undergoing maintenance or troubleshooting.
|
|
|
|
First, it is helpful is to understand how often the notable event is generated,
|
|
as well as the commonalities in some of these events. This may help determine whether
|
|
this is a common occurrence that is of a lesser concern or a rare event that may
|
|
require more extensive investigation. It can also help to understand whether the
|
|
issue is restricted to a single user or system or is broader in scope.
|
|
|
|
When looking at the target of the behavior illustrated by the event, you should
|
|
note the sensitivity of the user and or/system to help determine the potential impact.
|
|
It is also helpful to see what other events involving the target have occurred in
|
|
the recent past. This can help tie different events together and give further situational
|
|
awareness regarding the target.
|
|
|
|
Various types of information for external systems should be reviewed and (potentially)
|
|
collected if the incident is, indeed, judged to be malicious. Information like this
|
|
can be useful in generating your own threat intelligence to create alerts in the
|
|
future.
|
|
|
|
Looking at the country, responsible party, and fully qualified domain names associated
|
|
with the external IP address--as well as the registration information associated
|
|
with those domain names, if they are frequently visited by others--can help you
|
|
answer the question of "who," in regard to the external system. Answering that can
|
|
help qualify the event and may serve useful for tracking. In addition, there are
|
|
various sources that can provide some reputation information on the IP address or
|
|
domain name, which can assist in determining if the event is malicious in nature.
|
|
Finally, determining whether or not there are other events associated with the IP
|
|
address may help connect some dots or show other events that should be brought into
|
|
scope.
|
|
|
|
Gathering various data elements on the system of interest can sometimes help quickly
|
|
determine that something suspicious may be happening. Some of these items include
|
|
determining who else may have recently logged into the system, whether any unusual
|
|
scheduled tasks exist, whether the system is communicating on suspicious ports,
|
|
whether there are modifications to sensitive registry keys, and whether there are
|
|
any known vulnerabilities on the system. This information can often highlight other
|
|
activity commonly seen in attack scenarios or give more information about how the
|
|
system may have been targeted.
|
|
|
|
hen a specific service or application is targeted, it is often helpful to know the
|
|
associated version to help determine whether or not it is vulnerable to a specific
|
|
exploit.
|
|
|
|
hen it is suspected there is an attack targeting a web server, it is helpful to
|
|
look at some of the behavior of the web service to see if there is evidence that
|
|
the service has been compromised. Some indications of this might be network connections
|
|
to external resources, the web service spawning child processes that are not associated
|
|
with typical behavior, and whether the service wrote any files that might be malicious
|
|
in nature.
|
|
|
|
In the event that a suspicious file is found, we can review more information about
|
|
it to help determine if it is, in fact, malicious. Identifying the file type, any
|
|
processes that have the file open, what processes created and/or modified the file,
|
|
and the number of systems that may have this file can help to determine if the file
|
|
is malicious. Also, determining the file hash and checking it against reputation
|
|
sources, such as VirusTotal, can sometimes quickly help determine whether it is
|
|
malicious in nature.
|
|
|
|
Often, a simple inspection of a suspect process name and path can tell you if the
|
|
system has been compromised. For example, if `svchost.exe` is found running from
|
|
a location other than `C:\Windows\System32`, it is likely something malicious designed
|
|
to hide in plain sight when simply reviewing process names. Similarly, if the process
|
|
itself seems legitimate, but the parent process is running from the temporary browser
|
|
cache, there may be activity initiated via a compromised website the user visited.
|
|
|
|
It can also be very helpful to examine various behaviors of the process of interest
|
|
or the parent of the process that is of interest. For example, if it turns out that
|
|
the process of interest is malicious, it would be good to see if the parent to that
|
|
process spawned other processes that might also be worth further scrutiny. If a
|
|
process is suspect, reviewing the network connections made around the time of the
|
|
event and/or if the process spawned any child processes could be helpful in determining
|
|
whether it is malicious or executing a malicious script.'
|
|
references:
|
|
- https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.2/dev/rules/REQUEST-944-APPLICATION-ATTACK-JAVA.conf
|
|
tags:
|
|
category:
|
|
- Vulnerability
|
|
product:
|
|
- Splunk Enterprise
|
|
- Splunk Enterprise Security
|
|
- Splunk Cloud
|
|
usecase: Advanced Threat Detection
|