This article is wrong. It states: "MicroTik Cloud Core routers, mainly used by enterprises, may be affected if they run versions 1016, 1036 or 1072 of the MicroTik RouterOS.
That's not true. Linode had numerous allocations, including up to a /16 (if I recall), before receiving an ASN. They simply announced them from datacenter transit, which has pros and cons.
If doctors and nurses are at breaking point, its down to them been underfunded and under resourced. Blaming this on immigration is unhelpful and wrong!!
Can any one explain why they keep referring to this as a complex attack? From the article it seems to be a simple volumetric attack. They mention that it uses UDP port and TCP port 53, nothing complex about that...
Am I missing something here. It wasn't an L7 attack (or was it?) Why keep referring to it as complex?
I think the market's expectation is that a DNS provider is prepared for a DDoS of any size, but not necessarily any level of complexity, so that's a lot of incentive to talk up the complexity of the attack.
What's described in this incident report is totally within the capabilities of a single individual with public knowledge, though. If they could have proven otherwise, they probably would have (unless that somehow conflicted with their criminal investigation).
Much of the complexity is likely in building and managing such a large botnet.
There also isn't a lot of details here on the exact nature of the traffic. They say it was hard to distinguish between legitimate traffic and this malicious traffic. So the botnet is at least rotating their requests through lists of customers hosted with them (though that isn't complex, but it is forward thinking. If the botnet was all making non-stop requests for just a few domains, that would be a strong signal to start filtering traffic, first internally, then pushing ISPs to block it upstream).
I'm a huge fan of freeradius. I have tried multiple propiortary radius servers and I can honestly say freeradius is the most flexible most reliable radius server in the world. Thanks so much for your effort.
You would have to have the ASA configured to accept SNMP packets from the IP your sending them from (or maybe spoof the source address if you knew it as it would be a UDP packet) and you would also have to know the SNMP community string.
Chances are if you had all of this info you could cause all sorts of damage even without the vulnerability.
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.
> 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.
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.
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.
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?
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.
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.
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.
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.
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.
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?
ASAs are often used at the perimeter of small satellite networks using a local ISP's internet access, and then connecting back to HQ with IPSEC tunnels. I would guess that it is not uncommon, though bad practice, to centrally monitor SNMP on the external interface instead of over the IPSEC tunnel (which can be a little tricky to do).
Yeah, it's true I guess, and if you're using a random community string and this is NSA, I think we can all safely assume NSA knows every community string spoken anywhere on the public Internet.
Those are model numbers, not firmware versions. He lifted that from this Krebs artical (https://krebsonsecurity.com/2018/05/fbi-kindly-reboot-your-r...) which is also wrong.
All Mikrotik products running less than version 6.38.5 are vulnerable: https://forum.mikrotik.com/viewtopic.php?t=134776
It makes me wonder what else is wrong....