Details have surfaced on a recently patched vulnerability in IBM’s SecureRandom pseudo-random number generator that could allow an attacker to predict its output.
Only the default SecureRandom implementation in the IBM Java Cryptography Extension (JCE) framework is vulnerable; IBM recommends that other RNGs in the JCE which don’t hold the same vulnerability could be used as a workaround. Cigital technical manager Amit Sethi reported the issue to IBM, which issued a patch last month.
Sethi said the problem is twofold: first the random number generator is seeded based on system time; and second the PRNG leaks half of its state in output, opening the door for a hacker to use a brute-force attack to determine the rest of the output. While this is likely a coding error in IBM’s proprietary implementation, the first issue is a lot less complicated because random number generators have been using servers’ internal clocks as a seed since the ’90s, Sethi said, and most developers of these tools know it’s a bad idea.
“It’s a well-known problem and people shouldn’t be doing it, however there are many implementations of a PRNG seeded based on time,” Sethi said. “It’s easier to do it that way. One value that people could use that keeps changing is the current time, but that value is predictable.”
An attacker could exploit these vulnerabilities remotely, needing only access to some outputs from the pseudo random number generator.
“The risks depend on how the SecureRandom implementation is being used,” Sethi said. “For example, if someone used a broken implementation to generate a SSL key pair, someone might be able predict what the private half of the key pair is. They would then be able to intercept SSL communication with that system. If that particular random number generator is used to generate session IDs in a web application, you might be able to predict session IDs and take over sessions.”
A brute-force attack against the system time is the most likely attack scenario, Sethi said, rather than brute-forcing the internal state.
“It comes down to figuring out when a machine was started up,” Sethi said. “That’s the time when the Java Virtual Machine first came up and generated random numbers. A lot of servers will give out that information and brute-force times around that.”
Sethi cautioned that some other Java Cryptographic Extension providers may also use IBM SecureRandom and the vulnerability could impact those providers.
“If you have the IBMJCE provider enabled in your application (even if you’re not using IBMSecureRandom explicitly), make sure that you apply the latest patch from IBM as soon as possible,” Sethi said.
Random number generators have been scrutinized, in particular since the Snowden leaks surfaced; the most high profile being the NSA-designed Dual EC DRBG used as the default in RSA Security’s BSAFE crypto libraries. Dual EC DRBG has since been removed from NIST’s guidance on random number generators and RSA recommended developers not use it in new applications for fear it has been backdoored by the intelligence agency.
The weaknesses in SecureRandom don’t seem so sinister.
“Generating random numbers is really difficult,” Sethi said. “Our computes are meant to be deterministic. To generate something truly random is difficult. Ultimately, we’re just approximating randomness.”
