Flame Malware Hijacks Windows Update
wiredmikey writes "As more research unfolds about the recently discovered Flame malware, researchers have found three modules – named Snack, Gadget and Munch – that are used to launch what is essentially a man-in-the-middle attack against other computers on a network. As a result, Kaspersky researchers say when a machine attempts to connect to Microsoft's Windows Update, it redirects the connection through an infected machine and it sends a fake malicious Windows Update to the client. That is courtesy of a rogue Microsoft certificate that chains to the Microsoft Root Authority and improperly allows code signing. According to Symantec, the Snack module sniffs NetBIOS requests on the local network. NetBIOS name resolution allows computers to find each other on a local network via peer-to-peer, opening up an avenue for spoofing. The findings have prompted Microsoft to say that it plans to harden Windows Update against attacks in the future, though the company did not immediately reveal details as to how."
And an anonymous reader adds a note that Flame's infrastructure is massive: "over 80 different C&C domains, pointed to over 18 IP addresses located in Switzerland, Germany, the Netherlands, Hong Kong, Poland, the UK, and other countries."
The security surrounding Windows Update is rather pathetic, certificate or no certificate. It's cost me many, many extra hours and headaches, while they're "hardening up" windows update, they should also make a vastly improved repair utility for it. I hate spending all that time removing a virus from a customer computer just to find out at the end that Windows Update is irreparably broken and SFC, their own fixit tool, 3rd party mass re-registration tools, and registry utilities all cannot fix it so I have to reinstall. Considering that an OS install is classified as "totaled" if Windows Update no longer works, maybe they should protect it better AND make a flawless, end-to-end reinstaller that resets it to absolute default settings and fully repairs it.
Anyone know what this is about it's in the last paragraph "It's interesting to mention that these machines mostly run Windows XP and Windows 7 32 bit, but none of them run Windows 7 64 bit, which seems impervious against this and most other malware." Is that due to driver signing requirements?
Everyone that disagrees with me is a paid shill
Umm.. the developers behind Flame were able to hijack Windows update, gain access to a Microsoft code signing and website signing key, stay undetected in the wild for at least 2+ years.
But System Restore 2.0 is going to stop them? Your average piece of malware can survive a system restore...
I don't think you're being fair. Microsoft has fixed more security holes than all the other software companies on the planet combined. And I have every faith that they will continue to fix thousands and thousands of security holes every year for a long, long time to come.
Is that due to driver signing requirements?
Driver signing doesn't mean squat for security. Third-party drivers with security holes and back doors are a dime a dozen, and there are even some in Microsoft drivers, of course. I have a publicly-available CPU diagnostic utility that comes with a signed 64-bit driver that allows user mode to write to any desired MSR. That easily leads to executing arbitrary code execution, most easily by changing the syscall vector. Malware that acquires administrator privileges can just install some company's vulnerable driver.
Driver signing is really about DRM. Hollywood was strongly concerned about fake video card and sound card drivers being used to dump unencrypted content from protected sources. The proof of my statement is what happens when you boot the Vista/7/8 kernel in debug or test signing mode: everything works except Blu-Ray movies and other DRM content.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Well, I am not an expert on the topic but there are a few things you might want to consider before you get all overexcited on that...
First, there are hardly any infections outside the Arab-world. (my guess is that it just takes a look at the keyboard driver in use) Going by your username you're not an Arab guy.
Second, the virus seems to be activated by some kind of a human operator, and well... you are probably not important enough (read: high level nuke scientist or something)
Third, this thing is in the wild since 2010, maybe even as early as 2007, and you didnt get infected in all the updates since then (I assume), or it is to late anyway.
Fourth, you use Windows and then ask if you might catch a virus? Seriously?
Fifth, to be absolutely safe: format your HD a couple of times, get OpenBSD on it with a strong root password (at least 128 characters), get the battery out and pack the thing in a lead box with walls at least 5 inch thick, fill the rest of the box with epoxy and bury the whole thing on a depth of at least 10 feet... on Pluto...
rm -rf --no-preserve-root /
I saw an article about this already on Ars Technica. However, Ars included one detail that the Slashdot and Security Week stories don't:
Microsoft issued an emergency update Sunday that updated the Windows Certificate Revocation List specifically to expire the certificate used by this exploit.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
That's just not the way malware works any more.
Early viruses were great, they did something obvious like put dialog boxes on your screen, ask for cookies, wipe your hard drive, or other obvious malicious behaviour. This was a good thing because it meant that they would never really spread that far because once infected, people knew they were infected, and the infection caused enough trouble to be worth fixing.
Modern malware is a completely different beast, the goal of modern malware is to be unnoticed by the end user so as to live as long as possible in the machine, and spread to as many others as possible. usually with the goal of leeching bandwidth from these machines for use in various botnets. As such, malware that causes your machine not to boot would defeat the purpose of modern malware. a machine that isn't booted up will not join a botnet, and will not spread to other machines.
What is more likely is that the virus writers will intercept the keys used by UEFI, manage to sign their own bootloader, and still run windows in a way that the average end user can't tell the difference. this will make the virus almost impossible to remove as it will then have more access to the system than even the operating system itself does. On the bright side, once the UEFI keys are in the wild, the various free operating systems can use those same keys to sign their own bootloaders allowing people to run non-windows software in a signed way on windows only hardware (call it jailbroken...)
The answer to that has been a resounding yes ever since NetBIOS was introduced. It was always a windows only way of doing things that already had other non-proprietary standard ways of being accomplished. It has also been a vector for various malware over the years.
Parent post points out what I thought was the most interesting part of the article, that a cryptographic collision attack was used to generate the fake certificate. We've seen multiple articles here about researchers using cryptographic collision attacks against certain ciphers, but, aside from the story about GnuPG short IDs that were only 32 bit hashes, this is the first time I can recall hearing that one was used in the wild against a real security system. Now maybe people will pay attention to what those researchers were saying...