While threat hunting, RSA FirstWatch came across a curious exposure in Windows PCs, involving driver packages provided by a certain manufacture of audio streaming controllers. These USB audio streaming controllers are found in third-party hardware products used principally by audiophiles and PC game enthusiasts. Distributed between 2013 and 2017, packages from this chip maker were observed to silently install a self-signed root certificate into the PC’s Trusted Root Certification Authorities store.
The purpose of this post is to briefly describe the exposure of what we have nicknamed “Inaudible Subversion,” discuss root certificate store subversion exposure in the context of NetWitness visibility, and provide remediation steps should you be an audiophile or gamer with an exposed PC. In the big picture of things, we think that Inaudible Subversion may be a vulnerability of low--if any--consequence, but illustrates the influence of market forces behind hardware vendor sustainment of a still-popular operating system that is no longer supported by Microsoft.
Through reach-out via trusted partners, we established contact with the chip maker who acknowledged the problem, and who then began providing updated driver packages to many of its affected third-party hardware vendors, at least a dozen of which we had identified. The new driver packages no longer have the root certificate installing routine, at the cost of no longer supporting Windows XP. Still the updated driver packages do not remove the root certificate(s) in question, which is why we are providing remediation steps necessary at the end of this post. Mitre assigned this exposure the identifier CVE-2017-9758, but was initially tracked by HITCON ZeroDay project as ZD-2017-00386.
Problem details
FirstWatch found that specific driver installer packages provided by Savitech to their hardware vendor customers for distribution to end users, silently installed a SaviAudio root certificate into the PC’s Trusted Root Certification Authorities store (simply: trusted root store). When we say “silently” we mean that the driver installer package installs a self-signed SaviAudio root certificate to the PC’s trusted root store and Trusted Publishers stores, prior to the standard dialog box presented to the user confirming a driver (and trusted publisher certificate if so checked) to be installed (Figure 1).
Figure 1 SaviAudio self-signed root certificate installed prior to Windows Security dialog box
Checking the “Always trust software from [publisher name]” check box would normally be required, prior to a program installing a certificate in to a PC’s trusted publishers store. In our testing, checking the “Always trust software from Savitech Corp.” box in the driver installer routine would install a valid Savitech Corp. Verisign-issued certificate into the trusted publishers store, with the previously “silently” installed self-signed SaviAudio certificate (Figure 2).
Figure 2 Valid Verisign issued certificate added to same store as the self-signed certificate
The executable responsible for the SaviAudio self-signed certificate install, SwCoInst.exe, is named the same in each MSI file package FirstWatch was able to find. It is sometimes branded with the Savitech hardware vendor’s name in the executable file properties. The SwCoInst.exe executable writes the SaviAudio certificate file NewCert.cer, as well as a valid 2009 version of Microsoft’s Certificate Manager tool, CertMgr.exe, embedded inside (Figure 3). Prior to the completion of the driver package installer routine, CertMgr.exe and NewCert.cer are deleted from the program’s folder.
Figure 3 Three components responsible for root store subversion function in affected Savitech driver packages
Implications
An arbitrary certificate added to a Windows trusted root store, breaks the hierarchical trust model of Windows, giving significant power to the owner of the private key corresponding to that certificate, the same as any Certificate Authority (CA) behind certificates normally found on Windows systems. Usually, only a certificate issued by Microsoft would have “All” in the root certificates Intended Purposes field. Note: many large enterprises will typically install an “All” purposes root certificate on their Windows PCs to perform SSL decryption at the perimeter for outbound traffic, for network defense purposes, but that is typically the only exception.
An attacker who is able to obtain the corresponding private keys used to create the two known Savitech “SaviAudio” root certificates can generate any number of certificates signed by the otherwise untrusted Savitech private key. Any system installing the Savitech drivers from any one of many vendors will trust any certificate issued by the SaviAudio CA, for “All” purposes. An attacker may spoof web sites and other online services and applications, sign software and email, as well as decrypt network traffic. Common attack scenarios include impersonating a web site, performing a Man-in-the-Middle (MITM) attack to decrypt HTTPS traffic, and installing malicious software.
In best-case scenarios, Inaudible Subversion is a minor exposure
We assess that the Savitech driver developers were conscious of the affect of driver warning alerts for XP users, and subsequently came up with a clever way to seamlessly support Windows XP through Windows 10, using a single driver package, without increasing support calls to their hardware vendors. In spite of being officially un-supported by Microsoft for years, Windows XP is still a rather popular operating system, especially in Asia[ii], and that might generate some substantive demand from end users of Savitech products. On the other hand, users of Windows XP with even the latest available patches[iii] are already facing such security challenges that a self-signed certificate for which the private key is hopefully carefully guarded by Savitech, provides negligible additional exposure. There are notable incidents[iv]
The crux of the issue is that the workaround specifically designed to accommodate the demand for hardware support for an operating system no longer supported by Microsoft, also effects any other Windows operating system on which the driver installer package is run. This is the case with the affected all-in-one driver packages from Savitech, which do not discriminate by Windows version in their root store subversion routine. Which means the exposure to a much more secure operating system than Windows XP, from a subverted trusted root certificate store, probably exceeds a negligible level.
In our testing with actual audio hardware purchased from a Savitech vendor, removing the SaviAudio root certificates from our test Windows XP laptop after the Savitech hardware drivers had been successfully installed, caused no issues. Our test PC with Savitech hi-fi system[vi] worked perfectly at the extremely high 352.8 khz sampling rate of our test audio file, the same as before the root certificate was removed (Figure 4). And we confirmed that the root certificate was not needed for installing the Savitech drivers for any other Windows version besides Windows XP.
Figure 4 Demonstration that Savitech hardware drivers on Windows XP worked perfectly with SaviAudio root certificate removed
If given the chance, we would pass on to Savitech that they do not necessarily need to stop supporting Windows XP. However, we suggest that they provide a completely separate driver installer package for Windows XP, than for other supported Windows OSs. Additionally, Savitech should specifically modify the Windows XP driver package installers so that the SaviAudio certificate is removed from the PC’s trusted root store after the drivers have been installed. To caveat our suggestions, we have not tested multiple hardware platforms or the root certificate removal’s compatibility with the SaviAudio mobile applications[ii] that can control Savitech PC audio hardware over the network.
So why should we care about an inadvertent vulnerability from a friendly audio chipmaker?
If we have written this much about a nearly inconsequential vulnerability on an RSA product-focused site, you might figure that there is a product tie-in. And you would be right. In fact, it was Inaudible Subversion research that got multiple analysts and engineers at the RSA NetWitness team pondering. Specifically, we pondered on the consequences of not being able to observe a self-signed root certificate being maliciously installed in a PC’s trusted root store. One only needs to point to some notable crimeware campaigns to realize that the consequences could be significant.
Consider the Retefe Banking Trojan campaign as investigated by Palo Alto Unit 42 in 2015.
Retefe uses the Windows PowerShell to execute a series of commands that installs a new root certificate on the system and a proxy configuration to re-route the traffic to the targeted banking websites.
The Retefe Trojan writes the root certificate to the disk and then uses the following command to install it on the system.
certutil -addstore -f -user ROOT ProgramData\cert512121.der
Avast also investigated a Retefe campaign in 2016 with the same characteristic subversion of the target PC’s trusted root store. FirstWatch also posted on a more recent Retefe campaign last month on RSA Link[ii], the malware of which also installed a fake but realistic-appearing certificate in the infected system’s trusted root store. Finally, consider the RTM Banking Trojan as dissected by ESET in February of this year[iii]. RTM has a modular command switch specifically used to install a certificate into the infected PC’s trusted root store.
With these malicious illustrations in mind, we know that it is important for an enterprise security team to be able to detect if a system’s root certificate store has been subverted. Currently, detecting a certificate being added to the trusted root store of a PC protected by NetWitness Endpoint, requires some extra configuration in NetWitness Logs, or Sysinternal Sysmon installed on a PC such that tracking events similar in resolution (Figure 5) to NetWitness Endpoint tracking logs, be sent to a NetWitness log decoder.
Figure 5 Sysmon logs showing root store subversion by Savitech self-signed certificate
Client side Windows logging can be a mixed bag of Windows policies pushed by GPO or other endpoint tools that harvest these specific events. If your Windows logging policy includes event ID Security/4688 (detailed tracking and audit process creation) you will be able to see these events but beware, event ID 4688 is very high volume. If covering the endpoint with Sysmon is more your style, with the right template you will be able to capture the events via WMI into NetWitness logs under event ID sysmon/1 which look like Figure 5 above in event viewer and Figure 6 in NetWitness logs.
Figure 6 Sysmon event via NetWitness Logs
If you have NetWitness Endpoint and are pulling tracking data out via ODBC you will see events like Figure 7.
Figure 7 NetWitness Endpoint tracking data
And if you have the latest NetWitness Endpoint 4.4 you can enable the meta integration service and get tracking data and more, which would get you information like Figures 8 and 9.
Figure 8 NetWitness Endpoint 4.4 meta integration
Figure 9 NetWitness Event Analysis
Having the data available in one single interface is part of the solution, being able to alert on those events proactively is a much more scalable solution. Using the Application rules below you can create proactive alerts for these events (the first three rules group Sysmon events, NW Endpoint ODBC and NWEndpoint events together).
name="endpoint-event-include" rule="device.type='nwe_tracking' && category='createprocess'" alert=analysis.session type=application
name="endpoint-event-include" rule="device.class='windows hosts' && reference.id ='1'" alert=analysis.session type=application name="endpoint-
event-include" rule="device.type='nwe_tracking' && category='createprocess'" alert=analysis.session type=application name="endpoint-event-include"
rule="device.type='nwendpoint' && action='createprocess'" alert=analysis.session type=application name=p3_certmgr-add-local-root-cert
rule="analysis.session='endpoint-event-include' && process ends '\\certmgr.exe' && (param contains '-add' || param contains '/add') && param contains
'localmachine'" alert=analysis.session type=application name=p3_certmgr-add-local-root-cert rule="analysis.session='endpoint-event-include' &&
filename.dst='certmgr.exe' && query contains '-add' && query contains 'localmachine'" alert=analysis.session type=application name=p3_certutil-add-
local-root-cert rule="analysis.session='endpoint-event-include' && filename.dst='certutil.exe' && query contains '-add' && query contains 'root'"
alert=analysis.session type=application
In this case the alert sends information to the Session Analysis metakey (analysis.session) which you could turn into an alert or include in a summary report to review on a daily basis.
Figure 10 Event Alert
The detection can be mapped to Mitre Att&ck T1130 under Defense Evasion for install Root Certificate.
Not wanting to leave good enough alone, expect a part two to this blog post in the not so distant future. We don’t think root certificate subversion is going away any time soon, and the subject needs more attention from us before we can rest at ease.
Summary
In the big picture of things, Inaudible Subversion might be considered an inconsequential vulnerability, as it effects principally audiophiles and video game enthusiasts of third party hardware vendors. We also presume that the not insignificant die-hard base of Windows XP users has more pressing security concerns with their PC, than a self-signed root certificate from their friendly audio manufacturer. While the root certificate routine in these driver packages is not limited to running on Windows XP, additional testing showed that removing the self-signed certificate from the Trusted Root Certification Authorities store did not cause any issues, even on Windows XP. The certificate was only “needed” during the time that the Windows XP drivers were installed, and on our test platform, the audio hardware worked fine when the self-signed certificate was subsequently removed from the PC.
To Microsoft’s chagrin, we think that the manufacturer would be able to safely support their base of Windows XP users, by including the drivers for Windows XP in an installer package separate from the installer package for Windows 7/8.x/10. Also, in the separate Windows XP package, they could provide a simple routine to remove the self-signed certificate, following the driver installation.
Finally, we got to the point of our product-tied post, which is making sure that you can see when someone other than a friendly audio maker subverts a PCs root certificate store. While we can currently guide you on making your NetWitness products “root subversion ready,” we pledge that it needs to be more out of the box. So we are working on it.
This post was made possible by special contributions from Eric Partington.
FirstWatch would like to thank Ziv Chang of Trend Micro, Allen Own of HITCON ZeroDay, Asus Product Security Team, EMC Product Security Response Center, and CERT/CC for their assistance.
https://attack.mitre.org/wiki/Technique/T1130
https://blog.avast.com/retefe-banking-trojan-targets-uk-banking-customers
[ii] https://community.rsa.com/community/products/netwitness/blog/2017/10/12/malspam-targets-swiss-with-retefe-banking-trojan
[iii] https://www.welivesecurity.com/wp-content/uploads/2017/02/Read-The-Manual.pdf
https://researchcenter.paloaltonetworks.com/2015/08/retefe-banking-trojan-targets-sweden-switzerland-and-japan/
https://play.google.com/store/apps/details?id=com.savitech.bravow
[ii] https://itunes.apple.com/us/app/bravo-remote/id623158468
https://upload.wikimedia.org/wikipedia/en/6/61/XPDriverWarning.png
[ii] http://gs.statcounter.com/windows-version-market-share/desktop/asia
[iii] http://ryanvm.net/forum/viewtopic.php?p=133918#133918
[iv] https://www.kb.cert.org/vuls/id/870761
