Following Tenable Research’s disclosure of a critical SQL injection vulnerability in FileCatalyst Workflow in May 2024, further investigation by Dynatrace revealed another SQL injection vulnerability.

The vulnerability, identified as CVE-2024-6632, allows the abuse of a form submission during the setup process to make unauthorized modifications of the database. So far, the vulnerability only appears to be exploitable by an authenticated user during the setup process. To mitigate this vulnerability, users of the affected software are advised to upgrade to version 5.1.7.

How could an attacker exploit the new SQL injection vulnerability?

During the setup process of FileCatalyst Workflow, the user is prompted to provide company information via a form submission. The submitted data is used in a database statement, but the user input is not going through proper input validation. As a result, the attacker can modify the query. This allows for unauthorized modifications on the database. An attacker could potentially modify information on the database that go beyond what an authenticated user is allowed to do. They could also potentially modify other databases on the same database server.

Criticality

As of now, it appears this SQL injection vulnerability is only exploitable by an authenticated user during the setup process. It is therefore less critical than the previously disclosed vulnerability (CVE-2024-5276) and harder to exploit. Nevertheless, the vulnerability allows for unauthorized modification of the database, which, in certain scenarios, could be problematic.

How was the vulnerability discovered?

Dynatrace discovered the vulnerability as part of an investigation activity following the publication of CVE-2024-5276 by Tenable. An instance of FileCatalyst Workflow was instrumented by the Dynatrace OneAgent, which has the capability to automatically detect injection vulnerabilities in running applications. Shortly after the setup, Dynatrace reported the disclosed vulnerability, which allows an attacker to perform a SQL injection using the jobID parameter.

In addition to the known SQL injection vulnerability (tracked as CVE-2024-5276), Dynatrace OneAgent discovered a second SQL injection vulnerability with a different entry point. Dynatrace Runtime Vulnerability Analytics detects if user input is used in an unsafe way, which can lead to an injection attack and reports this as a code-level vulnerability. Further investigation showed that this vulnerability is still present in the version that provided a fix for CVE-2024-5276. It is also still possible to exploit this vulnerability by sending malicious input as part of the setup form.

How do I know if my FileCatalyst Workflow environment is affected?

If you are using FileCatalyst Workflow version 5.1.6 build 139 or earlier, you are affected by the vulnerability and should update your instance.

Read the advisory here.

How to patch and remediate CVE-2024-6632

To remediate the vulnerability, update FileCatalyst Workflow to version 5.1.7 or later.

Read the advisory here.

Please note that Dynatrace customers using Runtime Application Protection in blocking mode are protected against this vulnerability, as well as against CVE-2024-5276.

Coordinated vulnerability disclosure

The disclosure of this vulnerability was done in collaboration with Fortra.

Timeline:

2024-07-05: Dynatrace contacts Fortra to disclose the issue

2024-07-09: Fortra confirms the issue, and a CVE is reserved

2024-07-30: Dynatrace requests a status updated from Fortra

2024-07-30: Fortra provides an updated and release timeline

2024-08-27: Disclosure of vulnerability

The post New SQL injection vulnerability in FileCatalyst Workflow appeared first on Dynatrace news.

As teams conduct forensic investigations into the MOVEit Transfer vulnerability, many are finding they can’t conclusively determine their exploitation status. This uncertainty is because they may not have collected enough logs, or the logs don’t contain enough information. When working with logs originating from an out-of-the-box software such as Progress MOVEit Transfer, we can’t do much. What the software has been designed to log is what we get. But observability data (traces) can fill in the blanks to reveal useful evidence of possible exploitation, as proved by our analysis of the MoveIT vulnerability using Dynatrace.

What is the MOVEit vulnerability?

The MOVEit vulnerability is a critical SQL injection flaw in the web application MOVEit Transfer, which MITRE published as CVE-2023-34362 on May 31, 2023. When exploiting the vulnerability, attackers can gain remote code injection capabilities in the MOVEit server and modify or steal sensitive data from its database. On June 6, 2023, the ransomware gang Cl0p claimed responsibility for exploiting the MOVEit Transfer vulnerability starting on May 27, 2023, during the U.S. Memorial Day holiday. As a zero-day vulnerability, however, threat actors could have been exploiting the vulnerability since 2021, when the vulnerability was introduced into the software. Victims include large financial institutions, government agencies, and other critical service providers.

As soon as MITRE published the CVEs and the bad actors launched their exploits in the wild, the infosec community got busy reverse engineering malware and investigating attacker tactics. Progress Software, the company behind MOVEit softwareTransfer, has published an excellent overview, as have Huntress Labs, Mandiant, TrustedSec, Horizon3.ai and others.

Using Dynatrace to investigate the MOVEit Transfer vulnerability

Investigating the MOVEit vulnerability is a perfect use case for Dynatrace: having all your observability and security data immediately available to investigate a potential compromise, combined with indexless, schema-on-read storage and excellent processing speed, with one language (Dynatrace query language—DQL) to query them all.

To see how Dynatrace investigates the MOVEit vulnerability, we set up a proof of concept (PoC) to explore the exploit and its impact in a sandbox environment. The question was: Using Dynatrace Grail and DQL, what kind of attacker activity can we discover in the logs using an out-of-the-box logging setup both for the MoveIT vulnerability and the IIS logs of the server running the software?

As we started experimenting with the PoC and looking for the indicators of compromise (IoCs) in the IIS logs published by the community, the sky seemed clear. Running blazing-fast queries on historical logs stored in Grail was pretty straightforward. Lucky, because the vulnerability reportedly dates back to 2021. Because IIS logs contain IP addresses, client requests, and server response codes, querying them seemed quite promising to find suspicious indicators like certain IP addresses, strings and requests reported by the community.

For example, the LEMURLOOR web shell Cl0p used during the Memorial Day attacks used a backdoor called human2.aspx. This backdoor enabled attackers to access MOVEit data and users, download files, insert an administrative user, which enabled attackers to bypass credentials. The following query looks for the string human2.aspx in logs to detect if the attacker has added a webshell to exploit the MOVEit software.

The MOVEit vulnerability log quality wall

As the research progressed, however, we hit the log quality wall.

We found that the MOVEit default logs contained no useful information on the attacker’s activity.

The problem with the IIS server access logs was the headers. IIS access logs often log some headers but not all headers. So we’re likely to miss important evidence that would make the investigation and attack detection much faster.

And unfortunately, payloads containing valuable information on the exploits are not logged at all. Payloads would be nice, although the logs would get too crowded and full of privacy issues. But a security analyst can always dream…

These deficits left us unsure about what the attacker had done, their methods, and what data they compromised.

Using observability data for indicators of compromise

The disappointment with log quality sent us looking for more data to dig into. A good source for additional information is observability data. We can use metrics to detect anomalies, events to find unusual activities, and traces, which provide detailed insights into system activities. In Dynatrace, we can use one query language, DQL, to query all these different data sources.

For example, to see if the attackers installed a web shell, we can use DQL to find spans that contacted the endpoint human2.aspx.

In this query, we first fetch the spans (a span represents a single trace segment). Next, we filter them by the MOVEit service to improve the query performance. Finally, we filter by http.target that contains human2.aspx.

There are no results in this case, but this doesn’t mean there was no exploitation. There are other options to exploit the vulnerability. And since this IOC is now well-known, attackers will likely do it differently. You can normally find this information easily in logs (such as  IIS logs). But when you can get the information from spans, results get much more interesting.

Spans reveal more about MOVEit vulnerability exploit activity

Using spans, for example, we can find evidence of MOVEit vulnerability exploit activity in database queries. The exploit works by modifying the access tokens using SQL injection (SQLI). By using DQL to query spans, we can see if there were updates to the respective tables.

This is a simple query to check for updates on the hostpermits table, which is necessary to use the created access token from a remote host. The query is quite simple, but it might miss some matches. For example, if the database name is prepended or the table name has backticks around it. Let’s improve on the query to get better results and look for additional tables at the same time:

The improved query matches a wider variety of options and we can see that it found several SQL injections. The parse section of the query performs the following logic:

• DATA: matches any data, to match the beginning of the SQL query
• update: matches a string literal to find update statements
• BLANK: after the update keyword, there needs to be a space, but it could be more than one
• ('moveittransfer.'|'`'|''): matches either movittransfer (if the database name is prepended), a backtick (table names can be surrounded by backticks), or nothing
• ('hostpermits' | 'userexternaltokens'| 'trustedexternaltokenproviders'): matches against different table names

Logs, traces, spans – you need them all for investigations like the MOVEit vulnerability

It’s not possible to create logging from scratch for out-of-the-box software. We need to work with what we can get. Existing logs might not contain enough information to investigate the incident. Teams may have disabled useful logging by default, and when they discover the incident, it’s too late to configure logging. Therefore, looking at observability data jointly with logs can be a game changer.

Our investigation of the MOVEit Transit vulnerability proved that querying spans can give us valuable missing pieces to detect what the attackers were up to.

Interested in trying out these queries in your own environment? If you’re already a Dynatrace customer, these queries are available in a Dynatrace Notebooks template. Just ask your Dynatrace account rep.

The post MOVEit vulnerability: Observability context fills log data gaps for MOVEit Transfer vulnerability appeared first on Dynatrace news.

A new high-severity remote code execution (RCE) vulnerability was disclosed on October 13, 2022. The vulnerability affects the Apache Commons Text library. While some view CVE-2022-42889, aka Text4Shell, as the following Log4Shell vulnerability, others see its impact as less severe.

A remote code execution vulnerability is a cyberattack in which an attacker can remotely execute commands on a user’s computing device.

CVE-2022-42889 is not as critical as Log4Shell

Since this is a remote code execution vulnerability in an open source Java library, it has been compared with Log4Shell. This vulnerability emerged in December 2021 and affected millions of production applications.

But current analysis indicates that the Apache Commons Text vulnerability is not as widespread and much harder to exploit. Although the NVD severity rating is reported as 9.8, the vulnerability is undergoing reanalysis. Other agencies rate the vulnerability as less severe because the library is not as ubiquitous and the vulnerability is harder to exploit than other similar vulnerabilities. In either case, organizations should upgrade to the latest library version (1.10.0), which addresses the issue.

The Commons Text library provides tools for processing text, including functionality to escape and unescape text. It computes the similarity and distance between strings and substitutes variables within a string. The string interpolation makes it possible to dynamically evaluate and expand properties by using a prefix to locate an instance of org.apache.commons.text.lookup.StringLookup.

Starting with version 1.5, the standard lookups include interpolators that could make this vulnerability exploitable:

• “script” to execute expressions using the JVM (or Java Virtual Machine) script execution engine (javax.script)
• “dns” to resolve DNS records
• “url” to load values from remote servers via URLs

The vulnerability affects versions 1.5 to 1.9 of the library and has already been patched in Apache Common Text version 1.10.0.

How to determine whether your organization is affected

To determine whether your organization is affected by the Apache Common Text vulnerability, you need to evaluate whether one of the vulnerable versions of the library is being used in your applications. A simple approach could be to look for the individual jar files:

• commons-text-1.5.jar
• commons-text-1.6.jar
• commons-text-1.7.jar
• commons-text-1.8.jar
• commons-text-1.9.jar

But this might not be easy to accomplish in a large environment, especially in cloud deployments.

Detecting the Apache Commons Text vulnerability using Dynatrace Application Security

Dynatrace Application Security will detect the vulnerability automatically and identify whether your organization is affected. If so, it will be listed under the third-party vulnerabilities section. You can use the filters to quickly identify it by selecting Snyk/CVE ID in the Filter By field and search for “CVE-2202-42889,” as shown in the following screenshot.

If you have configured security notifications, IT teams can receive a notification as soon as the vulnerability is discovered.

Detecting the Apache Commons Text vulnerability using the Maven dependency tree

To quickly identify if projects are affected, you can use the Apache Maven dependency plugin to see if one of the vulnerable versions is in your project.

mvn dependency:tree -Dincludes=org.apache.commons:commons-text

The Apache Software Foundation resolved the vulnerability in Apache Commons Text 1.10.0, and organizations should upgrade to that version as soon as possible.

How to get Dynatrace Application Security for automatic runtime vulnerability analysis

If you are a Dynatrace customer and want to start using the new Application Security module, go to the Dynatrace web UI and select Vulnerabilities in the menu.

If your organization doesn’t yet use Dynatrace, it’s easy to get started in less than five minutes with the Dynatrace free trial.

The post New high severity vulnerability, CVE-2022-42889, in Apache Commons Text discovered appeared first on Dynatrace news.

At the end of March 2022, three critical vulnerabilities in the Java Spring Framework were published, including a remote code execution (RCE) vulnerability called Spring4Shell or SpringShell.

Since then, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has reported “evidence of active exploitation”, recording more than 37,000 exploit attempts in the first few days alone. With a critical CVSS score of 9.8, outlets report active scanning attempts from around the globe.

What is Spring4Shell?

Spring4Shell is a critical vulnerability in the Spring Framework, an open source platform for Java-based application development. Because 60% of developers use Spring for their main Java applications, many applications are potentially affected.

Spring is popular because it enables software engineers to more easily write and test code to maintain modular applications. The Spring Framework enables developers to map user requests to Java objects. Other libraries enable developers to become less dependent on enterprise web servers and, therefore, reduce configuration complexity and cost.

Spring4Shell is one of three vulnerabilities published on March 30:

1. Spring Core RCE (critical): CVE-2022-22965 a.k.a. Spring4Shell or SpringShell
   Affected library: org.springframework:spring-bean
2. Information exposure in Spring Cloud Function: CVE-2022-22963
   Affected library: org.springframework.cloud:spring-cloud-function-context
3. Denial of service in Spring Expressions: CVE-2022-22950
   Affected library: org.springframework:spring-expression

Like Log4Shell, a vulnerability discovered in December 2021, the Spring4Shell vulnerability challenges organizations to identify and remediate application vulnerabilities in production—before malicious attackers can compromise sensitive data, such as customer or employee data.

What is the impact of Spring4Shell?

With a CVSS score of 9.8, Spring4Shell is severe because if attackers exploit it, applications can be vulnerable to remote code execution (RCE). In fact, there are already proof-of-concept exploits available publicly. Accordingly, Spring has published a fix in Spring Framework 5.3.18 and 5.2.20.

Because Spring4Shell exposes an application to remote code execution, an attacker can possibly access all website internal data, including any connected database. It may also allow an attacker to access additional internal resources to gain more permissions or to make their way to other parts of an internal network.

How to identify whether your organization is vulnerable to Spring4Shell

As published in the Spring Framework RCE early announcement, malicious attackers can exploit the Spring vulnerability if an application operates under the following circumstances:

• Runs on JDK 9 or higher
• Uses Apache Tomcat as the servlet container
• Packaged as a traditional WAR and deployed in a standalone Tomcat instance. Typical Spring boot deployments that use an embedded Servlet container or reactive web server are not impacted.
• Depends on spring-webmvc or spring-webflux
• Uses Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions

There are several methods and tooling available to identify if an application is affected. We explore the following options:

• Dynatrace Application Security
• Dependency Check open source tool
• The Apache Maven Dependency plugin

Dynatrace Application Security detects Spring4Shell-affected components automatically

For customers using Dynatrace Application Security, Dynatrace detects all three vulnerabilities automatically and in all locations across highly distributed hybrid, multicloud environments.

In addition, if you have security notifications set up, Dynatrace automatically sends a notification with the relevant details for each vulnerability upon discovery.

Further, you can also find the vulnerabilities using Dynatrace in two other ways:

1. Sorting the vulnerability list by first seen
2. Finding the vulnerabilities using the CVE or SNYK ID:
   • Spring Core RCE: search for CVE-2022-22965 or SNYK-JAVA-ORGSPRINGFRAMEWORK-2436751
   • Information Exposure in Spring Cloud Function: search for CVE-2022-22963 or SNYK-JAVA-ORGSPRINGFRAMEWORKCLOUD-2436645
   • Denial of Service in Spring Expressions: search for CVE-2022-22950 or SNYK-JAVA-ORGSPRINGFRAMEWORK-2434828

In this example, we can see how Dynatrace discovered CVE-2022-22965 and CVE-2022-22963.

Although you should upgrade all affected applications, your priority focus should be applications running on Tomcat and Java 9 or newer. In the following screenshot, you can see how Dynatrace captures all this information and provides the details for each affected process so you can prioritize mitigation actions.

Because Dynatrace performs continuous full-stack monitoring, it has full awareness of the underlying runtime, including the Java version the vulnerable code runs. If you have many affected applications, you can extract a list of the affected processes that are on Java 9 or newer using Dynatrace APIs. You can find a sample Python script that uses Dynatrace Spring4Shell APIs on GitHub.

Scan folders using Dependency Check open source tool

Dependency Check is an open source tool you can use to find vulnerabilities in other third-party open source libraries.

There are different ways of using it, including as a command line tool, with a Maven or Gradle plugin, or integrated in third-party tools. In the following example, we use it as a command line tool.

To scan a folder for vulnerable libraries, run the CLI and point the tool to a folder, for example:
dependency-check --scan webapps.

Once executed, the tool generates an HTML report that lists the vulnerabilities. The following example shows that the Spring4Shell vulnerability (CVE-2022-22695) is listed:

Use the Apache Maven Dependency plugin to detect affected components manually

Another option is to use the Apache Maven Dependency plugin to identify whether your projects use affected libraries. To find out if your application exposes the vulnerability, navigate to the directory of your Maven project and run the following three commands:

Spring Core RCE

mvn dependency:tree -Dincludes=org.springframework:spring-beans

Here we can see that the application uses spring-beans version 5.3.13 and therefore has the vulnerability.

Information Exposure in Spring Cloud Function

mvn dependency:tree -Dincludes=org.springframework.cloud:spring-cloud-function-context

In this case, the application uses spring-cloud-function-context version 3.2.2, which means it exposes the vulnerability.

Denial of Service in Spring Expressions

mvn dependency:tree -Dincludes=org.springframework:spring-expression

In this example, the application uses spring-expression version 5.3.16, which means it is vulnerable.

How to mitigate risk of Spring4Shell

To mitigate risk, upgrade to the latest versions to address the Spring4Shell vulnerabilities.

1. Spring Core RCE – Upgrade to versions 5.2.20 and 5.3.18 or higher.
2. Information Exposure in Spring Cloud Function – Upgrade to versions 3.1.7 and 3.2.3 or higher.
3. Denial of Service in Spring Expressions – Upgrade to version 5.3.17 or higher.

See the Spring blog post Spring Framework RCE, Early Announcement for further details. We also suggest you take a look at the anatomy of the Spring4Shell vulnerability and how to prevent its effects—and those of similar vulnerabilities.

How to get Dynatrace Application Security

If you are a Dynatrace customer and want to start using the Application Security module for automatic runtime vulnerability analysis, go to the Dynatrace web UI and select Vulnerabilities in the menu (separately licensed).

However, if you’re not using Dynatrace yet, it’s easy to get started in under five minutes with the Dynatrace free trial. Contact us for how you can enable Dynatrace Application Security.

If you are concerned about Spring4Shell’s effect on Dynatrace components, please have a look at our security alerts, specifically SpringShell CVE-2022-22965.

The post Spring4Shell: Detect and mitigate new zero-day vulnerabilities in the Java Spring Framework appeared first on Dynatrace news.