Security researchers have discovered that Windows Update is partly responsible for how the Flame malware spreads across networks and how it is able to infect fully patched versions of Windows 7.
Until now, researchers had been baffled as to how completely patched Windows 7 machines could be infected, but, as it turns out, Flame had a helping hand from Windows Update itself.
As reported by Symantec, Internet Explorer automatically searches for proxy configuration settings when it is opened, using the Web Proxy Auto-Discovery Protocol (WPAD). The protocol looks for WPAD servers, and, upon finding one, downloads the settings contained in the server's wpad.dat file.
However, if a Flame-infected machine is on the network, it listens for these requests and masquerades as the WPAD server, providing uninfected hosts with a doctored wpad.dat file to ensure that web traffic goes via the infected machine. This essentially sets up a man-in-the-middle attack, where the Flame-infected machine can listen for Windows Update requests from anyone else on the network and respond with its own illegitimate patch.
Flame contains a module for serving its own patches, called Gadget. As Kaspersky Lab's Alexander Gostev reveals, it was probably named this due to how it pretends to be a component that allows gadgets to be displayed on Windows desktops.
Gostev has also verified the timestamps for Gadget. According to him, Gadget was compiled on 27 December 2010, signed the next day and then included in the illegitimate update on 11 January 2011. This could indicate that while components of Flame were developed over two years ago, this method of infection was not employed from the very beginning. It also indicates that Microsoft's signing flaw has been present since at least 28 December 2010.
Normally, patches served by Gadget wouldn't allow arbitrary code to be executed or installed, because Windows Update requires the code to be signed by Microsoft. But, as the company revealed recently, one of its certification authorities was providing certificates that allowed just this.
Flame's authors then had everything they needed to serve any machine on the network with Microsoft-signed code under the guise of being a legitimate patch.
Even then, the malware is cautious. The initial illegitimate patch served by infected machines isn't Flame itself. Rather, Flame sends out an advance scout/loader, which looks at system information and whether there is security software present. It's only after this check that the scout/loader then contacts the infected machine and asks for a copy of Flame.
While Microsoft has shut down the flawed certification authority to ensure that no further unauthorised certificates can be made and distributed, there are three certificates that must be revoked on users' machines. Ironically, the patch to revoke these certificates is being served through Windows Update.
Revoking the trust in these certificates may be a more complicated matter for Windows 8-compliant hardware that incorporates UEFI (Unified Extensible Firmware Interface) Secure Boot.
Secure Boot is implemented in firmware, and is meant to ensure that no unsigned software is run on a device or set of hardware. Where secure boot is implemented, Microsoft may have to issue firmware updates for its hardware to make sure that unauthorised certificates are no longer trusted, and to ensure that Secure Boot's purpose of using only trusted software is upheld.
Users can choose not to revoke trust in unauthorised certificates, and instead use them to circumvent Secure Boot on devices where it cannot be disabled, such as on Windows 8-certified ARM architecture, but this also opens them up to malware that may use the same unauthorised certificate.
ZDNet Australia contacted Microsoft on how it will address the revocation challenge, but it did not respond at the time of writing.