SANS ISC: Microsoft November out-of-cycle patch MS14-068 - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

We've started an immediate rollout, but all of a sudden can't load Windows Update on Windows 2003 machines. Anyone else seeing this?

2014-11-18 11:51:08:549 3116 3b4 COMAPI ----------- COMAPI: IUpdateServiceManager::AddService -----------
2014-11-18 11:51:08:564 3116 3b4 COMAPI - ServiceId = {7971f918-a847-4430-9279-4a52d1efe18d}
2014-11-18 11:51:08:564 3116 3b4 COMAPI - AuthorizationCabPath = C:\WINDOWS\SoftwareDistribution\AuthCabs\muauth.cab
2014-11-18 11:51:08:580 848 824 Misc Validating signature for C:\WINDOWS\SoftwareDistribution\AuthCabs\Downloaded\7971f918-a847-4430-9279-4a52d1efe18d.auth.cab.temp\muauth.cab:
2014-11-18 11:51:08:596 848 824 Misc Microsoft signed: Yes
2014-11-18 11:51:08:611 848 824 Agent WARNING: WU client fails CClientCallRecorder::AddService2 with error 0x80248015
2014-11-18 11:51:08:611 3116 3b4 COMAPI WARNING: ISusInternal::AddService failed, hr=80248015
2014-11-18 11:51:08:611 3116 3b4 COMAPI - Exit code = 0x80248015

This is critical for servers, however really only if the Key Distribution Center (Domain Controller) role is active.

"This security update is rated Critical for all supported editions of Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

This should not be rated critical for clients.

"The update is also being provided on a defense-in-depth basis for all supported editions of Windows Vista, Windows 7, Windows 8, and Windows 8.1 "


If a desktop OS is running a KDC, that would fall into the ISC "The difference between the client and server rating is based on how you use the affected machine." - i.e., you're using it as a server.

I was debating that and you are correct, I'll probably adjust the criticality down on workstations. On initial read, I thought that forging the service ticket could be used to compromise the clients (workstations), but the latest blog post from Microsoft makes it clear that this really only works against servers. See blogs.technet.com/b/srd/archive/2014/11/18/…

Have you updated the right box :)

The "ISC Rating" color scheme (white text on red background) would indicate a "PATCH NOW" rating, but it says "Critical" in the rating box. You might clarify the rating (or adjust the text or colors as appropriate.)

I have reports of this for both the GUI Windows Update and Microsoft Update on Server 2003 systems.

"but all of a sudden can't load Windows Update on Windows 2003 machines."

Seeing that as well here.

Our sole remaining Server 2003 VM was unable to get to Microsoft Update as well.

Workaround: If you have automatic updates running, you can use: "wuauclt.exe /detectnow" at the command prompt. After waiting in silence for a few minutes, you should then get the alternative (non-IE-based) updating mechanism in the system tray (don't expect any GUI-feedback while the update detection is underway). This worked for me.

If Automatic Updates isn't enabled on the server (and thus this work-around won't work), perhaps that can be turned on via control panel, system panel, or registry?

For those having problems with updating Windows Server 2003, we’ve found a workaround:

1) Stop the Automatic Updates and Background Intelligent Transfer Service services.
2) Delete or rename the %windir%\SoftwareDistribution folder.
3) Restart Automatic Updates and Background Intelligent Transfer Service services.
4) Go to the Windows Update site, NOT the Microsoft Update site, and DO NOT enable Microsoft Update.
Direct link to Windows Update site: http://windowsupdate.microsoft.com/windowsupdate/v6/default.aspx?ln=en-us
5) From Windows Update you can install updates. (Obviously MS14-068 is what we’re talking about today.)

The workaround breaks on first reboot and will have to be repeated to install additional updates.

Hopefully Microsoft will fix their screwup with Microsoft Update soon...

Trashed my computer (HP Probook 455 G1).

Could not boot into any mode of the operating system. Efforts to repair with Windows System Recovery Disk and HP Recovery Disc failed.

Finally managed to restore system from full image backup.

The one thing that may be non-standard on my computer is that the hard disk is encrypted with HP's security software.

Apparently Microsoft did not test this patch on computers running HP encryption.

This seems quite similar to an attack described at BlackHat this year
https://www.blackhat.com/us-14/archives.html#abusing-microsoft-kerberos-sorry-you-guys-dont-get-it

These script may be useful...

Reset, Repair and Reinstall Automatic Updates
Source: http://wuauclt.info/scripts.asp

Cheers,

Steve
Sanesecurity.com

This -

http://blogs.technet.com/b/srd/archive/2014/11/18/additional-information-about-cve-2014-6324.aspx

Says-

The only way a domain compromise can be remediated with a high level of certainty is a complete rebuild of the domain. An attacker with administrative privilege on a domain controller can make a nearly unbounded number of changes to the system that can allow the attacker to persist their access long after the update has been installed. Therefore it is critical to install the update immediately.

------

In the handlers notes above it is recommended a total install of the server OS.

Can this be clarified?

Many thanks!

Quoting Hurin:Our sole remaining Server 2003 VM was unable to get to Microsoft Update as well.

Workaround: If you have automatic updates running, you can use: "wuauclt.exe /detectnow" at the command prompt. After waiting in silence for a few minutes, you should then get the alternative (non-IE-based) updating mechanism in the system tray (don't expect any GUI-feedback while the update detection is underway). This worked for me.

If Automatic Updates isn't enabled on the server (and thus this work-around won't work), perhaps that can be turned on via control panel, system panel, or registry?

You can start task manager just before issuing the "wuauclt.exe /detectnow" command, you should see an increase in CPU activity after running the "wuauclt.exe /detectnow" command.

I noticed that the Authorization.xml file inside of C:\WINDOWS\SoftwareDistribution\AuthCabs\muauth.cab and C:\WINDOWS\SoftwareDistribution\AuthCabs\authcab.cab had the following line:

<ExpiryDate>2014-11-17T17:27:43.5251853-08:00</ExpiryDate>

The ExpiryDate seems to coincide with when Windows Update stopped working. After performing the workaround, the ExpiryDate line was changed to this:

<ExpiryDate>2017-12-03T11:59:25.7927833-08:00</ExpiryDate>

Quoting NickM:This -

http://blogs.technet.com/b/srd/archive/2014/11/18/additional-information-about-cve-2014-6324.aspx

Says-

The only way a domain compromise can be remediated with a high level of certainty is a complete rebuild of the domain. An attacker with administrative privilege on a domain controller can make a nearly unbounded number of changes to the system that can allow the attacker to persist their access long after the update has been installed. Therefore it is critical to install the update immediately.

------

In the handlers notes above it is recommended a total install of the server OS.

Can this be clarified?

Many thanks!

The handler note that mentions that users are "urged to reinstall" is referring to the updated patch originally released last week (the "schannel" patch). It's not referring to a total reinstall of the server OS. Microsft (and the handler) are noting that the schannel patch was updated and re-released and that we should reinstall it when it appears in Windows Update again (as it did on all my Server 2008 R2 servers). That's all separate from the Kerberos-related patch released yesterday.

Thanks Hurin...

I am ashamed I missed that...

- I'm a poor old man, my back is bent, my ears are grizzled, my eyes are old and bented.

<QUOTE>
The only way a domain compromise can be remediated with a high level of certainty is a complete rebuild of the domain. An attacker with administrative privilege on a domain controller can make a nearly unbounded number of changes to the system that can allow the attacker to persist their access long after the update has been installed. Therefore it is critical to install the update immediately.
------
In the handlers notes above, it is recommended a total install of the server OS.

Can this be clarified?
</QUOTE>

1. The way that I read it, the handlers recommended an IMMEDIATE reinstall of the previously-applied update.

2. That note from a Microsoft employee stated that "best practises" for remediating a COMPROMISED domain would be to do a complete rebuild of the domain. Anything "less" would be like the police returning your stolen vehicle to you, and then you immediately taking the car on a long, international, road-trip, while hoping that the vehicle has not been subtly sabotaged (low fluid-levels, slow oil/petrol/brake-fluid leaks), and that NO drug-sniffing dog at the international border will alert to some "unusual" aroma from some narcotic hidden inside the door-panels, or under the bonnet, or under the seats. You would not trust the once-compromised vehicle to be road-worthy; don't trust that a "cleaned-up" domain will be task-worthy.

Quoting Steve:I noticed that the Authorization.xml file inside of C:\WINDOWS\SoftwareDistribution\AuthCabs\muauth.cab and C:\WINDOWS\SoftwareDistribution\AuthCabs\authcab.cab had the following line:

<ExpiryDate>2014-11-17T17:27:43.5251853-08:00</ExpiryDate>

The ExpiryDate seems to coincide with when Windows Update stopped working. After performing the workaround, the ExpiryDate line was changed to this:

<ExpiryDate>2017-12-03T11:59:25.7927833-08:00</ExpiryDate>

This is being discussed heavily at this thread: https://social.technet.microsoft.com/Forums/windowsserver/en-US/77990b62-d97f-4648-815f-b021ddc07b5e/windows-update-for-windows-server-2003-will-not-load?forum=winservergen

I can confirm the problem is NOT related to the latest MS updates but is simply a coincidence of dates: The mauath.cab file from a system of ours that hasn't been updated since 10/15/2014 is byte-for-byte identical to the one newly created an hour ago on our Windows 2003 server. The expiry date was already there before the latest updates.

Steve, you received an updated expiry date when you removed the Software Distribution folder. Does that new date survive reboots and further updates, or does the problem return as others have reported?

Even if it comes back, saving an updated copy of muauth.cab and replacing it after every reboot (if that works) is less destructive of one's update history than removing "Software Distribution" every time you run updates.

to solve this problem temporarily, please downgrade muweb.dll to -> 7.6.7600.256 work without delete additional file!!1!
see -> http://www.msfn.org/board/topic/173049-windowsmicrosoft-update-not-working-on-windows-2000xp2003/?p=1089371

X86
http://download.windowsupdate.com/v9/1/microsoftupdate/b/selfupdate/WSUS3/x86/Other/muweb.cab

X64
http://download.windowsupdate.com/v9/1/microsoftupdate/b/selfupdate/WSUS3/x64/Other/muweb.cab