Priveon Labs Security Blog

A pair of recent SANS Diaries on Layer2 network hardening reminded me of one of my favorite tools for network auditing. Yersinia is an excellent tool for auditing multiple network protocols including STP, CDP, DTP, DHCP, HSRP, 802.1Q, 802.1x, ISL, and VTP. A list of attacks Yersinia can perform against the aforementioned protocols can be found here.

On the Web:

Sans Diary 1 on L2 Network Attacks: http://isc.sans.org/diary.html?storyid=7567
Sans Diary 2 on L2 Network Attacks: http://isc.sans.org/diary.html?storyid=7708
Yersinia HomePage: http://www.yersinia.net

Forbes recently released its "Most Hacked Software" list for 2009, although I'm not sure I agree with the article title. Replacing "most hacked" with the phrase "most vulnerable" or "most exploited" - both backed up with hard figures would have been more accurate and less sensational.

According to the article and iDefense, Adobe was the "most hacked software" with a major increase in vulnerabilities (45) in 2009. The increase in FireFox bugs is also noteworthy although the increase in the browser market-share is at least one contributing factor.

The article does - rather importantly - highlight the recent uptick in application vulnerabilities as opposed to more traditional OS flaws.

The continuing list included:

• Adobe
• IE
• FireFox
• Flash
• QuickTime
• Office
• Windows (XP)

On the web:

http://www.forbes.com/2009/12/10/adobe-hackers-microsoft-technology-cio-network-software.html

WPACracker.Com s a cloud-based WPA cracker that will perform a dictionary-based attack on PCAP files that include the WPA-PSK handshake. Use of the service is a mere $17 and utilizes a 400 node cluster to crack what would normally take days. This service is an alternative to using the precompiled Church of Wifi Rainbow tables or performing your own time-consuming dictionary based attack.

To prevent similar dictionary and rainbow table attacks, always use WPA2 AES/CCMP instead of WPA2-PSK.

On the web:

WPACracker.com

Prerequisites

Before beginning a mass deployment of CSA, there are some prerequisite tasks that should be performed in the MC. By default, it is very likely that the behavior of a systems management tool can get flagged as “Untrusted” and blocked by CSA. There are several rules needed to allow the systems management application to function normally. These should be in place and tested in your environment prior to deploying the agent. The following settings described are provided as examples. All settings should be verified against your specific configuration before implementing.

BigFix
For BigFix to operate properly on a machine running CSA, the following items are needed in the MC:

• Application Class: An application class defining the executables used by BigFix should be created using the following literals as examples. You should ensure that the option “This process and all its descendents” is selected.

  • @fixed:\program files\BigFix Enterprise\**\besclient.exe
  • @fixed:\program files\BigFix Enterprise\**\RunQuiet.exe

• File Access Control Rule: The BigFix application class should have read, write, and write directory permissions for all files.
• Registry Access Control Rule: The BigFix application class should have permission to write to all registry keys.
• Application Control Rule: The BigFix application class should have permission to run all applications.
• Network Access Control Rule: The BigFix application class should have permission to act as a client or server for all TCP and UDP ports.
• System API Control Rule: The BigFix application class should be allowed to perform all operations on the System API Rule settings.

SMS (SCCM)
CSA contains a default application class and rules that allow the basic functions of SMS to operate normally. Depending on your specific configuration and product usage, some changes may be required within the MC to accommodate your environment. You should perform testing before your deployment to ensure that the SMS client can function properly with the policies you have defined in CSA. Some software distribution packages will require additional rules to be created to allow the installation to complete successfully. The examples below can be used as a template for the rules needed in your environment.


For SMS to operate properly on a machine running CSA, the following items are needed in the MC:

• Application Class: There is a Cisco default application class that includes the file set for the SMS client executables. However, the application class does not include the child processes and will not allow the rules you create to apply to the setup processes launched by the software distribution process. It is a best practice to never modify a Cisco default item in the MC. Instead, create a new application class for the SMS client and reference the $Software distribution and inventory - SMS Agent file set. You should ensure that the option “This process and all its descendents” is selected.
• File Access Control Rule: The SMS application class should have read, write, and write directory permissions for all files.
• Registry Access Control Rule: The SMS application class should have permission to write to all registry keys.
• Application Control Rule: The SMS application class should have permission to run all applications.
• Network Access Control Rule: The SMS application class should have permission to act as a client or server for all TCP and UDP ports.
• System API Control Rule: The SMS application class should be allowed to perform all operations on the System API Rule settings.

In my next post I will be going over the Cisco Security Agent command line installation switches and how to extract the agent kit for packaging. Stay tuned.

In a previous blog entry I briefly discussed pentesterscripting.com - an up and coming repository for pentesters and auditors to share useful scripts. The site is worth revisiting now that the community has started adding useful pentest/audit related scripts.

PenTesterScripting.com