Should an ISP be to blame for the insecurity of their routers? Or the router manufacturer? Or the router customer? You be the judge.
It’s 2023-Oct-25 at 7:16 pm. An ISP customer in Ohio posts a complaint about their ActionTec T3200 suddenly offline with a solid red LED.
So, I wonder what happened. A poison pill? My neighbor and I both have an Actiontech T3200 router. His internet service went down last night. Mine went down this morning. We both did a routine reboot – power off / on. We both had the reboot fail after about 10 seconds. The routers now just sit there with a steady red light on the front. They won’t even respond to a RESET. He was able to get through last night and get a new router sent out. I repeatedly try live chat and get sent to the phone number, due to the backlog. The phone number is so backlogged, that it tells you to go back to chat, and ends the call. Windstream Direct has not been looked at since yesterday. Very strange.
Poison pill was right. But how did it get in?
A new report from Lumen Technologies’ Black Lotus Labs (try saying that five times fast) reveals that attackers moved quickly to destroy as many routers as possible, expanding to 600K, perhaps due to weak credentials or a backdoor.
At this time, we are unsure of the exploit used to gain initial access. When searching for exploits impacting these models in OpenCVE for ActionTec, none were listed for the two models in question, suggesting the threat actor likely either abused weak credentials or exploited an exposed administrative interface.
WindStream was the affected ISP, and their own documentation of the ActionTec router insists they made credentials random.
Password: The password is located on a sticker on the side of the modem. This password is different on every single T3200/T3260/T3280/T4220 modem.
Different passwords doesn’t mean true entropy, nor strength. The passwords could lack variety and repeat a pattern, for example, or maybe not even be different at all. This is easily verified.
And, assuming we verify passwords are different and strong, we have to next consider a likelihood of a backdoor (weakness in an “exposed administrative interface”).
Notably, the ActionTec T3260ws user manual lists an admin GUI interface and Telnet. Who the #$%@#$ still offers a Telnet service option?! But I digress… Telnet seems to get disabled by default, thank FSM, while an admin GUI sits enabled with a port open and default “root” user.
Lumen has an excellent and detailed report (with IOC) of what happened once the attackers had control of the router. And it concludes with this shout out to historians:
…this campaign resulted in a hardware-based replacement of the affected devices, which likely indicates that the attacker corrupted the firmware on specific models. The event was unprecedented due to the number of units affected – no attack that we can recall has required the replacement of over 600,000 devices.
Challenge accepted!
Here’s my activedefence / hackback / defendforward — whatever you want to call it — presentation at CONSEGI from 2012 where I explained how and why 4.5 million vulnerable ISP hardware devices had to be upgraded.
Ok, you might say, but there was a plausible software fix in this case that brought the final tally down to 300K devices. Fine, it’s true there was software to the rescue. I would say the ActionTec perhaps could also be rescued with a flash or whatever, but let’s not get into semantics.
Instead, consider the 2016 BrickerBot, which seemingly was named and done entirely for attention seeking purposes.
In an interview this spring, the Janitor explained that he refers internally to BrickerBot as “Internet Chemotherapy” and that he created the malware as a way to sabotage vulnerable devices before they were infected with the Mirai malware, which a hacker had used in the autumn of 2016 to launch some of the biggest DDoS attacks known to date.
How successful, I mean awful, was the BrickerBot? Let’s just say this quote comes from an article titled “BrickerBot Author Retires Claiming to Have Bricked over 10 Million IoT Devices“.
Ten. Million. Devices. Bricked.
That’s just a wee tad over the 600K devices needing upgrades, as claimed by Lumen as unprecedented.
And perhaps someone from NIST can remember more clearly than me how many devices were “accidentally” bricked in crazy early days of over-zealously pushing “hardened” configs? It was a lot, although far too many people want to forget 1990s hey days and probably now have lost records of mistakes made.