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.
Cryptographic Vulnerabilities, News & Research
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.
In previous posts we looked at the security of the JKS and JCEKS Java Keystores implemented in the default (Oracle) JCE/JCA crypto provider. Here we’ll take a look at what’s offered by BouncyCastle, a widely-used open-source alternative.
Like the Oracle provider, keystores in BC rely on password-based encryption for confidentiality, i.e. deriving an encryption key from a password and then using that to encrypt the keys for writing to a file. BC offers three keystore types: BKS (bouncy castle keystore), UBER (nothing to do with taxis), and a PKCS#12 compatible keystore for interoperability.
Here we summarize the encryption used in each keystore to protect private key values. Behaviour on certificates can be different, and some keystores also allow symmetric keys to be stored – more on this later. In addition to private key value encryption, UBER has an extra layer of encryption for the whole keystore, which means that all metadata around the keys and certificates will also be encrypted. Below the table, we’ll step through the analysis.
|UBER (keys)||PBEWithSHAAnd3-KeyTripleDES-CBC||Random(1024, 2047)||160b||168b|
|UBER (store)||PBEWithSHAAndTwofish-CBC||Random(1024, 2047)||160b||256b|
BKS uses triple-DES encryption, which is deprecated for most applications but not considered desperately insecure (it can still be used, for example, in PCI DSS environments). One reason for deprecation is that it has a 64-bit blocksize, which is not enough for high-volume applications. Here we’re only encrypting a private key so this shouldn’t matter. The key is derived following the method from PKCS#12v1.0, which is also deprecated (PKCS#12v1.1, from July 2014 recommends using only PBKDF2, which is defined in PKCS#5v2.1). The PBKDFs use a random salt, as we would expect. Note that the number of iterations of the PBKDF is a random value between 1024 and 2047. This is an unusual construct, and it’s hard to say how this offers extra security since the number of iterations also is recorded in clear in the file, along with the salt. In any case, 2047 is considered quite a low number of iterations for modern applications.
UBER uses encryption similar to BKS for the private key values. It uses the same PBKDF and iteration count, but a different cipher (Twofish), for encrypting the whole keystore. Twofish was an unchosen finalist for the AES competition and so received a fair amount of cryptanalytic attention in the late 90’s. No significant weaknesses have been found.
BCPKCS12 also uses the old PBKDF (from PKCS#12v1.0), and a fixed 1024 iterations, which is a low value by modern standards. This choice probably comes from the fact that PKCS#12v1.0 gives 1024 iterations as the value in its example of the ASN.1 syntax (the recently revised PKCS#12v1.1 says only that it should be “1024 or more”).
Apart from protecting the confidentiality of the value of private keys, keystores can also protect integrity, i.e. you can make a password-based MAC of the whole keystore and then check it hasn’t been tampered with.
To do this, BKS and the PKCS#12 keystore create an HMAC using a key derived using the same PKCS#5v1.0 PBKDF as used for encryption. However UBER does something a little strange. Since it has already used the second keystore-wide password to encrypt the whole keystore, it simply calculates a SHA-1 hash of the keystore before encryption and uses this to check integrity after decryption has happened. This MAC-then-encrypt approach is generally considered a bad idea, since it can lead to attacks if, for example, there is a perceptible difference in behaviour (an error message, or execution time) between a decryption that fails because the padding is invalid, or a decryption that fails because the SHA-1 hash is invalid (a so-called padding oracle attack).
Update March 2018
Note that early versions of BouncyCastle BKS (before v1.47) had a 20 bit HMAC key meaning that a functioning integrity password could be easily guessed. This issue only affects the integrity MAC, and would not help in obtaining the keys use to protect private keys.
Future Keystores – BC FIPS
Currently in beta, the FIPS version of Bouncy Castle will include a new keystore, BCFKS, which uses PBKDF2 with HMAC SHA512 for password based key derivation and AES CCM for encryption. This sounds promising.
Traps for the unwary
There are few more messy details around BC and Oracle Java keystores, in particular around their encryption of public-key certificates and their behaviour when given null or empty string passwords. We cover that and more in our Java Crypto Whitepaper
In 2014 I wrote a piece for this blog on RSA PKCS#1v1.5 encryption and why we need to get rid of it. At the time, the list of algorithms and padding modes to be included in the W3C WebCrypto API was under discussion, and I wanted to argue for the exclusion of this mode from the API. In the end it was indeed left out.
However, there is a RSA PKCS#1v1.5 signature mode that is present in almost every widely-used crypto API. This mode has long been regarded sniffily by cryptographers, particularly since Daniel Bleichenbacher demonstrated a signature forgery attack at the CRYPTO rump session in 2006. This attack only works in particular circumstances: the key needs to have a low public exponent (i.e. 3) and the verification code has to be lax in the way it parses the complete signature, ignoring some incorrect padding to the right of the hash that gives the attacker the room to get away with some garbage bytes necessary to make the forgery.
Just like for Bleichenbacher’s ’98 attack on PKCS#1v1.5 encryption, reaction at the time was limited. There was no assignment of this mode to legacy-only use like there was for the encryption mode. This can be understood because at first sight, it seems like the conditions for the attack (the parser bug and the low-exponent keys) are unlikely to be found in practice.
However, since then, other variants of the parsing bug have been found. There’s a version from GNU TLS where the garbage bytes can be put in the parameters field of the ASN.1 structure giving the hash to use. In 2014, Antoine Delignat-Lavaud found a bug in Mozilla’s crypto library (NSS) that allowed garbage bytes to be hidden in the length field of the same structure.
In 2015, Filippo Valsorda discovered another variant in the python crypto library, this time allowing the garbage to be hidden in the 0xFF padding string (it seems this bug was also present in NSS). Filippo just ran a training on this attack at DEF CON, which will no doubt result in more instances being discovered in the coming months.
You can try to avoid parsing bugs by instead recreating what the signature should look like, and the comparing it to the one you received, but it seems nobody is doing this. Even though public keys with exponent 3 represent only 0.37% of X.509 certificates found in the wild (Table 1), isn’t it time we moved to a more robust signature mode?
Cryptosense Analyzer is now available in SaaS edition. Get a free trial.
In collaboration with the University of Venice Ca’ Foscari, we’ve been researching the protocols smartcards and authentication tokens use to communicate underneath the PKCS#11 API that’s exposed to applications. These protocols tend to be quite different for each device.
Results include sensitive cryptographic keys in the clear, PINs in the clear or easily reversible, stateless protocols that allow easy injection of commands and restrictions on key use enforced at the PKCS#11 (driver) level that are trivially bypassed at the APDU level.
Our findings will be presented in September at the 19th International Symposium on Research in Attacks, Intrusions and Defences – RAID 2016.
The research was carried out some time ago, and manufacturers concerned were all informed well in advance of disclosure. We’ll continue to investigate more of the devices our customers use.
We’re delighted to announce we’re the winners of this year’s “Prix De l’Innovation”, a security start-up prize awarded by Le Cercle, an association of French CISOs and consultants.
— Le Cercle (@Le_Cercle) June 24, 2016
We were shortlisted on the basis our our written submission, then took part in the pitch competition last Thursday evening in Paris. The prize is a booth at the annual “Assises de la Sécurité” show in Monaco in October, France’s largest security trade show and conference.
If you’re coming too, let us know, we would be delighted to give you a personal demo of our tools for finding and fixing weaknesses in cryptography use by applications and infrastructure.
In the standard API for HSMs and other cryptographic hardware, PKCS#11, key-wrapping refers to the process of encrypting one key stored in hardware with another in order to send the first key somewhere else in a secure way. This operation has been the source of a whole series of security vulnerabilities, in particular because the encryption modes are often vulnerable to padding oracle attacks.
In PKCS#11 v2.40, new authenticated encryption modes were introduced. Properly implemented, these modes are secure against padding oracle attacks. This is good news, but unfortunately AES-GCM and AES-CCM, the two new modes, introduce a new security problem.
The two-time pad
Both AES-GCM and AES-CCM are what is known as counter modes. That means the encryption part of their operation works by using the AES block cipher to calculate a keystream that will be XORed against the plaintext. Roughly speaking, the first block of the keystream is obtained by encrypting an initialisation vector (IV). The second block of the stream is obtained by increasing the IV by 1 and encrypting again. This is repeated until the keystream is as long as the plaintext.
Such modes have several advantages: the security proof for the confidentiality part is quite direct, and encryption and decryption can be parallelized easily. However, in PKCS#11, the IV is supplied as a parameter by the calling application. That means there is nothing to stop a compromised application controlled by an attacker from using the same IV twice.
This opens up a whole series of attacks. For example, suppose the attacker wants to obtain the value of a wrapped secret key s. Suppose the ciphertext c containing the encryption of s was obtained at a certain HSM by calling the PKCS#11 command C_WrapKey using either CCM or GCM mode, and suppose the attacker obtains access to the HSM. The attack works even if we assume k is safely stored inside the HSM and properly protected by its permission attributes, i.e. not extractable, and the key s is no longer even present on this HSM.
To obtain s, the attacker can first store a known key in the HSM, using the C_CreateObject command that imports a cleartext value as a key. For simplicity, suppose he imports a string of 0s as the key. Then he asks the HSM to encrypt the string of 0s with the key k using C_WrapKey, and gives the same IV as was used in the ciphertext c, obtaining c’. Finally he XORs c and c’ to obtain the plaintext value of s.
Why does this work? Because if ks is the keystream generated by the IV and the key k, then c XOR c’ is equal to ks XOR s XOR ks XOR 0. If you XOR any x with 0 you get x, and if you XOR any x with itself you get 0. So ks XOR s XOR ks XOR 0 = s XOR ks XOR ks = s.
This isn’t the first time we’ve seen this problem: the YubiHSM has exactly the same issue.
Even if the attacker can’t use C_CreateObject (for example if it is disabled on this HSM), there are many other ways to import a known key onto an HSM, including taking advantage of padding oracle attacks on insecure unwrap modes, or incorrectly set permissions that allow encryption as well as unwrapping.
The solution is to force the HSM itself to generate the IVs for wrapping keys under CCM or GCM, and to make sure the wrapping keys can’t be used for any other functions using the existing permission attributes.
Here at Cryptosense we’re working in a proposal for key wrapping for PKCS#11 v3.0 that will include this and other features to allows keys to be wrapped along with their attributes, to avoid another family of attacks where keys are unwrapped with different permissions from when they were wrapped. We’ll keep you updated with news of that here, though you can also follow discussions on the PKCS#11 TC site (and the mailing list is public).
Meanwhile, to find out more about PKCS#11 security, start with our free whitepaper.