When Lazy Administrators Cause A Logjam

When Lazy Administrators Cause A Logjam

A demo of the methods in this article are here.

I had a debate with an administrator the other day. “Are you safe from Logjam?”, “Yes. I patched”, “But how do you know it is okay?”, “Well. I scanned it”, “But what if the scanner is not working right?”.

Overall, the administrator hadn’t understood what the threat was, and just patched without really knowing what had actually been fixed. With Logjam, the problem lies in the prime number settings of OpenSSL. So I’ll provide a basic overview of Logjam and what the core problem was.

Logjam came from the paper “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice” [here] and where it was discovered that many Web sites on the Internet used the same prime numbers for Diffie-Hellman Key Exchange. This allows for pre-computed keys to be generated for the values that Bob and Alice will use for their random numbers. It is thought that the NSA, for example, had created large tables of these values, and which basically just did a look-up to discover the shared key.

Within Diffie-Hellman key exchange, Bob generates an x value and calculates A:

A=Gˣ (mod p)

Alice does the same and generates y, and the value of B:

B=Gʸ (mod p)

Next Bob receives Alice’s value (B) and raises it to x, and then computes the shared key:

Key=Bˣ (mod p)

where x is Bob’s random number, y is Alice’s random number. The value of p is the prime number, and if it is a well-known prime number, the possible values of the keys can be pre-computed.

In the following we will generated the shared key for values of 100 and 101 and for a G value of 3. In this we calculate gˣ (mod p) and where g is 3 and the prime number is d8d8f37c39bf863fd60e3e300680a3030c6e4c3757d08f70e6aa871033L.

The research team thus found that many systems which default prime numbers which for the TLS Diffie-Hellman key exchange. If these are used, then an adversary can compile a list of keys for a range of random values (x and y), and then match these. In the following we use a prime number of 0x9fdb8b8a00454…7d08f70e6aa871033L:

Key: 0x9fdb8b8a004544f0045f1737d0ba2e0b274cdf1a9f588218fb435316a16e374171fd19d8d8f37c39bf863fd60e3e300680a3030c6e4c3757d08f70e6aa871033L

x	y		Shared Key
100 	100 	141712882825921845644704769632745622601375629836052341385366535757747023401534528023731408699709878650488921680095879119479989665027456617305151270652192
100 	101 	529609334064784835402608286401745579115015095123148250690161577251605425522484976671903284992718508527810347558185302624211217331517851802658463838404699
101 	100 	529609334064784835402608286401745579115015095123148250690161577251605425522484976671903284992718508527810347558185302624211217331517851802658463838404699
101 	101 	914874672215774533837192665152716001408958112991636900393715396216020576719815419003509111900658636212968102556916266364035044219645999393564279754348622

Examples of weak keys are:

Apache: 0x9FDB8B8A004544F0045F1737D0BA2E0B274CDF1A9F588218FB435316A16E374171FD19D8D8F37C39BF863FD60E3E300680A3030C6E4C3757D08F70E6AA871033

mod_ssl: 0xD4BCD52406F69B35994B88DE5DB89682C8157F62D8F33633EE5772F11F05AB22D6B5145B9F241E5ACC31FF090A4BC71148976F76795094E71E7903529F5A824B
0xFCA682CE8E12CABA26EFCCF7110E526DB078B05EDECBCD1EB4A208F3AE1617AE01F35B91A47E6DF63413C5E12ED0899BCD132ACD50D99151BDC43EE737592E17

Conclusions

A weak administrator presses a button and reads the result. Next they patch and check the version number of the patch, and re-scan. An excellent administrator understands the weakness and then investigates it. They then evaluate the patch, and continue to monitor for weaknesses.