I received notification of the following vulnerabilities outlined below via the full disclosure mail list but you can find a direct link to it here –> Link. I figured it was worth mentioning again since most organization depend on their Firewall as the primary means of protection against the many threats on the  internet.

The Cisco ASA 5500 Series Adaptive Security Appliance is a modular platform that provides security and VPN services. It offers firewall, intrusion prevention system (IPS), anti-X, and VPN services.

Cisco ASA 5500 Series Adaptive Security Appliances are affected by the following vulnerabilities:

SunRPC Inspection Denial of Service Vulnerabilities ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Sun RPC inspection engine enables or disables application inspection for the Sun RPC protocol. Sun RPC is used by Network File System (NFS) and Network Information Service (NIS). Sun RPC services can run on any port. When a client attempts to access a Sun RPC service on a server, it must learn the port that service is running on. The client does this by querying the port mapper process, usually rpcbind, on the well-known port of 111. Three DoS vulnerabilities affect the SunRPC inspection feature of Cisco ASA 5500 Series Adaptive Security Appliances, in which an unauthenticated attacker may cause the affected device to reload.

Note:  Only transit traffic can trigger these vulnerabilities; traffic that is destined to the appliance will not trigger the vulnerabilities. These vulnerabilities can be triggered by using UDP packets, not TCP.

These vulnerabilities are documented in Cisco bug IDs CSCtc77567, CSCtc79922, and CSCtc85753; and have been assigned Common Vulnerabilities and Exposures (CVE) IDs CVE-2010-1578, CVE-2010-1579, and CVE-2010-1580, respectively.

Transport Layer Security (TLS) Denial of Service Vulnerabilities ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

TLS and its predecessor, SSL, are cryptographic protocols that provide security for communications over IP data networks such as the Internet.

Three vulnerabilities exist on the Cisco ASA security appliances that can be triggered by a series of crafted TLS packets. An unauthenticated attacker may cause the affected device to reload. A Cisco ASA device configured for SSL VPN, TLS Proxy for Encrypted Voice Inspection, or configured to accept ASDM management connections is vulnerable.

These vulnerabilities are documented in Cisco bug IDs CSCtd32627, CSCtf37506, and CSCtf55259; and have been assigned Common Vulnerabilities and Exposures (CVE) IDs CVE-2010-1581, CVE-2010-2814, and CVE-2010-2815, respectively.

Session Initiation Protocol (SIP) Inspection Denial of Service Vulnerability ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SIP, as defined by the Internet Engineering Task Force (IETF), enables call handling sessions, particularly two-party audio conferences, or “calls.” SIP works with SDP for call signalling. SDP specifies the ports for the media stream. Using SIP, the Cisco ASA can support any SIP VoIP gateways and VoIP proxy servers. To support SIP calls through the Cisco ASA, signaling messages for the media connection addresses, media ports, and embryonic connections for the media must be inspected, because while the signaling is sent over a well-known destination port (UDP/TCP 5060), the media streams are dynamically allocated. Also, SIP embeds IP addresses in the user-data portion of the IP packet. SIP inspection applies NAT for these embedded IP addresses.

A DoS vulnerability affects the SIP inspection feature of Cisco ASA 5500 Series Adaptive Security Appliances. SIP inspection is enabled by default. During successful exploitation, an unauthenticated attacker may cause the affected device to reload.

Note:  Only transit traffic can trigger these vulnerabilities; traffic that is destined to the appliance will not trigger the vulnerabilities.

This vulnerability is documented in Cisco bug ID CSCtd32106 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2010-2816.

Crafted Internet Key Exchange (IKE) Message Denial of Service Vulnerability ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

IPsec is an IP security feature that provides robust authentication and encryption of IP packets. IKE is a key management protocol standard that is used in conjunction with the IPsec standard. A DoS vulnerability exists in the IKE implementation of the Cisco ASA.

During successful exploitation, an unauthenticated attacker may cause an affected device to reload.

Note:  Only traffic that is destined to the appliance may trigger this vulnerability when the affected device is configured for IPsec remote access or site-to-site VPNs.

This vulnerability is documented in Cisco bug ID CSCte46507 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2010-2817.

As a side note I would like to add that unless you are already running on version 8.3 you should disable the vulnerable services and take a moment to read the release note for version 8.3.

The are some syntax changes you have to adjust too, as well as do a full rule set conversion. Below is an example of an old rule and its recommended migrated counterpart. Some of the migrated rules and not all new since the were supported in older IOS version, however its now mandatory to do them the proper/recommended way instead of the older way.

Old Configuration

static (inside,outside) tcp 172.23.57.170 5080 10.50.50.50 80

access-list 1 extended permit tcp any host 172.23.57.170 eq 5080

access-list 1 extended permit udp any host 172.23.57.170 eq 5080

access-list 1 extended permit tcp any host 172.23.57.170 eq 10000

access-list 1 extended permit tcp any host 10.2.3.4 eq 5080

access-group 1 in interface outside

Migrated Configuration

static (inside,outside) tcp 172.23.57.170 5080 10.50.50.50 access-list 1 extended permit tcp any host 10.50.50.50 eq 80

access-list 1 extended permit udp any host 172.23.57.170 eq 5080

access-list 1 extended permit tcp any host 172.23.57.170 eq 10000

access-list 1 extended permit tcp any host 10.2.3.4 eq 5080

access-group 1 in interface outside

As a Network Admin you would soon realize after a few months of adding various  ACL rules there comes a time when you need to go back and consolidate those rules before it gets out of hand.

Now that most cloud providers are moving away from the traditional (80, 443) TCP ports and moving towards your none standard (8800, 3995) ports, your job as a Network admin requires you to now plan a bit more.

Normally if I got a call that a users is unable to access a certain web, I would first verify if its a “URL filtering issue” or a “Firewall” access issue. If I determined that its the latter, I would then write a typical ACL and grant the user access after the requested service has been test.

For instance if you receive a call about not being able to access a website X on port 5454, you can write a basic ACL rule:

access-list external_access extended permit tcp 192.168.10.5 255.255.255.0 69.196.224.24 255.255.255.0 eq 5454

Now the above rule would work just fine, but think about it if you recieve about 10-15 of those request a day, your firewall will be a mess after a while. The way to take care of this is by using Using Network Objects and Groups in a Rule.

Network objects let you predefine host and network IP addresses so that you can streamline subsequent configuration. When you configure the security policy, such as an access rule or a AAA rule, you can choose these predefined addresses instead of typing them in manually. Moreover, if you change the definition of an object, the change is inherited automatically by any rules using the object.

Below is how you would accomplish this if you reieved say three request  for web related access all on different ports:

======================================
Creating Object group and adding ports Cisco ASA Firewall
======================================

config t
object-group service External_Acess tcp
description Access to external websites
port-object eq 7778
port-object eq 5454
port-object eq 3322

object-group network External_Access_Users
description Access to external websites
network-object host 192.168.10.5
network-object host 192.168.10.7
network-object host 192.168.10.9

=======================================
Creating ACL and applying object group
========================================
access-list acl_inside remark ***** External  Websites Access *****
access-list acl_inside extended permit tcp object-group External_Access_Users any object-group External_Acess

Now the next time you receive a request for external website access on a none standard port you simply add the port to the service group, and the Host IP to the network access group and you are set. Now that’s much more easy on the eyes to look at!

If you have another way of achieving the same outcome don’t hesitate to leave a comment, in the end its all about learning.