Hacker News Reader

Comment by revelation | Hacker News Reader

I'm not sure I follow, what you can do with the bits of information you named when this vulnerability is not present?

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.

View on HN

> what you can do with the bits of information you named when this vulnerability is not present?

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.

Not really. As the preceding comment points out: it's pretty unusual for an ASA to speak SNMP to the Internet. Not having SNMP publicly exposed is CISSP-level (read: elementary, and idiosyncratically specific) best practice.

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.

That's what I was trying to say, you have access to a machine like a webserver that had internet-facing services you could exploit and now you want to go deeper into the network.

Or do they usually only speak SNMP on a management port?

No, I'm saying you can't do that with this bug; that's what I mean by "not a pivot bug". It's a way of persisting inside access you got some other way. Because, again, people don't listen to SNMP on the outside interface.

And that is what the parent is saying. The "other way" is through the web server that is exposed to the internet and can reach the internal ASA.

Reaching "the internal ASA" isn't giving you access the webserver didn't already have, hence, persisting, not pivoting.

Just a quick thought... what about all the monitoring software that relies on SNMP?

Not only is it all internal, but in modern networks SNMP is usually run on specific dedicated backchannel networks, precisely because anyone who has done network security since 1994 knows that SNMP is terribly insecure.

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.

Just a quick google for: Remote grafana SNMP, Remote LibreNMS SNMP, Remote Observium SNMP, etc. leads to all kinds of good stuff.

I mean, you can literally just ask a site like Shodan to give you a list of publicly available SNMP interfaces. Do you see a lot of what look like ASAs on that list?

I'd say that not only is it all NOT internal, it is often not run on "specific dedicated backchannel networks". Ask anyone who was a victim of a DDoS that made use of SNMP amplification.

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 not that common to monitor your network infra from the internet, is it? surely you're piping SNMP over local interfaces?

Actually this is kind of a sad situation; I have seen some SNMP publicly exposed, and a lot internally even when its' not actually being used and with default community.

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'm not sure what I think about the first two parts of your comment, but I'm a nerd so I can't let the last sentence go: what do padding oracle vulnerabilities have to do with error pages?

my understanding was that at least one of the attacks from a while back only gave the oracle due to different actual error descriptions in the response, whereas had there been custom error pages defined for all errors, there was no oracle to use.

I could very easily be wrong though.

Nope. It's any behavior change in response to bad ciphertexts, which changes are easily inferred. For instance: Lucky 13 is a padding oracle that uses only very fine-grained timing information to discern errors.

If SNMP wasn't public exposed (along with default community strings), we wouldn't ever see DDoS making use of SNMP amplification attacks.

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.

On an ASA?

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?

Reply on news.ycombinator.com