Cryptographers and Security Researchers have a penchant for coming up with colorful bacronyms and names which describe, in brief, the vulnerability or exposure. Some are them are BEAST, CRIME, ShellShock, SLOTH, POODLE, Lucky 13, Sweet32, Smurf, Petya, BlackNurse, FREAK, DROWN, BREACH, LOGJAM, HeartBleed, CloudBleed, TicketBleed, Fireball, CLOAK and DAGGER, WANNACRY, SambaCry, HIDDEN COBRA, BroadPwn, Blueborne, ROCA, KRACK, ROBOT etc.
I composed a poem that captures the scary world we live in.
The online world, ’tis a scary place indeed
what with HEARTBLEED, CLOUDBLEED and TICKETBLEED
where POODLE and SLOTH are truly menacing BEASTs
and SWEET32 and KRACK are a hacker’s feast
where a HIDDEN COBRA can give a DOSe of venom
CRIMEs galore, one can’t fathom
with all these BREACHes, your security went awry
so ShellShocked that you just WANNACRY
CLOAK and DAGGER played by every hacker
FREAKing you out with the return of the Bleichenbacher
2017 has been an eventful year for Security. In this blog post, I will take at a look at the various vulnerabilities, threats, exposures that were reported in 2017.
In 2017, the list of serious vulnerabilities and breaches include WANNACRY, ROCA, ROBOT, Equifax breach, KRACK, Fireball, CLOAK and DAGGER, Blueborne, BroadPwn, SambaCry, HIDDEN COBRA etc.
I describe in detail a few of them and mention the lessons we can learn from them.
WannaCry: March, April and May
Lesson to be learned: Promptly update software and apply patches
This was a painful and expensive lesson for people and organizations who did not take seriously the task of keeping their systems patched and current, even when the vendor released a critical patch. In April 2017, the hacker group Shadow Brokers leaked hacking exploits used by NSA. One of the exploits, called EternalBlue, was for a vulnerability in the Windows SMB protocol. A month earlier, in March, Microsoft released Security Bulletin MS17-010 which updated the Windows implementation of the SMB protocol to prevent infection via EternalBlue. In May, a month after the exploits were leaked, the WannaCry ransomware affected quarter of a million unpatched systems in more than 150 countries — important files were encrypted and rendered unusable unless a ransom was paid to get the decryption Key.
ROCA — Return of Coppersmith’s Attack
Lesson to be learned: No Security by Obscurity (No secret algorithms)
In RSA Cryptography, a pair of very large prime numbers is required to generate a public/private key pair.
Generating prime numbers requires a lot of computation and this is an issue on memory and CPU constrained devices like smart cards, TPMs (trusted platform module), HSM (Hardware Security Modules). There is an algorithm, aptly called “Fast Prime”, typically implemented in software, that accelerates the typically slow process of generating primes.
Infineon developed a RSA Library crypto module using this “Fast Prime” algorithm and this has been in use in millions of smart cards issued by governments, TPMs, HSMs, Yubikeys etc. for the past 5 years. The smart card chip plus firmware and the TPM module have Common Criteria EAL 5+ and EAL 4+ certifications, respectively.
Unfortunately, though the design and implementation were thoroughly analyzed and certified by experts, the prime-generation algorithm used by Infineon was never subjected to public review. The researchers Matús Nemec, Marek Sýs, Petr Svenda, Dusan Klinec and Vashek Matyas from Masaryk University found an algorithmic flaw in the construction of primes for RSA key generation by just analyzing the RSA keys generated and exported from the Infineon’s cards and tokens. This flaw, which they disclosed responsibly, makes it easy (just 100 CPU-years) to compute the RSA private key given the 2048 bit RSA public key.
In their paper the authors conclude that this failure was encouraged by the certification process which rewards security by obscurity. They caution:
Our work highlights the dangers of keeping the design secret and the implementation closed-source, even if both are thoroughly analyzed and certified by experts.
They also say
The certification process counter-intuitively “rewards” the secrecy of design by additional certification “points” when an implementation is difficult for potential attackers to obtain – thus favoring security by obscurity. Relevant certification bodies might want to reconsider such an approach in favor of open implementations and specifications. Secrecy may increase the dificulty of spotting a flaw (above the capability of some attackers) but may also increase the impacts of the flaw due to the later discovery thereof.”
ROBOT — Return of the Bleichenbacher Oracle Threat
Lesson to be learned: Heed recommendations and stop using protocols known to be flawed
When implementing crypto algorithms, in many cases, it is important to perform certain operations in constant time — this is quite difficult to do correctly. If not done in constant time, this leaks information to a potential attacker. The attacker treats this information as a gift from the oracle and performs more queries to get more information.
In Symmetric Key Cryptography, POODLE and Lucky 13 are couple of examples where the vulnerabilities are caused by this leak of timing information.
In 1998, cryptographer Bleichenbacher found a similar timing leak in the RSA encryption standard PKCS #1 v1.5 (RFC 2313) — it was dubbed the million-message attack as it required a million chosen cipher text messages to get enough info from the oracle (for e.g. TLS server) to decrypt the message. It was not a practical attack. The same year PKCS #1 v2.0 was published (RFC 2437) which introduced the RSAEP-OAEP (Optimal Asymmetric Encryption Padding) encryption scheme — it was recommended that the old scheme not be used in any new implementations.
Predictably, these recommendations were not heeded and PKCS #1 v1.5 is still in widespread use. The designers of the TLS protocol, instead of using the recommended RSAEP-OAEP scheme, continued to use the flawed PKCS #1 v1.5 standard, presumably because a) the attacks were not deemed practical and b) countermeasures to thwart the attack (suggested by Bleichenbacher himself) were applied (TLS 1.2, RFC 5246, section 188.8.131.52). Unfortunately, it is too easy to implement these countermeasures incorrectly. Attacks only get better and cryptographers Hanno Böck, Juraj Somorovsky, and Craig Young proved in their paper titled Return Of Bleichenbacher’s Oracle Threat (ROBOT) that you don’t need a million messages — just 15000 will do.
Even prior to this revelation, there was already a very good reason for not using RSA encryption for key transport in TLS as it doesn’t provide perfect forward security. If that wasn’t enough to sound the death knell for RSA encryption, the ROBOT vulnerability does. Note that TLS 1.3 will not support RSA encryption. For all TLS protocols, Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) ciphers should be used, for which the ROBOT vulnerability is not applicable, and it also provides perfect forward security — loss of RSA private key will not allow attacker to decrypt past stored encrypted communications.
Lesson to be learned: Promptly update software and apply patches (Apache Struts)
The Equifax breach exposed the financial data, social security numbers, birth dates and addresses of 143 million Americans. This is theft of sensitive info on a staggering scale. All indications are that a nation-state was behind the hack.
The gory details of this breach can be found in many places including this article from Bloomberg.
Lesson to be learned: Be careful what you download and from where
Chinese browser-hijacking malware dubbed Fireball takes over web browsers and turns them into ad-revenue generating zombies — it has infected 250 million computers worldwide. Point of entry is via bundling where it is installed (without user’s consent) along with a program that the user downloads.
Researchers have said that Fireball has the ability to spy on victims, perform efficient malware dropping, and execute any malicious code in the infected machines, this creates a massive security flaw in targeted machines and networks.
First SHA1 collision:
Finally, though vulnerabilities in the SHA1 hashing algorithm were known since 2004, the first SHA1 collision was announced this year, which is a remarkable achievement. SHA1 is deprecated and X.509 certificates shouldn’t be signed using SHA1.
2018 is not going to be any different — in fact one can expect more of the same.