Reading Physical Memory using Carbon Black's Endpoint driver

Enterprises rely on endpoint security software in order to secure machines that have access to the enterprise network. Usually considered the next step in the evolution of anti-virus solutions, endpoint protection software can protect against various attacks such as an employee running a Microsoft Word document with macros and other conventional attacks against enterprises. In this article, I'll be looking at Carbon Black's endpoint protection software and the vulnerabilities attackers can take advantage of. Everything I am going to review in this article has been reported to Carbon Black and they have said it is not a real security issue because it requires Administrator privileges.

Driver Authentication

The Carbon Black driver (cbk7.sys) has a basic authentication requirement before accepting IOCTLs. After opening the "\\.\CarbonBlack" pipe, you must send "good job you can use IDA, you get a cookie\x0\x0\x0\x0\x0\x0\x0\x0" with the IOCTL code of 0x81234024.

Setting Acquisition Mode

The acquisition mode is a value the driver uses to determine what method to take when reading physical memory, we'll get into this in the next section. To set the acqusition mode, an attacker must send the new acquisition value in the input buffer for the IOCTL 0x8123C144 as an uint32_t.

Physical Memory Read Accesss

The Carbon Black Endpoint Sensor driver has an IOCTL (0x8123C148) that allows you to read an arbitrary physical memory address. It gives an attackers three methods/options of reading physical memory:

1. If Acquisition Mode is set to 0, the driver uses MmMapIoSpace to map the physical memory then copies the data.
2. If Acquisition Mode is set to 1, the driver opens the "\Device\PhysicalMemory" section and copies the data.
3. If Acquisition Mode is set to 2, the driver translates the physical address to a virtual address and copies that.

To read physical memory, you must send the following buffer:

struct PhysicalMemReadRequest {
  uint64_t ptrtoread; // The physical memory address you'd like to read.
  uint64_t bytestoread; // The number of bytes to read.
};

The output buffer size should be bytestoread.

CR3 Access

Carbon Black was nice enough to have another IOCTL (0x8123C140) that gives a list of known physical memory ranges (calls MmGetPhysicalMemoryRanges) and provides the CR3 register (Directory Base). This is great news for an attacker because it means they don't have to predict/bruteforce a directory base and instead can convert a physical memory address directly to a kernel virtual address with ease (vice-versa too!).

To call this IOCTL, you need to provide an empty input buffer and output buffer with a minimum size of 0x938 bytes. To get the CR3, simply do *(uint64t_t*)(outputbuffer).

Impact

You might ask what's the big deal if you need administrator for this exploit. The issue I have is that the Carbon Black endpoint software will probably not be on an average home PC, rather on corporate endpoints. If a company is willing to purchase a software such as Carbon Black to protect their endpoints, they're probably doing other secure measures too. This might include having a whitelisted driver system, secure boot, LSA Protection, etc. If an attacker gains administrator on the endpoint (i.e if parent process was elevated), then they could not only disable the protection of Carbon Black, but could use their driver to read sensitive information (like the memory of lsass.exe if LSA Protection is on). My point is, this vulnerability allows an attacker to use a whitelisted driver to access any memory on the system most likely undetected by any anti-virus on the system. I don't know about you, but to me this is not something I'd accept from the software that's supposed to protect me.

The hash of the cbk7.sys driver is ec5b804c2445e84507a737654fd9aae8 (MD5) and 2afe12bfcd9a5ef77091604662bbbb8d7739b9259f93e94e1743529ca04ae1c3 (SHA256).