Very High
CVE-2020-0601, aka NSACrypt
CVE-2020-0601, aka NSACrypt
Description
A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates.An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source, aka ‘Windows CryptoAPI Spoofing Vulnerability’.
Add Assessment
Technical Analysis
I’m not so sure that @todb-r7’s assessment is completely correct, this affects all the things that validate certs, including TLS in browsers, powershell, etc. So kinda impactful beyond just local code execution, this could be a vector for all kinds of other spoofing.
More info in swiftonsecurity’s thread regarding how this pivots into RCE: https://threadreaderapp.com/thread/1217159419533893633.html
The method that should be affected here is https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certgetcertificatechain courtesy of https://twitter.com/hackerfantastic/status/1217211301375696896
Open source software that uses or exposes this method: https://codesearch.debian.net/search?q=CertGetCertificateChain&literal=1
The exposure of user-defined eliptical curves in TLS certificates created a window of opportunity for this bug to appear, which may have been mitigated if the underlying specification was simpler as well, especially with regards to seldom-used features like this. One may want to look ahead to similar bugs in other dark corners of a TLS implementation near you!
Technical Analysis
As others have said, this would likely require either MiTM or otherwise coaxing someone to run an executable in a typical malware distribution scenario for the authenticode bit. So, if defining exploitation as successful compromise of a user connection or system, I think the complexity of this is high, but the payoff/utility especially for snooping is fairly critical.
Agreed on the RCE vector, but I do have a problem with the “RCE” label since it tends to imply a certain specific type of code execution, rather than the enablement of a vector of execution, which this is.
Technical Analysis
This is a vuln in the way crypt32.dll on recent builds of Windows validates ECC certificates. Yes, it’s bad for cryptography. But, an attacker has to be in a position already to get you to either a) run an exe they give you (and then pass the cert check for a trusted publisher), or b) MITM your HTTPS connection (somehow) so their fake website looks like the real website. So… this kinda bugs me that it’s being called “RCE.” It’s not in any useful sense of the term. It’s an identity spoofing bug.
I guess it’s good that it doesn’t affected Windows 7 and 2008 R2 – guess we should stay on those huh :)
W74Life
But, can’t I make a legit cert with this technique and stick it on an external web site and get unpatched systems to trust it as being authentic?
Technical Analysis
This appears to be a bug with the authentication of elliptical curve cryptographic certificates definitely related to file source authentication through signing and possibly channel communications; there are unsubstantiated rumors about RCE, though I don’t see a pathway for that beyond a MitM attack. This is going to serve primarily as a local privilege escalation tool because Microsoft OSs depend on file authentication and privileged execution in some instances to avoid a requirement for user authenticated elevation for execution. I am unclear on how difficult breaking into an established session might be, but certainly spoofed signed files would be useful to a hacker.
Of the two likely scenarios, local privilege escalation seems the most likely, with MitM attacks possible. This is likely not a wormable threat and will require some amount of time and effort on the part of the attacker. Nation-state-level players might abuse this by owning update servers or routers and serving clients malicious signed updates or other binaries, but that’s not a likely threat model for average person or even company. In addition to the personalized nature of the attack vector, I imagine the barrier to writing even a local exploit would be higher than most, as cryptography is hard.
This is interesting, it is bad, and it should be patched, but it is not at the level of something like eternalblue or even bluekeep, in my opinion. I think that it was reported by the NSA has caused a bit more attention to it than the vulnerability warrants, but since there is a path to exploitation and a simple patch out that should have little effect on users, you should patch immediately.
Technical Analysis
Granted patching is not immediate and still lags in many orgs, but the trend for patching current systems (which is seems to apply to) is better than legacy and there is a working patch, thus I can’t see exploits working for long on major, mature organizations.
Technical Analysis
https://twitter.com/taviso/status/1217146026923978752
X.509 validation being broken is pretty big. I don’t know about RCE possibilities yet, but MITM and spoofing got a whole lot more serious.
https://twitter.com/saleemrash1d/status/1217495681230954506
https://medium.com/zengo/win10-crypto-vulnerability-cheating-in-elliptic-curve-billiards-2-69b45f2dcab6
It appears the vulnerable code is in the ECC implementation.
https://twitter.com/SwiftOnSecurity/status/1217159434880847879
Sounds about right for RCE possibility.
Looked at these yesterday: https://news.ycombinator.com/item?id=22048619 and https://github.com/ollypwn/cve-2020-0601. Seems legit!
Technical Analysis
This is now supposedly being exploited in the wild by Chinese state actors according to this NSA announcement: https://media.defense.gov/2020/Oct/20/2002519884/-1/-1/0/CSA_CHINESE_EXPLOIT_VULNERABILITIES_UOO179811.PDF
CVSS V3 Severity and Metrics
General Information
Vendors
- golang,
- microsoft
Products
- go,
- windows 10 -,
- windows 10 1607,
- windows 10 1709,
- windows 10 1803,
- windows 10 1809,
- windows 10 1903,
- windows 10 1909,
- windows server 2016 -,
- windows server 2016 1803,
- windows server 2016 1903,
- windows server 2016 1909,
- windows server 2019 -
Exploited in the Wild
References
Miscellaneous
All I’m complaining about is that it’s /not/ RCE. It’s certificate — and therefore, identity — spoofing. It doesn’t seem to me that being able to sign a binary with a trusted cert is “remote code execution,” it’s faking the source of the binary, /in order/ for you to run the executable yourself.
Now, there can be an attack involved that a) fakes the identity of an update service on the internet that b) delivers a fake update binary that c) is run automatically…. but that’s two different certs you’re forging in order to get the desired results, and neither attack feels like “RCE” to me.
I dunno. It’s a big(gish) deal (for APT sorts who can pull off that kind of attack), but it’s not RCE in the way we usually think about RCE bugs.
crypt32.dll is so uniquitous though, I’m sure there are a non-trivial number of apps that assumed that their certificate pinning was safe enough to provide protection against MitM. Think about how many EDR agents there are out there that talk to a bunch of non-public DNS hostnames for the local command-and-control hub, maybe using MDNS, etc. for that name – and then run code and commands they download. I think we’re going to see a lot of novel attacks utilizing this as a springboard just when folks thought it was safe-ish to trust airport wifi again.