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.

 

Recommendations

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.