How to Check for Dangerous Authority root Certificates and what to do with them?

Question

I started my exploration after I saw that one program adds some lines to certmgr.msc (PC wasn't connected to the Internet, so, I don't think, that this cert can be downloaded by MS). Installer of the program contains this .p12 file, Virustotal says it is clear, but I did some more research. I checked my Certificate store using

sigcheck -tuv

A rather strange certificate was found:

User\Root:
   Google
    Cert Status:    Valid
    Valid Usage:    All
    Cert Issuer:    Google
    Serial Number:  00 CD 0B 32 EF B4 F4 CD 13
    Thumbprint: 33FCD70343BBE07972D73CDEFDEB3C9F4DCEFE28
    Algorithm:  sha1RSA
    Valid from: 0:05 22.07.2015
    Valid to:   0:05 21.07.2020

There is too low info about

Thumbprint: 33FCD70343BBE07972D73CDEFDEB3C9F4DCEFE28

on the Internet, but I found some interesting links (sorry, I am a newbie on this forum and can't post more than 2 links, I posted others as quotes to this topic).

Now, I am very scared and confused. I do not understand what kind of danger it creates. And I don't know what to do with this. I am absolutely sure I didn't install this certificate manually. The same certificate was found on another computer on my local network.

I need to add that I also checked my computer with several "on demand" AV scanners (CureIt, KVRT), they did not see any problem in this certificate.

The result of execution certutil -verify -urlfetch is

Поставщик:
    CN=Google
    O=Authenticode
    L=Silicon Valley
    C=US
  Хэш имени (sha1): 407d40e1a0d9d25bb8196644ddfda715a850b236
  Хэш имени (md5): bf22e164aaf0a93af128e23e7a26f74c
Субъект:
    CN=Google
    O=Authenticode
    L=Silicon Valley
    C=US
  Хэш имени (sha1): 407d40e1a0d9d25bb8196644ddfda715a850b236
  Хэш имени (md5): bf22e164aaf0a93af128e23e7a26f74c
Серийный номер сертификата: cd0b32efb4f4cd13

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

CertContext[0][0]: dwInfoStatus=10c dwErrorStatus=0
  Issuer: CN=Google, O=Authenticode, L=Silicon Valley, C=US
  NotBefore: 22.07.2015 0:05
  NotAfter: 21.07.2020 0:05
  Subject: CN=Google, O=Authenticode, L=Silicon Valley, C=US
  Serial: cd0b32efb4f4cd13
  28fece4d9f3cebfdde3cd77279e0bb4303d7fc33
  Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
  Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  Сертификат AIA  ----------------
  Отсутствуют URL "Нет" Время: 0
  ----------------  Сертификат CDP  ----------------
  Отсутствуют URL "Нет" Время: 0
  ----------------  OCSP сертификата  ----------------
  Отсутствуют URL "Нет" Время: 0
  --------------------------------

Exclude leaf cert:
  0907d8af90186095efbf55320d4b6b5eeea339da
Full chain:
  28fece4d9f3cebfdde3cd77279e0bb4303d7fc33
------------------------------------
Проверенные политики выдачи: Все
Проверенные политики применения: Все
Не удалось проверить состояние отзыва сертификата
CertUtil: -verify — команда успешно выполнена.

(System language: rus)

A little later... I found another "strange" certificate, "Dekart Certificate Authority", there is too low info about them, but some sites note, that this is an additional WebMoney (WM Transfer Ltd, Russian analog of PayPal) certificate. Ok, but why sigcheck detects main WebMoney certificate as absent in the MS trusted list, but don't detect Dekart? This is some kind of mystic. Generally speaking, where can I see this list in plaintext form?

Answer 1

Yeah, that looks fake to me, I agree with your link. These lines in particular are suspicious:

Google
  Cert Issuer:    Google
  Algorithm:  sha1RSA
  Valid from: 0:05 22.07.2015
  Valid to:   0:05 21.07.2020

Let's dissect this and compare it against the cert presented when I browse to google.com.

Root CA

What you posted is a self-signed Root CA cert, we can tell because the subject and issuer are the same

Google
  Cert Issuer:    Google

Google does now own their own Root CA; it looks like they have an intermediate CA off a GeoTrust root:

Algorithm

Algorithm:  sha1RSA

Yeah, that's wrong. Google has been waging war to remove SHA1 from the internet since about 2015: as of January 2017 Google Chrome browser no longer displays the green lock icon for SHA1 certs, and in February 2017 Google researchers demonstrated the first publi collision attack against SHA1. So yeah, there's no way in hell Google would issue themselves a SHA1 cert in 2015 and continue to use it until 2020.

For comparison, the real Google Internet Authority G2 uses SHA-256 With RSA and renews it cert every year and a half (currently valid from May 2017 to Dec 2018).

---

Advice

I would delete that cert from your trust store, and see if anything stops working. Keep running regular virus scans out of fears that your system is already compromised. If that cert (or ones like it) show up in your trust store again, it might be time to wipe your hard drive and re-install the OS.

Update

In response to the extra info you posted:

Subject: CN=Google, O=Authenticode, L=Silicon Valley, C=US

LOL! Yeah, that's completely bogus. Here's how Google actually identifies itself in a certificate:

CN=*.google.com, O=Google Inc, L=Mountain View, ST=California, C=US

Answer 2

Looks bad.

This seems to be a bad CA cert. Best to nuke and rebuild your computer.

• Thread from the maker of the "RCC" ("Root Certificate Checker" program for Windows): https://hexatomium.github.io/2017/04/20/fake-goog-root/ (Archived here.)

• Hybrid-Analysis reports that this Cert is part of this program. Which VirusTotal marks as a virus.

---

Edit 1: Just for fun: some digging around.

Some in depth analysis of the contents of that P12 file. Read this only if you like this sort of thing.

Splitting apart the P12 file

Let's have a look at that p12 file and unwrap it:

$ sha256sum.exe cert.p12
c33d12dc723dfb5af945e69dd2af8a475234d3fae779b444bea924dcb816620a *cert.p12

$ openssl pkcs12 -in cert.p12 -out pembundle.pem -password pass:"" -nodes -info
MAC Iteration 2048
MAC verified OK
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Certificate bag
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048


$ csplit -f individual- pembundle.pem '/^Bag Attributes/' '{*}' --elide-empty-files
2036
1969
3396

Now let's look inside and give these objects some nicer names:

$ head individual-0*
==> individual-00 <==
Bag Attributes
    localKeyID: 70 04 3C 28 93 39 60 37 92 DA 92 8F 73 F5 50 86 60 3F BF 27
subject=/C=US/L=Silicon Valley/O=Authenticode/CN=PortableWares
issuer=/C=US/L=Silicon Valley/O=Authenticode/CN=Google
-----BEGIN CERTIFICATE-----
MIIFFzCCAv8CAQEwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxFzAVBgNV
BAcMDlNpbGljb24gVmFsbGV5MRUwEwYDVQQKDAxBdXRoZW50aWNvZGUxDzANBgNV
BAMMBkdvb2dsZTAeFw0xNTA3MjEyMTA1MTJaFw0xNzA3MjAyMTA1MTJaMFUxCzAJ
BgNVBAYTAlVTMRcwFQYDVQQHDA5TaWxpY29uIFZhbGxleTEVMBMGA1UECgwMQXV0
aGVudGljb2RlMRYwFAYDVQQDDA1Qb3J0YWJsZVdhcmVzMIICIjANBgkqhkiG9w0B

==> individual-01 <==
Bag Attributes: <No Attributes>
subject=/C=US/L=Silicon Valley/O=Authenticode/CN=Google
issuer=/C=US/L=Silicon Valley/O=Authenticode/CN=Google
-----BEGIN CERTIFICATE-----
MIIFGDCCAwACCQDNCzLvtPTNEzANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJV
UzEXMBUGA1UEBwwOU2lsaWNvbiBWYWxsZXkxFTATBgNVBAoMDEF1dGhlbnRpY29k
ZTEPMA0GA1UEAwwGR29vZ2xlMB4XDTE1MDcyMTIxMDUwOFoXDTIwMDcyMDIxMDUw
OFowTjELMAkGA1UEBhMCVVMxFzAVBgNVBAcMDlNpbGljb24gVmFsbGV5MRUwEwYD
VQQKDAxBdXRoZW50aWNvZGUxDzANBgNVBAMMBkdvb2dsZTCCAiIwDQYJKoZIhvcN
AQEBBQADggIPADCCAgoCggIBAOI8i0Hzr4lZFc2FsvopuCyNwZuYNqwiBqgJHKGj

==> individual-02 <==
Bag Attributes
    localKeyID: 70 04 3C 28 93 39 60 37 92 DA 92 8F 73 F5 50 86 60 3F BF 27
Key Attributes: <No Attributes>
-----BEGIN PRIVATE KEY-----
MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDbVi3zesndOgos
+Kesf017VXMWZwvttim67t15uUy6O6I5kzLElxuehgnHm/yQcNCXh/oLMyoxIPTw
pK0dmC09SRKwcX36ZPteBhhgdRHAY/5/7KaXHgKzWvK02XJ+mC2t81H15lemx/bA
+56zFUgYlxa2A+Zge3n5nrkT3uDPm8kmGfKycKZye4ODoKv/uU4JxGcUvrLKZSet
72gIwIlncK3puU7eRIQ95yBJengOWTdTYEdDl+Bimz+8GH7xGB5gdzB8q9F1QVTe
SHSvMURZLfatbHupbCWEmgqPvZzDV1ohP4Ab5dt1M1H5lnE3DNuOBqfbJ8gE3O26

Now that we have an idea what's inside, we can give them proper names. Let's also pump them through openssl to get the full parse out (via the -text parameter) along with the Base64 encoding.

$ cat individual-00 | openssl x509 -text > portablewares.cer

$ cat individual-01 | openssl x509 -text > fakegoogle.cer

$ cat individual-02 | openssl rsa -text > someprivkey.key

What about that privkey?

Now let's see if any of these certs belongs to the privkey:

$ openssl x509 -in portablewares.cer -pubkey | openssl pkey -pubin -pubout -outform der | sha256sum
041b989566cd1174449d4f74dbdeb82b58365a8942936676cbff662998f58fb0 *-

$ openssl pkey -in someprivkey.key -pubout -outform der | sha256sum
041b989566cd1174449d4f74dbdeb82b58365a8942936676cbff662998f58fb0 *-

$ openssl x509 -in fakegoogle.cer -pubkey | openssl pkey -pubin -pubout -outform der | sha256sum
1a0873fe3d24bf8e77775694eaab0940c37ac3d03b3d3b42acb4f600bb4f112f *-

It seems that the privatekey might belong to the "portablewares.cer".

Let's make sure and try to actually sign something with this. (I'm using the method recommended by journalist Hanno Böck to do this.)

$ ./TryAndSignWithThis.sh portablewares.cer someprivkey.key
4a96b377cd177bcece1af794cdcb5144cc9e3f7285e5652b0bc36c4f0551f439 *SignThisBlob.bin
4a96b377cd177bcece1af794cdcb5144cc9e3f7285e5652b0bc36c4f0551f439 *BlobAfterVerify.bin
Files SignThisBlob.bin and BlobAfterVerify.bin are identical

Yup. This privkey belongs to that certificate.

Let's give it a nicer name:

$ mv someprivkey.key portablewares.key

Script Listing

$ cat TryAndSignWithThis.sh
# Usage: TryAndSignWithThis.sh somecert.cert somekey.key
# Adapted from the script by Hanno Böck ( https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html , https://archive.is/RZgXp )
openssl x509 -in $1 -noout -pubkey > TryThisPubkey.pem
dd if=/dev/urandom of=SignThisBlob.bin bs=32 count=1 status=none
openssl rsautl -pkcs -sign -inkey $2 -in SignThisBlob.bin -out BlobWithSignature.bin
openssl rsautl -pkcs -verify -pubin -inkey TryThisPubkey.pem -in BlobWithSignature.bin -out BlobAfterVerify.bin

sha256sum -- SignThisBlob.bin BlobAfterVerify.bin
diff --report-identical-files -- SignThisBlob.bin BlobAfterVerify.bin

rm -- TryThisPubkey.pem SignThisBlob.bin BlobWithSignature.bin BlobAfterVerify.bin

Re. Hexatomium post

Also: This fake google cert is in fact the certificate that was mentioned in the HexAtomium blog post above. He has this available for download. And the pubkey is the same as for our cert.

$ curl -s https://www.trustprobe.com/TI/fake_google.cer | openssl x509 -inform der -pubkey | openssl pkey -pubin -pubout -outform der | sha256sum
1a0873fe3d24bf8e77775694eaab0940c37ac3d03b3d3b42acb4f600bb4f112f *-

Some googling

Let's do some further websearch for these certs/keys

$ openssl x509 -in fakegoogle.cer -outform der | sha1sum
33fcd70343bbe07972d73cdefdeb3c9f4dcefe28 *-

Googling for this turns up nothing too interesting.

$ openssl x509 -in portablewares.cer -outform der | sha1sum
70043c289339603792da928f73f55086603fbf27 *-

Googling for this turns up some VirusTotal scans of a files that are signed with that cert/key. Nice! ->

• Report for RadioSurePortable_x.x.x_online.paf.exe
• Report for DVDFab 9.2.1.2 Final Portable by PortableWares.exe

Now what about that key?

$ openssl rsa -in portablewares.key -outform der | sha1sum
writing RSA key
a8ab813368f9f9ef13d70ea6e2489d0d2f7eb36c *-

Googling for this results in nothing.

Now what if we search for the serial numbers?

$ openssl x509 -in fakegoogle.cer -noout -serial
serial=CD0B32EFB4F4CD13

Googling for this only turns up the Hybrid-Analysis scan again.

$ openssl x509 -in portablewares.cer -noout -serial
serial=01

This serial number is just bizarre and waves all sorts of red flags.

Full cert/key listing

Full parse outs of the certs/key:

• fakegoogle.cer
• portablewares.cer
• portablewares.key

Edit 2.

I actually found a sample EXE file that is signed with that cert/key.

• Report at Hybrid-Analysis.com. (You can also download that file by clicking the Login to Download Sample (5.9MiB) button in the top left corner.)
• Interestingly after I reuploaded this to VirusTotal the new report no longer mentions the supposed signer. Now it just says A certificate chain could not be built to a trusted root authority.
• The old report also had an expandable Signer node that gave more detail.

Edit 3.

I don't know what to make of this signtool output. The main signature is obviously fake. (As we found out above.) But what about the signed timestamps? Are they for real? Maybe somebody else can explain this.

C:\> signtool verify /all /pa /v /debug RadioSurePortable_x.x.x_online.paf.exe

Verifying: RadioSurePortable_x.x.x_online.paf.exe

Signature Index: 0 (Primary Signature)
Hash of file (sha1): 148528EE2FDB92441711B3E10760E1D191AD108D

Signing Certificate Chain:
    Issued to: PortableWares
    Issued by: Google
    Expires:   Thu Jul 20 23:05:12 2017
    SHA1 hash: 70043C289339603792DA928F73F55086603FBF27

The signature is timestamped: Sun Oct 04 23:04:08 2015
Timestamp Verified by:
    Issued to: Thawte Timestamping CA
    Issued by: Thawte Timestamping CA
    Expires:   Fri Jan 01 01:59:59 2021
    SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

        Issued to: Symantec Time Stamping Services CA - G2
        Issued by: Thawte Timestamping CA
        Expires:   Thu Dec 31 01:59:59 2020
        SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1

            Issued to: Symantec Time Stamping Services Signer - G4
            Issued by: Symantec Time Stamping Services CA - G2
            Expires:   Wed Dec 30 01:59:59 2020
            SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4


Number of signatures successfully Verified: 0
Number of warnings: 0
Number of errors: 1
SignTool Error: WinVerifyTrust returned error: 0x800B010A
        A certificate chain could not be built to a trusted root authority.

Answer 3

If you didn't install the root certificate and the PC is not connected to PC, then the certificate came from a local trusted root certificate cache (in Crypt32.dll library).

By default, only a subset of trusted roots are preinstalled in the MMC. However, when CryptoAPI builds a chain, it checks whether the particular root certificate is stored in the cache. If found, then certificate is copied from Crypt32.dll to certificate store (what you see in MMC). It is expected behavior for MS CryptoAPI and there is no harm in this.