[Cryptography] Juniper & Dual_EC_DRBG

[Ray Dillinger]

On 12/21/2015 02:49 PM, Emilien Gaspar wrote:

> One thing that I still don't understand is their custom paramters for
> the curve used by Dual_EC and what was exactly modified by the attacker.
> 
> Do we have more explanations now ? :-)

Best explanations I've seen so far:

http://blog.cryptographyengineering.com/

https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor

https://rpw.sh/blog/2015/12/21/the-backdoored-backdoor/


We got several things going on with Juniper firewalls apparently.
I'll list the ones I know about now.


First, they used Dual_EC_DRBG.  They knew it was broken
and they used it anyway.

Second, we can tell they knew it was broken because they
"compensated" for the possible backdoor by substituting
their own constants for P and Q rather than using the
NIST (and NSA) supplied constants.  But they give
absolutely no indication of where the constants they used
came from nor whether the math behind the ones they used
also came from (or were shared with) eavesdroppers or
thieves.

Many people, including myself, think they just rekeyed
the lock on the NSA's backdoor so it would look different
if their customers checked.  Nobody knows whether they
gave the new backdoor key to the  NSA, or whether the
NSA just stole it from them.

Third, they also "protected" the universe from the possible
backdoor by using the Dual_EC_DRBG to generate keys for a
3DES-based PRNG implementation - after all, if an attacker
never gets to see ~30 consecutive bytes of raw D_EC_DRBG
output, they can't work out the RNG state even if they know
the backdoor.  The problem with this was that in the middle
of a routine prng_reseed(), a side effect set a variable named
prng_output_index to 32, and a for loop immediately following
the call to prng_reseed(), which is supposed to process the
buffer before it goes out, repeats only for as long as that
variable is less than 31.  IE, not at all.  Thus the buffer
that was supposed to be processed by their 3DES-based
generator is not in fact so processed, and what goes out
into the world is in fact 32 bytes of the raw D_EC_DRBG
output. Cue the fail whale.  This would be idiotic had
it not been done on purpose.

Fourth, somebody made "unauthorized" code changes in 2012,
changing the Juniper-selected mysterious P and Q constants
for a *different* pair of mysterious P and Q constants.
Apparently a crook found the backdoor and managed to insert
code to use his or her or their own constants turning that
backdoor to his or her or their own advantage.  There are
numerous conspiracy theories as to the identity of the
crook.  One of the most pervasive and credible would imply
that this particular crook draws a regular government
paycheck.  On the other hand this "unauthorized" change may
be another fig leaf for Juniper, much like the use of different
P and Q constants in the first place prevented them having to
admit they were using  parameters provided directly by the
NSA.  This "unauthorized" code is something they can point at
and claim wasn't their fault, but which wouldn't have altered
the functionality of their backdoor at all had they done it
themselves.

Fifth, when this relatively complex Dual_EC backdoor was
discovered, Juniper immediately published another CVE about
a *different* and much simpler backdoor which allows anybody
who knows or can guess a legitimate account name to log
into it, with magical admin privileges, using the password

<<< %s(un='%s') = %u

.  The code that does this is comparatively blatant; the
string above, although it looks like the sort of string you'd
find doing something else, is a direct argument to strcmp.
The timing of this announcement is sort of silly; it implies
either that the code was finally reviewed when the news
about the Dual_EC_DRBG based backdoor came out, or that both
backdoors had been long known and the second was announced
in order to confuse the issue and draw attention away from
the first.

Sixth, their patch for the Dual_EC_DRBG backdoor is to
replace the "unauthorized" P and Q constants with the same
completely unexplained P and Q constants that Juniper
selected for unknown reasons years ago.  So it's a return
to "authorized" code, but somehow it fails to inspire my
trust.

Seventh, the bug that has them using Dual_EC_DRBG in the
first place has not, so far, been fixed by their security
patch.

Eighth, the much more damning bug that has them allowing
32 bytes of raw output from that horrible beast to go
directly out on the line has also not, so far, been fixed
by their security patch.

....  and I think that about sums it up.

My only remaining question is where did the bribe money
go?

			Bear
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x6FF42EB5.asc
Type: application/pgp-keys
Size: 3100 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151222/f9b61f7a/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151222/f9b61f7a/attachment.sig>