It’s been a big week in cyberspace, with high profile crypto vulnerabilities KRACK (affecting WPA2) and ROCA (affecting RSA keys generated by Infineon hardware) hitting the news. Not only these mammoth bugs were released, but a new Adobe Flash 0-day exploit was observed in the wild being used to install the FinSpy commercial malware, and finally, the DDE feature in Microsoft Office was found to be open to abuse to gain code execution. There has been a great deal of discussion on Twitter and elsewhere on the comparative severity of the different vulnerabilities and, in particular, how the crypto bugs were not as severe as initially thought.



I think the vulnerabilities are all interesting in their own way and it’s helpful to delineate the differences between them. Both the crypto bugs represent an attack on trust, that is, they undermine the trust that people and organizations have in security systems to protect them. WPA2 is used almost exclusively to secure WiFi networks around the globe and the consequences of a loss of trust in the protocol are severe. Many organizations will launch vast programs to ensure that they’re protected, equipment will be ripped and replaced and countless meetings will be held on the topic. Even though the risk, as it stands today, is low (a limited Proof of Concept code available and Microsoft Windows is relatively unaffected). In addition, requiring physical access also raises the bar to a successful attack. The perception, however, is that WPA2 is imperiled.

 KRACK logo

Figure 1 – KRACK attack logo (

A similar story exists for the ROCA vulnerability. Infineon products are used by many different types of crypto equipment used for software signing, Trusted Platform Managers (TPM), identity documents, certain authentication tokens, etc.. For each RSA key of 1024 or 2048 bit length which has been generated by a piece of hardware, it must first be established if a vulnerable Infineon chip was used to generate the key, secondly, one of the various tools must be used to verify that the key is not easily factorized due to the key generation vulnerability. Due to the prevalence of the vulnerable chips and the diversity of the equipment that they are used in, this verification process will be costly both in terms of money and time.

ROKA impact 

Figure 2 – ROCA impact diagram


This week Kaspersky Lab released a report on the usage of an Adobe Flash 0-day against Middle Eastern targets by the Black Oasis APT actor. The detection of the exploit resulted in Adobe issuing an out-of-band critical patch and the Chrome browser blocking the usage of vulnerable versions of Flash. The exploit was part of an attack that delivered the FinSpy commercial malware to selected targets, most likely for espionage purposes. While this attack demonstrates once again the validity of Adobe’s decision to retire Flash in 2020 and the importance of removing Flash entirely or enforcing click-to-play and mandatory patching, now this attack has been burned, the immediate danger has passed for many users. Anti-virus definitions have been updated, patches issued and many, but obviously not all, endpoints are now protected against this attack. The real danger of such exploits is, once they’ve been found in the wild, they often find their way into Exploit Kits and other attack toolkits which are used to exploit unpatched systems.

Adobe security update for CVE 2017 11292 

Figure 3 – Adobe security update for CVE-2017-11292

The final big news story was the discovery by SensePost of a method of gaining remote code execution from Microsoft Office documents by abusing a legacy feature called DDE. In a method similar to VBA macros or OLE embedded objects in Microsoft Office, the DDE technique does not require exploitation of a vulnerability, but rather rests on a user clicking through a confusing prompt which permits the attacker’s payload to be executed. While SensePost contacted Microsoft concerning the issue, it was deemed that the DDE feature was working as expected and would not be immediately patched. Numerous attacks have already been observed in the wild using this technique and, so far, many defenders are struggling to keep attackers using this approach out of their networks.

Prompt separating the user from system compromise

Figure 4 – Prompt separating the user from system compromise

The crypto attacks KRACK and ROCA are very different in their impact compared to the Adobe Flash 0-day and the Microsoft Office DDE issue. The crypto attacks are attacks on trust. Organizations deploying WPA2 and RSA-based encryption have to rely on the supply chain providers performing their due diligence on the products that they provide. This applies particularly to the ROCA attack where it is still unknown the full extent of the issue. More and more products are being discovered as generating vulnerable keys and we can expect that we will be having to check for weak keys for a long time to come.

The Flash 0-day and DDE issue are ways for attackers to gain initial access to a network, mitigations exist in terms of patching or disabling features, but once they have been dealt with, an organization can have a reasonable amount of confidence that they are resilient against attacks using these particular vectors. However, the uncertainty spread by attacks which undermine systems we use for protection is more insidious. The trust we have in these systems turns out to have been misplaced.

When assessing the impact of a vulnerability, it is worth keeping in mind what the consequences of the vulnerability are:

  • Is it a tool for providing unauthorized access to an attacker?
  • Or is it undermining the trust we have in the security systems we have built?

In terms of response, if unauthorized access to our networks is discovered, the response can be tactical and immediate, that is, a standard incident response. The response to an attack on trust must be more long-term and strategic. It must take into account the uncertainty around the lifetime and impact of the issue, these attacks on trust may live on for years in the most unexpected places.