Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

3/13/2012
12:48 AM
Vincent Liu
Vincent Liu
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Ron Was Wrong, Whit Is Right, And What You Need To Know

Clarifying the technical findings on a weakness in RSA crypto keys and some recommendations on how to prepare and protect your assets from the next inevitable crypto weakness discovery

Note: The credit for this post goes entirely to my colleagues at Stach & Liu. In particular, the initial draft of this entry was written by Carl Livitt and further updated by Rob Ragan. I felt it was a great summary that held a lot of value for those of us who are trying to understand and respond to the complex and often nuanced topic of cryptography.

For those who are new to PKI (Public Key Infrastructure) or want a quick refresher, the following video is a great explanation and metaphor based on colors and clocks. Whether the problem is influenced more by Moore’s Law or Murphy’s Law, history tells us that every so often there is a publicly disclosed key-generation flaw in a popular encryption algorithm. For example:

In most cases we see issues with random number generation rather than the core design of SSL security.

SSL Is Not The Problem
At the heart of much confusion around the topic is a concern that SSL encryption itself is flawed; it is not, and the research paper "Ron was wrong, Whit is right" does not describe any inherent weaknesses in SSL or other methods of encryption. The security of SSL and other asymmetric cryptographic systems relies on secrets that are difficult to calculate or guess. The secrets take the form of extremely large prime numbers that are generated once per cryptographic certificate. Any failure in the confidentiality of a certificate’s secret prime number(s) will result in the certificate being compromised, rendering it useless for the purposes of encryption and signing. As long as a certificate’s secrets remain secret, SSL remains strong.

The Root Cause
The actual issue under discussion in the research paper is the way in which cryptographic keys (and the associated prime numbers) are generated. What the researchers found is that a number of real-world SSL certificates have been generated with the same prime numbers. Researchers determined that the massive primes were not random. In fact, there was a great deal of repetition among certificates belonging to unrelated people, companies, and systems. Because of the lack of randomness, the researchers were able to use simple algorithms dating from Euclid’s era to quickly and easily calculate the secrets belonging to a quarter-million SSL certificates from systems all around the world. The underlying cause of the issue is not yet known, although tentative suggestions are pointing toward a broken key-generation implementation that is shared among several types of embedded devices.

What Type of Crypto Systems Are Affected?
As far as we know, the scope of the problem is limited to SSL certificates that use 1024-bit RSA keys. Not all 1024-bit RSA keys are affected. For now it is reasonable to assume the most widely affected systems will be HTTPS Web servers. The research indicates that only small subsets of RSA keys were generated insecurely. While the origin of each affected RSA key is not yet known, there are strong indicators that the keys were created on embedded systems, such as routers and firewalls.

What Systems Are NOT Affected?
All indicators from the current research (Q1–2012) suggest that only SSL certificates are affected. Other systems, such as PGP keys, RSA tokens, and other RSA-based keys, are either not affected or there is insufficient data to draw solid conclusions. It should be kept in mind that it is RSA key generation that is affected; the applications and systems that rely on RSA keys are not the culprit.

The Impact
If an adversary were able to calculate the secrets for an SSL certificate, he would be able to create a duplicate of that certificate. With a duplicate it would be possible to achieve these goals: decrypt any data that was encrypted using the compromised certificates, impersonate any system that used the certificate as a form of authentication, tamper with encrypted data in transit, or modify encrypted data at rest.

The Likelihood Of Successful Attacks
Practical real-world attacks are hard. This is because an adversary must not only exploit RSA key-generation weaknesses, but must also be in a position to intercept encrypted network traffic, steal encrypted data from a server, or somehow insert himself between two users in the middle of an SSL-encrypted conversation. As such, targets that are easiest to exploit will be internal network systems as opposed to external (Internet-facing) systems. This is because it is much easier for a malicious user to disrupt, redirect, or intercept traffic on a corporate LAN than it is on the Internet. A sufficiently knowledgeable person with access to a compromised key and an internal corporate network connection may be able to exploit the RSA weaknesses to intercept, decrypt, and modify SSL-encrypted network data. The likelihood of an adversary performing the same attack against, for example, an Internet-facing HTTPS server is far less likely. Such an attack is hampered by the difficulty of intercepting network communications between a Web server and its users. It should be noted, however, that certain nation states and ISPs do have the capability to monitor and intercept the connection between a user and a service.

Next Steps
It is almost inevitable that tools will be released to exploit this situation. For example, weaknesses in Windows password-hashing algorithms led to the release of L0phtcrack; similarly, weaknesses in Wi-Fi WEP encryption led to the release of AirCrack, NetStumbler, and many other cracking tools. It would be prudent to anticipate such tools and attacks, and prepare systems in advance. The following steps are highly recommended:

  • Establish a plan and policy to regularly review critical crypto systems, specifically for following key management best practices. See the Transport Layer Protection Cheat Sheet on OWASP for details on best practices.

  • Perform scans against all known corporate SSL-encrypted assets, such as HTTPS Web servers, email servers, SSL VPNs, etc. The scans should check for the presence of 1024-bit RSA certificates. See SSLScan for more technical details on how to perform such analysis.

  • Revoke certificates affected by the 1024-bit RSA vulnerability and those that do not follow NIST standards for recommended key length. The private key used to generate the cipher key must be sufficiently strong for the anticipated lifetime of the private key and corresponding certificate. The current best practice is to select a key size of at least 2048. Keys of length 1024 are considered obsolete as of the beginning of 2010.

  • Regenerate all such certificates with sufficiently strong keys and deploy them to the affected servers.

Additional Resources
For a more detailed but very accessible analysis of the issue, we strongly recommend taking a look at Dan Kaminsky's write-up on the topic, "Primal Fear: Demuddling The Broken Moduli Bug." Kudos to Dan for doing a fantastic job of explaining the issue so well.

Vincent Liu, CISSP, is a Managing Partner at Stach & Liu, a security consulting firm providing IT security services to the Fortune 1000 and global financial institutions, as well as U.S. and foreign governments. He has coauthored several books including Hacking Exposed Wireless, 1st and 2nd editions, Hacking Exposed Web Applications, 3rd edition, and the upcoming Web Application Security, A Beginner's Guide. He can be reached on Twitter @vinnieliu. Vincent Liu (CISSP) is a Partner at Bishop Fox, a cyber security consulting firm providing services to the Fortune 500, global financial institutions, and high-tech startups. In this role, he oversees firm management, client matters, and strategy consulting. Vincent is a ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Commentary
Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
Edge-DRsplash-10-edge-articles
7 Powerful Cybersecurity Skills the Energy Sector Needs Most
Pam Baker, Contributing Writer,  6/22/2021
News
Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-32823
PUBLISHED: 2021-06-24
In the bindata RubyGem before version 2.4.10 there is a potential denial-of-service vulnerability. In affected versions it is very slow for certain classes in BinData to be created. For example BinData::Bit100000, BinData::Bit100001, BinData::Bit100002, BinData::Bit<N>. In combination with &lt...
CVE-2021-35041
PUBLISHED: 2021-06-24
The blockchain node in FISCO-BCOS V2.7.2 may have a bug when dealing with unformatted packet and lead to a crash. A malicious node can send a packet continuously. The packet is in an incorrect format and cannot be decoded by the node correctly. As a result, the node may consume the memory sustainabl...
CVE-2021-2322
PUBLISHED: 2021-06-23
Vulnerability in OpenGrok (component: Web App). Versions that are affected are 1.6.7 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via HTTPS to compromise OpenGrok. Successful attacks of this vulnerability can result in takeover of OpenGrok. CVSS 3.1 ...
CVE-2021-20019
PUBLISHED: 2021-06-23
A vulnerability in SonicOS where the HTTP server response leaks partial memory by sending a crafted HTTP request, this can potentially lead to an internal sensitive data disclosure vulnerability.
CVE-2021-21809
PUBLISHED: 2021-06-23
A command execution vulnerability exists in the default legacy spellchecker plugin in Moodle 3.10. A specially crafted series of HTTP requests can lead to command execution. An attacker must have administrator privileges to exploit this vulnerabilities.