With the leak of exploits developed by The Equation Group, the long-secret, NSA-adjacent super-elite hacking squad — published by The Shadow Brokers, who have some extremely heterodox theories about auction design — it's now possible to audit the source code of some of the NSA's crown-jewel cyberweapons.
Enter Stephen Checkoway from the Computer Science department at the University of Illinois at Chicago (previously, considered to be one of the leaders of contemporary security research. He's taken a close look at BANANAGLEE BG2100's sourcecode for creating encryption keys, one of the foundational elements of security design, and found that The Equation Group, for all its fearsome reputation, writes some pretty rotten code.
Checkoway calls the code "sloppy and buggy": the key generator goes through an elaborate dance to generate a random number, calling various randomizers, slicing and dicing their output and feeding them back. But as Checkoway shows, this is counterproductive: it reduces the number of possible 128-bit keys from 2^128 to 2^64 — a titanic reduction in the keyspace.
Checkoway also audited BANANAGLEE BG2100's "background redirector," which is seemingly designed "to make it look like the attack host is sending data to and receiving data from the second host while actually communicating with the third." A quick analysis revealed that "both the code and the crypto are bad," "very bad."
The takeaway is as old as the Enlightenment: without external scrutiny and peer-review, even talented people make dumb mistakes. The hoarding and weaponizing of vulnerabilities by security services is predicated on the idea that they are so good that they'll discover things no one else can, and protect them flawlessly. But the Equation Group not only left its toys lying around for its enemies to find: the quality of their construction shows that this isn't the only mistake they've made.
Starting with the magic number field of the header, the packet is encrypted using RC6 in output feedback mode. To compute the IV, a SHA-1 hash of the plain text (starting with the magic field of the header) is computed and the 8 most significant bytes form the least significant 8 bytes of the 16-byte IV. (The most significant bytes of the IV are set to 0). It’s important to note that the random value identifying the fragments is not hashed into the IV.I’m no cryptographer, but this seems crazy. An IV should never be reused for a given key. And yet identical messages will produce identical IVs, even if the keys are different. Perhaps there’s something that guarantees a message will never be sent twice, but if I were designing this, I sure wouldn’t rely on that property.
Update: Sean Devlin pointed out that leaking bits of the hash of the plain text is also a pretty bad idea.
Equation Group Initial Impressions
[Stephen Checkoway/University of Illinois at Chicago]
(via /.)
(Image: Radsec, CC-BY)
