KrebsOnSecurity hit by same IoT botnet that hit a record DDoS on Cloudflare
twitter.com
twitter.com
> The NaWas infrastructure is designed as an on-demand service. After detecting an attack, the traffic is routed via BGP to the NaWas hardware and then the mitigation process starts. All traffic is then rerouted and the own connections can thus manage with less capacity
> NaWas has a BGP session with the participants on the clean side (with IXPs) on a private VLAN. A member can redirect a specific prefix or / 24 by advertising that prefix on the NaWas BGP session. NaWas advertises the prefix on our upstreams (transits & peering). So the trigger for redirecting is done manually or automatically by the participants.
They handle on average 9 attacks per day. Italy is following suite and setting up a similar organization.
The thing is, they provided a large, under-educated user base with powerful, complex and utterly sophisticated tools.
That the attacker targeted those and not less numerous and better guarded mainstream manufacturers only pays tribute to the success of Mikrotik.
Do you think the expensive manufacturers don’t do that? I’ve seen un-configured, un-updated, EoL Cisco equipment. Small businesses get sold it because it’s “the best”, but they don’t actually need anything nearly that complicated and don’t want to pay the ongoing costs so you end up with things like managed switches being used like you’d use a dumb switch that’s 1/10th of the price.
I was in a server room a couple of years ago that looked like a Cisco museum, with some of the kit dating back to the early 2000s. When I mentioned that running a business on gear that had been EoL'd for a decade+ wasn't quite up to security best practices my contact shrugged and said they wouldn't be updating any of it in any case since they'd long since lost all of their access passwords.
https://www.cvedetails.com/product/23641/Mikrotik-Routeros.h...
Step 2: Ban IoT that doesn't meet software compliance
Step 3: Pray that the compliance standard makes any sense and that the NSA don't require backdoors or suspect CRNG.
The general public can’t distinguish between secure and insecure products, but they can read a list of products that are covered by the $0.99/month insurance plan, and anything not on that list you need the $1.99/month plan.
DDoS victims can then make a claim against the insurance companies (who own the liability arising from each IP address; ISPs can de-NAT), a court can evaluate the evidence if necessary, and the insurance providers pay out.
N.B. It’s actually experts who would be penalized most by this scheme, because if you do something like run a customized FreeBSD box, it’s unlikely to appear on the audited-device list.
The "audit" can be as simple as the insurance company running automated pentests trying published exploits and passwords.
That would still achieve the desired goal (the majority of botnets spread via well-known vulnerabilities and/or bruteforced credentials, custom equipment where manual effort is needed on the attacker's part are a minority) while allowing enthusiasts to run custom hardware.
I worked for a popular service that regularly received DDoS attacks from botnets. We had logs with the IPs of tens of thousands of vulnerable devices. If you scanned them you could see the vast majority were compromised routers, VPNs, or IoT devices. Most of them had open proxies installed and were easy to identify as compromised. For the larger ones we could reach out and get them shut down (usually). But we didn't have time to contact thousands of ISPs.
I would've been happy to forward those logs, even with verification of compromise, to an independent body that could follow up and get them shut down. Even if a small fraction of ISPs didn't comply it would still remove the majority of compromised devices. Most of the companies we contacted were more than happy to get rid of problematic hosts and acted quickly. They just didn't have the expertise to monitor for such things themselves.
It would all have to be voluntary, of course, but it could be done.
This is the type of thing that I think CERT was originally intended for, but for whatever reason doesn't seem to handle.
I wonder if there are other RBLs worth subscribing to and blocking.
As an end user with a compromised device, it might be frustrating though... but then they probably should know and do something about it.
Is there larger scale accessible research on these botnets and the devices they affect?
Like, is the git repo secure? Can we add code that allows a backdoor or reaches out to a command-and-control server? Or how are their packages secured? Can we upload a malicious one to their package repo? Is the distribution server secure? Are the devices exposed directly to a WAN? Can we sell knock-off devices or modify legit devices before we resell them? Can we design them from the beginning to be exploitable? Were the engineers lazy and implement zero security controls? etc, etc...
This is why defensive security is rather difficult. You have to get everything right, but attackers only have to be right one time. Then when you get consumers involved, it becomes significantly more complicated and difficult. Some of these devices can stay active for years, and the owners realize no difference as long as it still works as expected.
Next you come up with some way to discover and exploit as many of these devices as you can. It could be by finding all IP addresses of exposed devices via something like Shodan, or exploiting and taking over a centralized server that all these devices communicate with, or some other novel way.
Anyways, once your in control of all these devices, you pick a target URL and send a command to all your devices to start CURLing a specific address over and over and over.
Boom, you have a IoT botnet for DDoS attacks.
I have a stereo component and a couple other things that I'll periodically allow to check for updates and then re-enable the blocks. If you have things like surveillance speakers that require a mothership to function, exceptions for those endpoints would of course be needed.
Someone recently gifted me an RGB lightbulb which demanded to be added to my WiFi network to set it up. None of the functions would work without the lightbulb being connected to the internet, even after setup (except on/off). The bulb would only take commands from the remote server! Infuriating. They also used some TLS so it wasn't straight-forward to spoof the packet.
It's been collecting dust not being plugged in since then. I feel bad not using it, and didn't tell my friend who gifted it to me. But I'm not going to let that thing run in my network sending usage statistics to the company. Or worse, get exploited. The lightbulb runs a web server, for fucks sake. What a dilemma.