Skip navigation
1 2 Previous Next

PatchZone

17 Posts authored by: jkuvlesk Employee

Thinking about migrating to ConfigMgr 2012?  If so, you should register for this webcast to hear some of the lessons learned over the last 5 years of use with ConfigMgr 2007 with Matt Hudson & Chris Nackers, both SCCM MVPs.  This webcast will cover what problems plague all environments, how some problems are solved with 2012 and how some will never change. This will be an open discussion where we can talk about how the community has solved or failed at solving various problems with ConfigMgr.   

 

Register here: http://bit.ly/ULdXiw

 

Have any burning questions?  Please list questions in the comments section of this post, or ask them during the presentation.

c, It’s patching time; Microsoft released Patch Tuesday updates for September yesterday. Microsoft released only 2 updates and none of them marked critical.  However, we should see an Microsoft Internet explorer soon, as they are working to incorporate the latest Flash update. Per a Patchmanagement.org post, Microsoft is working closely with Adobe to align release schedules as close as possible to ensure Flash Player in Windows 8 and IE10 are always secure.    Updates are light all-around, compared to August.  This month we have seen 3 updates to date from 3rd party application ISVs – Chrome, Firefox and Thunderbird.

 

The two Patch Tuesday updates address four issues in Visual Studio Team Foundation Server 2010 SP1, or Systems Management Server 2003 SP3 or System Center Configuration Manager 2007 SP2.

 


MS12-061 Vulnerability in Visual Studio Team Foundation Server Could Allow Elevation of Privilege

The security update resolves a cross-site scripting (XSS) vulnerability in Visual Studio Team Foundation Server that allows an attacker to inject a malicious script when user visits a specially crafted page using TFS Web access. The script on successful execution can give the attacker elevated privilege access to the user system.

 

 

MS12-062 Vulnerability in System Center Configuration Manager Could Allow Elevation of Privilege

This security update resolves vulnerability in Microsoft System Center Configuration Manager that allows elevation of privilege when the user visits a specially crafted URL. The attacker can pursue or force the users to click the URL, so users need to make sure they don’t click on malicious links.

 

Microsoft Security Advisories

       

Microsoft released the above five security advisories for the month of September 2012, of which the update on ActiveX kill bits seems quite essential. The security advisory sets the kill bits for the following third-party software: Cisco Secure Desktop, Cisco Hostscan and Cisco AnyConnect Secure Mobility Client.

 

Click here to assess your environment against known vulnerabilities for which there is a patch – free for 30 days.

jkuvlesk

Patch Management News

Posted by jkuvlesk Employee Sep 4, 2012

These are some interesting articles we have come across recently.

 

Java Menace

A new zero-day exploit found in Java causes attackers to exploit a vulnerability that can reveal user data. The vulnerability affects all Java Run-time versions.  Since the exploit has been made public users have no but to disable Java software on their machines or patch Java with the update released on 8/30. 

 

Check out how to patch Java error free.

 

The Rise of the “Blackhole” Exploit Kit: The Importance of Keeping Software up to Date

This article, written by Tim Rains of Microsoft, depicts the increase of reported blocks of HTML & JavaScript exploits was due to the emergence of JS/Blacole.  Blacole is a collection of web pages that contain exploits for vulnerabilities in JRE, Adobe Flash & Reader, MDAC and other products.  Often, these exploits target vulnerabilities that are years old.  Hence, the importance of keeping software up to date.

A related article from Security Affairs

 

Cuts in budget may have negative impact on security

A recent survey from InfoSecurity Europe and Tufin Technologies found 48% of companies focus on cost savings at the expense of security.  Sadly, a lack of endpoint security investment can be both dangerous and costly.

 

ConfigMgr (SCCM) – Troubleshooting Tips to Resolve Scan issues in Software Updates

In this blog post, Anoop C Nair walks through the cause and resolution of a software update SCAN error in SCCM, using an example with Windows 2008 R2 core servers.

 

ConfigMgr 2012 product patch servicing model

This post, by Rob Marshall, summarizes key aspects of the new cumulative update servicing model for System Center Configuration Manager 2012.  Some of the key points:
• SCCM will have patches packed together as single SFX bundle that can be read only from server site
• SCCM bundles will have Server and Client patch MSI’s, license files, scripts and files needed for server to deploy patches
• SCCM patches will be distinct for Server, Client and admin console
• Updates Publisher 2011 is the supported tool of choice for importing patches into ConfigMgr.

 

And one more…..
A better guide to setting up SCUP with a Microsoft PKI


Here are two free tools to help you with WSUS server migrations: WSUS Change Upstream Server Tool & WSUS Computer Migrator.

 

WSUS Change Upstream Server

The WSUSChangeUSS utility is designed to be used in conjunction with any WSUS upstream server migration involving a URL change to the location of the upstream server. The utility connects to each downstream server and updates the upstream server URL definition.

 

There are two functions available in this utility:

1)  Export a collection of downstream
servers from a WSUS server to an XML file. The syntax for the export function is:

  WSUSChangeUSS

  /command export

  /dssxmlfile <fully qualified file path to results xml file>

  /sourcewsusname <FQDN or NetBIOS name of the wsus server>W

  [/sourcewsusport <portnumber> /sourcewsususessl < yes | no >]

 

2) Configure a collection of downstream computers specified in an XML file with the parameters of an upstream WSUS server specified in the command parameters. The syntax for the import function is:

 

WSUSChangeUSS

  /command changeconfig

  /dssxmlfile <fully qualified file path to source xml file>

  /sourcewsusname <FQDN or NetBIOS name of the wsus server>

  [/sourcewsusport <portnumber> /sourcewsususessl < yes | no >]

 

A list of the valid commands and arguments are shown below...

 

/command <export | changeconfig>

/sourcewsusname <FQDN or NetBIOS name of the wsus server>

/sourcewsusport <portnumber> (optional parameter; defaults to 80 if not specified)

/sourcewsususessl <yes | no> (optional parameter; defaults to no if not specified)

/dssxmlfile <path to xml file>

 

 

NOTE: This utility requires that the .NET 2.0 framework is installed and the WSUS 3.0 SP1 or later Console or Server is installed (WSUS API)

 

WSUS Computer Migrator

 

The WSUSComputerMigrator utility is designed to be used in conjunction with a WSUS server migration using replication when server-side targeting is used. This tool will populate the existing computers into the correct groups on a replicated server. A reference to this technique can be found here: http://technet.microsoft.com/en-use/library/cc463370(WS.10).aspx

 

There are two functions available in this utility:

 

1) Export a collection of computers and group assignments from a WSUS server to an XML file. The syntax for the export function is:

 

WSUSComputerMigrator

/command export

/xmlfile <fully qualified file path to results xml file>

/wsusname <FQDN or NetBIOS name of the wsus server>

[/wsusport <portnumber> /wsususessl < yes | no >]

 

2) Import a collection of computers and group assignments from an XML file to a WSUS server. The syntax for the import function is:

 

WSUSComputerMigrator

/command import

/xmlfile <fully qualified file path to source xml file>

/wsusname <FQDN or NetBIOS name of the wsus server>

/logfile <xmlfilename>

[/wsusport <portnumber> /wsususessl < yes | no >]

 

Here is a complete list of all valid commands and arguments:

 

/command <import | export>

/wsusname <FQDN or NetBIOS name of the wsus server>

/wsusport <portnumber> (optional parameter; defaults to 80 if not specified)

/wsususessl <yes | no> (optional parameter; defaults to no if not specified)

/xmlfile <fully qualified file path to specified  xml file of list of computers and groups>

/logfile<fully qualified file path to xml file of log results> (only valid for import command)

 

NOTE: This utility requires that the .NET 2.0 framework is installed and the WSUS 3.0 SP1 or later Console or Server is installed (WSUS API)


Want a 3rd free tool?  Check out the Free Diagnostic Tool for the WSUS Agent to help troubleshoot WSUS connection issues.

  • Microsoft was not alone in delivering updates this patch Tuesday.  Below is a synopsis of the updates provided by Microsoft, Google and Adobe.

 

Microsoft Patches
Microsoft Patch Tuesday for August 2012 patches nine security vulnerabilities out of which five are labeled as critical, with updates preventing remote code execution.  The remaining updates are labled as important updates.


Critical Microsoft Updates
Cumulative Security Update for Internet Explorer – This update patches the exploit in Internet Explorer that allows the attacker to gain elevated user privileges via remote code execution in specific crafted webpages.
Vulnerability in Remote Desktop Could Allow Remote Code Execution– This patch prevents a remote code from being executed when the attacker sends a modified RDP packet.
Vulnerabilities in Windows Networking Components Could Allow Remote Code Execution – This update patches a vulnerability that allows remote code execution when a specially crafted response is sent to Windows print spooler.
Vulnerability in Windows Common Controls Could Allow Remote Code Execution– The vulnerability in Windows Common Controls allows remote code execution when the user visits a website that is crafted to exploit this software vulnerability.
Vulnerabilities in Microsoft Exchange Server Web Ready Document Viewing Could Allow Remote Code Execution– This patch fixes the vulnerability that allows remote code execution in the security context of the transcoding service on the Exchange server.

 

Microsoft Non-Critical Important Patches
• Vulnerability in Windows Kernel-Mode Drivers Could Allow Elevation of Privilege
• Vulnerability in JScript and VBScript Engines Could Allow Remote Code Execution
• Vulnerability in Microsoft Office Could Allow Remote Code Execution
• Vulnerability in Microsoft Visio Could Allow Remote Code Execution


3rd Party Application Patches
• Google has released Chrome 21.0.1180.77, a release that fixes many security and stability issues.
• Adobe released Flash 11.3.300.271 which fixes the vulnerability that allows attackers to crash the application and take control of user system by executing malicious code distributed through a Word document. This update also fixes a vulnerability in ActiveX, a version of Adobe Flash player in Internet Explorer.
• Adobe also released Adobe Reader 10.1.4, Acrobat 9.5.2 and Shockwave 11.6.6.636 which fixes a memory corruption vulnerability which could allow remote code execution.

• Oracle Java also released JRE 7u6 & JRE 6u34.

 

For a comprehensive list of recent 3rd party updates, check out this table.

  Complete the Patch Management Survey for a chance to win an Apple gift card, valued at $500.

Microsoft Patches
It’s going to be a busy week for patch administrators as Microsoft released their patch Tuesday updates for July 2012. Microsoft has released 9 bulletins of which 3 are rated critical, with the remaining updates noted as important, resolving a total of 16 vulnerabilities.


Critical Patches
Vulnerability in Microsoft XML Core Services Could Allow Remote Code Execution – This is the most critical update on this patch Tuesday as it resolves the vulnerability in XML Core Services 3.0, 4.0, 5.0 affecting Microsoft Windows, Office and Server Software.
Cumulative Security Update for Internet Explorer– This is a critical update for Internet Explorer which patches the exploit, from which an attacker could execute remote code if the user visits a specially crafted site.  In this case, the attacker could gain control of administrative rights over the system. The patch is critical for Internet Explorer 9 on Windows and Servers.
Vulnerability in Microsoft Data Access Components Could Allow Remote Code Execution This is a critical update that resolves vulnerability in data access components for Windows. If unpatched, could allow attackers to remotely execute code when the user visits a specific page and giving the attacker user rights over the system. The patch is addressed to all Data Access Components in Microsoft Windows and Server.

Non-Critical Important Patches
• Vulnerability in Visual Basic for Applications could allow remote code execution
• Vulnerabilities in Windows Kernel-Mode Drivers could allow elevation of privilege
• Vulnerability in Windows Shell could allow remote code execution
• Vulnerability in TLS could allow information disclosure
• Vulnerabilities in SharePoint could allow elevation of privilege
• Vulnerability in Microsoft Office for Mac could allow elevation of privilege
More information about Patch Tuesday 2012 can be found here.

 

Flash Plugin
Yesterday, there were some rumblings on the Adobe forums regarding a Flash 11.3 update.  As suspected, Flash released- overnight  - the new Flash 11.3.300.265 – perhaps for both Active X and Plugin versions.


This update is not on Adobe’s Distribution Agreement site yet, and no security bulletin has been published, but this update is on the Get Adobe page.

The Chrome 20 patch provided a Chrome updater. This is beneficial because it works like other updaters (Java) where Chrome monitors which level you are at and puts the update in the user's hands.

 

For enterprise customers, using the silent command line to deploy the Chrome patch across their environment (using the chrome_installer.exe), this update produces an error. The work around is to download and install the GoogleChromeStandaloneEnterprise.msi. Per Google, this is the stable release.

http://thwack.solarwinds.com/community/application-and-server_tht/patchzoneBack in the day, patch management had to be done using large spreadsheets, linking each patch to its specific version number in order to track what needed to be patched.  Tracking the software versions to be patched with a spreadsheet can be a nightmare for administrators.  Microsoft improved upon this process with the introduction of Windows Server Update Services (WSUS) in 2007, which made patching Microsoft updates easier.


Today, with the introduction of virtualization, administrators are faced with a different kind of problem: how do you distribute and deploy patches to multiple machines across the network when many of those systems are all shut down?  It is a very time intensive task for admins to turn on off-line physical systems or dormant virtual machines.  
Luckily, there are several approaches to solve for this issue,


• Administrators can announce a particular maintenance time were they can ask users to leave their desktops powered on.
• WSUS has a feature of notifying the user through balloon notification about the available update.  In this case, the desktop must be part of the WSUS automatic patch deployment processes.
• Administrators can use a remote wake up feature using a third party application, so administrators can switch on or reboot user systems remotely.  For virtual machines that are off-line, you can manipulate the bits on the VHD (virtual hard disk) file or you can power the machine on, update the machine using WSUS and then power the machine back down.


Scheduling maintenance time can cause network downtime and may become infeasible in large enterprise as it is difficult to determine whether the systems are turned off or on. And if your organization uses WSUS, end users can deny the update from happening by cancelling it.


Which is the best option?

Wake-On LAN might be the best alternative because you are able to reboot computers after the patch is applied.  Once more, if you are using a patch management tool, you can run a report to see if the patch was successful before you power-down the system.


How do you patch off-line servers & desktops? Please comment and share your experiences!

 

Sign up for alerts on PatchZone news & tips here.

The patching landscape: not a pretty picture.
The landscape of patching is messy.  We see 20 to 30 patches a month for Microsoft.  Those are predictable because they do come out on Patch Tuesday. There are a whole slew of other patches that come out in a month for Java, Adobe, Mozilla, etc. – the list goes on and on.  There are also many dependencies with 3rd party application patches.  For example, Flash is embedded in Adobe Reader, Chrome, and now in IE 10 later this year.  When there is a flaw in Flash, this causes these vendors to also issue patches, so we see a spiral of patch updates.

 

3rd party application patches are more difficult, because they are not predictable, so the workload of the sysadmin dealing with these patches is not predictable.  Almost always, these 3rd party patches are related to a security issue; bug fixes and feature enhancements are rolled out as planned releases.

 

Microsoft, on the other hand, does provide a fair amount of non-security related bug fixes.  About 1/3 of Microsoft patches are related to bug fixes – critical flaws in the product that cause performance issues or configuration settings (day light savings settings for example).

 

When should security patches be installed?
As soon as possible, but the sysadmin needs to take into consideration business need and risk of not updating the patch.

 

Internet facing patches need to be the top priority – a browser, Flash, Java, etc.  Why?  The whole world knows there is a security vulnerability and there are plenty of folks out there ready to exploit those vulnerabilities.  The longer you delay getting the patch deployed, the greater risk on your infrastructure.

 

Servers, especially web servers, mail servers – are an attack target.  Do these immediately.  Desktops/notebooks are less of a direct target.  However, the end user might do something naively or innocently.  Classic example – identity theft, email phishing skemes.

 

When should bug fixes be installed?
It depends.  If a bug fix comes out and if you are if you are not experiencing that bug or using that feature of the software, don’t install the patch.  Don’t increase the risk of instability into your system by installing unessary software.

 

Classic example - a year ago, a fix came out for Remote Desktop.  90% of users were not using.  Do you install across your entire environment?  The better approach is to check to see who is using this component, and apply the patch to those machines.

SolarWinds Patch Manager packages and tests 3rd party applications like Adobe, Chrome, Mozilla, iTunes, etc.  Lawrence, based on our past experience, which of these 3rd party apps are most vulnerable?

 

Lawrence: Most of patches in 3rd party application landscape are security related, and most are related to the user browsing content on-line, in real time.  Security updates that focus on Flash and browsers should be at the top of the list for patching. 

Sadly the majority of infections we have heard about in recent years were for these known vulnerabilities, meaning that a patch was available for Flash, Chrome, etc., but the patch was not deployed to the environment.

The other kind of applications are those used in an off line mode  – like downloading a document or video using Adobe Reader or QuickTime.  These tend to be less vulnerable.  The risk in these situations is end user does something inadvertently.


Has the increased use of content from social sites (videos, files) changed the frequency of threats from these applications? 
Lawrence: Video, in terms of AVI and Windows media files, is not risky because it takes a lot of effort to embed viruses.  Flash is the most frequently used medium for viewing video on line today.  It is not so much the risk from the Flash files, but ways to exploit Flash code through other methodologies.

Security threats for social media are not about direct attacks on players or browsers, but more around the social engineering aspects.  For example, fraudulent posts, and bad links that link to websites designed to steal information.  It is the users who are not savvy on these sites and they unknowingly are attacked.  It’s like the early days of AOL.  Everyone thought AOL was the internet – users did not know what they were doing.  Same situation we have today with Facebook.

 

Do customers need to be concerned about Browser/OS vulnerabilities for their mobile device?
Lawrence: Mobile software, iOS, Windows, etc. are as vulnerable as desktop software.  I have not seen incidences where mobile devices have been directly attacked.  We hear more about security protections on mobile data – password, encryption schemes.  Easy to use, consumer oriented security programs, like 4 digit codes to open your phone, are more of a threat and no amount of patching will solve for that.

Patching mobile systems is not so easy.  Hard to get updates to Windows phones with the mobile carriers being responsible for that – hard for Microsoft to get phones patched timely.  Android gets regularly updated for those people who are savvy enough to get the Android source and install it.  Most people don’t – it’s like installing a new version of Windows.

 

Will we see more patching for phone software?
Lawrence: Not likely until there are more cases of hacks.  I am surprised there have not been more attacks on iOS, because of the prevalence of iOS.  Is it harder to attack a mobile phone?  Maybe, maybe not.  Or perhaps it is the sophistication of the hackers – they don’t have the skill set yet to hack mobile.  It could also be that most mobile phones are protected via the carrier’s network – 3G/4G and not using wireless.

The patch management process varies from organization to organization based on infrastructure size, organizational policy and size of the organization. Smaller organizations may assign a single administrator to take care of patch management and the network, while large enterprise offices may have specific person or a dedicated team to deal with patch management. In all instances, the reason for patch management is to keep applications up-to date, mitigate vulnerabilities and to meet with compliance standards.

Patch management involves a series of responsibilities assigned to a person/team who handles patch management.  Responsibilities include:


• Identifying available patches or threats
• Deploying patches
Compliance assessment & reporting
• Educating stakeholders

 

Identifying the available patches is the first step in patch management.  The administrator should learn about their application landscape. They should be aware of software installed in the user desktops, servers etc. Only when the administrator has awareness about the environment, can they start identifying the necessary software that is needed to be patched.

 

Deploying patches involves testing the patch in test environment for possible errors and then deploying the patch.  After deployment it is necessary to monitor the application environment to determine whether the patch was successful – did it cause performance issues or was the patch deployed to all needed systems.

 

Compliance involves regular audit and assessment of whether applications have been patched for known security vulnerabilities  Audit reports help administrators understand:
• What systems need to be patched for a given vulnerability?
• Are the all systems in compliance?
One aspect of patch management is change management, which involves keeping in track of all updates.  So, if anything goes wrong there is back-out plan-documentation of the version and configurations to roll back to.  This documentation is also helpful in meeting audit requirements.

 

Education involves educating end-users as well management on why patch management is necessary.  With education, you can explain your logic for how frequently updates are made.  Updating regularly may cause system down-time which affects productivity, while not-patching increases the risk of vulnerability. So administrators need to educate users about patch management from security perceptive and also in-term of productivity.

System Center Configuration Manager (SCCM) Pros & Cons
SCCM is popular patch management software among most administrators. A single admin or group of administrators can use SCCM to control the deployment of software patches with ease.  One of the salient features behind the usage of SCCM by most administrators is the simplicity involved in the deployment of patches.
Below are some of the advantages of SCCM:
• The user can automate the software installation across all the systems in the environment
• SCCM directly pushes the updates to the systems without end-user needing to be involved or take action
• SCCM software updates can be scheduled
• SCCM can push updates to ultra-secure computers if proper credentials are provided

 

One may wonder if - SCCM can do so much why you will need a 3rd party Patch Management Software? Well, SCCM has its own disadvantages too. Below are some of the disadvantages of SCCMs:

• No immediate notification for failed updates.  For example, in the case of a user system being corrupted or in the case  of a previous installation failure the updates pushed may fail
• SCUP (System Center Updates Publisher) only provides updates for available catalogued patches.  Many application vendors like Adobe, Google, Oracle, do  not provide catalogs and in this case, the end user is forced to research when these patches become available, build the package, test it, and so on. There are quite a few manual steps to create a package with SCCM:
     -Research the patches needed.

     -Obtain the update installer, run the update installer, and document the pre-installation and post-installation conditions relevant to the update.
     -Create a package definition that encapsulates the metadata about the update, as well as the specific rules used to determine if the update is applicable, if the update is not yet installed, or if the update is already installed.

     -Publish this update package to the Software Update Point (SUP).
     -Synchronize the update package from the SUP back to the Site Server.
     -Build a Deployment Package (or add to an existing Deployment Package).

• Group policy edit and certification is not possible with SCCM
• Rollback of patches is not possible

 

Patch Management with a 3rd party Patch Management Tool
Most 3rd party patch management software seamlessly integrates with SCCM and adds more control and scalability in deploying patches and provides pre-built and tested updates for common 3rd party applications. Big vendors like Adobe, DELL etc. provide catalogs that can be consumed by SCUP. Administrators need to build update packages if the vendor doesn’t provide a catalog. Why spend time in testing, building, deploying (and potentially rolling back updates) when there is plenty of 3rd party patch management software vendors that can automate this task for you?

Importance of Patching Non-Microsoft Applications
Patch Management has become crucial part of IT administration and administrators fell the need to patch the third party software’s or risk the networks security.

Gartner states in its report - report - Top 10 Steps to Avoid Malware Infections that “IT organizations must strive for continuous improvement in vulnerability detection and rapid security patch management, especially in often overlooked non-Microsoft components that are Web-facing.” According to research released last year by the CSIS Security Group A/S, 85% of all virus infections occurred as a result of automated drive-by attacks created with commercial exploit kits – targeting 5 applications: QuickTime, IE, Adobe Acrobat & Reader and JRE.

All Internet-based applications, especially browsers and browser plug-ins (i.e., Adobe and Apple QuickTime), should be a top patching priority.  However, due to the un-predictable nature of 3rd party patches, deployment of non-Microsoft patches is often significantly slower and less organized.

 

How and when to patch Non-Microsoft products
Microsoft products can be patched with Windows System Update Service (WSUS).   However, non-Microsoft patches are not supported by WSUS and administrators can resort to manual patch process or purchase automation software for third party patch management. Manual patching can be done by pushing the software by manually preparing each server for patch deployment. Patch deployment to end-user can by deployed by using Group Policy along with Update Management. By editing group policy windows update agent can scan WSUS server for latest patches. Administrators can define when to deploy and scan the WSUS server for updates.

Another option is patching non-Microsoft products using System Center Configuration Manager.  This product provides the capability for creating the package, but does not provide the content itself – so administrators must still research, package and test the patches.

If going the manual route, administrators should plan patching based on business requirements (security/bug fix) and when they have time to schedule them.  To determine what needs to be patched, administrators can visit the third party sites that have the latest patch information.  Adobe, Oracle, and other ISVs normally describe the contents of the patch and sometimes flag the type of patch (severe, critical security update, bug fix, etc.).  Unless the patch is critical, the good option is to schedule the patch updates once in month so it reduces time spent on patching and prevents application performance issues related to patch updates.

 

Check out this table on Patchzone for the most recent patches available for 3rd party applications.

 

 

Here are some other links for reference:

Microsoft Security Bulletins  http://technet.microsoft.com/en-us/security/bulletin

Adobe Security Bulletins & Advisories: http://www.adobe.com/support/security/

Mozilla Security Bulletins http://www.mozilla.org/security/announce/

Apple Security Bulletins http://support.apple.com/kb/HT1222

Oracle Security Bulletins http://www.oracle.com/technetwork/topics/newtojava/overview/index.html

 

Automating patch management can save a lot of time
The manual route has its limitations.  Researching, building, testing and deploying patches are extremely time consuming tasks.  If your company has a large number of vulnerable servers, you should definitely consider purchasing patch management software.  What you should look for:


• Catalog of 3rd party patches –Most vendors support Adobe, Java and most browsers.
Before and after patch deployment scenarios – especially important for Java.
• A mechanism for scheduling where and when patches are deployed
• Support for creation of custom application packages.
Reporting for vulnerability assessment and patch compliance.
• Scalability – the software should scale to a large number of servers & desktops.

To recap the current state of things for those who might still be getting up to speed -- During the last week of May, 2012, in two separate investigations, F-Secure and the Iranian CERTCC discovered a new, highly sophisticated worm, which we now know colloquially as Flame. What Flame does it and generally how it does it is an entirely different discussion, and we'll not dig into that here, except to discuss one particular issue which was discovered and reported by F-Secure on Monday, June 4, and analyze the lessons to be learned that we all can apply to our own security mechanisms. (A detailed explanation of Flame is available from a number of sources, including Securelist and TWIT's Security Now May 30th podcast.

 

 

In short, Flame exploits a defect in the Microsoft Terminal Server Licensing Services application that generates licensing certificates for Terminal Services clients.  The certificate template, it appears, was configured to allow a code-signing certificate to be created. These certificates all derive from the Microsoft Root Authority.  And, as F-Secure correctly points out, a code-signing certificate from a Microsoft CA is the keys to the kingdom to being able to compromise the Windows Update Agent.


The replication of the worm then leverages this defect along with a couple of other weaknesses in Windows components. First, a man-in-the-middle attack using a spoofed Web Proxy Auto-Discovery (WPAD) Protocol service to intercept client requests to the Windows Update service was used to insert a downloader file onto an unsuspecting client system, and second, insufficient verification of the authenticity of the downloaded file on the part of the Windows Update Agent, thus allowing it to be infected. In this manner a single infected Flame system can replicate throughout an entire  organization in about 22 hours (since every online Windows system will queries Windows Update at least once every 22 hours).

 

Now, to date, the industry has published information on how the replication occurs, but one key question still remains unanswered -- How does the original client get infected in an organization. There must be other non-WU oriented replication mechanisms, so we'll be looking for more information on what else this malware exploits as the investigations proceed. Passing by that missing information for the moment, let's look at a number of mitigation steps an organization can take, in general, but also with respect to this specific threat.

 

 

First, a couple of lessons we learn from Microsoft:

  • Make sure your certificates are only created for exactly the purpose they are intended to serve. For example, a licensing certificate should not ever have had code-signing capabilities! Truly the root cause of much of this fiasco is the improperly configured certificate template in Microsoft's Terminal Services Licensing Server. (It should also be noted that this flaw has been repaired.)
  • Second, isolate your certificate chains of authority so they do not have cross-over privileges between different security domains. There are two flaws in this issue that contributed. First, Microsoft did not isolate the certificate chain between those which must be created by a trusted Microsoft entity (i.e. a Microsoft employee), and those which can be created by an end-user (i.e. a user of Terminal Services who needs to license a TS client). The other is that the Windows Update Agent was configured to trust ALL Microsoft certificates. This is also being remediated, with a forthcoming update to the Windows Update Agent that will trust only a certificate chain expressly created for only the Windows Update infrastructure.


Another contributing factor here is that WPAD is enabled, by default, on Windows systems. Use Group Policy to explicitly configure your organization's proxy configuration (if you require a proxy server for Internet access), or DISABLE this functionality completely if a proxy server is not required. Grant Bugher, CISSP, CSSLP, wrote a great blog post over four years ago about locking down WPAD -- specifically calling out this very type of man-in-the-middle attack as a risk where WPAD was improperly enabled.

 

Finally, using Windows Update as an organizational patching mechanism is a contributing factor. If clients were using a corporate managed patching infrastructure, such as WSUS, the clients would not be looking to go through a proxy server to get updates, they would be connecting locally to a WSUS server. Since the Flame malware expressly traps connection requests going to Windows Update, I believe this risk would be completely mitigated -- although I have not personally inspected the code.

So, to summarize:

 

1. Use and configure certificates only for the specific purpose for which they are needed.

2. Maintain separate certificate authority chains within separate security domains.

3. Disable automatic configuration services -- particularly those that configure functionality you're not using.

4. Implement a centralized patch management system -- and use it to immediately apply KB2718704 which revokes the compromised Microsoft certificate chain.