Strange driversigning with untrusted test-certificate and certificate that signed the RustDeskIddDriver.dll is also not the same certificate

[vitusb]

Bug Description

Hello ...

I've executed the Windows-Installer in a sandbox and examined the extracted-files (also the temp-files) and did a tiny check of the used certificates and the signed files and found some strange issues with the certficate-structure of this project:

Strange installation of ROOT-CERTIFICATE in ROOT-store

The certificate (fingerprint: d1dbb672d5a500b9809689caea1ce49e799767f0), that will be used to install and sign the driver under Windows ("rustdeskidddriver.cat") seems to be strange. It is a self-signed test-certificate by an anonymous id: "WDKTestCert admin,133225435702113567" that will not use a trusted ROOT-CA and only uses SHA-1 with RSA 2048 (weak) with a timed validity of !! 10 Years !!, much too long for this weak algo !

 Fingerprint: d1dbb672d5a500b9809689caea1ce49e799767f0
 CN = WDKTestCert admin,133225435702113567

The fact, that this certificate will be installed in the SYSTEM ROOT-CERTSORE is probably associated with a high risk ...

Also the certificate, that signed the installed driver-dll "RustDeskIddDriver.dll" is not the same as the certifcate, that created / signed the catalog-file above:

 Fingerprint: b27892e774a8cbe382ba7ddcf4649a723b6532d8
 CN = Zhou Huabing
 O = Zhou Huabing
 S = Central Singapore
 C = SG

This certificate was issued by "Sectigo Public Code Signing Root R46" ...

How to Reproduce

Check used certfile "RustDeskIddDriver.cer" of the installer and certificate of signed dll "RustDeskIddDriver.dll".

Expected Behavior

Usage of valid software-signatures, issued by a trusted ROOT-CA with "secure" algorithms for driver-installation and code-signing.

Operating system(s) on local side and remote side

Windows 10

RustDesk Version(s) on local side and remote side

1.2.3

Screenshots

"RustDeskIddDriver.cer"

RustDesk_install.bat

"RustDeskIddDriver.dll"

"rustdeskidddriver.cat"

Additional Context

No response

[ForDefault]

I actually ended up here from searching online, after, seeing this weird Cert but mine was in Chinese.
Same CN=WDKTestCert admin,133225435702113567
Thats all I can contribute. Except, maybe a bump to this lol

[rustdesk]

The certificate required to sign the video driver is a Windows WDK certificate and not a Chinese one

[nOrphf]

Hi

Glad to read that you have retrieved the EV certificate.
But I also came to this tread after discovering a "Chinese certificate"

Is this still RustDesk certificate?

Regards Lars

[xlionjuan]

https://github.com/rustdesk/rustdesk/wiki/Remove-RustDesk-test-certificate

[Staja]

I'm seeing this discussion spread over the internet like wildfire but, when I checked, the certificate only had an EKU for Code signing and KU for Key Encipherment and Data Encipherment; this is what I would expect to see from a certificate used for the stated purposes. TLS stacks (Eg: SChannel) should be adhering to those KU/EKU's; "Enabled for All Purposes" implies "-that are listed in KU/EKU's".

Regardless though, I think a certificate being pushed to end users should clearly identify itself and not use SHA-1, that should be rectified.

[Zakkaruu]

To add to this, you can verify and limit "purposes" by going into the certificate properties. The driver certificate only has Code Signing as an option.

Compare with an all purposes, all applications root certificate:

For MITM, Key Usage would need to have Certificate Signing. The RustDesk cert does not.

So long as the properties are respected as Staja said. (I tested with my own MITM/decryption cert, and they are respected in browsers--didn't test anything else)

I am also inclined to believe that the certificate just needs some fine tuning for transparency and increased security.

[rustdesk]

Ok, we will remove this idd driver since it brings so big trouble. Some functions (virtual display, privacy mode etc) will be lost.

[Hydro8]

Do you know the list of features that will be lost ?

[xlionjuan]

@Hydro8 virtual display and privacy mode

[danielmarschall]

When RustDesk is installed, there is a checkbox asking if the certificate should be installed or not. Wouldn't it be a solution to enable the features if the user chooses to install the cert, and disable the features if the user denies it?

[danielmarschall]

If the Virtual Display feature is removed in the next version, would that mean that I can no longer establish an unattended connection to a terminal server that has no attached monitor and/or active user session?

[florianbeisel]

Frankly, as for 1,2, we do not know either, we are not expert in this field, maybe because it is test cert.

• why this certificat is in root store.

Because its explicitly installed there by install_cert_runas_admin.bat in the RustDeskIddDriver.

.\CertMgr.exe /add RustDeskIddDriver.cer /s /r localMachine root

[rustdesk]

When RustDesk is installed, there is a checkbox asking if the certificate should be installed or not. Wouldn't it be a solution to enable the features if the user chooses to install the cert, and disable the features if the user denies it?

This is the current behavior, but it can not stop thread like this.

[danielmarschall]

@rustdesk Thank you for your quick reply. Can you please tell me if the Virtual Display feature is removed in the next version, would that mean that I can no longer establish an unattended connection to a terminal server that has no attached monitor and/or active user session? Or is the Virtual Display Driver just to make things a bit prettier (resolution, etc.)?

[joru1407]

This driver which is only signed with the Test-Certificate also leads to issues with ESET for example. ESET detects the RustDeskIddDriver.dll under %LOCALAPPDATA%\rustdesk\RustDeskIddDriver as Suspicious Object, moves it to the Quarantine and warns the user about it.

[rustdesk]

Fixed in latest release by removing our virtual display driver and cert, https://github.com/rustdesk/rustdesk/releases/latest. It will be restored once we get an EV, 1 month or more. Thanks for everyone who are giving help on EV

https://techcommunity.microsoft.com/t5/windows-hardware-certification/driver-signing-changes-in-windows-10/ba-p/364859
https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/code-signing-reqs#ev-certificate-signed-drivers
https://www.ssl.com/how-to/register-with-windows-hardware-developer-program/
https://www.ssl.com/how-to/signing-kernel-mode-drivers-for-windows-using-evcs-or-ovcs-certificates/
https://learn.microsoft.com/en-us/answers/questions/313092/user-mode-driver-signing-process
https://partner.microsoft.com/en-us/dashboard/Registration/Tenant/Hardware?step=GetStarted?step=GetStarted

Though we can not provide virtual display driver (for those having no display) for the time being, you can still install from 3rd party.

#222 (comment), you can find more virtual display in this discussion.

please do not use #6682 (comment), since it uses test cert as us also.

Or buy a HDMI plug.

#222 (comment)

[grenelt]

Virtual Display Drivers Knowledge Base | Getting Rid From Display Dummy Plugs

pavlobu/deskreen#86

[grenelt]

(VGA Hack) How To Make a VGA Dummy Plug

https://www.geeks3d.com/20091230/vga-hack-how-to-make-a-vga-dummy-plug/

[fragtion]

I'm using this on an internal LAN (no risks of exploiting) where I don't care about this vulnerability but the feature is essential for me / "I accept the risks". Very disappointed to install latest nightly and the feature is gone, and sadly I replaced old installer binary. Can someone please share nightly build from 18 February 2024 or thereabout? I have a build from Dec 2023 but I would prefer more recent build. Thanks

[xlionjuan]

https://github.com/itsmikethetech/Virtual-Display-Driver

[rustdesk]

This one is not verified and signed either, take your risk to use it.

[rustdesk]

Update: we have got EV, now we are waiting for Microsoft hardware developer account ready, @microsoft needs to verify the company profile and domain again, the process is very slow.

[vitusb]

Thank you all for your support !
Good Job 🙏🏼 👍🏼 ...

[rustdesk]

Update: https://twitter.com/rustdesk/status/1770983662571733227

[rustdesk]

Update: I have sent mail again and again, no reply so far about the progress.

[vgcouso]

Thank you for spending so much time on this.
Luck

[TGeRi]

Hi! This bug is still present in a way!
When I install Rustdesk (official build) v1.2.3-1 on a fresh PC (test PC is Win11 23H2 for me) the cert IS NOT installed, but a new CERTIFICATE STORE (with the chinese text as the name of this "certificate folder") IS created in Windows. It is empty, but Rustdesk install creates it nontheless.

It could be concerning for users as Google translate is this for that chinese text:

:)

[fufesou]

This is so strange.

I checked the code of 1.2.3-1 again and it will not try install the cert.

Unless someone has administrator rights and manually executes the command, this is equivalent to using certmgr.exe.

rustdesk/src/core_main.rs

Line 205 in a71ec3e

hbb_common::allow_err!(crate::platform::windows::install_cert(&args[1]));

Did you only install 1.2.3-1 and no other versions of RustDesk on your fresh PC?
1.2.3-1 does not have a certificate file, and install_cert will return at the entrance.

rustdesk/src/platform/windows.rs

Line 1923 in a71ec3e

let mut cert_bytes = std::fs::read(path)?;

Did you perform any other operations on your new computer?
I think this is more likely due to other reasons.

[danielmarschall]

Actually, I have this too. But I don't know when it was created. Could have been before 2.3.1-1. I have two roots, one with a certificate in it, and one without. I have now deleted the certificate, uninstalled rustdesk, and installed nightly, and it is NOT created again.

Unfortunately, I cannot delete the branches! They are there, even if no certificate is inside. How can I delete them?

EDIT: Additional note: Actually, I had the WDKTest certificate in this Chinese Characters Certificate Store, as well as in the "Trusted Publishers Certificate Store".

[fufesou]

Sorry for causing trouble to you guys.

You can delete strange branches by deleting the corresponding entries in regedit.

1. Open "certmgr.msc"
2. Open "regedit", delete the strange items.
3. Close and open "certmgr.msc".

If there're stille some strange items, you may not delete all items in "regedit".
Refresh "regedit" and delete again.

b.mp4

NOTE

There should be more than one place, you may need to find "Ctrl + F" to search the registry.

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates
Computer\HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates
Computer\HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\UserDS

[fufesou]

@TGeRi Confirmed. My PC creates this strange "certificate folder" too, after installing 1.2.3-1.

I'll try find out what causes this strange behavior.

[fufesou]

This code causes the strange cert directory.

rustdesk/src/platform/windows.rs

Line 1982 in a71ec3e

let store_handle = CertOpenSystemStoreW(0 as _, "ROOT\0".as_ptr() as _);

The corresponding C++ code is

#pragma comment(lib, "crypt32.lib")

#include <Windows.h>
#include <iostream>

int main(int argc, char* argv)
{
	HCERTSTORE handle = CertOpenSystemStoreW(NULL, (LPCWSTR)"ROOT");
	return 0;
}

1.2.3-1 will not install the cert. But it will try to remove the old test certs.

It tries to read the certs in ROOT , then find the issuer of "CN=\"WDKTestCert admin,133225435702113567\"\0". Remove all it's related certs.
It will found no certs, and do nothing. But the directory is created and left there.

I'll try the code #6444 (reply in thread) to remove the strange directories.

[hackgrid]

You can check in a freshly installed VM whether RustDesk really is responsible for that Chinese certificate!

[danielmarschall]

For my system(s) the test certs are in up to 4 locations:

• Trusted Publishers (only 1 system)
• Trusted Root Certification Authorities
• Short chinese dir
• Long chinese dir (only 1 system)

this is why ab07eb6 deletes the test certs from all stores of all users. This is very important. I don't know how it happened that the test certs spread in 4 different stores, but they did somehow.

[fufesou]

It would be very important that it gets deleted from all stores, because I still don't understand why on some of my machines the certificate was in "Trusted Publishers" (which is as bad as "Trusted Root Certification Authorities")
And the Rust code, will it also delete the wrong certificates from other users? This would also be important, because only user "X" will install/uninstall/update RustDesk, but there might be users "Y" and "Z" on that system (maybe other users with admin rights on a Terminal Server, who have previously installed and old RustDesk version).

I'll find a better way to delete all the certificates. Because the fingerprint is SHA1 hash of the cert.
Simply delete "D1DBB672D5A500B9809689CAEA1CE49E799767F0" in the correct stores is not safe.

1. Traverse the SystemStore and find all stores and fingerprints where the issuer is CN="WDKTestCert admin,133225435702113567". Then delete.
2. Delete the certificate in the wrong store.
3. Delete the empty wrong store.

[danielmarschall]

I am not familiar with the cryptapi, but I understand that CertOpenSystemStoreW() only opens HKLM but not any user store (and not other users stores)?

I wonder, would you feel more comfortable if the blob contents of the D1DBB672D5A500B9809689CAEA1CE49E799767F0 key are binary compared? The chance that a different certificate has the same SHA1 finger print is 2^160, so I think it is safe to assume the key with hash D1DBB672D5A500B9809689CAEA1CE49E799767F0 is the key we are looking for. Just parsing the cert and looking at the "CN" is much more ambiguous and can be freely chosen by humans.

If you want to make 100% sure, then you can analyze the Blob field. (Edit: see post below)

[danielmarschall]

@fufesou @rustdesk

What do you think about that?
https://gist.github.com/danielmarschall/0fadded4dbba7d790cc0f40723ec5990

(Edit: Small change fixed in re management information. It now avoids to assume that the cert starts at offset 0x4C)

If you don't trust SHA1, then binary comparison is the way to go, then the tiny chance of collission changes from 2^160 to exactly 0.

I didn't look up the code how to read a blob from registry. I first wait if you like it or not. If you accept, than I will do the rest and implement it.

[rustdesk]

Thanks, #7642

[rustdesk]

Update, still no progress, you can email or call this @microsoft support if you want to help.

[rustdesk]

Update: https://twitter.com/rustdesk/status/1781263566504653052