
Write-up on the CVE-2019-9745 vulnerability.
Creativity is at the core of penetration testing, which keeps our work interesting. One pitfall however is the tendency to 'over-engineer' attack scenarios and focus solely on bugs (error conditions). Flaws (unintended behaviour) may however be present with equally devastating results. This article provides a case-study to demonstrate the importance of pentesting for such flaws. Simultaneously it makes a case for employing an SDLC (Secure Development Lifecycle) process.
The article is part of the RD (responsible disclosure) of vulnerability CVE-2019-9745 and has been written in close cooperation with vendor CloudCTI. It gives a high-level overview of the vulnerability before deep-diving into the technical details. After demonstrating exploitation of the vulnerability a conclusion is provided with lessons learned.
The CloudCTI Recognition Configuration Tool we examined during one of our penetration tests is used to retrieve information from CRM (Customer Relationship Management) software. This provides callcenter personnel with relevant information during customer calls. Several issues where identified that can be chained together to fully compromise the local system. The vendor would like to stress this does not affect systems of other customers nor their own.
As with many security vulnerabilities an important issue lies in validating data originating from outside your sphere of influence. Equally important is the realization that systems and software operate in hostile environments. Time and experience has taught us eavesdropping is a threat on the internet. The same however is true for other communication channels, even within a system itself. This was instrumental in discovering the vulnerability.
A root-cause analysis of the encountered issues shows the importance of practices such as TM (threat modelling). TM helps identifying risks during the early stages of design and development. This can lead to mitigation of unacceptable risks or redesign/reimplementation. Although the reader is encouraged to perform their own analysis, descriptions of the vendor's countermeasures are provided for reference.
The vendor software consists of four applications that work together. The first application is the Graphical user interface (GUI). This allows the user to initiate information retrieval from several CRM software packages:
The GUI delegates information retrieval to a service (the second application) by sending a message. The first security issues manifest themself here: not only can anybody on the system observe the messages between the GUI and the service to determine their format and content (affecting confidentiality), they can also send their own messages (affecting authorization). Furthermore, the source of messages to the service is not verified (affecting non-repudiation). In STRIDE threat modelling terminology this means the system is prone to information disclosure and tampering. Indeed, information gleaned from these messages was instrumental in discovering the vulnerability.
The third application is one of many specialized importers. The service offloads information retrieval for a specific CRM package to a specific importer. The message send by the GUI contains specific instructions for this importer. Looking at the Exquise CRM importer it turns out information retrieval is further delegated to an external (fourth) application. Examining the internal logic of the importer it was discovered the external application could be specified in the message between the GUI and service. The issue that manifests itself here is that the external application is executed without verifying it's identity (affecting non-repudiation).
Chaining these issues together we could eavesdrop on messages to determine their format and send a message in which we specify our own malicious external application. That external application is executed with the same privileges as the importer/service. As these privileges are the highest possible within the system total control is achieved and the system is compromised.
These issues are mitigated by the vendor by encrypting the messages (mitigating the confidentiality issue) through the use of unique shared secrets (mitigating the authorization issue) that can only be accessed by the authenticated system users that own them (mitigating the first non-repudiation issue). Finally, the external application is cryptograpically signed (mitigating the second non-repudiation issue). Combining these measures successfully mitigates the vulnerability.
When the CloudCTI Recognition Configuration Tool GUI application (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\CloudCTI Recognition Configuration Tool.exe) is installed it is examined with Process Explorer. This uncovers that a companion service (Recognition Update Client Service) is installed and executed with NT AUTHORITY\SYSTEM rights:
Upon investigating the service executable (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\RecognitionUpdateClientServiceService.exe) it becomes apparent it is developed using the .NET programming language. This can be decompiled using dnSpy to gain the insight in it's internal logic, which will be detailed below.
RUCS2017Service (the internal .NET namespace in the service executable) turns out to be a thin wrapper around the RUCS2017 namespace (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\RUCS2017.dll). This defines a Named Pipe server named RUCS20151029 at RUCS2017.dll:RUCS2017.TRUCS2017:902:
That named pipe server is started at RUCS2017.dll:RUCS2017.TRUCS2017:833: