A week after Crysys Lab, Kaspersky, and the Iranian MAHER CERT each independently published their initial Flame analyses, and the implications are still being worked through. The malware itself — twenty megabytes of substantial engineering work, multiple modules, microphone-recording and Bluetooth-environment capabilities, MD5-collision-based code-signing — is the kind of thing that arrives once or twice a year now from the same general operator group that produced Stuxnet and Duqu. What is more operationally significant than the malware is what Flame demonstrated about Microsoft Update.
The MD5-collision technique is the part I have been spending the past few days reading about. Flame's code-signing approach used a chosen-prefix collision attack on MD5 — the same class of attack that Marc Stevens, Arjen Lenstra and Benne de Weger demonstrated in their 2008 rogue-CA paper — to produce a fraudulent certificate that chained to a Microsoft root. The certificate could then be used to sign code that Windows would treat as legitimate Microsoft software. The forged certificate was issued through Microsoft's Terminal Services Licensing infrastructure, which had been issuing certificates with MD5 signatures for years; the attackers found the path that let them pivot from "I can request a TS licence cert" to "I can sign arbitrary code as Microsoft" by exploiting the MD5 weakness in the cert chain. Microsoft's response was Security Advisory 2718704 on the third, which revoked the affected intermediate authorities and pushed an urgent patch to all Windows users to disable trust in those certificates. The follow-on patch on 12 June will fix the underlying MD5 issue in Terminal Services Licensing.
The structural implication is the part that is going to bother me for some time. Flame's operators were able to inject themselves into the Windows Update path of any host running Windows from approximately 2008 onwards. The mechanism is roughly: position yourself as a man-in-the-middle between the target and Windows Update; when the target requests an update, serve them a Flame-signed binary that Windows treats as legitimate. There is no evidence Flame was actually used at scale this way — the targeting profile suggests it was used selectively against high-value targets in Iran and the broader region — but the capability was there, and the implications for any operator running unencrypted Windows Update traffic across a hostile network are sobering. This is roughly the DigiNotar shape but for Windows software updates rather than for TLS certificates. The defensive answer is the same: assume that the trust chain is contested, and ensure that update integrity is verified by mechanisms beyond the platform's default trust store.
The other thing worth recording about Flame is what it tells us about the operational tempo of the people who built Stuxnet. Stuxnet was disclosed in summer 2010; Duqu in autumn 2011; Flame in spring 2012. The intervals are not random — each piece appears to support the next, with Duqu's reconnaissance toolkit feeding into Flame's broader-spectrum surveillance capability, and Flame's environment-mapping presumably feeding into whatever the next operation is. The cycle is now operationally roughly nine to twelve months, which is faster than Stuxnet-Duqu was, which itself was faster than I had assumed possible eighteen months ago. The implication for clients with industrial-or-OT exposure is that the threat intelligence relevant to them is not stable across years; it is changing across quarters.
The targeting profile in the Crysys and Kaspersky analyses is mostly Iran (with substantial concentration in Iranian government and energy-sector environments), with secondary concentrations in Sudan, Syria, Lebanon, and the broader Gulf region. Israel and Saudi Arabia have small numbers of detections, which the analysts are interpreting as either misdirected infections or specifically-targeted intelligence collection inside those countries. The geopolitical attribution writes itself; the New York Times' "Olympic Games" reporting from David Sanger last Friday, which surfaced a US-Israeli joint authorship for Stuxnet, is presumably going to be extended to cover Flame in the coming weeks. The general operator-attribution for the Stuxnet-Duqu-Flame line is now substantially less ambiguous than it was a year ago; whether that changes anything operationally for defence is a separate question.
For the Hedgehog SOC build I am working on, Flame has reframed one of the design questions. The original threat-intelligence brief I had written for the SOC was essentially "commercial cybercrime, hacktivist activity, and standard insider/external incidents". I am now adding a fourth category, which is "supply-chain and update-channel compromise", because the operational implications of the Flame disclosure for any client running standard software-update infrastructure are direct enough that they have to be in the SOC's detection scope. The detection signals are bounded — most of what would be visible is anomalous patterns in TLS connections to update servers, certificate-chain anomalies, and unusual outbound connections from update-related processes — but there are signals, and I would rather have the analysts trained to look for them than not.
For the engagements where I sit as advisor, the immediate post-Flame conversation has been the same conversation I have been having since the RSA breach: what compensating controls exist for the case where one of your defensive vendors has been compromised. Microsoft is a defensive vendor in the sense that Windows Update is a defensive infrastructure component. Flame demonstrates that the trust assumption that runs through every Windows-managed estate has been, for at least the past two years, vulnerable to a sufficiently sophisticated operator. The conversation is uncomfortable but increasingly familiar.
The next post is probably the LinkedIn breach, which is unfolding as I write this — there is a 6.5-million-password-hash dump that has just been posted to a Russian forum, the affected accounts include several at Hedgehog clients, and the structural lessons are familiar enough that the post will mostly write itself. Or it might be the Last.fm or eHarmony equivalents, which seem to have leaked the same week.