Reflecting back to 3rd Party Patching - The Unseen Security Threat we saw a scenario that described an attack vector which is much more prevalent than many believe.  Using 3rd party applications and their internal flaws to gain local privileges, which in turn provides a pivot point for other attacks and access throughout your environment.


In reviewing patch management programs I have found many which cover the topic of keeping these aforementioned applications patched, but little to describe the actual process of patching them; only the simple "keep 3rd party applications up to date...".  However, taking this general approach fails to improve the security within your environment.  A number of 3rd party applications leave what many refer to as "patching artifacts" or "software artifacts".  In the situation described in the previous post we have the attacker gaining access through the 3rd party application.  Expanding upon the scenario mentioned in this situation, we find that the patch management process was followed correctly and it was not the update, or lack of updates, that permitted the attackers access, but the artifact that was left behind.  The artifacts are the result of the previous versions either not being removed and/or not completely removed during the installation.  This practice is much more common than one might expect, and is often seen even in default system updates for certain operating systems.


Example 1: Oracle Java

Let's look at this from the software developer’s perspective for a moment.  As you can see, Oracle's Java website even stresses the fact that previous versions need to be completely removed prior to the installation of the latest version.


On a clean installation of Windows 7, fully patched, but running Java version 6 update 37, we begin a typical update process prompted by Java's own notification bubble.  We complete the update and are now at version 7, update 9 .  So we are good to go right?  Wrong, take a moment to look at not only the Java installation, but also the Java Runtime Environment screenshots, which shows that both of these versions are enabled at the same time.  So all the exploits that were available to an attacker prior to the update are still available and fully functional.


So how did the warning on their website, which was not so obviously found, notification bubble, and the update do to protect our systems? Absolutely nothing!

JRE6 Artifact After JRE7 Installation.pngJRE Runtime Settings.png

So maybe this is just a Windows flaw, bug, or feature.  It's not every operating system right? No, below is another screenshot, which came from an Apple OSX 10.8 system, which was recently updated, via Apple's internal patching process.  Apple would certainly remove the previous version, right?

JRE6 Artifact After JRE7 Installation (Apple).png

In reviewing this screenshot we see that not only is Java version 6 update 35 installed from Apple by default, but also we have both the 32 bit and 64 bit versions installed side by side.  So let's do the update shall we, let's update the Java installation to version 7, update 5.  Nope, the same result as the Windows Java update.  Both versions installed and enabled for the attackers pleasure.


This of course is just isolated to Oracle and Java right? Negative, this is actually very common if you begin to look around closely at your 3rd party applications.


Example 2: VanDyke SecureCRT

Just so that everyone doesn't think I am picking on Oracle here, let's look at a program I have used in the past and actually truly enjoy having installed when I work in a Windows environment. VanDyke's SecureCRT is described on their website as:


SecureCRT for Windows, Mac, and Linux provides rock-solid terminal emulation for computing professionals, raising productivity with advanced session management and a host of ways to save time and streamline repetitive tasks. SecureCRT provides secure remote access, file transfer, and data tunneling for everyone in your organization.


It's a program developed with Security in mind correct? They would certainly make sure no artifacts were left behind after an update right? Yet again we find ourselves facing the artifacts of patching and updating...

SecureCRT Artifcat After Upgrade.png

In this screenshot we see version 5.5 and version 6 installed side-by-side, again sitting there waiting for an attacker to begin their assault on your systems.


Some thoughts on why

So why does Oracle do this with Java, VanDyke do this with SecureCRT, and other software development companies follow suit?  I mean Oracle even warns you on their website not to have both versions installed, to completely remove the previous version.


The answer remains unanswered, but the theory is that many large corporations use these applications within their internal application development and they want to provide the opportunity to install the new version while preserving the previous version just in case issues begin to surface.  This is great in theory, however in practice this has become a hidden treasure for attackers.  Little Egyptian artifacts spread across your environment just waiting for the next tomb robber to sneak on in and steal your most vital data.



In closing, when you are developing the patch management processes and beginning the deployment of updates to 3rd party applications, let's look at the artifacts being left behind.  Maybe having version 6 and version 7 of Java installed on the same machine just in case you run into an issue isn't such a great idea after all.  Let's go back to the The Patch Management Process: 5 Common Sense Tips and consider building into our process a much needed step two, "Development / Testing Environment", this way you can have your testing completed and all bugs corrected prior to the update rolling out.  This way you can roll out the removal of the previous version first, and then roll out any updates or upgrades you might require.

Greetings all.


Today we have implemented a discussion forum in PatchZone. You can access the forum from the Discussions link on the Content tab of PatchZone.

PatchZone - Discussions link.png


Within the discussion forum we have defined three categories of conversations:

  • Patches - intended for discussions directly related to patch content. This would include Microsoft patches, 3rd party patches (Adobe, Apple, Oracle, etc.), or your own custom patches. We encourage software vendors to participate in this forum and represent their patches to the community.
  • Patch Management Products - intended for discussions related to specific patch management products, including how-to's, product comparisons, feature descriptions. We encourage patch management product vendors to participate in this forum and represent their products to the community.
  • Patch Management Practices - intended for discussions related to the "how to" of patch management, but without any specific consideration for what particular product you use to do this, or what products you might be patching.


When you create a new post in the discussion forum, you can select one, or more, or none of those categories for your post.

You'll find a set of checkboxes at the bottom of your post just before the Post button.

If your post does not fit into one of those categories, you can leave all three unchecked.

PatchZone Discussion Category Selection.png

When you view the discussion forum, you can quick-filter on one of those categories by clicking on your choice in the Categories column. Posts that do not have a category checked, will be visible in the unfiltered view of discussion content.

PatchZone Discussion Category Filtering.png

Today Microsoft announced the forthcoming content for Patch Tuesday -- Dec 11, 2012.


You can have Microsoft's security bulletins sent directly to you:

To receive automatic notifications whenever Microsoft Security Bulletins are issued, subscribe to Microsoft Technical Security Notifications.

Microsoft also hosts a webcast where they discuss the releases, typically the Wednesday after Patch Tuesday:

Microsoft will host a webcast to address customer questions on the security bulletins on December 12, 2012, at 11:00 AM Pacific Time (US & Canada). Register now for the December Security Bulletin Webcast. After this date, this webcast is available on-demand.

You can also follow the MSRC team at @MSFTSecResponse.

Number of Releases: 7

Number of CVEs addressed: 11

Critical Security Updates: 5 addressing vulnerabilities in Windows, IE, Office, and Exchange Server (2007 & 2010)

Important Security Updates: 2 addressing vulnerabilities in Windows


Updates are typically released by Microsoft at 10am PT (6pm UTC).

Configuring WSUS servers to synchronize relative to that time can be helpful in expediting availability of these security updates.

It's the big day.  You've got your rollout plan in operation, tested your patches and sent out your communications, yes you’ve guessed it, it’s patch rollout time. Patch days seem to go one of two ways: they are either very quiet or get very busy.  Walking into the office on a patch rollout day is always one where you dread to look to see if you have a voicemail waiting already as that's not usually a good sign. Managing the rollout and keeping track of how it’s going are very important and essential if you are going to spot any issues early.  During a patch rollout you will want to have several checks during the day to make sure that everything is running ok.


Helpdesk Monitoring:

When users have an issue with a patch their first port of call will be the helpdesk. Keeping in touch with your helpdesk during the day to see what the call volumes are like is always a good idea and helps to spot any issues early on.  Typically calls will be where there is an issue with a particular patch or application.


If there are issues being reported then you will need the following information from your helpdesk:

  • How many users are affected? (This is important because if you have 500 successfully patched machines and only 2 failures, it might not be patch related!)
  • Is the issue occurring on any machines that don't have the patches applied? (Helps to identify if it’s actually a patch issue or system issue.)
  • Steps for recreating the issue. (What was the user doing to get the error? The key is for you to be able to test it yourself on a patched and non-patched machine.)
  • Has the issue occurred previously? (If it’s occurred before, how was it fixed? Again helps to prove if the patches are at fault or not.)


Based on this information you can then start to investigate further and decide whether a patch is actually at fault or if the issue is unrelated.


Hopefully though when you check with your helpdesk there won’t be many calls at all.


System Monitoring:

Many automated patch tools have reporting built in so that you can see the progress of your rollout and easily view how many machines are showing as successfully patched and how many have reported a failure.  It's also important to check that your patch system is running ok.  The last thing you want on a rollout day is for your patching system to fail so regular health checks are key.  You may already have these automated but it never does any harm to manually check the system as well.


Backout Plans:

Most patch rollouts will not have any issues but there's bound to be the odd occasion when you may be asked to stop a patch rolling out or remove a patch.  It’s important therefore that you:

  1. Have a process for stopping a patch rollout.  This may involve changing the status of a specific patch or re-creating the rollout without the affected patch.
  2. Have a process for removing a specific patch.  Most patch management tools have an option to allow you to remove a previously installed patch.  If yours doesn't then a script to run the removal command line of the patch would work or you could remotely connect and remove it.
  3. Ensure that you have good evidence that a patch is causing the issue.  There are occasions when people will panic and want a patch stopped before you’ve even looked at it.  Taking the time to go through the helpdesk checks above will ensure that you have tracked the issue to the patch rather than it being an unrelated issue.


As I said in my first blog, Patch Planning: Steps for an Effective Patch Management Process, patching is never straight forward but hopefully you'll find that you have more successful patch rollouts than you do issues.

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.