EPICBANANA exploit for Cisco firewalls: checklist and fix

EPICBANANA exploit for Cisco firewalls: checklist and fix
The article in Cisco blog with the EXTRABACON description has also information about EPICBANANA exploit executed via CLI.
Vulnerable devices list is much less that SNMP one and it consists of ASA 5500 series, ASA 5500-x series, PIX and FWSM.
Exploit is able to cause a denial if service condition or arbitrary code execution by invoking certain invalid commands in an affected device. But an attacker must:
  • Know ASA interface IP-address with ssh or telnet permission.
  • Know login and password.
  • Connect to the box from trusted IP-address.
So, it is not very hard-to-protect situation but this bug is also a bug.
name='more'> Unlike SNMP-using EXTRABACON which is oficially published as a new Cisco says that EPICBANANA uses the vulnerability described in 2011. The vulnerability is registered this year as CVE-2016-6367 for some software upgrade stimulation. So, the software image with the fix is present. You need to download it and upgrade your box. And you must also pay for the support and downloads ability.

Cisco provides the table with affected and non-vulnerable software versions.

Cisco ASA Major Release First Fixed Release
7.2 Affected, migrate to 8.4(3) or later
8.0 Affected, migrate to 8.4(3) or later
8.1 Affected, migrate to 8.4(3) or later
8.2 Affected, migrate to 8.4(3) or later
8.3 Affected, migrate to 8.4(3) or later
8.4 8.4(3)
8.5 Affected, migrate to 9.0(1) or later
8.6 Affected, migrate to 9.0(1) or later
8.7 Affected, migrate to 9.0(1) or later
9.0 9.0(1)
9.1 Not affected
9.2 Not affected
9.3 Not affected
9.4 Not affected
9.5 Not affected
9.6 Not affected

I tried to find the bug described in the Resolved Caveats in Version 8.4(3) list but it was unsuccessful. May be I don't associate no one bug with the problem or some another reason.

Checklist for the future
The fixed software is 5 years old and the most part of Cisco firewalls use the not-affected version. Some exception is staff with the rule "no emergency case - no upgrade".
But even the most secured people must check the security settings on the firewall management interfaces.

It is not so hard to make this check:

# show run ssh
ssh 192.0.2.0 255.255.255.0 mgmt
# show run telnet
telnet 192.0.2.0 255.255.255.0 mgmt

Commands output shows us that hosts from the subnet 192.0.2.0/24 are trusted to manage ASA via interface named "mgmt" using telnet and ssh. If it is ASA admins network or terminal servers, jumphosts and NMC network then all OK. If there are all corporate users here it is necessary to constrict the allowed hosts quantity.
But it is critical in any case to use secure passwords on ASAs (no admin/admin or cisco/cisco etc.). Logins and passwords must meet the requirements:
  • personal accounts;
  • password complexity;
  • centralized accounts management;
  • start-stop accounting;
  • local emergency accounts must be used only in the case of AAA-servers unavailability.
Let's check if AAA servers are set:

# sh run aaa-server
aaa-server TACACS protocol tacacs+
 accounting-mode simultaneous
aaa-server TACACS (mgmt) host 198.51.100.1
 timeout 5
 key *****

aaa-server TACACS (mgmt) host 198.51.100.129
 timeout 5
 key *
****

output shows that TACACS named group contains 2 TACACS+-servers: 198.51.100.1 and 198.51.100.129 allowed to connect to the "mgmt" interface.

Then you may check AAA settings. It is necessary to have a correct authentication order (AAA then local):

# sh run aaa
aaa authentication enable console TACACS LOCAL
!  enable-authentication order: TACACS then LOCAL
aaa authentication http console TACACS LOCAL
! ASDM-authentication order: TACACS then LOCAL
aaa authentication ssh console TACACS LOCAL
! SSH-authentication order: TACACS then LOCAL
aaa authentication telnet console TACACS LOCAL
! telnet-authentication order: TACACS then LOCAL
aaa authorization command TACACS LOCAL
! command authorization order: TACACS then LOCAL
aaa accounting enable console TACACS

! EXEC mode start-stop accounting on TACACS
aaa accounting ssh console TACACS

! SSH-sessions start-stop accounting on TACACS
aaa accounting telnet console TACACS

! telnet-sessions start-stop accounting on TACACS
aaa accounting command TACACS
! commands accounting on TACACS


If commands output:

show run telnet
show run ssh
show run aaa-server 
show run aaa 

shows the similar picture you must not be very afraid of your ASA vulnerability for the "freeware" EPICBANANA version if your software is updated and TACACS-configured logins/passwords are not admin/admin or cisco/cisco.

P.S. One more thanks to Maxim Zimovets from Cisco for emergency analysis and vendor-side conclusion.
Alt text

Не ждите, пока хакеры вас взломают - подпишитесь на наш канал и станьте неприступной крепостью!

Подписаться

Андрей Дугин

Практическая информационная безопасность и защита информации | Information Security and Cyber Defense in Deed