KB#:  KKB000904

BACKGROUND

Microsoft has released an update to the Windows Update Agent (WUA) that is referred to as the WUA SelfUpdate.  This update is intended to harden WUA to prevent malicious attacks such as the recent FLAME malware (http://www.wired.com/threatlevel/2012/06/flame-microsoft-certificate/).  Microsoft has approached this update using a modified Controlled Release methodology.  The exact criteria regarding the timeline is unknown.  Microsoft has not made available a stand-alone installer or provided a hook through the WUA.api (which Kaseya leverages) to trigger the SelfUpdate.

At this time, not all Windows OS machines are eligible for the SelfUpdate.  However, we have found that for those endpoints that are eligible for the SelfUpdate (as determined by Microsoft), those that are configured to download patches from the internet OR any patches that are tagged as “Internet-based Install Only” may fail to install.   Both of these methods of installation leverage the Windows Update Agent on the local machine.  This failure is attributed to the requirement by the Windows Update Agent to complete the SelfUpdate process before patches can be installed.  The WUA.api cannot trigger the SelfUpdate.  Therefore, these patches may fail on endpoints that are eligible for the SelfUpdate when WUA is used for installation.

The SelfUpdate is not a traditional patch.  Traditionally, when a patch scan runs on a machine (whether that scan is called by Kaseya through the .api OR when a user or admin leverages the “Check for Updates” function within the local Windows Update/Automatic Update/Microsoft Update utility), WUA communicates with Microsoft to discover the patches that are missing from and applicable to the endpoint.  WUA writes the results into c:\Windows\WindowsUpdate.log and, if Kaseya requested the scan, will hand the results to Kaseya’s patch .dll for Kaseya-specific processing.  However, this self update process is not part of a typical patch scan.  Instead, WUA is checking whether the update is needed prior to actually scanning for missing patches.  In the WindowsUpdate log, the process looks similar to this (actual entries may vary based on the system, but the general information should be similiar):

2012-07-07         10:42:19:416       1136      e58       Setup     Checking for agent SelfUpdate

2012-07-07         10:42:19:416       1136      e58       Setup     Client version: Core: 7.5.7601.17514  Aux: 7.5.7601.17514

2012-07-07         10:42:19:416       1136      e58       Misc      Validating signature for C:\Windows\SoftwareDistribution\WuRedir\9482F4B4-E343-43B6-B170-9A65BC822C77\muv4wuredir.cab:

2012-07-07         10:42:19:416       1136      e58       Misc      Microsoft signed: Yes

2012-07-07         10:42:23:020       1136      e58       Misc      Validating signature for C:\Windows\SoftwareDistribution\WuRedir\9482F4B4-E343-43B6-B170-9A65BC822C77\muv4wuredir.cab:

2012-07-07         10:42:23:020       1136      e58       Misc      Microsoft signed: Yes

2012-07-07         10:42:23:035       1136      e58       Misc      Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:

2012-07-07         10:42:23:035       1136      e58       Misc      Microsoft signed: Yes

2012-07-07         10:42:26:717       1136      e58       Misc      Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:

2012-07-07         10:42:26:732       1136      e58       Misc      Microsoft signed: Yes

2012-07-07         10:42:28:074       1136      e58       Misc      Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab:

2012-07-07         10:42:28:090       1136      e58       Misc      Microsoft signed: Yes

2012-07-07         10:42:28:105       1136      e58       Setup     Determining whether a new setup handler needs to be downloaded

2012-07-07         10:42:28:105       1136      e58       Setup     SelfUpdate handler is not found.  It will be downloaded

2012-07-07         10:42:28:105       1136      e58       Setup     Evaluating applicability of setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.6.7600.256"

2012-07-07         10:42:28:776       1136      e58       Setup     Setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.6.7600.256" is applicable and needs to be downloaded.

2012-07-07         10:42:28:776       1136      e58       Setup     Evaluating applicability of setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256"

2012-07-07         10:42:28:823       1136      e58       Setup     Setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256" is applicable and needs to be downloaded.

2012-07-07         10:42:28:823       1136      e58       Setup     Evaluating applicability of setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256"

2012-07-07         10:42:28:885       1136      e58       Setup     Setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256" is applicable and needs to be downloaded.

2012-07-07         10:42:28:885       1136      e58       Setup     SelfUpdate check completed.  SelfUpdate is required.

 

After the SelfUpdate completes, the patch scan process proceeds.  Again, this check for the SelfUpdate does not appear to run when the scan is requested by a third-party such as Kaseya.  Rather, the check occurs when the Windows Update Agent locally creates a connection with Microsoft and when Windows Update policies are not implemented (Windows Update policies can be controlled using utilities such as Group Policy or Kaseya > Patch Management > Windows Auto Update.  Details are available here:  http://support.microsoft.com/kb/328010).  This connection appears to occur when the endpoint is configured to get patch information automatically from Microsoft.  

In previous updates to the Windows Update Agent, Microsoft has published a .cab file containing download URLs that allow third parties to trigger the SelfUpdate via the WUA.api (detailed here:  http://msdn.microsoft.com/en-us/library/windows/desktop/aa387285(v=vs.85).aspx).  In one such update, Microsoft did not update the .cab file until the end of the controlled release, but a stand-alone installer was made available for download, which Kaseya was able to distribute to endpoints to force the update.  With this release, Microsoft has not provided these tools which has left third-parties, including Kaseya, without a reliable way to trigger the SelfUpdate.

WORK-AROUND OPTIONS

At this time, we have identified four potential work-arounds to the SelfUpdate issue.  Each has some inherent benefits and considerations, and you may find a combination of these could benefit your environment.  As we have additional information, and/or if we confirm any additional options to address this issue, we will provide an update.

OPTION 1:  Attempt to force the SelfUpdate through custom Agent Procedures

The steps outlined below have proven successful in some, but not all, situations.  We cannot at this time predict the components necessary to lead to 100% successful results.  However, we do know the following:

  1. The endpoint must be deemed by Microsoft to be eligible for the update
  2. The update must be able to complete in the amount of time given in the Pause step (actual time to complete will vary based on environment, connection speed/bandwidth, available resources, Microsoft response time, etc.; admins may need to test various pause times to ensure sufficient time is granted).
  3. The endpoint/user must have appropriate access and rights to complete the installation.  This will depend on your configuration.
  4. The endpoint must be running XP or later.  Win2000 machines do not run reg.exe which is required for some of the steps.

=====================================================================================

***This process provides the high-level details necessary to create a set of custom Agent Procedures to backup then clear the necessary registry settings, attempt to force SelfUpdate, Reboot, then restore the registry settings to the original entries (a reboot prior to the restore is often, but not always, required).

*** Uses REG.exe available beginning on Windows XP (NOT available on Windows 2000!)

*** #workingDir# can be any directory

*** WUA version can be found in machines ptchscn2.xml file after a Kaseya patch scan

    or in C:\Windows\WindowsUpdate.log

*** The latest WUA version (following a successful self-update) will be 7.6.7600.256

=====================================================================================

** Start the process to attempt a forced self-update

-- Backup the "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" registry node

REG.exe EXPORT "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" "#workingDir#\WinAU.reg"

 

-- Backup the "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU" registry node

REG.exe EXPORT "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU" "#workingDir#\WinAUPolicies.reg"

 

-- Stop the WUA service

NET STOP wuauserv

 

-- Delete specific Windows Update registry values

REG.exe DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /va /f

-- Delete Windows Automatic Update Policy keys

REG.exe DELETE "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /f

 

-- Add the necesary values (Windows Update configured to notify but no download/install)

REG.exe ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v AUOptions /t REG_DWORD /d 2 /f

 

-- Restart the WUA service

NET START wuauserv

 

-- Attempt to force selfupdate

wuauclt.exe /DetectNow

 

-- Pause to give self-check and self-update time to complete (5 - 10 minutes ??)

PAUSE <configure appropriate pause time>

 

-- Reboot is sometimes required to complete self-update

REBOOT

 

** After reboot, restore registry to original settings

-- Stop the WUA service

NET STOP wuauserv

 

-- Delete Windows Update registry values set above

REG.exe DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /va /f

 

-- Restore registry backups

REG.exe IMPORT #workingDir#\WinAU.reg

REG.exe IMPORT #workingDir#\WinAUPolicies.reg

 

-- Restart the WUA service

NET START wuauserv

 

OPTION 2:  Configure patches to install from a LAN share or the System Server

This option should allow most or all patches to install on endpoints.  Distributable patches do not leverage WUA for installation.  Only those patches that are tagged as “Internet-based Install Only” should continue to fail (until SelfUpdate is completed on the endpoint).  To configure a LAN share, please complete the steps outlined in KKB000781.  Alternatively, choose to install the patches via the KServer by configuring endpoints to use the Patch Management > File Source option of “Pulled from System Server”.  If you choose to install patches via the System Server (KServer), ensure the Kaseya install drive has sufficient space to host patches for your environment.  Also ensure your KServer has available resources – including RAM, processor, and bandwidth to account for the increased workload.  For additional detail regarding File Source Configuration options and benefits and considerations of each, please review the Patch Management TechJam slide deck or Patch Management TechJam recorded presentation.

OPTION 3:  Leverage Machine Update

Regardless of the File Source configuration, Machine Update will cause distributable patches to download to the endpoint (either from the internet or via the LAN share or System Server) to the endpoint’s defined working directory.  Once downloaded, the patches are installed via command line.  This process is the same as when an endpoint is configured to use a LAN share, but will allow those endpoints that are configured with a File Source of “Download from Internet” to bypass the WUA installation process and instead use the distributable file for install.  Patches tagged as “Internet-based Install Only” will continue to fail if the SelfUpdate is needed but not present.

OPTION 4:  Request User Assistance/Log on locally to endpoints

Request your users launch Windows Update/Microsoft Update on their local machines and run a scan for missing patches.  This may not be a desirable option as it requires action on behalf of the end users and may lead to the installation of unintended patches.  However, in some envrionments, admins may find this to be a suitable alternative.  Launch the WUA Update client (the name will vary based on the Operating System, but should be called Automatic Update, Microsoft Update, or Windows Update) from the Program Menu or Control Panel.  Instruct users to click the appropriate button to complete a Scan (if prompted, choose “Custom” not “Express”).  The button name may vary based on the OS, but should be easily identifiable on the main screen of the update client.  Running the local scan should force any eligible endpoint to complete the SelfUpdate.

KASEYA’S PLANS GOING FORWARD

Kaseya is actively monitoring for a stand-alone installer release from Microsoft, for an update to trigger SelfUpdate via the .api, and for the release of specific URLs that can be used to push the update via the .api.  As soon as any of these become available from Microsoft, Kaseya will leverage the appropriate tools to assist with the SelfUpdate in a more streamlined fashion.  Past releases of SelfUpdate by Microsoft have included at least one of these functions, and the Kaseya processes built utilizing those tools have been very successful.  We are prepared to implement an integrated solution as soon as these key pieces are made available by Microsoft.

 

RESOURCES

http://blogs.technet.com/b/msrc/archive/2012/06/06/security-advisory-2718704-collision-attack-details-wu-update-rollout.aspx 

http://www.wired.com/threatlevel/2013/03/flame-windows-update-copycat/