<story><title>A Systematic Analysis of the Juniper Dual EC Incident [pdf]</title><url>https://www.cs.uic.edu/~s/papers/juniper2016/juniper2016.pdf</url></story><parent_chain></parent_chain><comment><author>tetha</author><text>I gotta say, the combine subtlety of this vulnerability is impressive:&lt;p&gt;- There is a config flag, which may or may not have a valid use. I&amp;#x27;m not a networker or security expert, I cannot tell.&lt;p&gt;- That config flag in turn causes two random number generators to interact via a global variable to cause 
a small off-by-one error. Furthermore, both code pieces don&amp;#x27;t look strinkingly wrong, from a cursory glance by someone not familiar with the code base. I&amp;#x27;ve seen worse code being approved in a review.&lt;p&gt;- This boundary error leaks internal state of the inner EC-based PRNG, which allows an attacker with prior knowledge, sufficient computing capacity and solid knowledge of math and crypto to get the state of the inner RNG&lt;p&gt;- This information can be exfiltrated through both a complex queue&amp;#x2F;pool-system and a complex handshaking protocol. Maybe I&amp;#x27;m more familiar with PRNGs, but the IKE part started to go over my head.&lt;p&gt;I&amp;#x27;ve always acknowledged the idea of very subtle, deniable and complex vulnerability introduction, both through cryptographic conditions, subtle code and language issues and all of that. Software is hard and complex.&lt;p&gt;But this is an example that&amp;#x27;s both scary, very complex and close enough to comprehension to be very, very scary without being vague. Thank you for the analysis and the write-up.</text></comment>
<story><title>A Systematic Analysis of the Juniper Dual EC Incident [pdf]</title><url>https://www.cs.uic.edu/~s/papers/juniper2016/juniper2016.pdf</url></story><parent_chain></parent_chain><comment><author>okket</author><text>Abstract: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;eprint.iacr.org&amp;#x2F;2016&amp;#x2F;376&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;eprint.iacr.org&amp;#x2F;2016&amp;#x2F;376&lt;/a&gt;&lt;p&gt;In December 2015, Juniper Networks announced that unknown attackers had added unauthorized code to ScreenOS, the operating system for their NetScreen VPN routers. This code created two vulnerabilities: an authentication bypass that enabled remote administrative access, and a second vulnerability that allowed passive decryption of VPN traffic. Reverse engineering of ScreenOS binaries revealed that the first of these vulnerabilities was a conventional back door in the SSH password checker. The second is far more intriguing: a change to the Q parameter used by the Dual EC pseudorandom number generator. It is widely known that Dual EC has the unfortunate property that an attacker with the ability to choose Q can, from a small sample of the generator&amp;#x27;s output, predict all future outputs. In a 2013 public statement, Juniper noted the use of Dual EC but claimed that ScreenOS included countermeasures that neutralized this form of attack.&lt;p&gt;In this work, we report the results of a thorough independent analysis of the ScreenOS randomness subsystem, as well as its interaction with the IKE VPN key establishment protocol. Due to apparent flaws in the code, Juniper&amp;#x27;s countermeasures against a Dual EC attack are never executed. Moreover, by comparing sequential versions of ScreenOS, we identify a cluster of additional changes that were introduced concurrently with the inclusion of Dual EC in a single 2008 release. Taken as a whole, these changes render the ScreenOS system vulnerable to passive exploitation by an attacker who selects Q. We demonstrate this by installing our own parameters, and showing that it is possible to passively decrypt a single IKE handshake and its associated VPN traffic in isolation without observing any other network traffic.</text></comment>