Tech Analysis: Addressing Claims About Falcon Sensor Vulnerability

CrowdStrike is aware of inaccurate reporting and false claims about the security of the Falcon sensor. This blog sets the record straight by providing customers with accurate technical information about the Falcon sensor and any claims regarding the Channel File 291 incident. CrowdStrike has provided a Technical Root Cause Analysis and executive summary that describes the bug in detail.

Our analysis, which has been peer reviewed, outlines why the Channel File 291 incident is not exploitable in a way that achieves privilege escalation or remote code execution. We’ll also provide details on how we secure the Falcon sensor’s channel files from being tampered with and abused.

Out-of-Bounds Memory Read: Understanding the Impact

The incident on July 19, 2024 was caused by an out-of-bounds (OOB) read of memory, leading to a crash in the Windows kernel.

Since the incident, both CrowdStrike and external security researchers have been analyzing the bug to determine if it can be abused for privilege escalation or code execution. The results of our analysis support the conclusion that it provides no mechanism to write to arbitrary memory addresses or control program execution — even under ideal circumstances where an attacker could influence kernel memory so the out-of-bounds address being read was fully controlled.

As described in the Technical Root Cause Analysis, the bug resulted from code attempting to inspect a 21st input parameter while only being provided with 20, leading to an out-of-bounds read. Even if an attacker had complete control of the value being read, the value is only used as a string being matched against a regular expression. We have investigated the code paths following the OOB read in detail, and there are no paths leading to additional memory corruption or control of program execution.

Furthermore, CrowdStrike has implemented multiple layers of protection to prevent tampering with channel files. These safeguards, which we detail in the following section, make it extremely difficult for attackers to leverage the OOB read for malicious purposes.

Protecting the Falcon Sensor from Malicious Tampering

One report made several incorrect claims, including that it is possible to provide arbitrary malicious channel files to the sensor. CrowdStrike prevents these types of attacks through multiple protections within the sensor that prevent tampering with assets (such as channel files) when they are delivered from CrowdStrike servers and stored locally on disk.

These protections include:

• Certificate Pinning
• Checksum Validation
• Access Control List(s) on Directories and Files
• Anti-Tampering Detections

Safeguards such as these make it extremely difficult for attackers to leverage channel file vulnerabilities for malicious purposes. By combining careful code design with robust protective measures, we’ve created a resilient system that maintains its security integrity even in the face of potential vulnerabilities.

Certificate Pinning

CrowdStrike employs a process known as “certificate pinning” when new updates are delivered to the Falcon sensor via channel files from CrowdStrike’s cloud environment. Certificate pinning is a security best practice where an application explicitly specifies which Certificate Authority (CA) and/or specific SSL/TLS certificate should be used for a secure server connection, thereby preventing man-in-the-middle (MitM) attacks.

By specifying the exact expected certificate using this technique, the sensor verifies that it is communicating with a CrowdStrike cloud server rather than an attacker’s server, which might be intercepting or impersonating the legitimate server through a MitM proxy (such as IE Proxy). Certificate pinning prevents attackers from using a fake SSL/TLS certificate to make the communication appear legitimate and secure.

Proxy Settings

We are also aware of posts mentioning an attack that modifies proxy settings to point web requests, including CrowdStrike traffic, to a malicious server. The post states that this type of proxying can block CrowdStrike traffic, while others claim it is possible to inject malicious channel files through this process.

A malicious network proxy might block traffic destined for CrowdStrike servers — a statement that can be made for any other cloud service that honors Windows’ proxy settings — a malicious proxy cannot overcome TLS certificate pinning to cause the sensor to download a modified channel file.

Checksum Validation

Once the channel file has been securely downloaded from CrowdStrike’s cloud environment, it goes through a checksum verification process to check that the file and its content are valid for use by the Falcon sensor. Checksum validation is a process of verifying data integrity by comparing a cryptographically calculated value against a stored value — in the form of a hash — to detect errors or tampering in either transmitted or stored data. The Falcon sensor retrieves the channel file and its SHA256 hash from the cloud environment, using TLS with certificate pinning, and verifies that the file contents match the hash.

After the SHA256 hash is verified, the Falcon sensor stores the hash in a secured location. Before loading the channel file from disk, the Falcon sensor verifies that the file contents match the expected hash to detect any local modifications of the file.

Access Control List(s) on Directories and Files

Taking this process a step further, once a channel file has been securely downloaded and validated against a cryptographically calculated and expected checksum value within the sensor, it is then placed in a directory requiring administrator privileges to access or modify. In simple terms, a user would need full administrator privileges on the system already to attempt to tamper with a securely downloaded and cryptographically validated channel file.

Anti-Tampering Detections

In addition to the aforementioned security controls, CrowdStrike implements detections to catch and prevent circumvention as an added layer of security. Notably, the Falcon sensor’s kernel driver will raise a detection alert from attempts to modify any sensor files, including channel files, outside the standard delivery and update mechanisms outlined above.

It is important to note that channel files do not contain executable code. Despite their .sys file extension, channel files are not drivers — they are simply a collection of detection patterns the sensor uses to find indicators of malicious behavior.

Virtual Machine Exploitation Risks

The code where the File Channel 291 bug occurred is a fixed-length pipeline of string matching operators, similar to a regular expression engine. While the code might resemble a complex virtual machine, the implementation avoids unnecessary state and general-purpose computations. Its design significantly differs from virtual machines found in font or JavaScript engines, and it is less likely to provide undesired exploitation primitives.

Key limitations that contribute to security and resiliency:

• The system can’t create or modify its own instructions. The sequence of matching operations is fixed.
• It can’t allocate new memory or access arbitrary memory locations. It only works with its input strings and the small state variable.
• The system can’t perform general arithmetic or complex logical operations. It’s limited to simple pattern matching.

This behavior resembles a specialized pattern-matching circuit more than a general-purpose computer. It’s designed to do one specific job efficiently and securely, without the flexibility (and potential vulnerabilities) of a full Turing-complete system.

These restrictions severely limit the potential for exploitation, even if the system exhibited Turing-complete behavior. The design prioritizes security by constraining the operations possible within the sensor’s execution environment.

Conclusion

Our thorough analysis of the Channel File 291 incident and the subsequent claims leads us to several important technical conclusions:

1. The out-of-bounds read bug, while a serious issue that we have addressed, does not provide a pathway for arbitrary memory writes or control of program execution. This significantly limits its potential for exploitation.
2. The Falcon sensor employs multiple layered security controls to protect the integrity of channel files. These include cryptographic measures like certificate pinning and checksum validation and system-level protections such as access control lists and active anti-tampering detections.
3. While the disassembly of our string-matching operators may superficially resemble a virtual machine, the actual implementation has strict limitations on memory access and state manipulation. This design significantly constrains the potential for exploitation, regardless of computational completeness.
4. Our internal security team and two independent third-party software security vendors have rigorously examined these claims and the underlying system architecture. This collaborative approach ensures a comprehensive evaluation of the sensor’s security posture.

We remain committed to transparent and rigorous security practices. As with any complex software system, we acknowledge that unforeseen vulnerabilities may exist. It is our responsibility to continuously improve the security of our products, and to this end, we conduct both internal and third-party reviews, operate a Bug Bounty program as described below and adhere to industry best practices.

We value the insights of the broader security community and have established CrowdStrike’s paid Bug Bounty program as a channel for researchers to share their findings. These contributions from external researchers are invaluable in our ongoing efforts to enhance the security and reliability of the Falcon platform. We encourage any security researchers who believe they’ve found opportunities to bypass anti-tamper protections or gain privilege escalation from the sensor to submit any potential findings through or directly to the CrowdStrike security team via bugs@crowdstrike.com.