Custom curl query?

Are you interested in processes that load libcurl.dll/libcurl-x64.dll for example?

E.g. You might build an exe that uses the libcurl library and your interested in those or are you interested in processes that shell out to curl.exe? 

I am looking for something to help identify this vulnerability.

Description

The version of curl installed on the remote host is affected by a heap based buffer overflow in the SOCKS5 proxy handshake. When curl is asked to pass along the hostname to the SOCKS5 proxy to allow that to resolve the address instead of it getting done by curl itself, the maximum length that hostname can be is 255 bytes. If the hostname is detected to be longer than 255 bytes, curl switches to local name resolving and instead passes on the resolved address only to the proxy. Due to a bug, the local variable that means 'let the host resolve the name' could get the wrong value during a slow SOCKS5 handshake, and contrary to the intention, copy the too long hostname to the target buffer instead of copying just the resolved address there.

CVE-2023-38545

Solution

Upgrade curl to version 8.4.0 or later

What about:

with file_list as (
select spj.cmd_line, sfj.path, sfj.file
from sophos_file_journal as sfj
join sophos_process_journal as spj
on spj.sophos_pid = sfj.sophos_pid
where sfj.subject = "FileBinaryReads"
and sfj.event_type = 9
and sfj.file like '%libcurl%'
)
select * from file_list join file as osqfile on osqfile.path = file_list.path where osqfile.file_version not like '8.4%'

You can get hashes and things, you could join on file_id as well but that could restrict to the same drive.
Maybe see what that returns.

It is using the standard file table of osquery to get the file version (and all other fields) for the path

I'll give it a shot. Thank you!

Hello, 

I'm curious if it was helpful and if it returned what you might have expected and if a manual double check confirmed it was expected? 

I'm sure it could be refined but OK as a starting point? 

The time it goes back in the journals is is only 15 minutes by default, so it would have only returned data for processes that loaded libcurl that wasn't 8.4 in the last 15 minutes.  The "time" > epoch could be used as needed.

Thanks

Hello, 

I'm curious if it was helpful and if it returned what you might have expected and if a manual double check confirmed it was expected? 

I'm sure it could be refined but OK as a starting point? 

The time it goes back in the journals is is only 15 minutes by default, so it would have only returned data for processes that loaded libcurl that wasn't 8.4 in the last 15 minutes.  The "time" > epoch could be used as needed.

Thanks

Hi sorry for the delayed response. I had the search set to run all of this week and so far everything has returned a "Failure to execute."

Works OK for me, this is a Live Query rather than datalake.