Manipulating Microsoft WSUS To Attack Enterprises 60
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.
More proof... (Score:3, Interesting)
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...
Re:More proof... (Score:4, Informative)
Is it any different then say apt-get using unsecured http or ftp connections?
Then you'd never get your product and/or it would be so ridiculously expensive that you couldn't afford it. EVERY major piece of software has bugs. It's a fact of life. Even the Space Shuttle where billions of dollars and decades of time were spent perfecting things still had a few bugs over it's life.
And how long is "a long time"? Windows 7 will be supported for 11 years, until 2020. XP was released in 2001 and just ended support last year after it was supported for 13 years. The Linux 2.4 branch was released in 2001 and was maintained until 2011. Where's the outrage that it's not still being maintained and supported?
Don't blame Google on that. Google continuously updates their software releasing fixes. It's the manufacturers and carriers that refuse to support/update them. It would be like yelling at Linus et al for a kernel bug that Debian or Redhat drags their feet to incorporate into their distributions.
Re: (Score:3)
Is it any different then say apt-get using unsecured http or ftp connections?
Yes. Apt doesn't run executables, it extracts .deb files that are signed by the distro key. The worst you could do would be to give the machine a different .deb file to the one it requested, which is potentially problematic (e.g. send an old version that has known security holes), but nowhere near as risky.
This attack will apparently run any Microsoft-signed executable with any command-line arguments. That's just hilarious.
Re: (Score:2)
apt can run an post install script can't it? If someone inserted themselves as a MITM then could execute a malicious script as part of you installing an update.
Re: (Score:1)
the scripts are in the deb so the signature also prevent that
Re: (Score:3)
the scripts are in the deb so the signature also prevent that
Yes, exactly.
This hole is a consequence of using random executables as installers, rather than a special installer file type.
Re: (Score:2)
Is it any different then say apt-get using unsecured http or ftp connections?
In addition to the package .deb files being signed, the official package repositories have signed package indexes. I suppose one could just serve up a modified index without a signature, but apt might warn or error on that. (I haven't checked this part)
Re: (Score:3)
Re: (Score:2)
Re: (Score:1)
That might actually work in the state that I currently reside in. Maine has an Implied Merchantability Act that actually warranties things for a "reasonable length of time." This exceeds any manufacturer's warranties. Not many people know about it and fewer act on it. I know of no instance where this has been tried but, I suspect, it would be a reasonable case and would be heard and judged on its own merits. Few items have a defined implied merchantability length and most are subject to a judge's or jury's
Re: (Score:2)
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.
Should Ford also be required to make parts for the Model A? At some point a company has to stop supporting old outdated products. For Google, once devices are no longer sold with X version of Android then they should set a date that they will stop support for it. Until then they can just apply security patches. That doesn't mean the device manufacture will update THEIR modified version of android and push it out to the devices though.
I do believe that device manufactures/carriers should be required to p
Re: (Score:2)
MS-DOS is the Model A of personal computers. There was a whole lot of aftermarket support for DOS operating systems for many years after Microsoft itself stopped contributing to DOS. Additionally there was very little in MS-DOS itself that was broken, at least from an outside-attack per
Re: (Score:2)
The same can be done by hobbyist with versions of Android that Google no longer maintains. Download the source, apply updates and patches and send to a user to install.
Re: (Score:1)
Should Ford also be required to make parts for the Model A? At some point a company has to stop supporting old outdated products.
There are parts suppliers other than the OEM. Part of the problem with software is the length of copyright, and the fact that some may claim distributing a patch would be copyright infringement.
Instead of mandating a fixed time frame that support must be provided, would it make any sense to tie continued copyright protection with continued support? That would allow the manufacturer to determine how long they wish to provide support, and also allow interested third parties fill the void later.
Re: (Score:1)
Wait, what? You can (notice I did not say had to) purchase content from Ubuntu for downloading via apt? That is, umm... Different? I'd expect something like that at RedHat but, Ubunto? How odd... When did they start this?
Note: I do not use Ubunto but I do use a fork that still uses plenty of Ubunto packages. I use Linux for Retards (Mint - cinnamon) and I like it because I do not have to screw with much to get it working. It has some bugs... I can deal with that. I can not set my wallpaper on this specific
Re: (Score:2)
This article is honestly a lot of fud - it relies on lazy Windows admins (and yes I admit there are far more of them around than lazy unix/linux admins).
Look at the attack vector - you can't just change where Windows checks for updates without local admin, or modifying the policy for the domain the machine is bound to - and you can't update the cert store for the same reasons. Yes privilege escalation attacks exist, but if someone has local admin on your windows box - why bother hacking the windows update s
Re: (Score:2)
To change the command line in a microsoft signed patch you'd have to edit the patch manifest file (big xml file with installable rules, installed detection rules, etc etc) - which would break the code signing cert on that package.
Again - by default the windows client only installs MS Signed packages - you can set a policy to install packages signed by your own code signing cert, but that's not the default behavior (that action requires domain or local admin).
To bypass that you'd have to exploit MS's "authen
Re: (Score:2)
This is why I never get the (lat/new)est stuff right away! I still use old stuff like Debian oldstable, unsupported Windows XP Pro SP3, Mac OS X v10.8.5, etc. because they all still work fine. I'll upgrade when I'm ready and forced.
Re: (Score:1)
If updates are signed... (Score:3)
... and this is why friends shouldn't let friends implement systems with unsigned automatic updates.
Re: (Score:2)
Can someone please explain to me how are they managed to bypass signed update functionality?
Not if you're too lazy to read the article.
Re:If updates are signed... (Score:5, Funny)
Re: (Score:2)
Didn't someone get a signing cert issued to them for Microsoft updates once? They could do that again.
Personally, though, I suspect the real attack would be to block the update that fixes whatever the latest bug is by offering all the officially signed Microsoft updates except for the one the attacker intends to use to upgrade from owning your router [slashdot.org] to owning the rest of your computers.
Re: (Score:2)
I suspect the real attack would be to block the update that fixes whatever the latest bug is
Even better would be an attack that un-blocks a borked microsoft update and actually allows it to be installed, crashing the victim's systems.
Re: (Score:1)
If you look at Microsoft's infrastructure and are honest about it - they keep that locked down pretty well and are surely subject to a whole bunch of attacks in myriad vectors. Yet you seldom hear about anything much happening at their end of things - the update servers never get hacked (I'd probably aim at those, personally), the ISOs never get corrupted on MSDN, nobody steals personal information, and nobody logs in and steals bunches of unknown MSDN or Technet keys.
They do have a bunch of Linux facing se
Re: (Score:1)
From the article:
They were basically able to get any existing signed executable to run with arbitrary arguments as system. Since they were abusing the update system, they even could get the system to download PsExec.
Re: (Score:2)
At first, I was thinking it was along the lines of "create a root key, push the key out to all machines in the domain as a trusted item, use WSUS or SCCM to push out a package. However, this attack only requires control of the WSUS server.
What is a workaround? Probably the usual common sense. Put WSUS on its own VM or machine, restrict RDP access into the box to a management network, enable Windows Firewall, have multiple WSUS machines [1] for separation, so one hacked box in receiving won't hose finance
Re: (Score:1)
Re: (Score:1)
I am not sure if this helps:
https://msdn.microsoft.com/en-... [microsoft.com]
Re: (Score:2)
By tampering with the unencrypted update request, and modifying the WSUS server to serve malicious files.
Change it from: "Hey, I'd like update CumulativeIEUpdate20150801.msu."
To: "Hey, I'd like SilentBackdoorAndBitcoinMiner.txt"
The compromised server says, "Sure, this uses CommandLineInstallation via the signed executable PsExec.exe."
Not really a story. (Score:2, Insightful)
Re: Not really a story, well... (Score:1)
Using a MITM to slip in a nastier set of stuff on the entire system is at least interesting, if not somewhat worrying.
Re: (Score:2)
If you're running windows, you're most likely compromised. Switch to Linux now.
I did switch to Linux [wikipedia.org] but for some reason I keep getting hacked. The last guy even patched it for me on the way out.
Re: (Score:3)
Dont need to be ON your network, I just need to be somewhere between you and Microsoft. That gives me a LOT of locations to choose from. Hell some ISP's and backbone operators simply have small sheds out in rural areas that are easily broken into without setting off alarms. Or if you did set off the alarms you have plenty of time to install a small device to do your MITM for you and leave making it look like some kids got bored tipping cows.
Re: (Score:2)
Still (Score:2)
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
Re: (Score:2)
Nessus already shows this (Score:2)
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 trip
Yeah, not a major concern (Score:1)
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