Slashdot Mirror
Manipulating Microsoft WSUS To Attack Enterprises
msm1267 writes: Microsoft's enterprise-grade Windows Server Update Services (WSUS), used to download and distribute security and driver updates, poses a significant weak spot if not configured properly. Researchers Paul Stone and Alex Chapman during last week's Black Hat conference presented research (PDF) on the the WSUS attack surface and discovered that when a WSUS server contacts Microsoft for driver updates, it does so using XML SOAP web services, and those checks are not made over SSL.
While updates are signed by Microsoft and updates must be verified by Microsoft, Stone and Chapman discovered that an attacker already in a man-in-the-middle position on a corporate network, for example, could, with some work, tamper with the unencrypted communication and inject a malicious homegrown update.
While updates are signed by Microsoft and updates must be verified by Microsoft, Stone and Chapman discovered that an attacker already in a man-in-the-middle position on a corporate network, for example, could, with some work, tamper with the unencrypted communication and inject a malicious homegrown update.
...that features will trump security every time.
I think that it's getting to be time to regulate software companies, especially for-profit companies. Their products are defective and they should be forced to correct those defects. And by correct, I don't mean sell you the newer version of their product. I mean doing real, thorough security analysis before shipping, and supporting previous versions for a long time.
Microsoft actually isn't as bad as they used to be but they still have too many post-ship bugs. I don't care how big the project is, there are still too many bugs. Google is who I'm now starting to wonder about, with all of these unpatchable cell phones because they don't want to support Android 2.3 or 4.1 even though the devices with these versions can't run anything newer.
And then there are the embedded systems, like cars...
Do not look into laser with remaining eye.
Windows 10 already provides that service.
Can someone please explain to me how are they managed to bypass signed update functionality? MitM will not give you magical powers to sign updates with MS key. As a result, the sig check would still fail when you attempt to install inserted update... So it either WSUS and signature check vulnerability, or not a big deal at all.
... and this is why friends shouldn't let friends implement systems with unsigned automatic updates.
If you already have someone with a MITM on your network, you've already been compromised. The sooner you know it, the better. This is kind of like those stories about some 'hack' someone found that requires keyboard access. If they have keyboard access, you're already sunk.
Using a MITM to slip in a nastier set of stuff on the entire system is at least interesting, if not somewhat worrying.
I'd feel sorry for anyone who actually believes any of the derp you just emitted. Too much wingnut fake-news, or was than an attempt at parody?
It is one thing to inject the malicious update, but it would still need to be approved for install, correct?
In our environment, I have multiple "rollout" groups which I release updates to over the course of the month.
The first group is, obviously, a testing group. But even with that, I research each update before approval.
Also, I have the automatically approve superseded updates and automatically update the WSUS server options turned off.
It seems to me that these are the basic practices that any admin would use....
My eyes reflect the stars and a smile lights up my face.
I doubled you can modify those XMLs even if they are plain text, if they are properly signed.
Exactly, the MITM goes away after a brief window of exposure, in the worst case. What's left is only the payload.
MS needs to come up with a better name than WUSS.
One of the things I've setup in the past
is a server environment with PCI DSS compliance
by default comms between internal servers and the wsus server are also not protected via ssl
(since you'd need to install the certs for the wsus onto the client machines if it's self signed)
one of the first things I turned on was SSL WSUS Support
(along with SSL Active directory, and SSL everything else)
If your doing your job properly when it comes to securing environments
usually you'll install a piece of software like tripwire or NNT or Nessus
part of which checks over all the settings, like group and local policy, with port scans
to list all the crap to be turned off or changed (wsus ssl in the group policy was at the top of the list btw)
Even when Windows is working correctly, it seems to screw things up.
Ok. So in order to make this work you'd need to have a WSUS server set up somewhere that has the malicious code and then change the client's update server setting. Since this is set by GPO it's going to be set back to the old value in a matter of minutes anyway if it's a corporate system.
Assuming the client is able to grab it then unfortunately unless the update from that server is signed by Microsoft the client server will refuse to install it. Is there a way around this problem? Yep, it's simple! You just need to create your own packages on the malicious server and sign them with its own code-signing certificate, and then your malware has to distribute the certificate to each and every client's code signing and root certificate stores in addition to setting another registry key that tells it to trust non-Microsoft signed code.
All of these settings which are settings normally controlled by GPOs in a corporate environment of course.
So the system was completely compromised long before you could ever set this all up. Sure, you could use this to keep your non-corporate machine botnet updated but there are far easier ways to do it and without leaving a nice trail of bread crumbs for the FBI to follow.