Spooky Season Brings a Toe-Curling Vulnerability

Over the past week, we’ve been teased with an especially spooky vulnerability disclosure, finally revealed on Oct. 11 as CVE-2023-38545. The vulnerability was discovered by researcher Jay Satiro and fixed in version 8.4 of libcurl. Versions 7.69.0 through 8.3.0 of libcurl are affected. The reality is there was a little more trick and a little less treat for this vulnerability, although it’s still noteworthy and worth patching.

What is the vulnerability?

Simply stated, this flaw exists when a SOCKS5 proxy handshake request is used to process curl requests for hostname resolution. Overly-long hostnames (more than 256 bytes) contained in the “Location” header will be used in a memcpy() routine in the vulnerable libcurl version, which can be exploited to cause a heap-based buffer overflow, potentially resulting in arbitrary code execution.

Is the default installation of libcurl vulnerable?

Yes and no! There are several reasons this vulnerability is marked “high” instead of “critical.” When it comes to libcurl, code execution via the overflow is only possible in cases where SOCKS5 proxy is used for hostname processing of curl requests, and only in applications that have not set CURLOPT_BUFFERSIZE or have manually set it to a value less than 65541. The curl tool itself (meaning the binary, as opposed to the curl library) is not vulnerable in its default state, as the CURLOPT_BUFFERSIZE is set to a default size of 100kB.

Are there any known exploits in the wild?

While many local proofs of concept exist triggering the overflow and resulting crash in libcurl, at the time of this publication there are no known exploits for this in the wild. Given the installation base of curl and the amount of detail provided about the vulnerability, it is likely that we will see exploitation attempts proliferate over the next few days. However, based on the mitigating factors around default installation and conditions for exploitation, we believe widespread exploitation is not likely to occur. 

How can I determine if I’m affected?

The ideal scenario would be auditing all systems using libcurl that are configured with a SOCKS5 proxy. This may be challenging given the ubiquity of this library, so the easiest step might be a network scanning tool or inventory management tool to find libcurl installations and patch them if they are on a vulnerable version.

Exabeam customers: How can I detect exploitation of the vulnerability?

Exabeam customers can use the Search tool to look for common anomalous behavior related to the exploitation of this vulnerability. Some of the rules that would be relevant include:

• First execution of process for user
• Abnormal process execution for user
• Abnormal process execution containing wget or curl commands for the user

Advanced Analytics Threat Hunter Search

Perform an Advanced Analytics Threat Hunter search by including the rules listed below in the “Reasons” section of Threat Hunter:

RuleID: A-EPA-HP-Commands-F

RuleName: “First execution of process on asset and the command of the process is curl/wget”

RuleID: A-EPA-HP-Commands-A

RuleName: “Abnormal execution of process on asset and the command of the process is curl/wget”

RuleID: EPA-UP-Commands-F

RuleName: “First execution of this process for user and the command of the process is curl/wget”

RuleID: EPA-UP-Commands-A

RuleName: “Abnormal process execution containing wget or curl commands for the user.”

RuleID: EPA-HP-Commands-F

RuleName: “First execution of process on host and the command of the process is curl/wget”

If any of these detection events contain curl commands with the target hostname containing a SOCKS5 proxy address (socks5h://), it is worth prioritizing analysis of the endpoint or user.

The following search will retrieve events related to this vulnerability.

activity_type:”process-create” AND process_name:”curl” AND “socks5h://”

What’s next?

We will be actively monitoring the threat landscape for working exploits and proofs of concept with code execution. We will continue to investigate further targeted detection capabilities based on this and provide relevant updates. 

Exabeam Security Research Team (ESRT) Mission Statement:

The ESRT strives to provide unique insight into how we look at the world of cyberthreats and risk by highlighting the common patterns that different threats and threat actors use, and why we need to reorient our detections and priorities to tactics, techniques, and procedures (TTPs) vs. indicators of compromise (IOCs).

We aim to share a newer ideology of investigating threats by answering the following questions: “who, what, and how”.