You've Got Mail! - The PFF File Format

My recent experimentation and blog post on the analysis of the Microsoft Extensible Storage Engine (ESE) database used by Microsoft  Windows Desktop Search (WDS) prompted me to begin looking at other ways Microsoft utilizes the ESE file format. Microsoft Outlook also utilizes the ESE in the form of the Personal Folder File (PFF) format. This includes the Personal Storage Table (PST) and Outlook Storage Table (OST) files which are commonly known as Outlook Data Files. The former (PST) is used in a non-enterprise setting when configuring outlook with email services such as pop/smtp and the later is created in enterprises with Outlook cached mode is enabled. Other forms of PFF include the Personal Address Book (PAB).

Joachim Metz has also done a fair amount of research on the PFF file structure as part of his libpff project. During the time of his research, the PFF file format was largely unknown. In 2010, however, Microsoft published the open specification on the PFF format and made it available as part of the MSDN Library.

The first four bytes of the file header contains the file signature of "!BDN " (0x2142444e). The 9th and 10th byte contain the content type which is 'SM' for PST (0x534D) and 'SO' (0x534F) for OST.

 
Metz's libpff pffexport utility will parse either file type. Once parsed, pffexport exports the following information on messages;

• Internet Email Headers
• Outlook Headers
• Conversation Index
• Recipients
• Message Body 
• Attachments 

Prior to Outlook 2007 there were three forms of file encryption available for PFF files; none, compressible, and high encryption. Metz documents the following about the two later options;

...actually more of a way to obfuscate the information in the PFF than real means to ensure confidentiality....

Microsoft's Open Specification document on the PST file structure also confirm Metz's findings on PFF encryption prior to Outlook 2007. They now recommended the use of Encrypted File System (EFS) or BitLocker Encryption to secure these files. Consequently, versions of Outlook after 2007 use compressible encryption and high encryption is no longer available.

Additionally, Microsoft Outlook allows users to set a password on their PST files. This password however, is a weak 32-but Cyclic Redundancy Check (CRC32) and consequently, is subject to collisions. This has been know for quite some time and Microsoft has documented this;

The PST Password, which is stored as a property value in the Message store, is a superficial mechanism that requires the client implementation to enforce the stored password. Because the password itself is not used as a key to the encoding and decoding cipher algorithms, it does not provide any security benefit to preventing the PST data to be read by unauthorized parties.

Metz clarifies this a bit more in his research. Applications, such as Microsoft Outlook, are conforming to the password protection but in reality, none of the data is actually protected by the password. Consequently, the libpff pffexport utility can export all items stored in the PFF file without supplying the password.

The libpff utility was able to parse the email headers and content on both the PST and OST files during my testing.

This certainly could be useful to forensics practitioners. The aforementioned, lack of security of these files however got me thinking more about the use of products such as Outlook Anywhere (RPC over HTTP) in the corporate world. Outlook Anywhere allows users to access corporate email on their personal computers using Microsoft Outlook. Consequently, corporate email would be stored in the local PFF file on the user's home system. Unless Whole Disk Encryption or other means were being used to secure the file system, then the potential risk to the intellectual property of corporation could be significant.

Happy Hunting!

Hacking a Fix

There have been many discussions, rants, and commentary on what it means to be a hacker. Many of us in the security community use the term in its original intended use and despise the way the media and popular culture portrays it. Hacking to many of us is about learning and using that knowledge to make improvements upon software and hardware. I have previously posted about the resourcefulness of people that define themselves as hackers. My coding skills are certainly not L337 and I am certainly not dropping 0-day but what I am very skilled at is understanding technical issues and finding unique solutions to them. This post is on one such issue and my obsession to fix it.

The Backstory

I recently exchanged emails with APC support on their use of a self signed certificate for SSL access to the web management interface of Powerchute Network Shutdown (PCNS). Powerchute Network Shutdown is used in conjunction with APC Universal Power Supplies (UPS). The product is used to manage and shutdown servers during power issues and outages. The most recent release is version 2.2.4.

In previous releases, APC did not support SSL for remote access to the web interface of PCNS. Although the current version now defaults to https, it only supports the use of a self signed certificate provided by APC. The risks of self signed certificates are well recognized. Such configurations can make a Man-in-the-Middle attack on an https session trivial.

While using a firewall to limit access to the web application or disabling the web service are certainly viable options in some environments, it may not be in others. Since I have a lot of free time during my commute and I tend to obsess about such things, I decided the fix the issue myself.

Poking the Source Code

By default APC PCNS can be found in the C:\Program Files\APC\PowerChute\group1 directory of a Windows system. The software is also available for several *nix distros, so consult the documentation as needed. The web server runs on port 6547 and is hosted on Jetty (Version 6.0.0). By default, version 1.5.0.18 of the Java Runtime Environment (JRE) is installed in C:\Program Files\AP\jre\jre1.5.0_18 directory.

Although this version of JRE has had its share of vulnerabilities, that is not the focus of this post (although if your reading this APC you may want to consider updating your shit).

I began by decompiling the .jar files associated with the application with Java Decompiler by Emmanuel Dupuy. A nice feature of Java Decompiler is its search capabilities. This is very useful to find what you’re looking for quickly or in my case stumble through the source code awkwardly. I quickly located the WebServerSettings class in the webServer.jar file.

Yes that is the password to the Java keystore hardcoded. Convenient isn’t it?

Certificate Management Hell

So using this newly obtained password we can view the current self signed certificate within the Java keystore with keytool utility included with the runtime environment.

>keytool -list -v -keystore "C:\Program Files\APC\PowerChute\group1\keystore"

Once found, I removed the current keystore entry, generated a new one, and created a csr for submission to my CA.

>keytool -delete -alias securekey -keystore "C:\Program Files\APC\PowerChute\group1\keystore"
>keytool -genkey -alias securekey -keystore "C:\Program Files\APC\PowerChute\group1\keystore" -dname CN=win7.securitybraindump.com,OU=Infosec,O=SecurityBraindump,L=Boston,S=Massachusetts,C=US"
>keytool -certreq -alias securekey -keystore "C:\Program Files\APC\PowerChute\group1\keystore" -file securekey.csr

Please note the following are the default values for the keytool -genkey option. You may want to change these to suit your requirements.

-keyalg "DSA"
-keysize 1024
-validity 90
-sigalg (Depends on the key algorithm chosen.) If the private key is "DSA", -sigalg defaults to "SHA1withDSA" or if "RSA", the default is "MD5withRSA".

For the purposes of this post I used a Windows 2003 CA (yes that is as ugly as it sounds but it is what I had readily had available at the time). To submit the csr to the CA, obtain my certificate, and export the CA Root certificate (for the chain) I used certreq.

>certreq -Submit -attrib "CertificateTemplate: WebServer" securekey.csr securekey.cer
>certutil -ca.cert rootca.cer

The base-64 certificates can then be imported into the keystore using the -import option.

>keytool -import -trustcacerts -v -alias rootca -file rootca.cer -keystore "C:\Program Files\APC\PowerChute\group1\keystore"
>keytool -import -v -alias securekey -file securekey.cer -keystore "C:\Program Files\APC\PowerChute\group1\keystore"

Once imported, verification can be accomplished by using the keytool -list option again.

After, installation, you must restart the PCNS1 service. Once restarted you can now enjoy your new, shiny, valid certificate. You may also want to consider changing the keystore password. While this is trivial to do using the keytool utility, the webserver.jar file will need to be altered to reflect the change and then recompiled using the JDK. For this reason, most of the Java development forums I read noted that hard coding the password is not practical. From a security perspective, no matter where the password is stored, you must trust the system storing it. Although I would suspect using the same static password across multiple independent systems is not ideal. If you have experience with the development and security of such systems I am interested in hearing your thoughts on this.

The "R" Word

So what is the Risk? As I mentioned earlier, using a self signed certificate is risky in regards to Man-In-The-Middle attacks. Users tend to ignore certificate warnings. Moreover, it is very feasible to pass a victim the legitimate self signed certificate during an attack. Consequently, the use of a self signed certificate is not providing much protection except against passive sniffing. If the web session to APC PCNS is hijacked, then the credentials to the application could become compromised. Once access is gained, one obvious scenario would be a Denial of Service (DOS) attack by shutting down the systems controlled by the application. I wanted to find something a bit more nefarious, however. It so happens that PCNS allows administrators to not only shutdown systems when events are triggered but also run command files.

Note that the command file does not need to be located on the server being attacked. It also should be noted that if running multiple executables from a command file, the following syntax needs to be followed due to a bug in the current release (thank you readme.txt). Note: quotes are only needed if the path contains spaces.

@START "some path\evil.exe" arguments
@START "some otherpath\pwn.exe" arguments

I'll let the output from my evil.cmd file containing the "whoami > whoami.txt" command speak for itself;

 nt authority\system

NUM! Happy Hunting!

Guest Post on the SMB Minute

Today The SMB Minute has blogged a post written by myself entitled; Those Who Cannot Remember the Past are Condemned to Repeat it. The SMB Minute is a podcast/blog focused on small and medium businesses. Aaron and Tim's goal is to talk tech for the business community by putting things into terms easy for the non-technical to understand. Thank You to both for entertaining my thoughts and ideas.

The Open Source Vulnerability Database

I had the opportunity to listen to a great interview on episode 19 of the Tenable Network Security Podcast during my morning commute yesterday. The interview was with Jake Kouns the President and co-founder a of the Open Security Foundation which oversees the Open Source Vulnerability Database (OSVDB) and the DatalossDB. The interview is certainly worth a listen and for those not familiar with OSVDB, take a few minutes to check it out. To quote OSVDB's about page;

OSVDB is an independent and open source database created by and for the security community. The goal of the project is to provide accurate, detailed, current and unbiased technical information on security vulnerabilities. The project will promote greater, more open collaboration between companies and individuals, eliminate redundant works, and reduce expenses inherent with the development and maintenance of in-house vulnerability databases.

I just wanted to take a few minutes to point out the interview and OSVDB's Winter 2010 Fundraiser. So if you use the database please consider donating as it is a fantastic resource that would be missed.

Is a Warning a Mitigation?

On Friday the good people at The Internet Storm Center posted some notes on a readers experience with a recent targeted phishing attempt of his corporate OWA (Outlook Web Access) users. The email used to target the end users is convincing. It explains that their mailbox settings have been changed due to a security update and includes a hyperlink to what appears to be an URL residing on the corporate domain. Once clicked, the unsuspected recipient is brought to another site that offers up an executable containing the ZBot Trojan.

Soon after reading the post, I chatted with a few people who stated that they too had witnessed this attack at their place of employment. None of this is very surprising to me, except that it does not seem to occur more often. At first glance, one might be inclined to believe this is a low risk attack vector. It's just OWA right? I disagree however. Many organizations allow OWA untethered from the internet. OWA runs on Microsoft Exchange which indicates it is a Microsoft Active Directory environment. In almost all cases OWA is using the same login credentials that is used to authorize the access to corporate resources such as Windows end nodes, file shares, VPN's, databases, and web applications. It is the "keys to the kingdom" if you will. Combine this with end users running as local adminitrators and there are multiple opportunities for compromise.

OWA has been no stranger to vulnerabilities in the past. An URL redirection vulnerability affecting Exchange 2003 has gone unpatched and almost unnoticed by many Exchange administrators for years. With the exception of some frustrated forum posts from a handful of systems administrators and security practitioners, there seems to be little mention of the issue. The user is presented with the organizations OWA login page and after providing credentials is redirected to the attackers server. An example of the redirected URL:

https://[victim]/exchweb/bin/auth/owalogon.asp?url=http://[attacker/file.exe]

Such vulnerability would only make the aforementioned phishing attempt more effective. The Open Web Application Security Project (OWASP) recently released release candidate 1 of the The Top Ten Critical Web Application Security Risks of 2010. Number eight on this list is  UnvalidatedRedirects and Forwards. To quote the summary of this risk:

"Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages."

Again there is no official Microsoft patch for the issue but the aforementioned OSVDB link does contain a comment describing a mitigation tactic. By hard coding the redirectPath variable in login.asp to you company's full URL path for the locale you’re using, you can prevent the redirection. It should be noted however the redirectPath should be hardcoded in each of the locale's being used (i.e. language set in the user’s browser). While Exchange 2007 is not affected by this example it is affected by a similar URL Redirection described here. Upgrading to Exchange Service Pack 1 or higher fixes the issue.

So I am not sure why I was surprised when I recently received an email from one of the email lists I subscribe to. In it, Dan from http://www.madjic.net/ describes a similar redirection issue with Exchange 2007 SP1. He had verified that with some modifications, URL redirection is still possible via:

https://[victim]/owa/[user]@[victim]/redir.aspx?URL=http%3a%2f%2f[attacker/file.exe]

One would need to include the victim's login name but this would be trivial since in many Exchange environments the email address is the same as the Windows username. Now here is the rub. Once redirected the end user is presented with the following warning:

So my question is this; is a warning a mitigation? (Please comment as I am truly curious on everyone's opinion on this) While certainly an improvement, I would not consider it a fix or mitigation. Users have a tendency to click through warnings. SSL Certificates are a great example of this. This actually reminds me of another Microsoft mitigation from almost a decade ago (I am dating myself now).

This warning was included in Outlook 2000 Service Pack 2 and above and was a direct result of worms such as the ILOVEYOU virus which leveraged VBA in Outlook to spread to the others in the victims contact list. Did it stop the propagation of such malware?

Certainly properly architecting OWA and placing it behind a proxy with appropriate ACL's that restrict outbound connections would be a better solution than a warning. This may not be feasible for small businesses, however. End User education is always a must but with spam and attacks becoming more streamlined and targeted this is not a realistic solution in itself. I purpose the better solution would be to provide systems administrators with an easy way to turn redirection off (that is a hint Microsoft). Hey let's get a bit crazy! Let's make the default setting be disabled.

I think most of us understand the concept of the path of least resistance. Attackers will always take the road that is less bumpy. History has proven that phishing, is one such avenue. Many attack vectors have come and gone but yet phishing attacks still exist. Let’s not give the bad guys anything that is going to make their jobs any easier. Now go forth and mitigate!

Adobe's "0 Face"

As you may already know, Adobe acknowledged another public security vulnerability in their products on December 15, 2009. APSA09-07 affects all current and earlier versions of Adobe Acrobat and Reader with JavaScript enabled and is currently being exploited in the wild. There is no doubt Adobe products have been in the cross hairs of attackers over the past two years and Adobe's use of JavaScript seems to provide an easy opportunity for exploitation.

Upon reading the advisory, it was no surprise that disabling JavaScript was the mitigation. Many users in my environment do not use this functionality and it can easily be turned off via the Windows registry. The problem is it does not remain off. When opening an Adobe JavaScript enabled .pdf the user is presented with a prompt to re-enable JavaScript. To date Adobe does not provide any way to permanently disable JavaScript via the Adobe Reader preferences menu or the registry. We all know how useful warnings are for end users right? <insert self-signed ssl certificate here> But I'll save the use of a warning as a form of mitigation of badly thought up functionality for a later blog post.

<my rant>

So Adobe products are increasingly being targeted and although Adobe seems to have picked up the pace with their security stance, I have often questioned if they have enough internal resources to do anything but be reactive. Once again, a zero day leveraging JavaScript in an Adobe product is flying around and the patch for this vulnerability will not be available until January 12, 2010. In my opinion, this is unacceptable. Adobe seems to be struggling with putting out the fires and are not being preventative by fixing their code or providing systems administrators with the tools or patches they need to properly mitigate. I can personally tell you my corporate IDS and Antivirus have been lighting up like a Christmas tree (tis the season) with attacks using this exploit.

Soon after the advisory dropped, I listened to Dennis Fisher and Ryan Naraine interview Brad Arkin on the Digital Underground podcast. Brad Arkin is currently Director of Product Security and Privacy at Adobe and has held previous positions at Symantec and @stake. Now Brad seems like an intelligent guy and I applaud him for taking on such a challenge. I became annoyed while listening to the interview, however. Ryan Naraine repeatedly queried Brad during the podcast on what I have suspected for quite some time. Does Adobe have enough resources in place for dealing with the current trend of attacks targeting their products? Brad seemed to repeatedly side step the question. He attempted to explain the complexity of dealing with such vulnerabilities with such a large and diverse install base.

<disclaimer> While I may have no experience dealing with what Brad has stepped up to do, I do have a lot of experience mitigating vulnerabilities in the corporate environment and my opinions here are based on that experience. </disclaimer>

Now while I have no doubt that this is a challenge indeed, maybe Adobe needs to stop, glance around, and take a cue from the company that has the largest and most diverse install base I know of. That company would be Microsoft. While far from perfect, Microsoft seems to have made some significant advances with their security program over the last 5-6 years. When MS08-067 dropped in October 2008 (for those not familiar, that’s the vulnerability used by the Conficter variants), Microsoft did what any responsible software vendor should do. They released an Out-Of-Band patch!  So what gives Adobe?

I almost jumped out of my skin when Brad stated Adobe often needs to shift resources off of other security projects and research to handle an exploit such as this. So to answer Ryan’s question, I guess you do not have enough resources then? My point is if you have to shift all your resources to handle each and every fire and it still takes you a month to put out the fire, then you will never be preventative. Maybe I am being naive here but I don't believe so.

</my rant>

Ok so with my ranting out of the way, I did state that I thought Adobe was making improvements. One such improvement is their implementation of the JavaScript Blacklist Framework mentioned during the podcast. It is still reactive but it is at least something. Thank you to Dennis, Ryan, and Brad for bringing this to my attention. To quote Adobe’s tech note located here;

“The Adobe Reader and Acrobat JavaScript Blacklist Framework introduced in versions 9.2 and 8.1.7 provides granular control over the execution of specific JavaScript APIs. This mechanism allows selective blocking of vulnerable APIs so that you do not have to resort to disabling JavaScript altogether.”

Brad admitted during the interview that this is only effective for specific vulnerabilities and it may break legitimate uses of functionality in Adobe Acrobat and Reader. He further stated Adobe has many more improvements coming during 2010. I can only hope this includes some preventative improvements to their code base and internal resources dedicated to the current target on their back.

More can be found on using the blacklist framework to mitigate the vulnerability in APSA09-07 here.

For an entertaining and informative Adobe rant (that puts mine to shame) checkout the latest post on the Sourcefire VRT Team blog, entitled Matt's Guide to Vendor Response

Happy New Years to Everyone!

Update:

More reports of sophisticated Adobe exploits have been appearing this week. Some have little to no coverage by the AntiVirus vendors. I noted the following article describing Adobe's plans to begin testing a silent Adobe updater. Someone needs to tell Adobe an updater only works if you actually provide the update and explain to them the basics of enterprise change control.

Details of the attacks can be found here and here.

Another Update:

Adobe has release patches for the Acrobat/Reader vulnerability as well as another vulnerability in Illustrator.  The Advisories can be found here:

http://www.adobe.com/support/security/bulletins/apsb10-02.html
http://www.adobe.com/support/security/bulletins/apsb10-01.html

I also found a great ADM template for tuning Adobe Acrobat and Reader JavaScript settings on the Praetorian Prefect Blog. Again, just note that the user will be prompted with a warning when opening a .pdf containing JavaScript.

OK Last Update

The Sourcefire VRT team posted an excellent article this week on the using the Acrobat JavaScript Blacklist Framework on common exploited functions within Adobe Acrobat and Reader. An example taken from their post for Adobe Acrobat 9 would be as follows:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Adobe Acrobat\9.0\FeatureLockDown\cJavaScriptPerms]"tBlackList"="Collab.getIcon|DocMedia.newPlayer|Util.printf|Spell.customDictionaryOpen|Doc.syncAnnotScan|Doc.getAnnots"

 Additionally, they provide benign Adobe Acrobat files using each of these functions to test with.

Didier Stevens also pointed out during a recent interview on PaulDotCom Security Weekly that the new version of Adobe Reader and Acrobat has changed the way it warns users that JavaScript is disabled. While not quite the administrative control I had hoped for, it is a slight improvement as it renders the .pdf regardless of the action taken by the user.

Yet Another Update on the Symantec Vulnerability

It looks like DSHIELD has picked up on an increase in probes for port 12174 associated with the Symantec Advisory covered previously on this blog here and here. In some cases of upgrading from previous versions of Symantec Corporate Antivirus to 10.1 MR8, servers are still vulnerable to this exploit. So make sure AMS and Intel File Transfer service (xfr.exe) is not running and listening on TCP Port 12174.

Update on Symantec Vulnerability

So I wanted to give everyone an update on the Symantec Antivirus vulnerability I outlined in my previous post entitled; Lessons Learned: Vulnerability and Expectations Management. It appears that the exploit code has been published to the Exploit Database and has also been added to the Metasploit Framework. If you have not read my previous article, please make note here. In some cases of upgrading from previous versions of Symantec Corporate Antivirus to 10.1 MR8, servers are still vulnerable to this exploit.

The problem is due to the fact that AMS2 does not get removed in all cases of upgrading from version 9 to 10. If the Intel File Transfer service (xfr.exe) is running and listening on TCP Port 12174 then you are still vulnerable. Disabling the service or completely uninstalling and reinstalling Symantec Antivirus were the two options given to me by support at Symantec. I use the term "support" loosely here as I'm the one that told them disabling the serviced mitigates the issue.

I have attempted to get Symantec to edit their advisory with this information without success. So make sure you verify your patches with the attached code or favorite vulnerability scanner. Tenable Nessus does have a plugin available here.

Only You Can Prevent Forest Fires - A Smokey The Bear Approach to Security

A few weeks back Larry Pesce from PaulDotCom posed the following question on Twitter:

"Hmm. If you had to deploy ONE security technology in your organization, what would it be? What is the risk reduction vs, total effort?"

Many people quickly replied. Some answers included: a comprehensive patch management solution (my pick), Security Information Management (SIM) system, network based firewall, Intrusion Prevention System (IPS), incident response plan, and my personal favorite "a very large dog..." . Larry quickly followed up asking what would the second technology be and why?

I struggled with that question. After all it is a "no win" situation. A proper incident response plan would certainly be needed but is reactive. Network defenses would be beneficial but do not take in account a mobile workforce. I finally settled on some sort of central system that would facilitate the system hardening of the end nodes. The reasoning for my answer is the result of experiences I had early in my information systems career.

During my time as a desktop support tech, I spent most days putting out fires. The lack of centralized patch management, host based firewalls, build procedures, and asset management was the source of chaos for the desktop and systems administration teams. Worm outbreaks, improper configuration, and end users running with local administrator rights were the norm not the exception. Consequently, the team was too busy chasing their tail around to be proactive. Those experiences resonated heavily with me and ever since I have insisted in being proactive whenever possible.

Would have proper incident response or a SIM solution have helped my former employer? Maybe. Incident Response procedures and SIM's are important parts of any defense infrastructure but they are reactive, not preventative. Consequently, I would certainly place them in my top five but only after implementing the basics of defense.

While Larry's hypothetical situation is enough to give any security practitioner nightmares, I found it to be a great source of self reflection. Larry discusses the replies in more detail during Episode 172 of PaulDotCom Security Weekly, so check it out when you get a chance. I'm interested to know what you would choose and how fast you would update your resume if you found yourself in the same situation.

Lessons Learned: Vulnerability and Expectations Management

As an information security professional, a large portion of my work day is spent with vulnerability and patch management. So when I saw a security advisory addressing multiple vulnerabilities in both Symantec's Corporate Antivirus and Endpoint Security Solution products last June, I immediately investigated. You can read the security advisory here. I became concerned because other Vendors also use the Intel File Transfer service so I thought it be prudent to investigate.

I began looking around and noted that Tenable Network Solutions had a Nessus plugin. You can find the plugin here. So like any true geek with nothing to do on a Saturday evening, I began scanning. I was surprised at what I found.

The systems running the Intel File Transfer service from other vendors were not vulnerable but systems patched with Symantec 10.1 MR8 were still be vulnerable. The solution table in Symantec’s Advisory states that the issue with AMS2 was fixed in this version.

I contacted someone I knew at Tenable and asked for assistance in verifying the vulnerability. The plugin actually contains remote execution code but it is commented out by default. With instruction from Tenable I uncommented the cmd = "calc"; line in the NASL script and ran a nessusd -R to perform a reload of the Nessus Database. Sure enough, the next scan verified that cmd.exe would execute without authentication on the vulnerable machines.

So what gives? Is Symantec's advisory incorrect? Not entirely, although it may be misleading. This became a case of reading the fine print. Further down the advisory we find this information:

"AMS2 is installed by default with Symantec Antivirus Server 9.0. AMS2 is an optional component in Symantec Antivirus Server 10.0 or 10.1. These vulnerabilities will only impact systems if AMS has been installed."

And further down, under mitigation section:

"Reporting has replaced AMS2 as the recommended method of alerting. Symantec Endpoint Protection Central Quarantine Server 11.0 MR3 and later no longer include AMS2. Symantec recommends that customers who are still using AMS2 switch to Reporting to manage alerts in their environments. If the customer is unable to switch to reporting immediately then Symantec recommends that the customer either disables AMS2 as a temporary mitigation or completely uninstall AMS2."

All the systems vulnerable had all been upgraded from an earlier version of Symantec Antivirus Corporate Edition 9.X. During the remote upgrade process there seemed to be no way to specify if AMS2 was to be installed or not. Symantec support seemed unable to instruct me on how to remove or disable AMS2 from the affected systems and I have spent the last several months trying to get them to change the advisory so that the solution table listed at the top of the document noted this tidbit at the bottom. To say the least I have not been successful in this endeavor and feel a bit frustrated. Although the Sales Executive has been nice enough to try and sell me their Endpoint Protection v11 product and recommended I start with a fresh install.

If you do want to mitigate the vulnerability, I determined disabling the Intel File Transfer service works well and does not seem interfere with my configuration. I recommend you test this in your own environment however.

So Lessons Learned:

Read Security Advisories carefully.
Scanning is an important part of any vulnerability management plan.
Manage your expectations when dealing with vendors.

Updated December 29, 2009

Posted two updates on the release of the POC for this vulnerability and a report of the exploit being used in the wild by SANS ISC.