Priveon Labs Security Blog

Cisco's AnyConnect Client version 2.4 now runs on the following new platforms:

• Microsoft Windows 7 (32-bit and 64-bit)
• Mac OS X 10.6 and 10.6.1 (both 32-bit and 64-bit)

This is good news for those of who have made the jump to the new OSs, but make sure you are aware of some potential DNS issues if you're a Mac user.  In the AnyConnect 2.4 release notes [Published: November 17, 2009], a caveat is mentioned: "Mac OS X releases 10.6.0, 10.6.1, and 10.6.2 do not tunnel DNS queries; however, we expect that a fix release will resolve this issue (CSCtc54466)."

Later on in the release-notes Cisco also mentions:

"Mac OS X 10.6 Sends All DNS Queries in the Clear -- With split-DNS enabled, Mac OS X 10.6 sends all DNS queries in the clear. It should send DNS queries targeting split-DNS domains over the VPN session. Apple plans to resolve this issue in an upcoming update."

Just a heads up for those running OS X 10.6 and the AnyConnect 2.4 client with split-DNS configured.  For troubeshooting purposes clearing the local cache can sometimes help (dscacheutil -flushcache).

As of this morning (November 19, 2009), several flights have been delayed or cancelled in Atlanta's Hartsfield International Airport (ATL) due to a computer/network issue. The issue has been described as a "packet switch" that "failed due to a database mismatch" according to an AP article. While not a security issue most likely, it does serve as a strong reminder of the fragile critical infrustructure which we rely on every day. Something as simple as a subtle switch misconfiguration (or malicious misconfiguration in the case of a security breach) can impact all connected systems. In this case, the result is delayed and cancelled flights. What if this were your network? What would the impact be? Take a moment to review your high-level Disaster Recovery (DR) plans and leverage this FAA outage to your benefit.

Slack space is the unused space between the end of the actual file and the end of the the defined data unit (cluster).

A cluster is the smallest unit of storage that the operating system can deal with.

When a file is written, and does not occupy the entire cluster, the remaining space is slack space.

For example, assume that the OS uses a 4k cluster and 512 byte sector, meaning it writes data in 4k increments made up of eight 512 byte sectors, regardless of the actual size of the file being written. This means that if a 2000 byte file were written to this cluster the remaining 2096 bytes would be slack. Within this slack space there are two areas to consider – the first is that between the end of the actual file and the sector in which the file ends, and the second is the remaining sectors in the cluster that contain no data as depicted below.

In the example above, we see that the file will write 3 complete sectors and partially fill the fourth sector, leaving the remaining sectors in the cluster unchanged. The first area of slack, sometimes referred to as RAM slack, is padded with data as determined by the OS. The activity that occurs on the remaining area is also OS dependent but can either be untouched or wiped. In cases where the OS does not wipe the unused sectors, there will be remnants of the previous file that existed. The impact of this depends on what the contents of the previous file were. As an example, assume that it was a large file containing a list of customers and their personal information. An analysis of the slack space in this case could uncover a portion of this list and expose sensitive information. Another risk presented by slack space is its ability to hide data from the OS and/or host application and the fact that a number of tools exist to allow such activities.

As you can see, monitoring access to a file and it's secure contents is not the only problem but also monitoring access to what used-to-be a file as well...

FIPS 140-2 is the Federal Information Processing Standard for cryptographic modules that is used to protect sensitive but unclassified information. There are four levels defined within this standard (levels 1-4), each with increasing control requirements that build upon the previous requirements where 1 is the lowest and 4 is the highest.

Level 2 requires: the use of approved algorithms, cryptographic boundary, role-based or identity-based authentication, and an audit mechanism.

In the MARS appliance, FIPS 140-2 is accomplished through the introduction of the CS-MARS FIPS PCI Card and comes with two caveats:

• The MARS 110RF cannot interoperate with a CS-MARS Global Controller  - this is related to the Global controller not parsing information

• The MARS 110RF cannot interoperate with a Checkpoint Firewall Device - the OPSEC-LEA and CPMI components used for Checkpoint communications are not considered secure in this framework.

With the October release of MARS v6.0.5, we wanted to quickly review the basic steps to upgrade from MARS 4.x to 6.0.5. It should be stressed that moving from 4.x to 6.x is not an upgrade, but rather a data and configuration export from 4.3.6 to a newly installed 6.0.1 image. This means the first step will be to upgrade your current appliance to 4.3.6 if it is not already there using the pnupgrade command. Once on 4.3.6, export the configuration and event data to your NFS server using the pnexp command. Verify that the information successfully exported and begin a re-image of the appliance using a 6.0.1 image. Configure the basic network information on the new image and then import the configuration and event data back into the MARs system using the pnimp command. Once up and running on 6.0.1 follow the upgrade path to 6.05.

Release 6.0.5 offers the following enhancements - FIPS 140-2 Level 2 complaince for the MARs 110 with the purchase and installation of a FIPS PCI card and the ability to configure custom login banners for ssh sessions.

For more information on the 6.0.5 release see the Cisco release notes

http://www.cisco.com/en/US/docs/security/security_management/cs-mars/6.0/release/notes/rnote605.html