Priveon Labs Security Blog

In my last post, I went over the command line switches that can be used to extract the CSA agent kit as well as configuring the installation options. This blog post will now deal with an overview of the deployment options.

Agent Deployment

New Deployments

Installing CSA on a computer that does not already have an existing version of the agent installed is relatively straight forward. Once the desired command line parameters are chosen, the package is simply configured to execute that command line.

Upgrades

Installing CSA on a machine that already has a previous version of the agent is slightly more complex. The upgrade process requires that the agent service be stopped before the upgrade can begin. By default, there are rules in place that prevent the agent service from being stopped without a query and challenge to the logged-in user. Without additional configuration, the installation would fail due to not being able to stop the agent service. However, there are methods for successfully rolling out CSA upgrades using software distribution tools.

Note: When a host’s CSA agent is upgraded by running the agent kit installer (both manually and automated), the groups that the host is a member of in the MC (Management Console) are reset to those that are attached to the agent kit. For example, if a host was put into 10 different groups in the MC by the CSA administrator but was upgraded by running an agent kit that was attached to only two groups, then after the upgrade was complete, the host would only be a member of the two groups attached to the agent kit. This behavior does not occur on host upgrades initiated directly by the MC.

Audit Mode Upgrade

One option is to place the agents to be upgraded in audit mode before the upgrade begins. This method is relatively simple to implement and will allow the upgrade to complete without prompts on the target machine. One significant disadvantage of using the Audit Mode upgrade process is that since the agents are in audit mode, they have no protection against attacks. All operations initiated on the host and targeted at the host will be allowed to occur. It can also be difficult to correlate the machines in the MC that need to be put in audit mode against the machines that are being targeted by the software distribution. This method requires a great deal of coordination between the CSA administrator and the administrator of the software distribution application to be effective and minimize the amount of time the agent is in Audit mode.

Protect Mode Upgrade

A second option involves a combination of custom rules in the MC and editing the package that distributes the CSA setup files. This allows the agent to remain in protect mode at all times apart from the moments the actual upgrade is being performed. The initial administrative effort to implement this solution is higher than an Audit Mode Upgrade but no additional effort from the CSA administrator is required for future upgrades. It is recommended as an administration and security best practice to utilize the Protect Mode Upgrade method. Detailed instructions on implementing the Protect Mode Upgrade method for BigFix and SMS/SCCM will be included in this series of posts.

The process flow is detailed below:

1. A File Access Control rule sets the Security Level of the agent to Low when the application class of the software distribution tool reads or writes a specific file in a specific location (A registry access control rule could be used in the same manner if it was preferable to write a specific registry key value)
2. A Rule Module either based on the Security Level Low system state contains an Agent Service Control Rule that allows all applications to disable the agent security or a custom state condition that can be used to accomplish the same purpose without using the security level as the system state.
3. When the software distribution tool begins the installation process, it first creates the file referenced by the File Access Control Rule mentioned above
4. This causes the agent to change the security level to Low
5. Now that the agent security level is set to Low (or the custom state condition is set), the upgrade process can stop the agent service and complete the upgrade
6. After the upgrade is complete, the systems management tool will change the security level back to medium on the agent
7. The upgrade is complete and the host was protected during the entire upgrade with the exception of the few moments the agent itself was being upgraded

In my next post I will go over in detail how to utilize BigFix to deploy CSA.

Denial of Service (DoS) vulnerabilities have been identified in Cisco Unified Communication Manager (formerly known as Cisco CallManager).  Exploitation is accomplished with either malformed CTI Manager Messages, malformed SIP Message Vulnerabilities, and/or malformed SCCP Message Vulnerabilities.  Products affected include:

• Cisco Unified Communications Manager 4.x
• Cisco Unified Communications Manager 5.x
• Cisco Unified Communications Manager 6.x
• Cisco Unified Communications Manager 7.x

Customers are urged to upgrade to 4.3(2)SR2, 6.1(5), 7.1(3b)SU2, or 8.0(1).  Note: Cisco Unified Communications Manager version 5.1 reached the End of Software Maintenance on February 13, 2010.  Software can be obtained on Cisco's website (a CCO ID and valid contract are both required) Details:

http://www.cisco.com/warp/public/707/cisco-sa-20100303-cucm.shtml

Microsoft issued a security advisory (981169) on March 1, 2010 which impacts supported versions of Windows 2000, 2003, and XP using Internet Explorer. This is related to how VBScript interacts with windows help files when using IE. If exploited, a malicious person could trick the user into pressing the F1 key which could then allow remote code execution.

The current workaround (pre-patch day-zero), is to do any of the following:

• Tell users not to press their F1 Key

  • More on this below...

• Restrict users from accessing the windows help system through windows ACL

  • echo Y | cacls "%windir%\winhlp32.exe" /E /P everyone:N
    

• Change the IE security zones setting to restrict ActiveX and other scripting

  • Good luck with this approach if you want other sites to continue working

So, let's go back just for a second to "Tell users not to press their F1 Key". Is this not the same as trying to keep a child away from an object by saying "Hot! Don't Touch!"? We all know how this ends... It works, yet makes the person more curious, then you leave, and can anyone guess what happens... They touch it. Especially in this case where the attack will often be in the form of repeated pop-ups asking the user to press F1.

If asking users to not do something actually worked, we wouldn't have most of the security issues we see today... right?

Anyway, for those of you who want to do a little more research. PoC code is available at exploit-db. Please review the code, modify for your purposes, and also download the hlp file and host on a trusted server for PoC testing.

If you attended ShmooCon 2010, you likely witnessed and/or experienced:

• 2 feet of snow falling in 24 hours
• A hotel roof collapse (ok, so it was a single section of glass from the atrium)
• Snowball fights and snowball-induced tree avalanches
• Sledding accidents and other random mischief
• Snowpocalypse 2010 related travel and dining woes

Oh, and there happened to be a security con going on as well.

Despite a winter storm pummeling the DC area with snow, Shmoocon 2010 was an overall success. The opening talk - Closing the TLS Authentication Gap (Marsh Ray & Steve Dispensa - PhoneFactor) was a wild tale of vendors, vulnerabilities, and NDAs. The SSL TLS renegotiation vulnerability was already known by many ShmooCon attendees by the time the conference started. So what made this talk "securitygeek-cool" if it wasn't a "0-day?"

First, you have the fact that this was a far-reaching protocol implementation flaw that affected multiple hardware and software vendors. Multiple is bit of an understatement; this flaw effected most software and hardware that utlizes TLS version 3. To quote the CVE entry for 2009-3355:

The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as used in Microsoft Internet Information Services (IIS) 7.0, mod_ssl in the Apache HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l, GnuTLS 2.8.5 and earlier, Mozilla Network Security Services (NSS) 3.12.4 and earlier, multiple Cisco products, and other products, does not properly associate renegotiation handshakes with an existing connection, which allows man-in-the-middle attackers to insert data into HTTPS sessions, and possibly other types of sessions protected by TLS or SSL, by sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context, related to a "plaintext injection" attack, aka the "Project Mogul" issue.

Normally the technical details of vulnerability discovery are what fascinate me and I mentally fall asleep during the rest of the lecture. This presentation was different in that what interested me was the discussion of how the authors disclosed (responsibly, I might add) a huge flaw in TLS. This was in the middle of legal wrangling and trying to come to a consensus with representatives of companies that are often competitors - some of which have a less-than-stellar track record in dealing with vulnerability disclosure.   And some the aforementioned vendors that had nothing more than a "stall-the-disclosure-of-this-vulnerability" objective.

In the end, the ShmooCon keynote disclosed more than a vulnerability. Possibly as critical as CVE-2009-3355 is/was, the ShmooCon keynote disclosed how difficult it is to responsibly disclose a vulnerability that involves multiple parties with varying agendas and touched upon the ongoing argument over "full disclosure." 

Preso:  http://www.shmoocon.org/2010/slides/tlsgap.zip

Video:  http://www.shmoocon.org/2010/videos/TLSAuthentication-Dispensa.m4v

This entry comes from the department of: Why would anyone do this?

If you have not already heard about Blippy.com, check it out. Basically, it allows you to link various bill payment/purchasing solutions to their account so you can share all of your purchases by location and dollar amount in real-time! This includes credit cards... Oh, and once set up, you can link this to your Facebook and/or Twitter accounts so everyone can be informed immediately.

This is insane. Give me a single good reason why this should ever occur.

Now, just to illustrate a piece of the problem, try the following:

1. Open a browser to Google.com and search for "capitalone site:blippy.com"
2. Look for the entry for "Capital One on Blippy" and click the link
3. Now, look around... several transactions come right up...
4. Want to look at more interesting info? Click on one of the usernames on this page
5. Now you can see what a specific individual has been spending in relation to their Blippy tracking.
6. Oh, and if you are interested... You can add the RSS feed to keep up... :)

While Blippy has a 'Follow-me system', by default all of your transactions are shared with the public unless you change that setting to private.

Is it me, or is everyone's Proof of Concept application (First one they write) for Facebook and Twitter going immediatley viral? Rather than to the bit-bucket...

If this trend continues, I think privacy will not be a concern at all. A divide-by-zero error of sorts...