Fuzzing has long been one of our favorite ways to search for security issues or vulnerabilities in software, but when it comes to fuzzing popular systems used in ICS environments, it traditionally involved a custom hardware setup to fuzz the code in its native environment.

Wednesday, August 28, 2024 12:00

Hunting for vulnerabilities in industrial environments has become increasingly important as industrial control systems and critical infrastructure face threats from state-sponsored actors and ransomware groups hoping to cash out on million-dollar payments.  

Fuzzing has long been one of our favorite ways to search for security issues or vulnerabilities in software, but when it comes to fuzzing popular systems used in ICS environments, it traditionally involved a custom hardware setup to fuzz the code in its native environment. 

However, I recently created my own fuzzer after Weston Embedded made its full µC/OS protocol stack source code openly available in 2020. µC/OS (also stylized as MicroC/OS) is a real-time operating system commonly used in resource-constrained embedded systems like industrial control systems. The operating system uses a scheduling mechanism to ensure efficient task management in industrial environments, and we recently discovered multiple vulnerabilities in the system that could allow an adversary to carry out a range of malicious actions, including causing a denial of service or gaining the ability to execute arbitrary code on the system.  

Today, we’re publishing a three-part look at how I created this fuzzer, the various hurdles I faced along the way, and how it used it to fuzz two different µC/OS protocol stacks. These individual posts are linked below. 

*   Part 1: HTTP server fuzzing
*   Part 2: Handling multiple requests per test case 
*   Part 3: TCP/IP server fuzzing, implementing a TAP driver

The vulnerabilities we uncovered by fuzzing µC/OS protocol stacks

This time, I’ll discuss why this approach is more challenging than simply substituting a socket file descriptor with a typical file descriptor.

Wednesday, August 28, 2024 12:00

So far in this series, I’ve developed a fuzzer for the µC/HTTP-server. As described in the previous post, this fuzzer reads from a file to enable compatibility with AFL++. That implementation only fuzzes a single request at a time. Although that single request fuzzer uncovered a few security vulnerabilities, there are complex and interesting object interactions and internal state transitions that occur when multiple requests are received in a single session. 

I wanted to be able to fuzz those interactions and transitions by providing a single test case file containing multiple requests. So, this time, I’ll discuss why this approach is more challenging than simply substituting a socket file descriptor with a typical file descriptor, and I’ll describe the feature I added to the open-source library libdesock to support multiple requests.

**Reading from a socket vs. reading from a file**

It’s a bit confusing thinking about solving this problem because socket communication is two-way communication with a request-response pattern, while reading from a file occurs one way. In a networking client/server model, the client will typically make a request of the server, and the server will respond before the client sends another request. 

The µC/HTTP-server works in a single thread so it completely processes and responds to the first request before ever reading from the socket descriptor for a second time. 

Our goal is to simulate multiple requests from the client using a single test case file. But what happens if we include two requests within the same test case file? The server code will read the available data from the file until it reaches EOF or fills the buffer.

For instance, suppose a test case file contains two complete HTTP requests. The buffer size of the µC/HTTP-server is 1,460 bytes and the length of our two requests combined are only 841 bytes. This means the entire test case fits within the buffer and is read into memory at once. The µC/HTTP-server will process the first HTTP request and then discard the remaining data in the buffer. Then, when the server code reads from the test case file again, it will have reached EOF while only actually processing the first request. 

To address this, we need a way to instruct the server to stop reading the file after processing the first request. This can be achieved by using a delimiter in the test case file. The delimiter should be a unique value that is unlikely to appear anywhere else in the request.

**libdesock **

To implement this strategy of using a delimiter to indicate where one request ends and another begins, I added a feature to an existing library called libdesock. The purpose of this library is to de-socket a network application to enable fuzzing. This is because fuzzers typically provide their test inputs via stdin while network applications expect their inputs from network connections. Typically, a network server application will call the libc functions socket, listen, accept and then read/recv. 

Libdesock operates by leveraging the Linux dynamic linker feature, LD_PRELOAD. When the LD_PRELOAD environment variable is set to the path of a shared object file, it instructs the dynamic linker to load that shared object before all others. As a result, when the dynamic linker searches for a symbol being called in the executable, it will first look in the shared object specified by the LD_PRELOAD environment variable. Normally, the symbols for the functions socket, listen, accept and read/recv are found within libc.so and executed from there. However, when LD_PRELOAD is set to libdesock.so, those symbols are found within the libdesock library and executed there instead. This allows libdesock to alter the behavior of those calls. By intercepting these calls, libdesock cleverly redirects recv/read to stdin rather than a network socket.

**Multiple request feature**

Originally, the libdesock code would read up to the size of the buffer used from stdin. This leads to the same issue as mentioned above when attempting to read multiple requests from an input file (stdin in this case): 

> “For instance, suppose a test case file contains two complete HTTP requests. The buffer size of the µC/HTTP-server is 1460 bytes and the length of our two requests combined are only 841 bytes. This means the entire test case fits within the buffer and is read into memory at once. The µC/HTTP-server will process the first HTTP request and then discard the remaining data in the buffer. Then, when the server code reads from the test case file again it will have reached EOF while only actually processing the first request.” 

To address this, I added a feature to the libdesock read code to look for a request delimiter while reading. If the delimiter is found, it returns all the data read before encountering the delimiter. On the next call to read, it will begin reading after the delimiter and search for another delimiter. This approach works for fuzzing multiple requests in most networked applications because these applications typically run a processing loop where read/recv is called, the data is processed, and then read/recv is called again. This loop continues until the connection is closed. As mentioned in the first blog post, it was necessary to modify the executable for fuzzing so that it would exit when read returns 0. This is crucial for fuzzing, as it indicates the executable has finished processing the test case and has exited normally. If you’d like to see the code, you can check out libdesock here.

**Vulnerability highlight**

This version of the µC/HTTP-server fuzzer, which supports multiple requests per test case, uncovered two additional vulnerabilities. In both instances, a vulnerability in the processing of the first request is exploited by the second request.

When disclosing these vulnerabilities, I discovered that much of the µC/HTTP-server codebase is shared across multiple products. The other affected products are the Silicon Labs Gecko Platform and Weston Embedded Cesium NET. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:203:1 and 119:282:1. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

Below is an overview of each vulnerability.

**TALOS-2023-1726**

When processing the protocol version portion of an HTTP request, an integer underflow occurs, which leads to an extremely large value within the connection object’s buffer length p_conn->RxBufLenRem. In the next iteration of the processing loop, that large value is used as an argument when calling receive. This means that the next request wouldn’t be limited by the max buffer size (1,460 bytes), and an attacker could overflow the receive buffer directly with the second request. 

**TALOS-2023-1732**

In this vulnerability, a buffer overflow of one byte occurs when handling the header fields in an HTTP request. This one-byte overflow is significant because the µC/HTTP-server heap implementation stores a pointer to a free chunk of memory in the first four bytes of an allocation. This means that the one byte overwrite can modify the free chunk address which will be used as an allocation sometime in the future. Abusing this vulnerability required four requests. The first two were innocuous and caused specific heap allocations to occur (a technique known as “heap grooming”). The one-byte overwrite is triggered by the third request, while the fourth request leads to an improper allocation in the heap.

Both vulnerabilities involved modifications to global objects between requests. These types of interactions can be difficult to understand with static code analysis because it is not always obvious the order that functions will be called under specific circumstances. There are more of these types of complex vulnerabilities out there that could be revealed with multi-request fuzzing and I hope that using this file delimiter technique will lead to more of them being found and fixed. 

In Part 3, I write a TAP device driver to fuzz the µCOS TCP/IP implementation.

Fuzzing µCOS protocol stacks, Part 2: Handling multiple requests per test case

Any vulnerability in an RTOS has the potential to affect many devices across multiple industries.

Wednesday, August 28, 2024 12:00

This is the first post of a three-part series, where we will be delving into the intricacies of fuzzing µC/OS protocol stacks. The techniques I will discuss are universally applicable to various RTOS environments, though our focus will primarily be on µC/OS. 

I’ll highlight some of the strategic code modifications I implemented across different µC/OS components. The objective is to streamline the process of developing a fuzzing harness tailored for the µC/HTTP-server. In the second installment of this series, I’ll discuss a technique that I used for delivering multiple requests per fuzz test case. The third post will be like this one, as I’ll describe the code modifications that I made with the aim of fuzzing the µC/TCP-IP stack.

For a bit of context, µC/OS is an RTOS, or “Real-Time Operating System.” An RTOS is a specialized operating system designed to manage hardware resources and host applications that need to run in systems where timing is critical, such as in embedded systems, medical devices, or industrial controls. RTOSes haven’t been fuzzed as thoroughly as software that runs on desktop operating systems, primarily due to the complexities associated with setting up a fuzzing harness for these systems. 

Developing a harness for an RTOS requires more coding effort than what is typically required for a straightforward, single-line fuzzing harness used with desktop applications or libraries. 

Any vulnerability in an RTOS has the potential to affect many devices across multiple industries. It’s important to put these codebases through the same rigorous testing as is common for desktop operating systems. My hope is that the techniques described in this blog post series will encourage more widespread use of fuzzing of RTOS software components. 

Historically fuzzing RTOS code involved a custom hardware setup to fuzz the code in its native environment, or fuzzing on an emulated version of the system. However, when Weston Embedded made the full µC/OS source code openly available in 2020, it sparked my curiosity about whether there could be a less complex approach to fuzz this type of code.

The goals for my fuzzer are:

*   Use a modern fuzzing framework (I chose AFL++).
*   Modify the networking code to accept input from a file.
*   Handle multiple requests per test case (more on this in part 2).

Additionally, the constraints (self-imposed) for my HTTP fuzzer are:

*   A software-only solution.
*   Run natively on Linux.

With that in mind, I wanted to avoid using emulation or dedicated hardware for my fuzzer.

**Linux port**

To make use of a modern fuzzing framework like AFL++, I needed to write some code that would allow the µC/HTTP-server to operate on Linux instead of the native µC/OS kernel. However, I had to give some thought to what exactly I wanted my fuzzer to target and determine appropriate insertion points for my hooks that would enable this protocol implementation to run on Linux.

Below is a basic architecture diagram showing the software component structure of a µC/HTTP-server application. The blue highlight represents the components that I will be modifying to port the application to Linux. The orange highlight represents the code which is the target for the fuzzer.

The modular design of µC/OS makes it wonderful to work with for this type of fuzzing. The Kernel Abstraction Layer (KAL in the diagram) provides a common API that is utilized by each of their libraries. This makes it easy to create a custom KAL that either mimics the desired RTOS functionalities for my fuzzer or simply returns a success signal for features that aren't relevant to the fuzzing process. Although µC/OS provides a POSIX-compatible KAL that enables the µC/HTTP-server to run on Linux, I chose to create my own KAL interface to simplify the entire setup. 

The KAL lays out an API blueprint for operating system components like task management, locks, semaphores, timers, and message queues. In the case of µC/HTTP-server, the only KAL function it calls is KAL_TaskCreate, which means I only needed to implement this particular function in my custom KAL interface. Additionally, since the task in question is the main HTTP processing loop, I found a workaround by directly invoking the function itself within the KAL_TaskCreate function, bypassing the need for a more complex task creation process. Example code below:

    void  KAL_TaskCreate (KAL_TASK_HANDLE     task_handle,
                          void              (*p_fnct)(void  *p_arg),
                          void               *p_task_arg,
                          CPU_INT08U          prio,
                          KAL_TASK_EXT_CFG   *p_cfg,
                          RTOS_ERR           *p_err)
    {
        /* return success  */
        *p_err = RTOS_ERR_NONE;
        /* fake it and call the function */
        p_fnct(p_task_arg);
        return;
    }

**Networking port****Socket reads**

Much like the Linux port mentioned earlier, there is a network abstraction called NetSock within µC/OS's TCP/IP protocol suite which is like a POSIX socket in its functionality. For the purposes of this fuzzing project, my attention isn't on probing the underlying TCP/IP stack; instead, I'm focused on the µC/HTTP-server code. To ensure that the fuzzing input is fed directly to the µC/HTTP-server code without first passing through the TCP/IP code, I created a custom NetSock implementation. 

My ultimate goal for this fuzzer is to read network data from a file. However, it will simplify the testing and debugging process to use existing tools to send real network traffic to my application. Once my µC/HTTP-server application is working enough to load a web page in a browser, it shouldn’t be too difficult to redirect protocol data from a file. 

I decided to implement a NetSock to POSIX socket port. All that was required to do that was to call the POSIX counterpart within the NetSock API and return an appropriate µC/OS error code. Below is example code demonstrating receiving data from a socket:

    NET_SOCK_RTN_CODE  NetSock_RxData (NET_SOCK_ID          sock_id,
                                       void                *p_data_buf,
                                       CPU_INT16U           data_buf_len,
                                       NET_SOCK_API_FLAGS   flags,
                                       NET_ERR             *p_err)
    {
        *p_err = NET_SOCK_ERR_NONE;
        ssize_t recvLen = 0;
        recvLen = recv(sock_id, p_data_buf, data_buf_len, 0);
        if (recvLen < 0)
        {
            *p_err = NET_ERR_RX;
            return NET_SOCK_BSD_ERR_RX;
        }
        else if (recvLen == 0)
        {
            *p_err = NET_SOCK_ERR_RX_Q_EMPTY;
        }
        return recvLen;
    }
    

I then repeated this process for each of the NetSock_\* functions. I used the correct NetSock_\* function signature, called the corresponding POSIX socket function call and then returned an error code that was of the type NET_SOCK_RTN_CODE.

**File reads**

With my µC/HTTP-server application now properly responding to HTTP requests, the next step was to set it up for fuzzing by having the NetSock code read from a file instead of a real POSIX socket. There are a few different options of how to achieve reading from a file. The first is using a tool called libdesock. The way that file redirection works with this tool is that the library gets loaded by the Linux linker before other libraries by using LD_PRELOAD. This allows the libdesock library to intercept POSIX socket calls and redirect them to stdin and stdout. 

Since I was already well acquainted with modifying the NetSock code, another simple approach is to read from a file instead of calling recv within NetSock. To implement this, my µC/HTTP-server application takes a file name as an argument and stores a file pointer to that file in a global variable named curr_inputfd. Below is an example of “receiving” data from a file: 

    NET_SOCK_RTN_CODE  NetSock_RxData (NET_SOCK_ID          sock_id,
                                       void                *p_data_buf,
                                       CPU_INT16U           data_buf_len,
                                       NET_SOCK_API_FLAGS   flags,
                                       NET_ERR             *p_err)
    {
        ssize_t totalLen = 0;
    
        *p_err = NET_SOCK_ERR_NONE;
    
        totalLen = read(curr_inputfd, (char*)p_data_buf, data_buf_len);
    
        if (0 > totalLen)
        {
            /* return an error */
            *p_err = NET_ERR_RX;
            return NET_SOCK_BSD_ERR_RX;
            
        }
        else if (0 == totalLen)
        {
            /* we've read the whole file and we can leave*/
            *p_err = NET_SOCK_ERR_CLOSED;
        }
    
        return totalLen;
    }
    

It is important to note that the above code returns an error when the end of the file (EOF) is reached. This happens because NetSock_RxData is invoked within a processing loop, and the error serves as an indicator to the caller that this "socket" has been closed.

When fuzzing an application, it is crucial for the fuzzer to differentiate between a clean exit (normal program termination) and a crash. Additionally, the program should terminate after processing the fuzzed input. Therefore, I needed to make another code modification for fuzzing purposes, ensuring that the program exits after the file has been read and processed, resulting in a "normal" termination. 

Without this modification, the application would continue running in a processing loop, causing the fuzzer to mistakenly count this as a hang rather than a normal program termination, leading to false-positives for hangs.

By placing the exit in this location, it will be called during the typical execution flow of closing a connection. And, as noted above, when the error code NET_SOCK_ERR_CLOSED is returned from NetSock_RxData, it triggers the HTTPsConn_Close function, which subsequently terminates the program's execution.

**Memory errors**

A major benefit of porting my µC/HTTP-server application to run natively on Linux is that I can compile my application with AddressSanitizer. AddressSanitizer, or ASAN, is a compiler feature in GCC and Clang that can detect memory errors in C/C++. 

This can be a very valuable tool when used in conjunction with fuzzing to reveal software vulnerabilities. When ASAN is enabled, the application will crash when a memory error is encountered. 

Things like use after free, NULL pointer dereference, and buffer overruns will cause an immediate crash even if the test input would not have normally crashed the program. When ASAN causes a program to crash, it’s like an alarm bell going off for a vulnerability researcher (**“**Look over here, there are problems in this section of code!**”**). I wanted to use ASAN when running my fuzzer, but it didn’t work straight away for heap memory in my µC/HTTP-server application. This is because µC/OS provides its own heap implementation. 

ASAN works by tracking heap memory allocations made with glibc malloc, but my application doesn’t use malloc at all. The simplest solution that I produced was to add preprocessor macros to detect when the application was being compiled with ASAN and redirect the allocation to glibc malloc. Here’s an example of what I mean:

    void  *Mem_DynPoolBlkGet (MEM_DYN_POOL  *p_pool,
                              LIB_ERR       *p_err)
    {
    #ifdef __SANITIZE_ADDRESS__
        p_blk = malloc(p_pool->BlkSize);
        if (NULL == p_blk)
        {
            *p_err = LIB_MEM_ERR_POOL_EMPTY;
            return(DEF_NULL);
        }
        else
        {
            *p_err = LIB_MEM_ERR_NONE;
        }
        return (p_blk);
    
    #endif /*__SANITIZE_ADDRESS__*/

µC/OS provides developers the capability to define constraints on the heap's location and utilization with its specialized heap allocator. This feature is particularly useful in systems with limited memory, where developers require fine-tuned control over memory allocation. However, since my application is running on Linux, I'm not constrained by memory limitations, and I have access to the standard glibc malloc function. Simply calling malloc within Mem_DynPoolBlkGet  works because the caller of Mem_DynPoolBlkGet doesn’t care about the specific memory location of the pointer that's returned. Rather, it expects the pointer to reference a chunk of memory that's ready for use and meets the minimum size requirement. By making this minor adjustment to the code, I enabled the Address Sanitizer (ASAN) features I wanted, without affecting the rest of the application's functionality.

**Vulnerability highlight**

To this point, we’ve made strategic modifications to µC/OS code, creating a software-only fuzzing solution capable of running natively on Linux and accepting input from a file. The approach we discussed here has proven its efficacy by uncovering five unique vulnerabilities: TALOS-2023-1725 (CVE-2023-24585), TALOS-2023-1733 (CVE-2023-27882), TALOS-2023-1738 (CVE-2023-28379), TALOS-2023-1746 (CVE-2023-31247) and TALOS-2023-1843 (CVE-2023-45318).

When disclosing these vulnerabilities, I discovered that much of the µC/HTTP-server codebase is shared across multiple products. Other affected products are the Silicon Labs Gecko Platform and Weston Embedded Cesium NET. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:201, 119:281, 1:12685, 1:39908. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

The next installment of this series will describe the complexities of handling multiple requests per test case — an enhancement that holds the potential to reveal even more vulnerabilities.

Fuzzing µC/OS protocol stacks, Part 1: HTTP server fuzzing

This is the final post in the three-part series that details techniques I used to fuzz two µC/OS protocol stacks: µC/TCP-IP and µC/HTTP-server.

Wednesday, August 28, 2024 12:00

This is the final post in the three-part series that details techniques I used to fuzz two µC/OS protocol stacks: µC/TCP-IP and µC/HTTP-server. 

The first post highlighted code modifications necessary for developing a fuzzing harness tailored for the µC/HTTP-server. The second discussed a technique for delivering multiple requests per fuzz test case. Finally, I’ll detail the code modifications required for fuzzing the µC/TCP-IP stack. Please refer to the first post in the series for a description of Real-Time Operating Systems (RTOS) and the motivations for this research project. 

My goals in fuzzing µC/TCP-IP are the same as for µC/HTTP-server:

*   Use a modern fuzzing framework (I chose AFL++).
*   Modify the networking code to accept input from a file.
*   Handle multiple requests per test case.

Self-imposed constraints:

*   A software-only solution.
*   Run natively on Linux.

I wanted to find a straightforward way to fuzz this code without relying on emulation or dedicated hardware. 

**Linux port**

To utilize the AFL++ fuzzing framework, this code must run on Linux rather than µC/OS. This is a similar challenge I faced in Part 1. This time, however, I opted to use the POSIX KAL implementation that µC/OS provided rather than develop my own. This architecture diagram shows the layout of the various software components of µC/OS. The blue highlight represents the components I will be modifying to port the application to Linux. The orange highlight represents the code that’s the fuzzer’s target.

With my µC/HTTP-server fuzzing harness, I decided against using the provided POSIX KAL implementation. The µC/HTTP-server code I was targeting did not use many of the OS components, so it was simple to implement my own minimalist KAL interface. In contrast, the µC/TCP-IP implementation uses a separate task for receiving data and uses semaphores and message queues requiring a more complete KAL implementation. 

Using the code provided by µC/OS felt like taking a shortcut. It was painless and worked right out of the box with only minor modifications. That’s not something that I can say for working with the networking side of things, which required a lot of development.

**Network port ****TAP device**

My primary goal for the fuzzer is to enable it to accept network data from a file. To start, I adopted the strategy I used for my µC/HTTP-server, which involves ensuring my program functions with actual network data. Doing this initially allows for more straightforward debugging and testing of my code, as I can use standard Linux utilities to send real network traffic to my program.

It was a bit more complicated to get data from the network to be processed by µC/TCP-IP than it was for µC/HTTP-server. This is because TCP/IP is a lower-level protocol than HTTP. HTTP is an application layer protocol while TCP/IP is a transport layer protocol. Typically, user mode applications interact with the network at the application layer via POSIX sockets or a NetSock for µC/OS. 

In Linux, when using sockets, the kernel manages the TCP/IP processing and only delivers application layer data to the user mode application. However, my challenge was that my user mode µC/TCP-IP application is intended to handle the TCP/IP protocol itself. To bypass the kernel’s TCP/IP stack, I utilized a TAP device — a purely software-based kernel virtual network device.

Although this module is called µC/TCP-IP, it actually covers multiple layers of the OSI model. The layers circled in orange indicate layers of the OSI model for which the µC/TCP-IP module will process:

The µC/TCP-IP code is expecting to receive an Ethernet frame, and it includes handlers for ARP, IP, TCP and UDP. Because µC/TCP-IP is expecting to receive Ethernet frames, a TAP device should be used because it transfers Ethernet frames unlike a TUN device which transfers IP packets. 

A TAP device is meant to be used by user space programs that attach to it. When the operating system sends packets to a TAP device, they are delivered to the attached user space program. Conversely, packets sent by the user-space program to the TAP device are injected into the kernel network stack as if they originated from an external source.

To use a TAP device, I wrote my own Ethernet device driver using the API provided by µC/TCP-IP. I needed to create and configure my TAP device with the driver and implement functions to transmit and receive data. Again, µC/OS was great to work with for this because their API was well-defined and documented. Additionally, there are dozens of device drivers in the µC/TCP-IP repository for various ethernet hardware. Having all this example code and documentation was immensely helpful. In implementing this, I used the open-source tapip utility as a guide for creating and configuring a TAP device within my µC/TCP-IP Ethernet driver.  

The most confusing part of this was visualizing the network topology involving the TAP device. I created and assigned the TAP device an IP address of 10.10.10.1 and the Linux kernel assigned it a MAC address of 46:31:92:b0:48:5b. For remote communication, I'd need to create a network bridge, but for testing, local communication is adequate. The TAP device that I created is given the name tap0 and even shows up when running ifconfig: 

I also needed to assign my µC/TCP-IP application its own MAC and IP addresses, effectively creating another virtual Ethernet device. This adds a layer of complexity, as it's a virtual ethernet device operating through another virtual Ethernet device. Within the µC/TCP-IP application I've set up a virtual Ethernet device with an IP address of 10.10.10.64 and a MAC address of 12:12:12:34:34:34. This setup is a bit confusing because it's not externally visible in the Linux system — it's exclusive to the µC/TCP-IP application, as if the application were running on a separate machine, with the tap interface acting as the link between the Linux host and the µC/TCP-IP application.

To validate the functionality of µC/TCP-IP, I developed an echo server running on port 10001. To test my setup, I used the Linux utility netcat to establish a TCP connection to the µC/TCP-IP application. When traffic is sent from a linux application using tap0 and the mac or ip address of the µC/TCP-IP virtual interface is provided, it will be processed by my application. To send a test message and establish a TCP connection, I could execute a netcat command such as echo 'test' | nc -N 10.10.10.64 10001. Here, the netcat tool operates through a socket connected to the tap0 interface. This socket uses the Linux kernel TCP/IP stack which will first send an ARP request from tap0’s address to broadcast to learn the corresponding MAC address for that IP address. Then, the µC/TCP-IP application will receive that broadcast message, process the request, and respond with its own MAC/IP address pair. Then, a TCP connection will be initiated using the MAC/IP address pair of the µC/TCP-IP application. The image below was captured using Wireshark attached to the tap0 interface. 

The µC/TCP-IP application is not using sockets when interacting with the tap0 interface, instead, it uses a file descriptor to directly read from and write the device. The result is that the µC/TCP-IP application is writing packet data directly to the network without modification. The diagram below shows how each of these components work together to establish the TCP connection shown above. 

**File reads**

At this point, I’ve confirmed that my µC/TCP-IP echo server works using netcat. The next step for fuzzing is to modify the Ethernet driver to read from a file instead of the TAP device. Although my Ethernet driver isn’t using sockets, it is still possible to use libdesock because it overrides the read and write from libc. However, this required some code modifications in addition to using LD_PRELOAD with libdesock. First, I needed to create a socket descriptor that libdesock would redirect to stdin. Since the µC/TCP-IP application does not use sockets when interacting with the tap0 interface, I had to utilize a libdesock debug function, _debug_instant_fd, which provides a file descriptor that is automatically redirected to stdin. 

Typically, libdesock would redirect a file descriptor when accept is called, but since this is happening at a lower level, I needed to use the file descriptor that libdesock provided with the call to _debug_instant_fd. I used a compile time flag to create this libdesock file descriptor instead of creating a tap device for my fuzzing build:

    #ifdef DESOCK_FUZZ
        /* calling _debug_instant_fd for libdesock */
        fd = _debug_instant_fd(0);
        p_dev_data->tunFd = fd;
    #else
        /* Create TAP device */
    

Then, I needed to add code to terminate the µC/TCP-IP echo server once the last request was read from the file.

           ret = read(p_dev_data->tunFd, p_dev_data->RxDataPtr, p_dev_data->rxSize);
    …
    #ifdef DESOCK_FUZZ
            } else if (0 == ret)
            {
                exit(0);
            }
    #else
    	/* Continue processing */

After those code modifications, when we use LD_PRELOAD with libdesock, our application will read request data from stdin. By utilizing libdesock I immediately gained support for handling multiple requests because of that added feature. For more information on how libdesock works, refer to Post 2 from this series. 

**Memory errors**

I wanted to use Address Sanitizer (ASAN) with my fuzz application, as it is designed to detect many different types of memory errors like use after free, NULL pointer dereference and buffer overruns. The heap implementation used by µC/TCP-IP is different from that of µC/HTTP-server, but I was able to employ the same technique that I described in Post 1 from this series.

**Vulnerability highlight**

Now, we've successfully adapted the µC/TCP-IP code to develop a fuzzing solution that operates solely in software, is native to Linux, and can process inputs from a file. The approach we discussed here uncovered two unique vulnerabilities: TALOS-2023-1828 and TALOS-2023-1829. One of which is a result of fuzzing multiple requests at a time.

When disclosing these vulnerabilities, I discovered that much of the µC/TCP-IP codebase is shared across multiple products. Silicon Labs Gecko Platform is also affected by TALOS-2023-1828. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:201, 116:2 and 116:151.

**Conclusion **

Thank you for following along in this series about fuzzing µCOS protocol stacks. To recap, we created software-only fuzzing solutions for fuzzing µC/HTTP-server and µC/TCP-IP. The fuzzing solutions discussed here include the ability to run natively on Linux and accept input from a file. We also covered a feature contribution to libdesock which allows for multiple requests to be processed by the application in a single test case, resulting in more complex vulnerability findings. My hope is that the techniques described in this series will encourage others to fuzz other RTOS platforms to make these important systems more secure.

Below is a list of vulnerabilities that were disclosed because of this research presented in this blog series:

*   TALOS-2023-1725: Out-of-bounds write vulnerability
*   TALOS-2023-1726: Buffer overflow vulnerability
*   TALOS-2023-1732: Memory corruption vulnerability
*   TALOS-2023-1733: Heap-based buffer overflow vulnerability
*   TALOS-2023-1738: Memory corruption vulnerability
*   TALOS-2023-1746: Memory corruption vulnerability
*   TALOS-2023-1828: Denail of service vulnerability
*   TALOS-2023-1829: Double-free vulnerability
*   TALOS-2023-1843: Heap-based buffer overflow vulnerability

The following is a list of Snort rules that will detect exploitation attempts against these vulnerabilities: 119:201, 119:281, 1:12685, 1:39908, 119:203:1, 119:282:1, 116:2 and 116:151. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

Fuzzing µC/OS protocol stacks, Part 3: TCP/IP server fuzzing, implementing a TAP driver

In recent investigations, Talos Incident Response has observed the BlackByte ransomware group using techniques that depart from their established tradecraft. Read the full analysis.

BlackByte blends tried-and-true tradecraft with newly disclosed vulnerabilities to support ongoing attacks

It’s not unusual for a threat actor to exaggerate the extent of a hack or breach to drum up interest, and hopefully, the eventual purchase or ransom price.

Thursday, August 22, 2024 14:00

My current least favorite thing about the churn of social media that I’ve seen over the past week is waves of stories, posts and videos saying that every U.S. citizen’s Social Security number has been stolen or potentially viewed by a threat actor. 

The claim comes from a class action lawsuit filed on Aug. 1 against a data broker called National Public Data, claiming they failed to keep U.S. citizens’ Social Security numbers secure. A threat actor going by USDoD claimed in April that it had accessed a database that included information on every person in the U.S., Canada and the U.K.  

The lawsuit states that a breach at National Public Data resulted in the exposure of more than 3 billion personal records (a number that obviously surpasses the current population of the U.S.), including every Social Security number. That sounds scary, and many people took the statement as fact, running to create warnings that your Social Security number had definitely been breached and you needed to “TAKE ACTION NOW!” 

Except, the claim in the lawsuit is still unsubstantiated. This is not to say there was never a breach or that \*some\* public records weren’t stolen or accessed, but almost certainly not literally every single Social Security number. 

For starters, I used a tool from security firm Pentester that allows users to search for if their Social Security number, birthday, or other sensitive information may be in the NPD Breach. I searched for everyone in my immediate family, parents, and stepparents, and nothing turned up. I suppose it’s possible that for some reason just my family was exempted from the breach, but that seems unlikely. 

Reporters at TechCrunch have also viewed the allegedly stolen data, and determined much of the information was incomplete or incorrect, though some of it was legitimate. 

It’s not unusual for a threat actor to exaggerate the extent of a hack or breach to drum up interest, and hopefully, the eventual purchase or ransom price. Which is why I’m disappointed that so many people took off and ran with the claim that every American was affected by this breach. 

There are always steps we can be taking to better protect our personal information, so I don’t want to make it seem like we’re all totally safe and to just go about your business as usual. And if you do use the linked tool above and find that your information may be affected by the NPD breach, it could be a good idea to freeze your credit or keep a close eye on your bank account(s).  

But all the LinkedIn posts and viral videos claiming that every American’s had their Social Security number stolen only leads to more FUD. And it plays right into attackers’ hands: By spreading that FUD, it makes users more likely to fall for other scams that are trying to capitalize on the breach by sending phony scams around identity protection or offering new information on the allegedly stolen data.  

**The one big thing **

Cisco Talos has uncovered a new remote access trojan (RAT) family we are calling “MoonPeak.” This a XenoRAT-based malware, which is under active development by a North Korean nexus cluster we are calling “UAT-5394.” Our analysis of infrastructure used in the campaign reveals additional links to the UAT-5394 infrastructure and new tactics, techniques and procedures (TTPs) of the threat actor. This cluster of activity has some overlaps in TTPs and infrastructure patterns with the North Korean state-sponsored group “Kimsuky,” however, we do not have substantial technical evidence to link this campaign with the APT. 

**Why do I care? **

Either UAT-5394 is actually Kimsuky (or a sub-group within Kimsuky) and they are replacing QuasarRAT with MoonPeak. (We have observed UAT-5394 actively setting up and operating QuasarRAT C2 servers before they eventually adopted the use of XenoRAT and MoonPeak.) Or UAT-5394 is another group within the North Korean APT machinery that borrows their TTPs and infrastructure patterns from Kimsuky. Any actor potentially associated with North Korea is worth watching, as these groups are constantly trying to steal money, intellectual property or data on behalf of the state. So, any new developments in how state-sponsored actors work together is relevant to defenders and users alike. 

**So now what? **

Talos released a new Snort rule set that detects the new malware disclosed this week. The timelines of the consistent adoption of new malware and its evolution such as in the case of MoonPeak highlights that UAT-5394 continues to add and enhance more tooling into their arsenal. And the rapid pace of establishing new supporting infrastructure by UAT-5394 indicates that the group is aiming to rapidly proliferate this campaign and set up more drop points and C2 servers, so this is activity we’ll be continuing to monitor and update readers on. 

**Top security headlines of the week **

**A North Korean state-sponsored actor recently exploited a zero-day vulnerability that Microsoft patched earlier this month.** Security researchers say that actors connected to the Lazarus Group, the most prolific and well-known North Korean APT, actively exploited CVE-2024-38193. This is a use-after-free issue in AFD.sys, a binary file in what's essentially the kernel entry point for the Winsock API. The actors then installed the FudModule malware, which was first discovered in 2022. FudModule is more stealthy than other malware, finding additional and new ways to hide from detection. Microsoft disclosed and patched CVE-2024-38193 earlier this month as part of its regular Patch Tuesday update cycle. At the time, it was listed as a zero-day, meaning adversaries had exploited the issue in the wild before a patch was available. This was one of the six zero-days included in Microsoft Patch Tuesday this month. An attacker who exploits the vulnerability could obtain nearly full access to Windows and usually run untrusted code. (Ars Technica, PC World) 

**The FBI and other U.S. federal agencies publicly stated that Iran is behind recent cyber attacks targeting both major U.S. presidential campaigns.** A public statement warned that state-sponsored actors from Iran were trying to “stoke discord and undermine confidence in our democratic institutions.” Threat actors successfully breached an email account belonging to a staffer on former U.S. President Donald Trump’s campaign and leaked that information, though many major news outlets declined to publish any reports on the information because of the way in which it was obtained. “The \[intelligence community\] is confident that the Iranians have through social engineering and other efforts sought access to individuals with direct access to the Presidential campaigns of both political parties,” U.S. intelligence officials said in the statement. The presidential campaigns from the Democratic and Republican parties both said they received spear-phishing emails seemingly connected to the efforts. (Associated Press, BBC) 

**Nearly all Google Pixel devices since 2017 have been vulnerable to an exploit that exists in an otherwise dormant app.** Security researchers disclosed the vulnerability last week in Showcase.apk, a software package that exists on all Pixel phones and can be used to turn the devices into store demos for Verizon. Though details on the exact type of vulnerability are still unclear, a report from iVerify stated that the way the software operates fundamentally changes the way the Android operating system works, leaving Pixel devices susceptible to man-in-the-middle attacks or the installation of spyware. Google has since removed the software package from all devices, as it is no longer in use. A Google representative told Recorded Future that it had not seen any information indicating the software had been exploited, and that the hypothetical exploit requires the attacker to have physical access to the device and knowing the user’s device passcode. The app is not present on the Pixel 9, the newest line of phones Google unveiled this week. (Wired, The Record) 

**Can’t get enough Talos? **

*   How multiple vulnerabilities in Microsoft apps for macOS pave the way to stealing permissions 
*   Talos Takes Ep. #194: A 1-on-1 with Talos VP Matt Watchinski 
*   MoonPeak malware from North Korean actors unveils new details on attacker infrastructure 
*   Bug Leaves Microsoft Apps for MacOS Open to Silent Takeovers 
*   Multiple flaws in Microsoft macOS apps unpatched despite potential risks 
*   Multiple Microsoft Apps for macOS Vulnerable to Library Injection Attacks 

**Upcoming events where you can find Talos **

**_BSides Krakow_** **_(Sept. 14)_**  

_Krakow, Poland_ 

**_LABScon_** **_(Sept. 18 - 21)_** 

_Scottsdale, Arizona_

**_VB2024_** **_(Oct. 2 - 4)_**

_Dublin, Ireland_

**Most prevalent malware files from Talos telemetry over the past week **

**SHA 256:** 70ff63cd695033f624a456a5c8511ce8312cffd8ac40492ffe5dc7ae18548668  
**MD5:** 49d35332a1c6fefae1d31a581a66ab46  
**Typical Filename:** 49d35332a1c6fefae1d31a581a66ab46.virus  
**Claimed Product:** N/A  
**Detection Name:** W32.Auto:70ff63.in03.Talos

**SHA 256:** db697b450d015ee948bb50d895acca3e27058b6d546d93212791b9f5ff31c0a3  
**MD5:** 391b3770ab60f9e535fbf3db70c89b04  
**Typical Filename:** vt-upload-o0OJb  
**Claimed Product:** N/A  
**Detection Name:** W32.Auto.db697b.181952.in01

**SHA 256:** a024a18e27707738adcd7b5a740c5a93534b4b8c9d3b947f6d85740af19d17d0  
**MD5:** b4440eea7367c3fb04a89225df4022a6  
**Typical Filename:** Pdfixers.exe  
**Claimed Product:** Pdfixers  
**Detection Name:** W32.Superfluss:PUPgenPUP.27gq.1201

**SHA 256:** c67b03c0a91eaefffd2f2c79b5c26a2648b8d3c19a22cadf35453455ff08ead0  
**MD5:** 8c69830a50fb85d8a794fa46643493b2  
**Typical Filename:** AAct.exe  
**Claimed Product:** N/A  
**Detection Name:** PUA.Win.Dropper.Generic::1201

**SHA 256:** 161937ed1502c491748d055287898dd37af96405aeff48c2500b834f6739e72d  
**MD5:** fd743b55d530e0468805de0e83758fe9  
**Typical Filename:** KMSAuto Net.exe  
**Claimed Product:** KMSAuto Net  
**Detection Name:** W32.File.MalParent

No, not every Social Security number in the U.S. was stolen

Cisco Talos has uncovered a new remote access trojan (RAT) family we are calling “MoonPeak.” This a XenoRAT-based malware, which is under active development by a North Korean nexus cluster we are calling “UAT-5394.”

MoonPeak malware from North Korean actors unveils new details on attacker infrastructure

An adversary could exploit these vulnerabilities by injecting malicious libraries into Microsoft's applications to gain their entitlements and user-granted permissions.

How multiple vulnerabilities in Microsoft apps for macOS pave the way to stealing permissions

Voting Village co-founder Harri Hursti told Politico the list of vulnerabilities ran “multiple pages.”

Thursday, August 15, 2024 14:00

As promised, I’m back this week to recap some of the top stories coming out of Black Hat and DEF CON.  

Also as promised, AI was the talk of Vegas during Hacker Summer Camp (or at least from what I’ve been reading and hearing, I wasn’t there in person). 

Several exhibitions and talks at both conferences showed how easy it is to create deepfake videos and potentially use them to spread fake news and disinformation. Two security researchers worked to deepfake themselves and even managed to trick people into believing it really was them on one end of a video conference call.  

Others on the show floor had the opportunity to try their hand at creating deepfakes with the help of the Defense Advanced Research Projects Agency (DARPA). One standout example was a fake video of former Royal Family member Meghan Markle being transposed onto the face of a reporter who could then speak in an approximation of Markle’s voice to say whatever she wanted to. 

The good news is that, for now, these types of deepfakes are also incredibly easy for tools and humans alike to detect.  

For example, Adobe’s Content Authenticity Initiative is working to place labels on images to indicate that they were originally human-made, and clicking on the image would allow the user to read more information about that image’s history and where and how it had been created. 

And in the case of the Meghan Markle deepfake, the SemaFor tool on display at the DEF CON village appropriately detected the image as fake using its scoring system (it didn’t help that the deepfake creator couldn’t account for the fact that the “creator” was wearing glasses).  

Security researchers also used DEF CON and Black Hat to show where potential security pitfalls lie with the rise of AI tools and software. 

One talk centered around how Microsoft’s AI Copilot could essentially be turned into an “automated phishing machine” by leaking personal information, and other researchers warned about an over-reliance on learned language models (LLMs) to write software code that often includes vulnerabilities and errors. 

Over in the DEF CON Voting Village, security researchers found their usual swath of vulnerabilities that could be used against popular voting machines and other hardware that will likely be used in the 2024 U.S. presidential election. While we don’t have many details on the specific vulnerabilities found, Voting Village co-founder Harri Hursti told Politico the list of vulnerabilities ran “multiple pages.” 

There are a few issues that came to light for me when I was reading about this research and bug hunting: One is that there isn’t enough time to implement many of these fixes before the November election, and there are just so many different pieces of equipment and manufacturers that it’s impossible to properly inspect all these devices. I may feel compelled to write more about this later, but it’s interesting to me that we as a country have managed to decide on essentially two cell phone manufacturers that we’re willing to buy from: Apple and Google. Yet there is no standard for the types, age and vendors that we rely on for our elections, and when they’re not in use, they just sit in storage.  

**The one big thing **

This month’s Microsoft Patch Tuesday includes updates for security vulnerabilities in Office, Visual Studio, Azure, CoPilot, Teams and more. Of the six zero-day vulnerabilities Microsoft disclosed as part of its regular patching cadence, half are local privilege escalation vulnerabilities, meaning adversaries could combine them with other flaws to make their attack more serious or with higher-level privileges. Cisco Talos’ Vulnerability Research team discovered four of the vulnerabilities Microsoft patched this week: CVE-2024-38184, CVE-2024-38185, CVE-2024-38186 and CVE-2024-38187. These are elevation of privilege vulnerabilities in the Microsoft Windows kernel-mode driver that could allow an attacker to gain SYSTEM-level privileges. Talos researchers also discovered eight vulnerabilities in CLIPSP.SYS, a driver used to implement Client License System Policy on Windows 10 and 11. 

**Why do I care? **

Talos discovered three issues, TALOS-2024-1971 (CVE-2024-38062) and TALOS-2024-1970 (CVE-2024-38062) and TALOS-2024-1969 (CVE-2024-38187), an adversary could exploit by sending the targeted system a specially crafted license blob, which could lead to a denial of service. TALOS-2024-1964 (CVE-2024-38184) is exploited in the same way, but in this case, could allow the adversary to bypass the usual security checks that take place and allow them to tamper with the license. By tampering with the license, an adversary could change its properties such as when the license expires, or even create a new license that could then be used with other applications downloaded from the Windows store. Two other out-of-bounds write vulnerabilities, TALOS-2024-1966 (CVE-2024-38186) and TALOS-2024-1988 (CVE-2024-38062), could lead to privilege escalation. And in both cases, the vulnerable functions could play into a sandbox escape attack. 

Microsoft also issued a patch for a zero-day vulnerability that was already being exploited in the wild and publicly disclosed. The company warned of CVE-2024-38200 last week, which could lead to the unauthorized disclosure of sensitive information to malicious actors. 

**So now what? **

Talos released a new Snort rule set that detects attempts to exploit some of the vulnerabilities disclosed Tuesday. Cisco Security Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org. The rules included in this release that protect against the exploitation of many of these vulnerabilities are 63858 – 63861 and 63864 - 63878. There are also Snort 3 rules 300980 – 300988. Talos’ Vulnerability Roundup also has technical details on the eight CLIPSP.SYS vulnerabilities. 

**Top security headlines of the week **

**Secure messaging app Signal is now blocked in Venezuela and Russia, limiting a popular communication channel for activists and protestors in those countries.** In Russia, government officials have said that the app violates the country’s privacy legislation, while in Venezuela, the block comes after weeks of protests over the country’s disputed presidential election results. Signal is a popular option for users looking for encrypted messaging or hoping to avoid government censorship. The app told users that they could circumvent these blocks by turning on the app’s “censorship circumvention” settings or using a VPN to create a new account. Venezuela’s ruling party has also ordered that access to X/Twitter be restricted for 10 days, and YouTube also experienced a widespread outage in Russia that the company said was “not as a result of any technical issues on our side or action taken by us.” (The Verge, Engadget) 

**The FBI has shut down dozens of servers and the main leak site associated with the Radar ransomware group (aka Dispossessor).** Radar started out as a threat actor known for taking data stolen by the LockBit ransomware operators and offering it for sale on dark web forums, but eventually became its own self-sufficient ransomware operation. In a press release announcing the takedown over the weekend, the FBI said that Radar particularly focused on small-to-mid-sized businesses and organizations from the production, education, healthcare, financial services and transportation sectors. They identified 43 victims across the U.S., U.K., Argentina, Australia, Brazil, Canada, Poland, Germany and more. The group’s infrastructure included three servers in the U.S., three servers in the U.K., 18 servers in Germany, and eight U.S.-based domains, all of which were seized and displayed a takedown message from the FBI at the time of the takedown. (Dark Reading, Inc.) 

**The head of the U.S. Cybersecurity and Infrastructure Security Agency used her time at the Black Hat conference to call on software makers to adopt a security-by-design practice.** Jen Easterly, speaking in the keynote section of one of the largest cybersecurity conferences in the world, said that “We don’t have a cybersecurity problem, we have a software quality problem.” Easterly said many technology companies have voluntarily adopted CISA’s secure-by-design standards, which pledges to bake cybersecurity and vulnerability reviews into the design process of all new hardware and software products. “The cybersecurity industry was created to solve a problem created by another set of vendors, the technology companies and software makers. For decades tech vendors have been allowed to create insecure software,” she said. She also called on Congress to establish what she called a “liability regime” to hold companies responsible for designing insecure products and providing support to companies that due adhere to cybersecurity standards. (Inside AI Policy, CyberScoop)  

**Can’t get enough Talos? **

*   A refresher on Talos’ open-source tools and the importance of the open-source community 
*   Current attacks, targets, and other threat landscape trends 
*   As AI transforms cybersecurity, Cisco’s Martin Lee has only one piece of advice for IT managers: expect the unexpected 
*   Cisco Integrated Talos Threat Intelligence for All Splunk Users 

**Upcoming events where you can find Talos **

**_BSides Krakow_** **_(Sept. 14)_**  

_Krakow, Poland_ 

**_LABScon_** **_(Sept. 18 - 21)_** 

_Scottsdale, Arizona_

**_VB2024_** **_(Oct. 2 - 4)_**

_Dublin, Ireland_

**Most prevalent malware files from Talos telemetry over the past week **

**SHA 256:** 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
**MD5:** 2915b3f8b703eb744fc54c81f4a9c67f f  
**Typical Filename:** VID001.exe  
**Claimed Product:** N/A  
**Detection Name:** Win.Worm.Coinminer::1201

**SHA 256:** c67b03c0a91eaefffd2f2c79b5c26a2648b8d3c19a22cadf35453455ff08ead0  
**MD5:** 8c69830a50fb85d8a794fa46643493b2  
**Typical Filename:** AAct.exe  
**Claimed Product:** N/A  
**Detection Name:** PUA.Win.Dropper.Generic::1201

**SHA 256:** 161937ed1502c491748d055287898dd37af96405aeff48c2500b834f6739e72d  
**MD5:** fd743b55d530e0468805de0e83758fe9  
**Typical Filename:** KMSAuto Net.exe  
**Claimed Product:** KMSAuto Net  
**Detection Name:** W32.File.MalParent

**SHA 256:** 24283c2eda68c559f85db7bf7ccfe3f81e2c7dfc98a304b2056f1a7c053594fe  
**MD5:** 49ae44d48c8ff0ee1b23a310cb2ecf5a  
**Typical Filename:** nYzVlQyRnQmDcXk  
**Claimed Product:** N/A  
**Detection Name:** Win.Dropper.Scar::tpd

**SHA 256:** bea312ccbc8a912d4322b45ea64d69bb3add4d818fd1eb7723260b11d76a138a  
**MD5:** 200206279107f4a2bb1832e3fcd7d64c  
**Typical Filename:** lsgkozfm.bat  
**Claimed Product:** N/A  
**Detection Name:** Win.Dropper.Scar::tpd

AI, election security headline discussions at Black Hat and DEF CON

Eight of the vulnerabilities affect the license update feature for CLIPSP.SYS, a driver used to implement Client License System Policy on Windows 10 and 11.

Wednesday, August 14, 2024 12:02

Cisco Talos’ Vulnerability Research team recently discovered 11 vulnerabilities in Microsoft Windows CLIPSP.SYS and Adobe Acrobat Reader that were all disclosed this week as part of the company’s regular security updates.

For more on Patch Tuesday, check out Talos’ blog post here. 

Eight of the vulnerabilities affect the license update feature for CLIPSP.SYS, a driver used to implement Client License System Policy on Windows 10 and 11. The three others are use-after-free or out-of-bounds read vulnerabilities in Adobe Acrobat Reader, one of the most popular PDF readers on the market currently.

Microsoft and Adobe have patched the issues mentioned in this blog post, all in adherence to Cisco’s third-party vulnerability disclosure policy, while LevelOne has declined to release a fix.

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website. 

**Multiple vulnerabilities in Windows CLIPSP.SYS**

_Discovered by Philippe Laulheret._

CLIPSP.SYS is a driver in Windows 10 and 11 that implements the Client License System Policy. The process of updating this license can be exploited by an adversary to carry out several different exploits.

Talos discovered three issues, TALOS-2024-1971 (CVE-2024-38062) and TALOS-2024-1970 (CVE-2024-38062) and TALOS-2024-1969 (CVE-2024-38187), an adversary could exploit by sending the targeted system a specially crafted license blob, which could lead to a denial of service.

TALOS-2024-1964 (CVE-2024-38184) is exploited in the same way, but in this case, could allow the adversary to bypass the usual security checks that take place and allow them to tamper with the license. By tampering with the license, an adversary could change its properties such as when the license expires, or even create a new license that could then be used with other applications downloaded from the Windows store. 

Two out-of-bounds write vulnerabilities, TALOS-2024-1966 (CVE-2024-38186) and TALOS-2024-1988 (CVE-2024-38062), could lead to privilege escalation. And in both cases, the vulnerable functions could play into a sandbox escape attack.

TALOS-2024-1965 (CVE-2024-38185) and TALOS-2024-1968 (CVE-2024-38062) are also out-of-bounds read vulnerabilities, but in their cases, lead to the disclosure of sensitive information and an out-of-bounds kernel read, respectively.

**Adobe Acrobat Reader vulnerability could lead to remote code execution**

_Discovered by KPC._

Adobe Acrobat Reader contains three vulnerabilities, one of which could allow an attacker to execute arbitrary code. 

TALOS-2024-2002 (CVE-2024-41832) and TALOS-2024-2003 (CVE-2024-41835) exist in the CoolType font processor in Reader. An adversary could embed a specially crafted font in a PDF, and then trick the targeted user into opening that PDF, to exploit these vulnerabilities. 

This could allow the adversary to view sensitive contents of arbitrary memory, which could aid in further exploitation and exploit mitigation bypass.

TALOS-2024-2009 (CVE-2024-41830) is the most serious of the issues Talos discovered, with a CVSS score of 8.8 out of 10. If an adversary tricks a user into opening a specially crafted PDF, malicious JavaScript code in the PDF could trigger the reuse of a previously freed object, leading to memory corruption and potentially arbitrary code execution.

Source

TALOS