There’s a working Proof of Concept for the “ChainOfFools” CVE-2020-0601 Crypto API bug — but it isn’t as bad as you think

Topic

New Reply

Long story short, Yolan Ronmailler has posted a working Proof of Concept for NSA’s CVE-2020-0601 Crypt43 bug. The code is available on Github. There’s
[See the full post at: There’s a working Proof of Concept for the “ChainOfFools” CVE-2020-0601 Crypto API bug — but it isn’t as bad as you think]

4 users thanked author for this post.

Moonbear, Alex5723, Pepsiboy, rontpxz81

Reply | Quote

Replies

Woody, I really can’t agree with you here on downplaying the severity of this vulnerability.

In order for it to work, the victim first has to visit a site that has a clean copy of the certificate that the attacker has subverted, and then visit the site with the subverted certificate. Unless the attacker has full control over your network, the chances of that happening are slim indeed.

This is not any more difficult than a conventional man in the middle attack. If an attacker is already man in the middling you, all they have to do is transparently proxy a legitimate web page first (without the ability to see or modify the content), and then attack subsequent requests. This attack is not any harder to exploit compared to other man in the middle attacks.

E.g. attack google search by transparently proxying homepage and then intercepting the new request when a user searches. You can’t modify the homepage initially, but you can modify the results.

While we know that Chrome requires the user to visit a clean site to cache the certificate first, what about classic edge? What about software programs that auto-update and already have a cached copy of the certificate?

All these quotes are saying is that man-in-the-middle is less dangerous than remote code execution, which is true. The minor hurdle to exploitation is not much of a hurdle at all.

This problem is so trivial and the patch so simple that it is unlikely to cause problems, and it should be safe to tell users to update immediately. The potential attack surface on third-party applications that use the Windows crypto API is broad.

2 users thanked author for this post.

Sportsman, Barry

Reply | Quote

What you say is correct but… I have to weigh the potential for a widespread attack (which is still not imminent) vs. the very real problems we’ve seen, historically, with buggy Windows patches. If the patches were more reliable, there’d be no question. If the patch were for just this one vulnerability, there’d be no question. But it isn’t that simple.

Stay tuned.

Reply | Quote

FWIW, I patched it immediately (no problems observed on my PC), although I later learned that Windows Defender and some other AV’s have added detection for the malformed certificates.

https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Exploit:Win32/CVE-2020-0601.A&ThreatID=2147749406

Windows 10 Home 64-bit

1 user thanked author for this post.

woody

Reply | Quote

Would someone be able to please explain what keeps this from effecting Windows 7?

I feel as if I’ve missed something very obvious in everything I’ve read.

Is it as simple as the Crypto API not working the same between Windows 7 & 10?

Reply | Quote

Win7 doesn’t use the same Crypto verification sequence. It isn’t at risk.

2 users thanked author for this post.

ryegrass, Moonbear

Reply | Quote

[Moonbear]

Wow, I did not expect it to actually be that simple.

• This reply was modified 5 years, 4 months ago by Moonbear.

Reply | Quote

woody wrote:

Win7 doesn’t use the same Crypto verification sequence. It isn’t at risk.

Is that also true for Windows 8?

Win 10 ver. 22H2 x64

Reply | Quote

Windows 8.1 and earlier are not affected, per https://www.kb.cert.org/vuls/id/849224/

Windows 10 Home 64-bit

2 users thanked author for this post.

woody, JD

Reply | Quote