Cisco Adaptive Security Appliance SNMP Remote Code Execution Vulnerability
tools.cisco.com
tools.cisco.com
At least 3 years.
That said, the term "responsible disclosure" is Orwellian, and you should very much avoid using it.
The better term is "coordinated disclosure". But uncoordinated disclosure is not intrinsically irresponsible. For instance: if you know there's an exploit in the wild for something, perhaps go ahead and tweet the vulnerability without notice!
I see it as a kind of Hippocratic Oath in the field.
I must be misunderstanding. Would you mind expanding on this more?
I would personally in almost every case report vulnerabilities I discovered. But not in every case (for instance: I refused to report the last CryptoCat flaw I discovered, though I did publicly and repeatedly warn that I'd found something grave). More importantly: my own inclination to report doesn't bind on every other vulnerability researcher.
I understand morality is subjective, but that's my 2 cents on the matter.
EDIT: about the vulnerabilities you didn't disclose, I really can't understand why not. Why not just send an email to the maintainer: "hey, when I do X I cause a buffer overflow"? You don't even have to help them fix it. You probably won't answer this, but can you tell me why you wouldn't disclose a vulnerability?
I confess to being a bit mystified as to how work I do on my own time, uncompensated by anyone else, which work does not create new vulnerabilities but instead merely informs me as to their existence, somehow creates an obligation for me to act on behalf of the vendors who managed to create those vulnerabilities in the first place.
Perhaps you have not had the pleasure of trying to report a vulnerability, losing several hours just trying to find the correct place to send the vulnerability, being completely unable to find a channel with which to send the vulnerability without putting the plaintext for it on the Internet in email or some dopey web form, only to get a response from first-line tech support asking for a license or serial number so they can provide customer support.
Clearly, you have not had the experience of being threatened with lawsuits for reporting vulnerabilities --- not in software running on someone else's servers (which, absent a bug bounty, you do not in the US have a legal right to test) but on software you download and run and test on your own machine. I have had that experience.
No. Finding vulnerabilities does not obligate someone to report them. I can understand why you wish it did. But it does not.
Can't I just flip this around on you and say you have an ethical obligation to spend some of your time looking for vulnerabilities? If you started looking, you'd find some. Why do you get to free-ride on my work by refusing to scrutinize the stuff you run?
To some small extent, yes, though how much work is up for debate. Maintainer's email and PGP public key is right there on the website? Yeah, I think you're obligated. No email you can find, no way to contact them, or are just outright hostile? No, I think you shouldn't have to deal with that.
But I feel like you agree with that, though maybe not in those exact words. After all, you've had to jump through all kinds of hoops to disclose vulnerabilities, been threatened with lawsuits for doing the right thing, and yet you still practice responsible disclosure in almost every case in spite of the burden of effort and potential risk. Aren't you doing it because you think disclosure is the right think to do? That's all I mean by obligation.
EDIT: sorry, not "responsible disclosure," "cooperative disclosure" or whatever term you want to use for disclosing the vulnerability to the maintainer.
Nobody has to enter a burning car and risk his life but at least you have to call the emergency service or do whatever you can reasonably do to help. And it really doesn't matter whether you are doing your work delivering packages, whether the accident was the fault of the driver because he was driving intoxicated, if somebody else could also help or whatnot.
Discovering a vulnerability is of cause different in most respects - the danger is less imminent, the vendor may have a larger responsibility and so on. But the basic structure is the same - more or less by accident you end up in a situation where there is a danger and you are in the position to help to make the outcome probably better.
So I think one can not simply dismiss that there might be a moral obligation to disclose a vulnerability to the vendor on just the structure of the situation, one has to either argue that there is also no moral obligation in the accident scenario or argue that the details are sufficiently different that a different action - or no action in this specific case - is the morally correct or at least an morally acceptable action.
I would feel a moral obligation to help mitigate concrete physical harm to victims of an accident. I feel no such obligation to protect against hypothetical threats to computer systems.
Chances are, you recognize similar distinctions; for instance, I doubt you feel obligated to intervene in accidents that pose only minor personal property risks.
But I need to be careful saying things like that, because it is very easy for me to say that, because I don't spend any time looking for those kinds of flaws. Security research is pretty specialized now, and I don't do spare-time Windows work. I might feel differently if I did.
I would not judge the (many) researchers who would not necessarily disclose that flaw immediately.
So, it won't be fixed.
Hopefully only one or two people know about the same flaw you found...
Oh, but you would know ahead of time if concrete physical harm could possibly come to the victim of an accident?
Well good for you! You should probably be in charge of defending all infosec research, since apparently you can't be hacked.
A good shorthand definition for "responsible disclosure" is "report to the vendor, and only to the vendor, and disclose to nobody else until the vendor chooses to release a patch, and even then not until a window of time chosen by the vendor elapses."
Maybe you thought I was saying "the only way to disclose responsibly is to honor a formal duty to the vendors of insecure software". No, that was not my argument. If you thought it was, well, that's a pretty great demonstration of how the term is Orwellian, isn't it?
Or I could be missing part of your argument (it was quite terse, after all). Maybe you could fill in some details.
Thankfully, the black market doesn't want 99.99999% of the vulnerabilities people find.
I have friends who have sold vulnerabilities to people other than vendors. I do not think they're unethical people, and I don't know enough about those transactions to really judge them. So, it really depends, I guess. But if it were me, I'd be very careful.
I don't feel wrong saying that all of those are irresponsible. There are some people who write good code, who at least make an effort to avoid vulnerabilities, and those are the responsible ones.
I will say we'll never get real confirmation if this was actually stolen from the NSA, but if the other bundle contains a bunch of nice original vulnerabilities people will presume it was.
A laptop alone could get me $250, but no one wants to give me even $10 for telling them their door is unlocked.
In general what are some risks invovled (I am just not very familiar and wondering in general). Is it a tax issue, the chance IRS could come after you for undeclared income?
Maybe believing that it's good when fewer vulnerabilities exist and when attackers are less able to exploit things? Does that count as charity?
https://www.washingtonpost.com/world/national-security/power...
The publicly available data would suggest that thus-far NSA-hoarded vulnerabilities are definitively known to actors who appear willing to act against US interests.
Vendor disclosure means those vulnerabilities can be patched and US interests can cease being vulnerable, but could also confirm NSA awareness of vulnerabilities - which could in turn cause attribution concerns for past or present operations the NSA is undertaking or has undertaken using these vulnerabilities (in addition to providing additional credibility to the leaker).
What a tangled web.
Hmmmm.
Or maybe there are lots of overseas networks where they enable SNMP and leave the community string "public"?
(Also: how batshit crazy is it that the ASA will let you use "public" as your community string, let alone default to it?)
Again the case I'm making is that this particular bug is really only useful for persisting onto networks you've already compromised.
I'm thinking specifically of my old company, which used Nagios to monitor a few hundred VMs on AWS in addition to the several thousand servers & all the networking gear running locally.
No! For example, at one place I was employed at, the switches had different VLANs - one for private internal network, one which had external (direct) internet access, one for VoIP telephones, one for printers, one for servers and one for BYOD external consultants. Basically, compartmentalization - and everything was firewalled, and every cross-VLAN access had to be separately allowed.
So this exploit (or, for that matter any switch/router exploit) can be used not just for persisting, but for escalating privileges. Assume you have hacked a fax printer via the telephone line (hey, given that, I'm tempted to actually grab a modem and do some fuzzing with my fax printer...), you can then use its network connection to punch holes in the firewall and spread.
Whereas persisting onto an ASA sounds like an actually widely useful capability! The ASAs don't get reimaged during incident response.
Indeed, yes, but entities large enough to afford dedicated teams to run hundreds of pieces of Cisco gear with proper segmentation etc. usually also tend to be those of most interest to any espionage outfit.
Last I heard, ex-employer switched from huge VLAN switches to dedicated, unconnected switches for each network part after Snowden. Given the leak here, I'd say their fear wasn't totally unjustified.
In environments I've seen, the network management network is the thing most likely to be isolated first.
In any case, this is after all just the free stuff. If you believe that what they are offering is the real deal, of course, and with this release I'd put the probability at >0.
Would it be very had to sniff traffic and brute force the secret otherwise?
> Exploitation and Public Announcements
> On August 15, 2016, Cisco was alerted to information posted online by the Shadow Brokers group, which claimed to possess disclosures from the Equation Group. The posted materials included exploits for firewall products from multiple vendors. The Cisco products mentioned were the Cisco PIX and Cisco ASA firewalls.
> Source
> The exploit of this vulnerability was publicly disclosed by the alleged Shadow Brokers group.
Chances are if you had all of this info you could cause all sorts of damage even without the vulnerability.
In any case, the scenario for this exploit is that you have access (possibly only restricted, no superuser) to an internet-facing machine and are looking to expand your reach into the internal network. That's why they are keen to exploit these Cisco boxes, they are a stepping stone to the wider network that might be otherwise firewalled off and a pretty permanent one at that.
Rather, my (uninformed) guess is that this implant is exclusively used to persist onto networks that have been compromised through some other vector. It's not a pivot bug.
Or do they usually only speak SNMP on a management port?
It may be a little less rigorous because ASAs are often prem boxes in enterprise environments, not like tier 1 backbone components. But it might be a little more rigorous because ASAs are firewalls.
I would agree that it should be internal and should be run on internal-only interfaces/networks but the reality is that that very often isn't the case.
The average ASA is better off than most other devices simply because one must explicitly configure and enable SNMP on it. Too many other devices ship with it enabled, accessible from 0/0, with the default community strings set to "public" and "private". I believe the last abuse@ e-mail I received notifying me of a customer with a device exactly like that was on Saturday.
It's one of those issues where a CISSP will evaluate the Impact x Likeliness metric and schedule a fix for 'next quarter'.
Similar to when the various big padding oracle web attacks came out; you'd have been in a much better position had you fixed the default error pages, but that's not enough a high-risk issue to prioritize a fix.
I could very easily be wrong though.
As the senior network engineer at an ISP, I probably see this more than a lot of others here but recent history shows us that SNMP being publicly exposed is rather common.
Obviously, as I mentioned downthread, even something as simple as a Shodan query can show you lots of public SNMP servers. But how many of the are firewalls?
If you have SNMP write access you can effectively control the ASA. You could for example get the ASA to fetch a new configuration from your own TFTP server.
For example: http://www.cisco.com/c/en/us/support/docs/ip/simple-network-...
Hence why SNMP is always protected by an ACL. If you have SNMP exposed then you already have big problems.
Gaining access to that public host would then grant you RCE to the protected internal firewall.
If the public host were hosted, say, at AWS/DO/etc., and used a VPN for access to those internal network devices, you've just gained access to the internal network itself.
(Note also that a) SNMP uses UDP and b) community strings, v1 and v2c at least, are plain-text. SNMPv3 has a bit more protection but it's not as widely used.)
Well fuck, NSA was inside pretty much any corporate network they wanted then.
Wouldn't the firewall be just as exposed to the internet? After all, that's what it's job is: to protect the internal network from the external. In your scenario the attacker would first have to hack the NMS to get the community string on the firewall running SNMP
SNMPv3 supporters different, more secure, authentication methods but a lot or organisations continue to use SNMPv2 because it is a simpler more streamlined setup.
Plus the appliances support different user levels, so you'd still potentially be able to use this to escalate access.
HTTP Status 404 - /security/center/content/CiscoSecurityAdvisory/cisco-sa-20160817-asa-snmp
type Status report
message /security/center/content/CiscoSecurityAdvisory/cisco-sa-20160817-asa-snmp
description The requested resource is not available.
Apache Tomcat/7.0.54
They had so many good things to say about their security-mindedness in this post, they even explained Pythons pexpect, and I can't imagine any parallel universe where that somehow connects to the security of Cisco devices.