Come verificare i certificati radice di autorità pericolosa e cosa fare con essi?

4

Ho iniziato la mia esplorazione dopo aver visto che un programma aggiunge alcune righe a certmgr.msc (il PC non era connesso a Internet, quindi, non credo, che questo certificato possa essere scaricato dalla MS). Il programma di installazione del programma contiene questo file .p12 , Virustotal post è chiaro, ma ho fatto qualche ricerca in più. Ho controllato il mio archivio certificati usando

sigcheck -tuv

È stato trovato un certificato piuttosto strano:

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

Ci sono informazioni troppo basse su

Thumbprint: 33FCD70343BBE07972D73CDEFDEB3C9F4DCEFE28

su Internet, ma ho trovato alcuni link interessanti (mi dispiace, sono un principiante su questo forum e non posso pubblicare più di 2 link, ho postato altri come citazioni su questo argomento).

Ora sono molto spaventato e confuso. Non capisco che tipo di pericolo crea. E non so cosa fare con questo. Sono assolutamente sicuro di non aver installato questo certificato manualmente. Lo stesso certificato è stato trovato su un altro computer sulla mia rete locale.

Devo aggiungere che ho anche controllato il mio computer con diversi scanner AV "on demand" (CureIt, KVRT), non hanno riscontrato alcun problema in questo certificato.

Il risultato dell'esecuzione 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 — команда успешно выполнена.

(Lingua del sistema: rus)

Un po 'più tardi ... ho trovato un altro certificato "strano", "Dekart Certificate Authority", ci sono informazioni troppo basse su di loro, ma alcuni siti notano che si tratta di un WebMoney aggiuntivo ( WM Transfer Ltd, analogo russo di PayPal) certificato. Ok, ma perché sigcheck rileva il certificato WebMoney principale come assente nell'elenco MS di fiducia, ma non rileva Dekart? Questa è una specie di mistico. In generale, dove posso vedere questa lista in formato testo?

    
posta WallOfBytes 06.08.2017 - 14:51
fonte

3 risposte

4

Sì, sembra finto per me, sono d'accordo con il tuo link. Queste righe in particolare sono sospette:

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

Analizziamo questo e confrontalo con il certificato presentato quando sfoglio a google.com .

CA principale

Ciò che hai postato è un certificato CA radice autofirmato, possiamo dire perché subject e issuer sono uguali

Google
  Cert Issuer:    Google

Google ora possiede la propria CA principale; sembra che abbiano una CA intermedia di una radice di GeoTrust:

Algoritmo

Algorithm:sha1RSA

Sì,èsbagliato.GooglehaintrapresounaguerraperrimuovereSHA1daInternetdal2015: a partire da gennaio 2017 il browser Google Chrome non visualizza più l'icona di blocco verde per i certificati SHA1 e in Febbraio 2017 I ricercatori di Google hanno dimostrato il primo attacco di collisione publi contro SHA1 . Quindi sì, non c'è verso che Google rilascerà un certificato SHA1 nel 2015 e continuerà a utilizzarlo fino al 2020.

Per il confronto, il Google Internet Authority G2 effettivo utilizza SHA-256 With RSA e lo rinnova ogni anno e mezzo (valido da maggio 2017 a dicembre 2018).

Consigli

Vorrei eliminare quel certificato dal tuo negozio di fiducia e vedere se qualcosa smette di funzionare. Continua a eseguire regolarmente scansioni antivirus per paura che il tuo sistema sia già compromesso. Se quel certificato (o simili) compare nuovamente nel tuo negozio di fiducia, potrebbe essere il momento di pulire il tuo disco rigido e reinstallare il sistema operativo.

Aggiornamento

In risposta alle informazioni extra che hai postato:

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

LOL! Sì, è completamente falso. Ecco come Google si identifica effettivamente in un certificato:

CN=*.google.com, O=Google Inc, L=Mountain View, ST=California, C=US
    
risposta data 06.08.2017 - 16:28
fonte
3

Sembra brutto.

Questo sembra essere un cattivo certificato CA. È meglio nuke e ricostruisci il tuo computer.

Modifica 1: solo per divertimento: alcuni per scavare.

Alcune analisi approfondite dei contenuti di quel file P12. Leggi questo solo se ti piace questo genere di cose.

Divisione del file P12

Diamo un'occhiata al file p12 e scartalo:

$ 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

Ora guardiamo dentro e diamo a questi oggetti alcuni nomi più belli:

$ 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

Ora che abbiamo un'idea di cosa c'è dentro, possiamo dare loro nomi propri. Buttiamoli anche attraverso openssl per ottenere l'analisi completa (tramite il parametro -text ) insieme alla codifica 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

Che mi dici di quel privkey?

Ora vediamo se qualcuno di questi certificati appartiene alla 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 *-

Sembra che la chiave privata possa appartenere al "portablewares.cer".

Assicuriamoci e proviamo a firmare effettivamente qualcosa con questo. (Sto utilizzando il metodo consigliato dal giornalista Hanno Böck per farlo.)

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

Yup. Questo privkey appartiene a quel certificato.

Diamo un nome più bello:

$ mv someprivkey.key portablewares.key

Elenco script

$ 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. Post di hexatomium

Inoltre: questo falso google cert è in effetti il certificato che è stato menzionato nel post del blog HexAomium sopra. Ha questo disponibile per il download. E il pubkey è lo stesso del nostro cert.

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

Alcuni google

Facciamo qualche altro websearch per questi certificati / chiavi

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

Cercare su google per questo non rende nulla di troppo interessante.

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

Su Google per questo vengono visualizzate alcune scansioni di VirusTotal di file firmati con tale chiave / chiave. Bello! - >

Ora che mi dici di quella chiave?

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

Su Google per questo non si ottiene nulla.

E se cercassimo i numeri di serie?

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

Cerca su Google per questo fa di nuovo la scansione dell'analisi ibrida.

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

Questo numero seriale è semplicemente bizzarro e sventola ogni tipo di bandiera rossa.

Elenco completo cert / chiave

Analisi completa della chiave / chiave:

Modifica 2.

In realtà ho trovato un file EXE di esempio firmato con tale chiave / chiave.

Modifica 3.

Non so cosa fare di questo output di segnapunti. La firma principale è ovviamente falsa. (Come abbiamo scoperto sopra.) Ma per quanto riguarda i timestamp firmati? Sono per davvero? Forse qualcun altro può spiegarlo.

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.
    
risposta data 06.08.2017 - 19:40
fonte
0

Se non hai installato il certificato di origine e il PC non è collegato a PC, il certificato proviene da una cache di certificati radice attendibili locali (nella libreria Crypt32.dll).

Per impostazione predefinita, solo un sottoinsieme di root attendibili è preinstallato in MMC. Tuttavia, quando CryptoAPI crea una catena, controlla se il particolare certificato di root è memorizzato nella cache. Se trovato, il certificato viene copiato da Crypt32.dll nell'archivio certificati (ciò che viene visualizzato in MMC). È previsto un comportamento per MS CryptoAPI e non c'è nulla di male in questo.

    
risposta data 06.08.2017 - 15:25
fonte

Leggi altre domande sui tag