EXTRABACON SNMP-exploit for Cisco firewalls - diagnostics, workaround and fix

There are lot of discussions about Shadow Brokers' published exploits NSA for a last time. But the situation became interesting when Cisco alerted to the information posted with exploits confirmation.

Cisco blog contains article about Shadow Brokers' exploits. It provides some clarity in the context of danger: to fear ot not to fear, who must be afraid of this, what is the topic of the fair and how to fear.
Additional thank to Maxim Zimovets (Cisco lvl80 engineer) for emergency analysis and vendor-side conclusion.

So, EXTRABACON is an exploit which causes buffer overflow on a vulnerable device by specially crafted SNMP-packet. The vulnerable devices list is posted in  the Cisco Security Advisory for CVE-2016-6366. The most popular are Cisco ASA, FWSM, PIX ASA-SM and other firewalls. All supported versions of SNMP (v1, v2c, and v3) are affected by this vulnerability. All Cisco ASA Software versions are vulnerable too.
That's enough to start to be afraid.
But don't panic! For the CVE-2016-6366 vulnerability exploitation attacker's situation must meet the requirements:

1. SNMP must be enabled on the firewall.
2. Hacker must know the IP-address of the SNMP-enabled firewall interface.
3. Hacker must know or guess the SNMP community (v1, v2c) or login-password-algorithms (v3).
4. Trusted IP-address for SNMP is known.
5. Trusted IP-address for SNMP is spoofed.
6. IPv4-only is vulnerable.

So, you can see that it is not as horrible as it seems in the first once. But it is necessary to check your firewalls by these 6 points (IPv4 point #6 is a blocking one).

Let's check SNMP comfiguration:

# show run snmp-server

you can see some similar output:

snmp-server host mgmt 192.0.2.1 community *****

snmp-server host mgmt 192.0.2.2 community *****

snmp-server community *****

It means that SNMP is enabled (p.1), hosts 192.0.2.1 and 192.0.2.2 are trusted (p.4) for SNMP to "mgmt" interface (p.2) by IPv4 (p.6).
SNMP community is not exportable from the configuration. It must be known or guessed (p.3).
IP spoofing ability depends on uRPF setting and ACL applied on the network equipment between attacker and your ASA (p.5).
So, it seems all OK and there is no reason to cry.
If you concluded that your ASA is vulnerable by some reason (p. 1-6) you may eliminate the non-compliant point. Change the community value for hard-to-guess one and snmp-server host (if SNMP is used). Another way is to disable SNMP in the case it is not used by typing the no snmp-server command.

L3-interfaces terminating PC- and servers- subnets must be uRPF-enabled to prevent IP spoofing of SNMP-trusted hosts:

L3_access(config-if)# ip verify unicast source reachable-via rx

But it is useful to provide some additional checks (it is unknown how much exploits are non-published yet) on your ASA:

• SNMP-check all ASA interfaces using your community:

~$ snmpwalk -c community_name -v 2c asa_iface_ip_address 1 

or using your login-pass-algo (may vary in your command):

~$ snmpwalk -v 3 -A SNMP_Password -X Priv_Password -a SHA -x AES -u snmpv3user -l authPriv asa_iface_ip_address 1

• SNMP-check your ASA by the same command using non-trusted hosts.

If your ASA is not responsive for these checks then all OK. It means that "free" EXTRABACON version is not dangerous for you.

But it is useful to check your ASA software and files integrity using ASA Integrity Assurance.

Please keep in mind that all actions described are workaround because your software version is still vulnerable. So, you must install the new Cisco firewall software version or patch with the fix after its' publication.