Hacker News new | past | comments | ask | show | jobs | submit login
Microsoft have signed multiple rootkits (twitter.com/gossithedog)
157 points by bobcostas55 on June 20, 2021 | hide | past | favorite | 25 comments



Looks like a signed driver, it’s not particularly hard to turn any driver into a rootkit especially a networking one.

If you manage to say install npcap on a machine which is also signed these days you can pretty much capture the entire network traffic and send it w/e you want… heck both the capturing and the “sending” can be done from within the npcap driver itself since it can both capture and send packages the logic however needs to reside somewhere else.

The biggest issue here looks to be that MSFT changed their signing protocols.

> In the past, Microsoft only signed the .cat file. Starting with Windows 10, Microsoft now signs all of the portable executables in the returned payload. For example, the .dll file is also signed by Microsoft.

https://docs.microsoft.com/en-us/windows-hardware/drivers/da...

They used to sign only CAT files now they’ll sign pretty much anything that was submitted, I’m guessing their review process can’t actually validate what these things do other than they meet the compatibility requirements.

So what they do is that they base their process on “validating” the partner which these days with 100,000 hardware vendors especially in China is pretty darn hard, and even if the process is quite strict it still leaves them open to supply chain attacks.

While it might look bad it’s still better than the alternative, if getting your driver signed would be too hard then it would be the same as the early Windows 7 days during which even relatively large and reputable hardware vendors asked you to disabled driver the mandatory driver signature checks because they were too slow in getting their software signed.

Also note that this doesn’t impact other signing protection such as smart screen for that Microsoft has a much stricter process however I’m also guessing it would quite possible to sneak something past that too since plenty of small even one man shop commercial software managed to get through the red tape for that.


Our experience in the Web PKI is pretty stark. Assuming well-meaning, basically competent people, all you can hope for is that they can enforce some simple easy-to-follow rules and you will need to check their work to keep them on the straight and narrow. To the extent they screw up and you miss it, the screw-ups will continue, to the extent the rules are too hard for them to follow they just won't.

But I don't see how that regime is useful here because the rules they would need to follow are anything but simple and easy-to-follow. To be effective they need to be more or less reverse engineering complicated drivers day in and day out. So I am not surprised the result is ineffective.

Actually I'd say the practical alternative, which you should indeed prefer in real life, is Class Drivers. Notice how that webcam you bought just plugs in and works? Same for your wireless mouse, the no-name USB headset and the 2TB USB hard disk you bought. Because those are standard classes of device, they don't need custom drivers.

This current practice is security theatre. There's the big show with the "certification process" and then actually they'll just ship whatever malware somebody pays for.


Then why not use an open source OS with generic drivers which are available in source code and can be inspected, and even build in an exactly reproducible way with a system like GNU Guix?


> the practical alternative, which you should indeed prefer in real life, is Class Drivers

Class drivers are great, but they require devices to comply with standards, which are usually not very accommodating of whatever new bells and whistles manufacturers want to add. Putting RGB lighting on literally everything, for example, was not really considered when the standards were written.


RGB doesn't really need kernel-level drivers.


A catalog file (.cat) has a bunch of file hashes (think file identities) in it. Signing that means indirectly signing all of those files.

Signature validation means checking an embedded signature if it exists, then looking for the hash in the installed .cat files and, if found, checking that signature.

Authenticode signatures like this are PKI-based. They can be revoked if determined not to be valid later.


I think the issue with the Win10 model is that the signature on any PE files is independent so one can use it for some bypass outside of the process of installing a driver. That said WHQL/WHLK signatures aren’t useful for bypassing things like smartscreen and do require an additional EV code signing cert to identify the publisher for that. Which again at large scale isn’t probably hard to get.


Looking at the VirusTotal results in the Twitter thread, all but one of the rootkits were actually detected by Microsoft's own anti-virus engine. I think Microsoft should consider running the submissions for driver signing through their anti-virus scanner (or even better, VirusTotal). Won't catch everything, of course, but it's pretty low hanging fruit.


I’m pretty sure that these were added to the defender list after they were signed and seen in the wild…

Same goes for VT they only classify something as malware after there is sufficient evidence that it is malware.

For the most part the only difference between malware and non malware is the intent of the operator, pretty much any functionality can be abused for malicious purposes.

This especially holds true for most security/system management suites they have pretty much the same capabilities as any decent RAT malware the only difference is the reason behind why they are deployed.


The real purpose of all these so-called 'security measures' which many Operating System software companies have implemented (e.g. dev licences, requiring programs to be signed) is to restrict users' ability to use software written by third party entities in favor of software designed by the OS's parent company. The irony is that these big corporations have become some of the least trustworthy entities on the planet - They have become hotbeds for hackers, white collar criminals and psychopaths. Any random software you can download online is more likely to be trustworthy than a signed software developed by big tech. With big tech, the chance of software being malware (e.g. spying on you) is almost 100%.


With the offensive posture of the NSA, I would be highly surprised if this weren't true. They can be compelled to do anything, and compelled to keep it secret.


While it's true that the NSA could feasibly compel them to do this, I would be reasonably surprised if they exerted that capability so casually that this many ended up uploaded in e.g. VirusTotal.

If everyone thinks random signed drivers can be malicious, then they're more cautious about them, looking for them. If everyone thinks signed drivers are a sign of trustworthiness, it's much more likely that your malicious driver can wind up where it needs to be, and stay there without being noticed.

My personal bet is heavily on malware getting signed either through a stolen cert/compromised signer or simple incompetence.


While they could, I don't think so in this case, as the drivers mentioned report back to C&C servers in China. While the NSA could obviously set up servers there, the simpler case would be that they have not.

Don't forget that the other mission of the NSA is to protect American computer infrastructure. Doing something like this where the driver distribution is so wide and indiscriminate would also argue against their involvement.

My guesses are in order: 1. The driver authors copied source from somewhere else without understanding what it did. 2. Malicious intent from the Chinese firms. 3. Malicious intent from the CCP. 4. Any other reason.


Incompetence is more likely than malice. I am sure they have done both.


I do not suspect this is a complete analysis of the risk.


Of course they do. They regularly sign anti-cheat programs which are rootkits, so it’s not even an uncommon occurrance. Being a rootkit is insufficient to flag a program as malicious.


I wonder what would happen if Microsoft required drivers to be redistributable at least by Microsoft and hosted them on a server for download by independent researchers, similar to how fwupd is doing it. Then the researchers could find ways to identify malware and point it out to Microsoft. As a bonus it might make the life of fwupd easier too.


> researchers could find ways to identify malware

Perhaps OS developers should move to a validation system something like FCC has (i.e. to check for allowed electromagnetic interference) that requires analysis and certification by a third party of the driver before it gets signed and rolled-out.


In many ways they do this already and they do it terribly as you would expect from Microsoft. Not only do they install spyware automatically from OEM manufacturers like HP, they also often revert driver updates like Radeon drivers where they'll install an old driver on top of the new one you just installed.


Less likely Microsoft has signed multiple rootkits and more likely that someone has either stolen the certificate, they have someone at Microsoft signing the malware for them or they have found a vulnerability in the signing process imo.


Not necessarily. Driver QA & signing is not malware exorcising magic.

If you are a genuine hardware vendor, giving them an actual, working driver binary so they can run whatever QA and static static analysis test suite on the binary, you might have the benefit of a doubt and get it signed once it passes.

That assumption of good faith mixed with "Betriebsblindheit" is probably all it takes to get a signed driver with a backdoor/rootkit/whatever in it.

For comparison: https://news.ycombinator.com/item?id=26887670

EDIT: I'm not trying to imply that's what happened here, we don't have enough details yet. Just trying to point out, that binary signing isn't a panacea and doesn't require Ethan Hunt cable dangling into a secure computer room to work around.


Perhaps it should be mentioned that drivers are halfway to a rootkit even when not being malicious. A driver has (and often needs) access to all apps' memory for example.


I certainly believe Microsoft has high level employees working for Russian Government. Every version of Microsoft internal builds leak to Russian websites.


I’m sure Apple has/will do similar. Isn’t the point of the cert not so much to vet the recipient but to create cost (including nonmonetary) to attain the cert and then have the ability to rapidly revoke the cert and nullify the malware installed base?

Even if Microsoft makes some pretense of vetting, no one can ever perfectly weed out malware authors in advance, as that would require knowledge of their future thoughts and motivations (hard enough to assess those in the present).

(If Microsoft has failed to revoke certs for known rootkits, by all means bash them hard for that.)


By the way, this is the equivalent of smuggling malicious source code into the Linux kernel. Look what worked better, security-wise.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: