Delving into Windows CE, Part 4: Vulnerability Research into a Windows CE-Based HMI Used in the Wild

Introduction

This is the final installment of our Windows CE research series. In previous parts, we demonstrated how to build and debug Windows CE applications, and also showcased our custom Windows CE debugger client. 

In this blog, we describe  vulnerability research conducted using our debugger  utility and insights gained throughout this project. The research we will present here was conducted on the C-more HMI device. C-more HMIs are a graphical interface to process-level devices such as programmable logic controllers (PLCs). C-more HMIs are made by Japanese manufacturer JTEKT Group and are distributed by AutomationDirect.  

What Is An HMI?

Human-machine interfaces (HMI) are industrial panels used in critical infrastructure to monitor industrial processes and enable facility management by engineers. These devices are integrated in almost any type of operational setting and usually have network accessibility inside an industrial network.

Our Target Device: AutomationDirect C-More HMI

The AutomationDirect C-more HMI platform is a line of human-machine interface (HMI) products designed for industrial control and automation applications. C-more HMIs provide operators with customizable interfaces to monitor, control, and interact with machinery and processes. C-more HMIs are compatible with AutomationDirect PLCs as well as a wide range of third-party controllers. They include Ethernet, serial, and USB connections. 

The C-more HMI is a Windows CE based embedded system making it a perfect fit for field testing our new debugger utility.

Using Internet search engines such as Censys and Shodan, our team managed to find approximately 330 instances of C-More HMI panels with exposed web services to the internet, using the following queries:

These devices can be accessed online and usually present a preview of the graphical content inside the HMI.

C-more Firmware Unpacking

Our team managed to retrieve the firmware image of the device by installing the C-More Programming Software from the vendor’s site. Inside this software we managed to find the device firmware, located in the following path: %Installation-Directory%\C_more_EA9_v6\Firmware\EA...eas9

Naive attempts to extract the filesystem of the device from its firmware image using binwalk were unsuccessful. This was due to the fact the firmware was packed in a proprietary format that binwalk failed to fully understand. 

To overcome this, we opened the firmware in an hex editor and started to analyze the firmware image format. The analysis turned out to be quite simple and we managed to extract the filesystem files from the firmware using a simple Python script to extract the filesystem stored in that firmware.

WSFTP.exe: C-More HMI’s FTP Server

As we looked into the filesystem extracted out of the firmware image of the C-More HMI platform, we noticed that it contains many artifacts. One of them was the intriguing executable WSFTP.exe. This executable as the name suggests is an FTP server which C-More HMI provides for the comfort of operators.

Out of curiosity, we decided to check how many HMI devices are there on the internet that expose this service. As we searched the internet we managed to find many devices with this service exposed. This meant for us that if we would be able to find vulnerabilities in this application, it would pose a critical threat to these systems actively used in industrial facilities. And so we dived into analyzing the executable and managed to find an intriguing security issue allowing for an attacker to remotely change code execution of the application.

Old Bugs Do Exist: Stack Buffer Overflows

Searching for potential security issues in the FTP application, we discovered a function in charge of copying wide-char strings controlled by an unauthenticated attacker into a stack-based memory buffer.

This function has insufficient bounds check routines to mitigate potential memory corruption issues induced by maliciously crafted attacker input.

The vulnerable routine in charge of the insecure memory copy is located inside the function named TG_widechars_copy, which is called from many different FTP commands handling methods. One such method is the TG_TYPE_cmd handling function. This method is reachable without needing to be authenticated on the server when invoking the TYPE command on the server.

With our knowledge about this insecure method, we noticed that it is being used to copy attacker controlled input without consideration for boundary limits of the destination buffer located on the stack. This meant we managed to find a classic stack based buffer overflow vulnerability, that we could try to develop a PoC exploit for.

To confirm this issue, we went on with testing the FTP server using a simple input that should yield a crash of the application.

Confirming that the issue exists in the application. We used dynamic analysis with our custom Windows-CE debugger to develop our PoC for exploitation. 

During our dynamic analysis of the application we found that using this vulnerability we are able to overwrite the registers r4,r5 and pc with attacker-controlled content taken from our provided TYPE command payload.

One thing that became apparent was the fact that we are copying wide-charstring-encoded content from the attacker input into the stack. This meant that our overwrite wasn’t complete, and that our registers were partially filled with null-bytes using our simple payload. 

Yet we did manage to overcome this minor obstacle. The main concept leading to this was the fact that wide-char encoding is not confined to only the ASCII range, and could be used to denote other types of symbols, for example emojis. So our assumption was that there must be some symbols that could be used to compose valid addresses in our exploit.

To do so, we went ahead and created a translation table that enumerated the range of potential character values that could be used to compose valid addresses that could be used in an exploit chain of this vulnerability.

Using the table we created we managed to find all sorts of useful pairs of bytes that can compose valid addresses in the application runtime, that we could also utilize. In our PoC we created a payload to overwrite the PC register with the value 0x12030 using the discovered vulnerability.  Doing so we proved we can divert the code flow and have control over the application runtime.

Having control over the PC register and also over R4 and R5, using this impactful primitive we are able to redirect code flow and have the ability to take control over this application. Using a return-oriented programming (ROP) chain we can alter the functionality of the program to gain a remote command execution ability over the device.

Developing a PoC for this vulnerability (CVE-2024-25137) and finalizing our analysis, our team coordinated disclosure of this security issue to AutomationDirect, which addressed the issue in C-MORE EA9 HMI to V6.78. The Cybersecurity & Infrastructure Security Agency published an advisory on this and two other CVEs, CVE-2024-25136 and CVE-2024-25138.

Wrapping Up

Our research into the Windows CE application attack surface resulted in the release of an open-source CE debugger and in this final installment, details on one of three vulnerabilities we disclosed in the C-more HMI, a Windows CE-based industrial panel. 

Our vulnerability research focused on the device's FTP server, WSFTP.exe, and uncovered a stack buffer overflow vulnerability allowing for remote code execution changes. The vulnerability stemmed from an insecure memory copy routine due to bypassed bounds checks.