Extra Bacon? Yes please, even though the Cisco bug of this name is bad for you Tens of thousands of Cisco ASA firewalls are vulnerable to an authentication bypass exploit thought to have been cooked up by the United States National Security Agency (NSA). The "Extra Bacon" exploit was one of many found as part of an Equation Group cache leaked by a hacking outfit calling itself the Shadow Brokers. …
Until a script kiddie automates the exploit and starts fishing. Want to bet how many community strings might be guessed? I quote from the depth of the net:
By convention, most SNMPv1-v2c equipment ships from the factory with a read-only community string set to "public". It is standard practice for network managers to change all the community strings to customized values in the device setup.
We all know about 'standard practice'. Might be interesting to hear from commentards with deeper insight about this issue.
As this exploit is restricted to Cisco ASA's (possibly PIXes, but as they are end of life I'll conveniently ignore them...), SNMP is enabled by default but no communities/hosts are defined to allow monitoring without further configuration.
As far as best practice, I would assume:
- monitor via a secure path (VPN or secure WAN to the inside interface)
- use standard company-/location-specific SNMP strings that do no include public/private/secret
- use separate communities for RO/RW access and only use RO-communities for monitoring to make capturing RW communities harder
- ensure both SNMP settings/ACL's restrict SNMP access to trusted hosts/networks
None of these practices makes monitoring a firewall difficult for a known authorised party (i.e. if you are doing it internally or via a third party). The biggest challenge for remote monitoring of a firewall on a Internet connection with a dynamic IP and technologies like Easy VPN address that requirement with minimal effort for competent operators.
Based on these recommendations, any ASA's discovered via the Internet with publicly accessible SNMP access are very poorly configured...
There is a wide variety of expertise in the El Reg readership. Can someone please explain what information the Extra Bacon exploit permits a malicious agent to access? What information or web usage is endangered by a Cisco firewall being pwned?
Anon because I prefer not to advertise my ignorance :)
Quick summary (not a network bod but I'm sure one will interject if necessary):
If someone *cough*NSA*cough* (or anyone else, now it's been leaked) sends the thing a specially crafted packet it immediately spews its "private" "cryptography" key back to that sender. Possession of the private key is, literally, total pwnage and opens the (back)door to remote code execution, traffic surveillance/subversion/redirection, etc. All doubleplusbrowntrousersbad if the Cisco/NSA device is a "trusted" component of your own "private"/"secure" network but, to everyone else without such a device on such a network (us), it's all "meh" - the public interwebs are built and run like that anyway, by corporations of letters.
http://www.theregister.co.uk/2016/08/17/cisco_two_shadow_brokers_vulnerabilities_real/
http://www.theregister.co.uk/2016/08/20/cisco_pix_6_nsa_hack/
My understanding is that "Extra Bacon" is an exploit that was used to identify a potential Cisco ASA for compromise and allow remote access. The SNMP test is just an easy way of identifying the exploit bug is present.
Once the Cisco ASA is remotely accessible, the firmware would be replaced with a fully backdoored version that would allow access to specified hosts regardless of the configuration visible to firewall admins. The backdoored version would allow packet capture, permit/deny ACL entries and general remote admin of the firewall.
From the dumps, there were attacks for Netscreen, Fortigate and Checkpoint firewalls.
ExtraBacon is the actual exploit with some shellcode which will change the password checking to allow easier logins. One python file does the SNMP check and exploiting for key and changing the login for the device. Check the part which says 'disable password checking on target'.
A snippet from Firewall/EXPLOITS/EXBA/extrabacon_1.1.0.1.py
----------------------------------------------
print "# cat %s" % self.get_key_file(key = key)
if self.key_data.lower() == "unsupported":
return
print "\nTo disable password checking on target:"
print "# %s exec -k %s %s --mode pass-disable" % (self.env.progname, key, " ".join(self.params.args[2:]))
print "\nTo enable password checking on target:"
print "# %s exec -k %s %s --mode pass-enable" % (self.env.progname, key, " ".join(self.params.args[2:]))
----------------------------------------------
There are so many sysadmins (yes they haven't even heard of sysops yet) who live under a rock and just think the know everything.
Its usually the bunch on here who never miss an opportunity to say they don't have Facebook.
These are the guys who don't patch routers.
*IMHO
At my org they(IT) had to reboot their ASAs about once a month otherwise a memory leak would cause them to stop passing some kinds of traffic and remote management would break needing someone on site to physically cut power to the unit. They never got budget to get redundant pairs too. Maybe the issue had another resolution but I try to stay out of corp IT's business.
They moved off the last ASA maybe a year ago.
At my end of the org we never use Cisco so didn't have that issue. Haven't had the misfortune of managing a Cisco device directly since 2008.
Other than here the last time I saw ASAs was 2 jobs ago and there they had a similar issue but wasn't a memory leak (and they did have pairs). The dumb network engineer set tcp state timeouts to something like 1 week and the state table would fill up maybe once every 1 to 3 months (faster after I started at company ) . They couldn't figure it out for over a year even with cisco support(their workaround was reboot both units remotely via PDU at the same time. They didn't understand why both were affected until I explained to them the state table is replicated between units). Took me about 1 minute. Told network engineer to change the timeout(he feared people would complain about dropped tcp sessions ) and started monitoring state table size via SNMP. State table size never got above maybe 10 or 20k entries for the next roughly 18 months I was there for (the unit max was 500k entries if I recall right). I also don't recall anyone complaining about the firewall dropping their idle connections.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
