Windows Update abUsed to Spread Malware

Having a monoculture of M$’s OS on PCs is deadly. M$’s update process was used to ship malware. To do that a fake signature was developed one way or another. Since we now know that USA/Israel cooperated in this, there are some feasible paths:

  • M$ gave a signature to their “partners” in US government for the purpose,
  • M$ was tricked into doing so,
  • USA cracked M$’s keys…, or
  • USA bought keys from malware artists.

I have no idea which of these happened, but it is clear that if you want secure IT, you must eliminate the monoculture. It is clear that if there were some compromised keys, there could be more, a lot more out of thousands of millions of signatures. Is it enough that M$ revokes a few signatures? I doubt it. The world will demand diversified IT ASAP. This is good news for FLOSS. I would bet Iran is pulling out all the stops to eliminate that other OS today. How many others will pick up the pace of migration as a result of this? How many others will set up super-computers to crack codes so they can use this trick?

“Having a Microsoft code signing certificate is the Holy Grail of malware writers”

see Flame malware hijacks Windows Update to spread from PC to PC | Ars Technica.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology. Bookmark the permalink.

22 Responses to Windows Update abUsed to Spread Malware

  1. oiaohm says:

    Ivan
    “You claim you’re secure, I claim a determined group will gain entry because no OS is secure.”

    I did not claim the debian system was not beatable. Ivan it does not contain basic stupid mistakes like using out of date and deprecated checksum system for many years. Before flame started spreading debian had already moved onto SHA1 and now they are on SHA2 since flaws turned up in SHA1.

    You will notice that I talk about the requirement of doing HIDS a lot this is because I understand anything is defeat-able. Only way to locate a long term defeat is hids.

    Even fort knox could be robbed with enough determination. To date on one has attempted it just looks too hard.

    Its like the story of two people and a angry bear. Neither can out run the bear. Thing is they don’t have to out run the bear. The first one caught will stop the bear.

    Basic flaws makes windows look weak to attackers and Linux look hard. So the bear being malware writers take what look like a easy lunch.

    You claim determined group will gain entry is like the claim a determined group will gain entry to fort knox.

    Appearance is key. Being sloppy and doing incompetent things not rolling over keys. All makes windows look soft target. So of course it will get attacked more.

    That flame worked shows MS incompetence.

  2. Ivan says:

    Nonsense, Pete. Bob’s anti-china nuclear weapons factory running Debian would be cracked by the China’s Ministry of State Security and his anti-zionist biologic warfare factory running Ubuntu would fall to Mossad.

    You claim you’re secure, I claim a determined group will gain entry because no OS is secure.

  3. oiaohm says:

    Ivan In fact Debian keys are a bit trickier than that.

    This is the master keyring http://keyring.debian.org/

    Notice signing with sha1 is not even good enough. sha2 is all new issued and used keys. Windows was trivial because defective MD5 was still in usage that should have been dropped years ago. xbox360 is still using sha1 that should have stopped usage years ago as well.

    Next debian repositories in fact do check there keys against the keyring and default install when adding a repository or new debian key check against keyring. So case of impersonation of a debian prinary key way that happened to MS update. One would have been harder because a upto date checksum system is in use. Two if the key was labeled debian it would be vetted against the keyring.

    Yes a voiding system is designed into the debian key system for hids auditing. All keys should check out against the keyring.

    Something most people don’t notice is that debian itself does not trust downstream repositories. If a repository is not staying up to date with packages normally inside 3 months due to key changes debian side the packages will start not validating also lead to debian no longer downloading packages from that repository. Adding a fake repository also required faking the keyring servers.

    Yes one key in a repository not checking out against the keyring if its so called a copy of a debian repository you system will stop downloading from it.

    In fact one of the biggest not checked for risks is the fact debian will stop talking to repositories if only a local one is setup and the keys get damaged or it gets out of date.

    “Nope, they only have to crack one key to duplicate the Windows Update attack in Debian.”
    No they have to break the keyring server as well. Or there altered key will fail conformation as a valid key. Yes debian downloads a second copy of the key from the keyring server.

    So yes you would need man in middle against debian setting up just a repository is not going to work. Debian does not just accept keys without attempting to validate them. Worse the validation happens over SSL and requires correct CA signed connection. So now to breach debian you have to breach way more than 1 key. You have to break the validation key and invalid key in repository and hope user does not put more than one repository in there system. Yes another way validation will fail.

    There are other distrobutions without such quality controls on there key systems as debian.

    Yes a fake repository in a business network I walk in with a debian laptop I updated somewhere not infected and it will complain about something being wrong normally because you are going to end up with time miss alignments. With a mixture of valid and expired keys in the repository in the wrong order.

    Attacker a long time ago tried man in the middle with a repository serving up old by valid signed packages. Ivan. So Debian is touchy about how current of keys stuff is signed with. Major secuirty flaws the packager deprecates their signing key and uses a new signing key in future.

    Debian keys are not static. This is what makes man in the middle so hard. You crack a key by the time you do it could be deprecated and no longer in usage.

    Microsoft keys are static mostly. This is another weakness.

    oldman openssh mess caused debian to audit its secuirty processes. There are still extra recommendations from that including auto test case running that are not fully implemented yet.

    Compared to windows oldman the debian key and package distribution system looks like fort knox.

  4. Ivan says:

    All security updates are mirrored from security.debian.org, if it’s compromised all eight Debian users are compromised. Not to mention your nuclear weapons factory.

  5. Ivan wrote, “Once the black-hats have the key to the security.debian.org and their fake repository is set up, your nuclear weapons factory that uses Debian is toast.”

    It is much harder to crack that key than setting up MD5 collisions which take hours. You’re talking weeks or months with ordinary PCs to have any chance. It’s a 2K-bit key. Compromising the repository does not compromise every client on the planet.

  6. Ivan says:

    The key is obtained from multiple independent key-servers and the attacker has no way of knowing which one the recipient will use.

    Nope, they only have to crack one key to duplicate the Windows Update attack in Debian. Once the black-hats have the key to the security.debian.org and their fake repository is set up, your nuclear weapons factory that uses Debian is toast.

    I suppose now you’ll tell us that the alphabet soup of intelligence agencies across the planet just lack the resources to do this…

  7. oldman says:

    “Then you agree, it’s not a concern in the near future, and
    Debian can crank up its encryption/checksum protocols in plenty of time before disaster is imminent.”

    I agree that linux is not going to be anywhere near dominant any time soon.

    As far as the Debian “team” being able to get ahead and say ahead of the black hats, my reacktop is simpley this.

    HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA…

    (loses his breath… hits the floor gasping for air… )

    The same people who allowed the crippling of OpenSSH to happen are going to keep two steps ahead of the criminals looking to commit cyber-theft?

    You must be joking Robert Pogson.

  8. oldman wrote, “should the day arrive that Linux becomes a predominant, it will gain that value.”

    Well,

    1. then you agree, it’s not a concern in the near future, and
    2. Debian can crank up its encryption/checksum protocols in plenty of time before disaster is imminent.

    Either way, I am safer with GNU/Linux by a long shot, perhaps a factor of 1000 or more, and that’s sufficient reason by itself to use GNU/Linux. There are plenty more that GNU/Linux can do to improve security like using readonly media and rebooting frequently… Some already do that for their banking.

  9. oldman says:

    “As I wrote before, the target had better be very high value to make an attempt feasible.”

    Uh Pog, should the day arrive that Linux becomes a predominant, it will gain that value.

  10. Ivan wrote, “checksums cease to matter unless they are manually checked. “

    The signatures on the release file and the packages is checked against a public key of 1024/2048 bits. It is not trivial to fake them. The key is obtained from multiple independent key-servers and the attacker has no way of knowing which one the recipient will use. The world+dog will be alerted promptly when APT sings out that it cannot verify the signatures. So, no amount of man-in-the-middle will make an attack trivial. As I wrote before, the target had better be very high value to make an attempt feasible. APT is very open but sufficiently complex to make such an attack a real PITA to implement. Think how easy compromise is with a single stolen password compared to all the work suggested. Also, the probability of detection is huge since Google and everyone else can see what you are doing. Isn’t openness grand?

  11. Ivan says:

    How much effort will it take an attacker to fake all those signatures/checksums?

    Very little effort is required once you’ve completed the man-in-the-middle with your signed packages.

    Once your target’s security updates are coming from your server, checksums cease to matter unless they are manually checked. Something that no one would do as long as the updates from your server are close enough to upstream to not raise attention.

    It is not trivial to fake those.

    I’m going to go out on a limb here and say that it wasn’t trivial to do that to Windows Update, either.

  12. Ivan wrote, “a cryptographic collision attack coupled with a man-in-the-middle attack and you ignore that the same tactic would work against a linux repository if it had been the target.”

    Hmmm… Suppose I install something that is dependent on 10 other packages. How much effort will it take an attacker to fake all those signatures/checksums? 128-bit MD5s and 160-bit SHA1s? It is possible but it would be much easier to get to the right people and machines directly. Then there is the obvious problem that file-sizes, names, kinds would not match and be found out in other ways. A system with an intrusion-detection system would be able to catch that pretty quickly. A crude system I have used calculates an MD5 or other sum for every file on the system. The Debian Release file is signed with a 1024-bit or longer key. It is not trivial to fake those.

    As in all matters of security there is a tradeoff between the efforts required to exploit a compromise and the effort required to prevent exploits. Such an attack is rather indirect and not guaranteed to succeed so a lot of effort is likely to be wasted. Suppose one works all that out but I switch to Wheezy while your attack is aimed at Squeeze packages. You are out in the cold.

  13. Ivan says:

    Let’s see, a cryptographic collision attack coupled with a man-in-the-middle attack and you ignore that the same tactic would work against a linux repository if it had been the target.

    Mazel Tov!

  14. oiaohm wrote, “Samba is not used in all server farms. “

    Chuckle. I have two instances of Samba in my home, sitting idle from when last that other OS ran in my home. I just haven’t been bothered to kill them. I use sshfs and NFS for the GNU/Linux boxes.

  15. oiaohm says:

    iLia “Try Mac OS X Server as a server OS, Linux is a monopoly in server OS domain, and you must eliminate the monoculture, so go ahead and say “goodbye” to Linux server.”

    In fact Linux is a multi culture. Samba is not used in all server farms. Cluster file-systems exist that are used instead. Sudo weakness only happened if you were using IP access filters.

    BSD still exists in places.

    Yes MS is a monoculture in design in so many areas iLia. Linux is not. Linux more types of network filesystems. So attack against one of those file-systems will not work against all locations Linux is used.

    Weakness in a filesystem. Again does not work against them all. Is there another option to sudo. Yes there is selinux roles both can be used to raise privilage. Modern day dbus and policykit to reduce usage of sudo or selinux roles.

    Try finding a weakness in a Linux that will be everywhere. It is not a monoculture is not there.

    Even with a defective sudo installed is it possible to make it do the right thing. http://selinuxproject.org/page/NetworkStatements Yep it is. selinux can monitor incoming network access and what its going to and set user privilege accordantly. So even that sudo would allow more selinux would nail anyone attempting that.

    This is the big problem secure systems faults like the recent sudo fault in fact did not alter secuirty at all. The fault was non functional on secure systems. Yes this is what gave away its existence.

    Its the classic case of we have a person protecting a door then another person behind that person if that first person fails to protect. You need more than a solo exploit to get very far in secure linux systems with the most sensitive data.

    Yes Linux is like double dead bolt doors. Each protection point there is at least a second one to back up the first. Of course there are a lot of people who run there systems poorly configured.

  16. lpbbear says:

    “Re: UEFI and surge of electronic waste. I mentioned that last year, once Windows 8 gets infected, how is one suppose the fix the thing? I know, you toss the slate and go out and buy a new one”

    Exactly.

    Even though I am a Linux user and supporter, as a computer tech I see a steady stream of virus infected and or trashed Windows systems. I gave up years ago trying to save customers files using any Windows based utility. It was a total waste of time and I could not reasonably expect customers to pay for all the time I ended up wasting using a Windows based utility to salvage their files. I use Linux run from cd discs to accomplish that task and because of the flexibility of Linux it saves me a ton of effort and time which results in a much lower cost to the customer.
    From what I understand of how UEFI works I won’t be able to do that unless I am allowed to disable UEFI, boot into a Linux cd, and have direct access to the customers Windows files to save them. Even if that does work I have to add a bit of extra effort to go into the BIOS, shut off the UEFI crap, save the files, back into the BIOS, turn on the UEFI crap and reload and hope that some other Microsoft braniac idea doesn’t block my ability to copy files back to the system after its reloaded. In any case a whole lot of hassle for no benefit other than for Microsofts in its obvious attempt to block other competing operating systems.

    IMHO you are correct. Just like after Vista hit the market with its bloated inefficient garbage, theres going to be a whole lot of wasted computer hardware being tossed out.

  17. dougman says:

    OSX is just as susceptible to malware, just saying.

    Re: UEFI and surge of electronic waste. I mentioned that last year, once Windows 8 gets infected, how is one suppose the fix the thing? I know, you toss the slate and go out and buy a new one

    Perhaps that’s the point of it all, increased consumerism.

    Re: Embedded XP is scary, I do not understand who in their right mind would use that, especially in today’s environment.

    D.

  18. kozmcrae says:

    iLia wrote:

    …and you must eliminate the monoculture, so go ahead and say “goodbye” to Linux server.”

    What flavor of Linux would you say “goodbye” to?

  19. iLia says:

    you must eliminate the monoculture

    Try Mac OS X Server as a server OS, Linux is a monopoly in server OS domain, and you must eliminate the monoculture, so go ahead and say “goodbye” to Linux server.

    And don’t forget the recent Samba and Sudo vulnerabilities.

  20. If Iran didn’t start the move to ditch Windows after Stuxnet, they deserve what they got. All these “embedded XP” SCADA systems scare me, too.

  21. kozmcrae says:

    “Secure boot UEFI. Since this would have changed nothing against a key breach.”

    That’s for sure. I think another unintended consequence of UEFI will be an upsurge in electronic waste. People will be trashing their computers and buying new ones when malware or just everyday use makes their Windows boxes turn to junk. There will be no GNU/Linux to reclaim their machines.

  22. oiaohm says:

    This is why complete control of the update system and means to perform host intrusion detection is so important.

    Revoking a few signatures is not enough. Proper off line host intrusion detection would be good. Yes it should check that the keys installed are all valid against a 1 to 1 binary reference.

    Pushing a patch out threw the update system is not going to stop this happening again and again and again. Might fix current problem. Longterm it will fix nothing.

    Also this breach in signing also shows the problem with Secure boot UEFI. Since this would have changed nothing against a key breach.

    Anti-virus companies are saying they cannot do anything against a flame style attack. Why because they are the wrong tools.

    Windows users have to wake up to the wisdom of Linux Admins. How was breach at kernel.org found there was no signature for the infection. No anti-virus would have found it. Host Intrusion Detection is how that breach was found.

    The Linux users seeing something advanced next worry was did it carry extra payload to patch bios chips. The full recommendation was hids everything in the kernel.org and linux.com case including firmware chips. This could have been seen as a over reaction.

    The reality Linux world has been defeating stuff like flame for a long time. So have a really good understanding how bad it could be.

    Remember flame is fully programmable lua at core and what it runs in that it only downloads into ram at times. So you really don’t have a clue what flame has done to the systems. So the worst should be presumed that everything about the machine that can be breached is.

    “How many others will set up super-computers to crack codes so they can use this trick?”

    To forge a md5 is all that was required then you could have setup a fake update server pushing out a key update with a invalid key letting you in.

    http://www.mscs.dal.ca/~selinger/md5collision/ Yes this was demoed in 2006. Flame has been around for about 5 years. So about 12 months after the invention of method was it done.

    Md5 collision making was possible on a 2006 computer with a few days to waste.

    Checksums alone are fairly worthless from a secuirty point of view. Checksums + size are hardder but still can be fairly worthless. Only way to be absolutely sure is a binary to binary compare.

    UEFI secure boot is still based on the idea of checksums. What used SHA1.

    http://lukenotricks.blogspot.com.au/2009/05/cost-of-sha-1-collisions-reduced-to-252.html

    Yep not good. “practical collisions are within resources of a well funded organisation” is the rating of sha1. xbox360 also depends on sha1 for game protection.

    So Secure Boot UEFI is most likely government breached before its even first deployed. So anti-virus and secure boot will do nothing against government funded attacks.

    Only option really is proper binary based hids.

Leave a Reply