如何检查危险的权威根证书以及如何处理它们?

信息安全 证书 证书颁发机构
2021-08-15 18:52:27

在看到一个程序添加了一些行之后我开始了我的探索certmgr.msc(PC没有连接到互联网,所以我认为这个证书不能被MS下载)。该程序的安装程序包含这个 .p12 文件,Virustotal很清楚,但我做了更多研究。我检查了我的证书存储使用

sigcheck -tuv

发现了一个相当奇怪的证书:

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

相关信息太少

指纹:33FCD70343BBE07972D73CDEFDEB3C9F4DCEFE28

在互联网上,但我发现了一些有趣的链接(对不起,我是这个论坛的新手,不能发布超过 2 个链接,我发布了其他人作为该主题的引用)。

现在,我非常害怕和困惑。我不明白它会造成什么样的危险。我不知道该怎么办。我绝对确定我没有手动安装此证书。在我本地网络的另一台计算机上找到了相同的证书。

我需要补充一点,我还用几个“按需”的 AV 扫描仪(CureIt、KVRT)检查了我的电脑,他们在这个证书中没有发现任何问题。

执行的结果certutil -verify -urlfetch

Поставщик:
    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 — команда успешно выполнена.

(系统语言:rus)

稍后......我发现了另一个“奇怪”证书“Dekart Certificate Authority”,关于它们的信息太少,但一些网站指出,这是一个额外的 WebMoney(WM Transfer Ltd,俄罗斯类似 PayPal)证书. 好的,但是为什么 sigcheck 检测到主 WebMoney 证书在 MS 受信任列表中不存在,但没有检测到 Dekart?这是某种神秘主义。一般来说,我在哪里可以看到明文形式的这个列表?

3个回答

是的,这对我来说看起来很假,我同意你的链接。这些行尤其可疑:

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

让我们对此进行剖析,并将其与我浏览到google.com.

根 CA

您发布的是自签名的根 CA 证书,我们可以知道,因为subjectissuer是相同的

Google
  Cert Issuer:    Google

谷歌现在拥有自己的根 CA;看起来他们有一个来自 GeoTrust 根的中间 CA:

google.com 证书链

算法

Algorithm:  sha1RSA

是的,那是错误的。自 2015 年左右以来,谷歌一直在发起从互联网上删除 SHA1 的战争:截至 2017 年 1 月,谷歌 Chrome 浏览器不再显示 SHA1 证书的绿色锁图标,并且在2017 年 2 月,谷歌研究人员展示了针对 SHA1 的第一次公开碰撞攻击所以,是的,谷歌不可能在 2015 年为自己颁发 SHA1 证书并继续使用到 2020 年。

相比之下,实际Google Internet Authority G2使用SHA-256 With RSA和更新它的证书每年半年(目前有效期为 2017 年 5 月至 2018 年 12 月)。


建议

我会从您的信任存储中删除该证书,看看是否有任何停止工作。继续运行定期病毒扫描,以免您的系统受到威胁。如果该证书(或类似证书)再次出现在您的信任库中,则可能是时候擦除您的硬盘驱动器并重新安装操作系统了。

更新

针对您发布的额外信息:

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

哈哈!是的,这完全是假的。以下是 Google 在证书中实际标识自己的方式:

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

看起来很糟糕。

这似乎是一个糟糕的 CA 证书。最好核对并重建您的计算机。


编辑1:只是为了好玩:一些挖掘。

对那个 P12 文件的内容进行了一些深入的分析。仅当您喜欢此类内容时才阅读此内容。

拆分 P12 文件

让我们看看那个 p12 文件并打开它:

$ 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

现在让我们看看里面,给这些对象一些更好的名字:

$ 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

现在我们已经知道里面是什么,我们可以给它们起正确的名字。让我们也通过 openssl 抽取它们以获取完整的解析(通过-text参数)以及 Base64 编码。

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

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

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

那个私钥呢?

现在让我们看看这些证书是否属于私钥:

$ 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 *-

似乎私钥可能属于“portablewares.cer”。

让我们确保并尝试用它实际签署一些东西。(我正在使用记者 Hanno Böck 推荐方法来做到这一点。)

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

对。此私钥属于该证书。

让我们给它起一个更好听的名字:

$ mv someprivkey.key portablewares.key

脚本列表

$ 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

回覆。六角柱

另外:这个假的谷歌证书实际上是上面 HexAtomium 博客文章中提到的证书。他有这个可供下载。公钥与我们的证书相同。

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

一些谷歌搜索

让我们对这些证书/密钥进行进一步的网络搜索

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

谷歌搜索这个结果并没有什么太有趣的。

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

对此进行谷歌搜索会发现一些使用该证书/密钥签名的文件的 VirusTotal 扫描。好的!->

现在那把钥匙呢?

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

谷歌搜索这个结果一无所获。

现在如果我们搜索序列号呢?

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

谷歌搜索只会再次出现混合分析扫描。

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

这个序列号很奇怪,挥舞着各种危险信号。

完整的证书/密钥列表

完全解析出证书/密钥:

编辑 2。

我实际上找到了一个使用该证书/密钥签名的示例 EXE 文件。

  • 在 Hybrid-Analysis.com 上报告(您也可以通过单击Login to Download Sample (5.9MiB)左上角的按钮下载该文件。)
  • 有趣的是,在我将其重新上传到 VirusTotal 后,新报告不再提及假定的签名者现在它只是说A certificate chain could not be built to a trusted root authority.
  • 报告还有一个可扩展的Signer节点,提供了更多详细信息。

编辑 3。

我不知道如何处理这个 signtool 输出。主要签名显然是假的。(正如我们在上面发现的那样。)但是签名的时间戳呢?他们是真的吗?也许其他人可以解释这一点。

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.

如果您没有安装根证书并且 PC 未连接到 PC,则证书来自本地受信任的根证书缓存(在 Crypt32.dll 库中)。

默认情况下,MMC 中只预装了一部分受信任的根。但是,当 CryptoAPI 构建链时,它会检查特定的根证书是否存储在缓存中。如果找到,则将证书从 Crypt32.dll 复制到证书存储区(您在 MMC 中看到的内容)。这是 MS CryptoAPI 的预期行为,这没有什么害处。