Edit: At 4:43pm EST on September 2, 2022, Director of CISA Jen Easterly responded to this entry via tweet. We appreciate the update and look forward to more improvements in the future.

CVE-2021-38406 Shouldn’t Be on the CISA KEV List

On August 25, 2022, CISA added CVE-2021-38406 to their Known Exploited Vulnerabilities (KEV) Catalog. This was a significant addition to KEV because CVE-2021-38406 affects Delta Industrial Automation’s DOPSoft software. This addition to the KEV catalog is almost certainly a mistake, which we’ll discuss below in great detail. Technically, they might have included this CVE on purpose, but that would mean that CISA just low-key dropped some huge news about the next Stuxnet, which is unlikely to the point of unbelievability. But, you decide!

What’s DOPSoft and CVE-2021-38406?

DOPSoft is HMI programming software. An attacker that exploits DOPSoft can potentially find themselves on an engineering workstation within the ICS network and with specialized programming access to local HMI. That’s a very critical and dangerous place for any attacker to be.

CVE-2021-38406 reportedly affects DOPSoft’s parsing of project files. That’s notable because, despite vulnerabilities affecting all sorts of ICS project files, there have been very few publicly disclosed examples of project file infections used in the wild. The only examples we’re aware of are Stuxnet (Step7 project files) and AutoCAD/AutoLISP project file malware. With this KEV entry, CISA has disclosed a unique and ICS-specific attack being exploited in the wild.

Of course, that’s if you only look at the surface level information that CISA provides. The reality is that this CVE doesn’t affect DOPSoft project files, and there is evidence that suggests the CVE was added to the catalog in error. Let’s dive deeper.

The CVE Description is Bad

CISA includes the CVE’s description in their KEV entry. The description for CVE-2021-38406 follows:

Delta Electronic DOPSoft 2 (Version 2.00.07 and prior) lacks proper validation of user-supplied data when parsing specific project files. This could result in multiple out-of-bounds write instances. An attacker could leverage this vulnerability to execute code in the context of the current process.

ICS-CERT is the credited CNA and therefore the likely culprit for this misleading description. The vulnerability was actually discovered by the prolific vulnerability researcher, kimiya, and disclosed through the Zero Day Initiative (ZDI). The vulnerability description provided by ZDI for CVE-2021-38406 is much more specific.

This vulnerability allows remote attackers to execute arbitrary code on affected installations of Delta Industrial Automation DOPSoft. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of XLS files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process.

Here we can see that ZDI says the vulnerability affects xls files. Notably, xls files are not DOPSoft project files. xls is a Microsoft Excel format. Use of the Microsoft XLS file format is only associated with one feature of DOPSoft, and that’s multi-language support. The software can support multiple language texts on any given widget. For example, this DOPSoft screenshot shows a text block that can present as “hello world!” in English, Spanish, or German.

DOPSoft allows the programmer to export the multi-language data as an xls file, presumably, so language specialists can review/edit the content, and then the programmer can import updated versions of the text. This is all done through the Edit drop-down menu when a project is already loaded.

When the data is exported, it looks exactly how you’d expect:

According to ZDI, the vulnerability is exploitable when a new multi-language xls is imported. Which means, getting back to the topic at hand, DOPSoft project files are not affected as ICS-CERT indicated. The xls file is not a project file (e.g. it doesn’t control logic on an HMI, nor can it be used to launch DOPSoft). DOPSoft project files use the dps, dpb, or dop extension.

The only way the xls could be considered a project file is if the Import Multi-Language Text functionality embedded the xls in a DOPSoft project file. That would be a little strange, but not inconceivable (it’s ICS software after all). So we decided to pull apart the DOPSoft project file format in order to find an embedded xls.

File Format Exploration

It’s important to know if the xls is contained within DOPSoft project files, not just to nit-pick ICS-CERT, but to determine how many clicks are required to exploit a victim. The affected software is end-of-life and hasn’t been patched for CVE-2021-38406, so understanding the full attack is important when discussing remediation guidance. If the xls file is contained within a project file then double clicking on the project will trigger the xls parsing and exploit the victim. If the xls is only parsed during Import Multi-Language Text then an attacker has to get a victim to launch DOPSoft, load a project, and then import the malicious xls. Both scenarios are obviously doable, but the second is more involved (and therefore less likely).

The DOPSoft dps project file is split into two parts. By default, the first part is essentially empty (a bitmap filled with 0xfc). The second part contains gzip compressed data.

The compressed data explodes into a large binary blob of unknown format with a short ASCII preamble (“Delta-HMI Screen Editor DOP V1010”).

We spent some time in windbg figuring out what this unknown format is. Turns out, the file is xor encoded after the first 42 bytes. So we trim the project file:

tail -c +42 B8B6 > B8B6.xor

And run the following Python script to deobfuscate it:

f = open('B8B6.xor', "rb")
g = open('B8B6.deobfs', "w")

try:
    while True:
        byte = f.read(1)
        if byte == '' or len(byte) == 0:
            break
        xbyte = chr(ord(byte) ^ 0x64)
        g.write(xbyte)
finally:
    f.close()

g.close()

And the result is a very large ini file.

[Application]
Version=4.00.07.04
DefaultScreen=1
DefaultMemFmt=2
PanelSeries=DOP-B series
PanelName=DOP-B10E615 65536 Colors
PanelRotate=0
ModelName=-1106222768
WarpText=1
ShowAfterReadDataFlag=0
StopUpload=0
SpeedupPageChange=0
StartupDelayTime=0
Name=HMI
OptimizeType=2
CommInt=0
IntRetry=3
ControllerSection0=Delta
ControllerName0=Delta DVP PLC
HMIStationNr0=0
DefPLCStationNr0=1
CommName0=Link2
PortNr0=2
Interface0=0
databits0=7
stopbits0=1
baud0=9600
… truncated …

Most importantly, we find that the ini file contains no xls data. Instead, the multi-language data is represented as normal ini entries. Below you can see our three hello worlds!:

[State]
Value=0
FgColor=16579836
BgColor=11842740
FontColor=0
FontSize0=12
FontRatio0=100
FontName0=Arial
wTextLen0=26
h\00e\00l\00l\00o\00 \00w\00o\00r\00l\00d\00!\00\00\00
FontSize1=12
FontRatio1=100
FontName1=Arial Greek
wTextLen1=24
h\00o\00l\00a\00 \00m\00u\00\00\00\00\00o\00!\00\00\00
FontSize2=12
FontRatio2=100
FontName2=Calibri
wTextLen2=24
h\00a\00l\00l\00o\00 \00w\00e\00l\00t\00!\00\00\00
FontAlign=33
FontBold=0
FontItalic=0

Which means, we don’t think ICS-CERT’s description is correct. The project file does not contain an xls file, so it will never trigger CVE-2021-38406. An attacker is required to trick the victim into loading the malicious xls via the Import Multi-Language Text feature. Users should be able to continue safely using DOPSoft affected by CVE-2021-38406, as long as they avoid using the multi-language import feature.

Ok. Fine. But Was It Exploited in the Wild?!

Exploitation might be complicated in a real world scenario. But it’s still doable. The conditions are actually ideal.

The question, “Does CVE-2021-38406 belong in the KEV catalog?” remains relevant even if the CVE description is bad.

CISA calls the KEV catalog the authoritative source of vulnerabilities that have been exploited in the wild. However, CISA never provides any justification for the items they add, or don’t add, to the catalog. Entries are simply added and that’s that. But anyone that has been involved with the entry adding process knows that CISA largely relies on open source reporting from the security industry in order to populate the catalog. They’ve chosen to never credit or even cite their sources, opting instead to represent the work as their own, for reasons we won’t speculate on here.

Regardless, the lack of citation/proof makes challenging any entry on the list almost impossible. Each KEV entry requires action by federal civilian executive branch agencies due to the Binding Operation Directive 22-01. Each erroneous entry wastes time, resources, and taxpayer money, not just in the federal space but the myriad security companies that have been, more or less, forced to support the KEV catalog in their products. Not to mention the potential reputational harm an incorrect entry might cause. The fact that CISA provides no evidence and provides no obvious avenues for dissent is problematic.

Which brings us back to the subject at hand. CVE-2021-38406 was added to the KEV catalog along with 9 other vulnerabilities on August 25, 2022. Three of the newly added vulnerabilities, CVE-2022-22963 (Spring Cloud), CVE-2022-24112 (Apache APISIX), and CVE-2021-39226 (Grafana), were included in an August 19, 2022 article by Unit 42 called, Network Security Trends: Recent Exploits Observed in the Wild Include Remote Code Execution, Cross-Site Scripting and More. The article details exploits seen in the wild. Additionally, Unit 42 accidentally tagged the article with the DOPSoft CVE, CVE-2021-38406.

We know this inclusion was accidental because Unit 42 does not discuss the vulnerability, even in passing, at any point in the article. Also, their data collection method, pictured below, would not be able to detect exploitation of CVE-2021-38406 because it’s a local exploit requiring (fairly significant) user interaction.

The IPS might see a malformed xls file over network traffic, but that isn’t quite the same as seeing an actual exploitation attempt.

And, finally, we know CVE-2021-38406 was accidentally tagged in that article because we were told so:

Conclusion

There is no other open source information indicating that CVE-2021-38406 has been exploited in the wild. Could it be that CISA knows this vulnerability, which requires significant user interaction to exploit niche ICS software, was exploited in the wild? Or is it more likely that CISA was lifting CVEs from Unit 42’s blog and erroneously included CVE-2021-38406 because it was mistakenly included in the article?

Finally, this research demonstrates that we clearly need some kind of mechanism to challenge weird-looking updates to the KEV list to avoid burning a lot of time, effort, money, and heartache on chasing vulnerabilities that many, many people must chase because they’re subject to BOD-22-1.

edit: Title changed as per request at 4:22pm EST on Sept. 2, 2022