Cryptographic Vulnerabilities, News & Research
Google recently announced a project to produce tests for cryptographic libraries to detect common weaknesses. Piloted by star cryptographers Daniel Bleichenbacher and Thai Duong, this is an exciting development for us at Cryptosense, and not just because they cite our CRYPTO ’12 paper in their RSA tests. It’s a validation of the prevalence and seriousness of security flaws around crypto use, and the need to detect them, which is exactly our mission at Cryptosense.
As of today we support user accounts on our crypto protocol scanning and analysis site discovery.cryptosense.com.
It’s free to sign up, and once you sign in, you can:
- manage a list of servers for which you want regular scans;
- see a summary of the latest results;
- get remediation help in the browser;
- get on-demand rescans;
- select whether you want regular email reports.
Features in the pipeline include results in JSON format for integration with other tools. What else would you like to see?
Unchanged default access passwords are a pervasive problem in computer security. A recent high-profile example is the Mirai botnet that spread by using 61 common default login credentials.
In programs using crypto, passwords are often used to generate cryptographic keys. For example, they are used to generate the “key encrypting keys” that are used to protect private keys stored in keystores, or the master key used to protect persistent application data written to storage.
Unfortunately, these passwords are susceptible to the same problem: they have de facto “default values”, often coming from HOWTOs for setup. For example, the password “changeit” figures in several guides for configuring TLS private keys for Java web applications. We trace these passwords using our Analyzer tool, and we encounter a substantial number of “changeit”s in the wild.
Sometimes default crypto credentials are even easier to exploit. In the recent Primefaces bug, many applications were using the default password (“primefaces”) to generate the encryption key. This would lead to secret values encoded in encrypted URLs being leaked, and unlike access passwords, there would be no log to show that attack was being made.
Application frameworks can sometimes make it unnecessarily complicated to change default passwords, but still there’s little point encrypting if the password is unchanged. Our Analyzer tool checks crypto passwords against a dictionary of known defaults and common weak passwords.
Back in October we published new results from our online RSA keytester. Despite the potency of this method of factoring (calculating the GCD of a large sample of keys) being well-known since at least 2012, we were still able to factor keys of almost 50 000 Internet-facing HTTPS servers.
This month a new article by Marcella Hastings, Joshua Fried and Nadia Heninger of the University of Pennsylvania appeared at the Internet Measurement Conference. It traces the evolution of weak RSA keys on Internet-facing devices since 2010, using the same factorisation method.
The paper is worth reading in detail, but here are two key findings:
- Despite all the publicity around the original results, the raw number of vulnerable devices is pretty much the same as back in 2012.
- Most of the vulnerable keys are new keys, some from new products released as recently as 2015.
This is consistent with our own results, though the researchers were able to go much further in tracking down some of the vendors of the affected products, leading to at least one CVE form Huawei. But several vendors did not respond, and the bottom line is that not many devices are getting patched (the biggest improvement came in 2014 when a bunch of vulnerable devices were taken offline as a reaction the the Heartbleed vulnerability).
This is serious because the flaw allows an attacker to passively decrypt TLS traffic (since most of the devices only support RSA TLS key exchange, using the same broken RSA key as the certificate). The researchers explain the consequences of this:
Among the vulnerable devices that we examined, HTTPS is used primarily to serve remote management interfaces. Many of the vulnerable firewalls also use TLS to encrypt SSL VPN connections. An attacker who is able to decrypt connections to one of these devices may obtain administrative credentials for the device or view remote user traffic to internal network resources.
Testing for weak keys
You can submit a key to our free GCD engine for testing for common factors with our database of 23 million keys.
To find keys on Internet-facing services, you can use our discovery tool and submit the keys directly. For large scale tests or internal scanning, we offer a paid service – get in touch for more details.
One task our users often want to perform with application crypto audit reports produced by Cryptosense Analyzer is to export certain results in detail for adding to an issue tracker. We’ve now made this easier by adding stars to instances of our analysis rules. Clicking on a star marks an instance for export. You can then export all the starred instances along with full stacktrace information indicating where in the code the issue comes from.
Our Java Crypto Analyzer tool works by tracing calls to the cryptographic library from all parts of the application under test, including libraries, framework components and dependencies.
We recently tested the Analyzer on a large web application which uses a whole host of different libraries including PrimeFaces, a popular open-source library for graphics and UI elements in web applications. One result in particular came from stacktraces leading to that library. It seemed that PrimeFaces was encrypting strings in URLs using a custom scheme based around a password that is set in the configuration file.
The Analyzer flagged up multiple problems:
- Fixed salt in password-based key derivation
- Low iteration count (19) in password-based key derivation
- Weak key derivation algorithm: PBEWithMD5
- Weak encryption algorithm: DES
- Short symmetric key (56 bit)
- Unauthenticated encryption with PKCS5 padding (possible padding oracle)
The upshot of this is an encryption scheme that could be attacked in multiple ways. The default password (“primefaces”) is likely unchanged in many installations. Even if changed, with the weak password-based key derivation function and fixed salt, a dictionary attack could be mounted. The padding oracle could reveal individual plaintexts. Finally, if all else fails, since the key is fixed for an individual server, it could even be worth brute-force guessing the 56 bit DES key (specialist FPGA hardware can do this in a few hours).
What would be the consequences of breaking this encryption in a graphics library? While following up on this issue, we discovered that it was partially fixed in February 2016 after being reported by Minded Security. They used the PadBuster tool from our friends at Gotham Digital Science to exploit the padding oracle and break the URL encryption. This allowed them to submit fake URLs which, it turns out, are interpreted as Expression Language by the server, leading potentially to remote code execution. PrimeFaces was patched to switch the encrypted URLs for pseudo-random IDs at the price of maintaining a little more state on the server.
However, our Analyzer results showed the weak encryption scheme was still being used. Its second usage is to protect the values of QR codes and barcodes encoded in URLs. We reported this to PrimeTek, and they promptly fixed it in version 6.0.6.
We would advise anyone using to PrimeFaces to ensure they have upgraded at least to version 5.2.21, 5.3.8 or 6.0 (which patches the remote code execution flaw), and preferably to version 6.0.6 (which fixes the QR code and barcode protection issue by removing the weak encryption completely).
Find crypto bugs
We’ll be running a new training here at our offices in central Paris in December covering crypto flaws in applications.
Mention crypto flaws to many people and they will think of deprecated algorithms that pose a marginal risk, but crypto bugs in applications can lead directly to things like remote code execution, compromise of credentials and loss of data. We’ll show how this happens and how to avoid it. The training will include some examples of real flaws we’ve found recently using our Analyzer software.
Go to the event page to find the syllabus and how to sign up.
PrimeKey Solutions develops and supports the most downloaded open source enterprise public-key infrastructure (PKI) software available, EJBCA. You can find out why they use Cryptosense Analyzer for Java in a case study we’re releasing today.
We already use a variety of tools to ensure software quality, but we see security as an area of continuous improvement, and Cryptosense tools give us a cryptography-focused view that other tools can’t provide. A strong statement in itself, given the fact that PrimeKey’s teams of engineers work day in and day out with cryptography.
Tomas Gustavsson, CTO PrimeKey
PrimeKey Case Study
Over the past few months, we’ve been taking a look at the security of applications using the Java crypto API or Java Cryptographic Architecture (JCA), and examining the most commonly-used providers, Oracle JCE and BouncyCastle. Some of the results have been published in previous blog posts. We’ve decided to summarise all our findings in a free whitepaper.
From the intro:
This whitepaper is intended for developers who use, or are considering using, the Java crypto API, and for application security testers who review crypto security. It is not intended to be an introduction to cryptography, but rather a concise guide for readers familiar with crypto basics. We will tour the Java crypto API and explain common mistakes that cause security problems and crop up frequently in real applications.
We hope you find it useful – feedback is welcome. We’ll be updating the document in the future to cover some single sign-on protocol implementations and Java application framework crypto that we’ve been looking at recently, but suggestions for other topics are welcome.