CurveBall: Microsoft Windows CryptoAPI Spoofing Vulnerability Webcast

CurveBall: Microsoft Windows CryptoAPI Spoofing Vulnerability Webcast


 

Kudelski Security’s Francisco Donoso, Director – Global Security Strategy, provides a brief webcast overview of CurveBall, the Microsoft Windows cryptographic API vulnerability. 

Today, we’ll be talking about CurveBall, a Microsoft Windows cryptographic API vulnerability. We’ll give you a brief overview of Curveball as the vulnerability is called, talk a little bit about the potential impact and what you can do to remediate and detect.

First things first CurveBall impacts, Windows 10, Windows Server 2016 and Windows Server 2019. The reason that these operating systems are impacted is because they support new versions of Elliptic Curve Cryptography. ECC, as it’s called, is just another signature algorithm similar to RSA that’s faster and more efficient than RSA. With ECC you can have smaller key sizes that are effectively as secure as larger RSA keys and thus they’re really valuable for fast, speedy encrypted communication.

The vulnerability exists because Microsoft now supports what are called non-standard curves, which allow attackers to spoof certificates that Microsoft Windows would consider valid even though they are not. Because of this, Curveball can allow attackers to spoof HTTPS certificates. That means that an attacker in a privileged network position who can capture your client’s traffic could potentially spoof a certificate using one of these non-standard curves and intercept that traffic, potentially modifies it and potentially introduce other traffic into that supposedly secure stream. Additionally, this allows attackers to spoof what are called code signing certificates, which are intended to protect machines by application whitelisting. Several application whitelisting solutions allow organizations to prevent non-signed binaries or code from running on their machines. Additionally, there are several cryptographic protections that Microsoft Windows requires for security purposes to be signed either by Microsoft itself or a trusted developer.

Leveraging this vulnerability, an attacker could potentially run malicious code on a system that should not have been run. Now Kudelski Security and our research team have released a proof of concept exploit. Here you can see that we’ve been able to spoof a certificate that’s considered valid for GitHub.com, even though this is hosted on a Kudelski Security site. This is a real-world example of the potential impact of the CurveBall vulnerability.

So again, this exists because Windows fails to properly validate elliptic curve cryptography certificates, allows an attacker to spoof those certificates to intercept HTTPS or TLS traffic or potentially run malicious code on a system that requires binaries to be run. Kudelski Security has released a proof of concept exploit and published a detailed blog on the topic, for those of you who are interested.

Now talking a little bit about detection and response, Microsoft, in coordination with the U.S. National Security Agency, released a patch for this vulnerability on January 14, 2020. Everyone should apply that patch as soon as possible. From a detection perspective, the new patch actually introduces a new application event logged by Windows computers with a source of Microsoft Windows Audit CVE. For those of you who are looking to detect potential exploitation of this vulnerability, once a system has been patched, you’ll be able to centrally collect these potential logs and identify an attempt to exploit this vulnerability. Just a quick note that this event will only be written once the patch has been applied to the impacted computer. Finally, it’s also possible to detect potential tampering or TLS certificates spoofing by monitoring TLS handshakes using a system like an intrusion detection system or other network monitoring solutions. There are several signatures that vendors have released and if you’re interested, our blog posts also cover some more additional details.

Finally, I just want to remind everyone that while this vulnerability is highly impactful, it’s not the end of the world. Windows updates, which are used to deliver secure code and patches to all of these windows machines are not impacted. They actually use a separate algorithm, RSA, and Microsoft has embedded the full certificate chain in Windows to validate that they’ve been properly signed by Microsoft. That limits the potential impact. Additionally, Microsoft released several critical severity vulnerabilities in remote desktop gateways that we recommend clients prioritize. Since those are much more likely to be exploited by unsophisticated attackers in the next few days.

Read the proof of concept here: https://research.kudelskisecurity.com/2020/01/15/cve-2020-0601-the-chainoffools-attack-explained-with-poc/

Read the security advisory here: https://modernciso.com/2020/01/16/security-advisory-multiple-critical-vulnerabilities-on-windows-systems/

SECURITY ADVISORY: Multiple Critical Vulnerabilities On Windows Systems

SECURITY ADVISORY: Multiple Critical Vulnerabilities On Windows Systems

On January 14th, 2020 (Patch Tuesday), Microsoft released patches for a severe vulnerability Window’s cryptographic subsystems and critical vulnerabilities in Windows Server Remote Desktop (RDP) Gateway. These Microsoft vulnerabilities are considered critical and the Cyber Fusion Center strongly recommends applying these patches as soon as possible. Kudelski Security expects active exploitation in the near future.

The U.S National Security Agency released an advisory regarding a vulnerability in a cryptographic library (Crypt32.dll) used in Microsoft Windows 10, Windows Server 2016, and Windows Server 2019 (CVE-2020-0601). This issue impacts the verification of elliptic curve cryptography (ECC) signatures in security certificates. The verification of such certificates has been discovered to be defective and may allow an attacker to incorrectly validate a forged certificate. Successful exploitation of this issue has been shown to allow for interception, modification, and decryption of TLS / HTTP(s) traffic by attackers in privileged network positions. Additionally, this may allow attackers to successfully bypass code-signing requirements on Windows systems or bypass Device Guard application whitelisting solutions.

Kudelski Security’s research team has been able to successfully exploit this vulnerability to issue spoofed HTTPs certificates considered valid by Windows 10, Windows Server 2016, and Windows Server 2019:

https://research.kudelskisecurity.com/2020/01/15/cve-2020-0601-the-chainoffools-attack-explained-with-poc/

Additionally, Kudelski Security has released a public POC available on our Github page:

https://github.com/kudelskisecurity/chainoffools

This “Patch Tuesday” also included patches for multiple critical vulnerabilities in Windows Remote Desktop (RDP) Gateways. These critical vulnerabilities lead to unauthenticated Remote Code Execution (RCE) with SYSTEM privileges. Such vulnerabilities could be leveraged by attackers to remotely compromise systems without authentication or user interaction. Remote Desktop Gateways allow organizations to centralize Remote Desktop services and provide remote access to Windows endpoints and servers without a VPN, provide web-based RDP user experiences, and more.

Description

Microsoft released patches for a severe vulnerability Window’s cryptographic subsystems and critical vulnerabilities in Windows Server Remote Desktop (RDP) Gateway. Kudelski Security expects active exploitation in the near future. As such, the Cyber Fusion Center strongly recommends mitigating these issues as soon as possible.

The Microsoft Windows cryptographic subsystem vulnerability was publicly disclosed jointly by Microsoft and the U.S National Security Agency (NSA) after being successfully patched by Microsoft. Microsoft and the NSA have publicly stated that that they’ve not observed any exploitation of this vulnerability. Additionally, Kudelski Security has been able to leverage this vulnerability to successfully to issue spoofed HTTPs certificates considered valid by Windows 10, Windows Server 2016, and Windows Server 2019 and has released public Proof Of Concept code (POC) on our github page. Please review the sources linked in this document for our blog post and links to the POC code.

The vulnerability is in a cryptographic library (Crypt32.dll) used in Microsoft Windows 10, Windows Server 2016, and Windows Server 2019 (CVE-2020-0601). This issue impacts the verification of elliptic curve cryptography (ECC) signatures in security certificates. The verification of such certificates has been discovered to be defective and may allow an attacker to incorrectly validate a forged certificate. Successful exploitation of this issue has been shown to allow for interception, modification, and decryption of TLS / HTTP(s) traffic by attackers in privileged network positions. Additionally, this may allow attackers to successfully bypass code-signing requirements on Windows systems or bypass Windows Device Guard or other application whitelisting solutions.

Additionally, Microsoft has released patches for multiple critical vulnerabilities in Windows Remote Desktop (RDP) Gateways. These critical vulnerabilities may lead to unauthenticated Remote Code Execution (RCE) with SYSTEM privileges. These vulnerabilities could be leveraged by attackers to remotely compromise systems without requiring to validate credentials or user interaction. Remote Desktop Gateways allow organizations to centralize Remote Desktop services and provide remote access to Windows endpoints and servers without a VPN, provide web-based RDP user experiences, and more.

It’s important to note that Remote Desktop (RD) Gateway is a separate application rather traditional Remote Desktop Protocol. Organizations looking to identify any potentially exposed RD gateways should look for systems exposing UDP port 3391 (not the traditional RDP Port on TCP 3389) along with Remote Desktop Web Services on HTTPs (TCP/443).

Kudelski Security expects to see attackers leveraging these Remote Desktop Gateway vulnerabilities to compromise unpatched systems in the near future due to the prevalence of the technology and the ability to compromise critical systems without authentication or user interaction. As such, we strongly recommend that clients apply these patches as quickly as possible.

Detection

Microsoft Windows Crypto Subsystem issue

Organizations who do not currently have Kudelski Security Cyber Fusion Center’s Threat Monitoring and Hunting services may want to ensure Windows Application Logs are being centrally collected and monitored. Microsoft has introduced a new Windows Event source named “Microsoft-Windows-Audit-CVE”. Microsoft Windows will now write events to the local Windows application logs with this source if there are attempts to exploit this vulnerability. Note that the Windows Event source will only be available after the latest patches have been applied.

Additionally, it’s possible to detect potentially invalid TLS certificates being used to exploit this vulnerability by intercepting TLS packets and checking certificate signature for uncommon elliptic curve parameters. By analyzing TLS traffic, the “ServerHello/Certificate/ServerHelloDone” packet contains the certificate which should be checked for possible forgery.

Additionally, the Cyber Fusion Center is actively working with our vendor partners to ensure we can actively detect attempted exploitation of this vulnerability. For customers with the Cyber Fusion Center’s Endpoint Detection and Response service will be proactive notified if potential exploitation is detected.

Microsoft Remote Desktop Gateway issues

Organizations who do not currently have Kudelski Security Cyber Fusion Center’s Threat Monitoring and Hunting services or our vulnerability scanning services may want to identify exposed versions of Web Services for remote desktop or systems that respond to UDP port 3391. Several vendors have released IDS or IPS detection signatures.

Additionally, the Cyber Fusion Center is actively working with our vendor partners to ensure we can actively detect attempted exploitation of these vulnerabilities. For customers with the Cyber Fusion Center’s Endpoint Detection and Response service will be proactive notified if potential exploitation is detected.

Mitigation and Response

The Cyber Fusion Center is actively working with our vendor partners to ensure we can actively detect attempted exploitation of these vulnerabilities. For customers with the Cyber Fusion Center’s Endpoint Detection and Response or Threat Monitoring services will be proactive notified if potential exploitation is detected.

For customers with the Cyber Fusion Center’s vulnerability scanning service will be proactively notified if any vulnerable Remote Desktop gateway systems are detected.

Sources

 

 

Don’t Let Crypto Ruin Your Day

Don’t Let Crypto Ruin Your Day

A few years ago, a customer handed us a report from a Big 4 consulting firm describing how, after close to 100 person-hours of review, a team of ‘highly-qualified senior security engineers’ had failed to find any flaw in their encrypted communications product. Half a day later, I had worked out how to break the product’s encryption, and demonstrated a working exploit. The customer was confused—why hadn’t the well-dressed consultants caught the vulnerability?

One possible reason is that such firms will often present as ‘senior engineers’ or even ‘experts’, junior hires whose only expertise is a night browsing about the subject matter. For an hourly rate of $250. But that’s another story.

The reason it took me half a day to discover the flaw is principally to do with skillsets. Crypto requires specific skills. Like a good general surgeon won’t necessarily be a good heart surgeon, a good all-around security engineer won’t necessarily be the right person to review cryptography products.

Why Crypto Is Hard

To be honest, I don’t think that crypto is intrinsically harder than other domains of information security. I find crypto much simpler than, say, browser security. But crypto is viewed as hard because it requires totally different skills, especially mathematics, and because it involves security notions that aren’t used elsewhere. A security engineer can have years of experience in web security, application security, and network security, yet have little exposure to concepts such as forward secrecy or indistinguishability.

Of course, bugs in cryptographic software can be the same kind bugs as is any piece of software, bugs such as buffer overflows or use-after-frees (think Heartbleed). Finding logic bugs, however, often requires an understanding of the crypto protocols and their subtleties. Even harder is cryptanalysis, the task of studying properties of cryptographic designs and implementations. Doing cryptanalysis for a general security engineer is like asking a cryptographer to reverse engineer an obfuscated binary program. If you don’t have thousands of hours of experience, you won’t find the subtlest vulnerabilities (such as these), and it will take you days to do what an experienced person would do in hours.

An additional risk with crypto is that of side channels, or the leak of information about secret material from the program’s behavior. This class of bugs includes for example timing leaks, which occur when the execution time of a program reveals information on the cryptographic keys. A common side-channel attack in software applications is the padding oracle attack (alas, not yet eradicated).

The bottom line is that reviewing crypto is much more than checking what algorithms are used, as I’ve previously blogged about.

What To Do About It

To review the crypto in your crypto product, hire cryptography experts who are used to doing this kind of job. Purely academic researchers may help for the more theoretical analysis, but are rarely familiar with practical considerations.

You’ll find such crypto experts either in large security companies, or in smaller shops specialized in crypto reviews. It can be hard to identify the qualified teams though. A sign of ability is the publication of vulnerabilities or presentation of their research at conferences. Note that the absence of evidence is not evidence of absence; some companies choose not to publish anything.

Another approach, especially if part of your code is open-source, is to organize a bug bounty and offer a reward to discoverers of vulnerabilities including crypto vulnerabilities.

In any case, to prevent failures in your crypto product, follow the usual advice: refrain from creating your own protocol or algorithm and rely on time-tested software components.

And beware marketing. All that glitters is not gold, and with a view to getting a generous slice of an increasingly lucrative market, security companies are keen to package up their infosec-related skills as crypto-specific ones. Dig beneath slick marketing to find out if there is substance to the claims or, as Nomx experienced earlier this year, you could well end up with a Pi(e) on your face.