The database vendor isn’t mentioned in the report but I think we can probably all guess the name.

Aside from that important fact, this report is about the dangers of centralizing biometrics into a singular place where a single mistake harms practically everyone in society. Not all, but some, and that’s more than enough to worry.

The publicly exposed database contained 1,661,593 documents with a total size of 496.4 GB. I saw documents containing: facial scan images, finger prints, signatures (in English and Hindi), identifying marks such as tattoos or scars, and much more. There were also scans of documents such as birth certificates, testing and employment applications, diplomas, certifications, and other education related files. Among the most concerning files were what appeared to be the biometric data of individuals from the police and military in verification documents. Upon further investigation, I saw documents indicating the records belonged to two separate entities which suggests they operate under the same ownership: ThoughtGreen Technologies and Timing Technologies, each of which provide application development, analytics, development outsourcing, RFID technology, and biometric verification services.

Fingerprints are public yet distributed very widely, in other words, if you think about how often and where you have been leaving yours… like on a glass at a restaurant.

However, having your fingerprints grabbed by someone pulling over 1.5 million other people’s fingerprints at the same time (due to a single database vendor on the Internet failing to achieve authentication) is a different issue.

Related:

Here’s a very similar story, where hacking the data service vendor Snowflake just led to a massive leak from many of their customers.

In the conversation with Hudson Rock, the threat actor reveals that there is much more to the story than these two breaches, and that additional major companies suffered a similar fate, allegedly including:

— Anheuser-Busch
— State Farm
— Mistubishi
— Progressive
— Neiman Marcus
— Allstate
— Advance Auto Parts

Further explaining the source of the hack, the threat actor adds that all of these breaches stem from the hack of a single vendor — Snowflake. […] To put it bluntly, a single credential resulted in the exfiltration of potentially hundreds of companies that stored their data using Snowflake, with the threat actor himself suggesting 400 companies are impacted.

When a single employee can be compromised to give access to hundreds or thousands of customers, the Snowflake response probably shouldn’t be that context is needed.

Even worse is when they start saying that Snowflake wasn’t involved in any way with the massive theft of customer data from Snowflake. Uh huh.

Here’s what they allegedly are trying to snow reporters with:

On may 31st, Snowflake released a statement in which they claim that they are investigating an industry-wide identity-based attacks that have impacted “some” of their customers.

Industry-wide is another way of saying baseline.

What Snowflake inadvertently is saying is they fell below an acceptable baseline while being trusted to NOT do exactly that.

Watch the “who me, am I the baddie” Snowflake now try to point the finger at its customers, a known horrible idea and safety anti-pattern. Like blaming bank customers for the vault being robbed of their money. Or blaming Tesla owners for being killed by the Autopilot.

That’s very bad news for some, even if not every single customer. It’s a lot more bad news than if Snowflake had done more to prevent a single employee compromise affecting so many customers, let alone turning a blind eye to widespread known threats that would very predictably harm their customers.

Negligence? Due diligence? You make the call. Every Snowflake customer now should be planning to exit that vendor to find better care, not least of all because of how Snowflake is responding.

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.

There’s a detail in the recall news that caught my eye.

The remedy will remove dependency on the driver seat occupancy sensor from the software and only rely on driver seat belt buckle and ignition status to activate the seat belt reminder signals, the NHTSA said.

Tesla is being forced to remove driver seat occupancy sensor code, in order to ensure proper driver seat seatbelt use.

Sounds suspicious, because this says a sensor meant to provide safety is being disabled by safety regulators for… safety.

Backwards?

It suggests something about Tesla management designing their sensor code that… hmmm how did safety inspectors put it… “failed to comply with the federal safety requirements“.

Why would Tesla ever do that, and how? What was the management design decision that made a safety sensor unsafe, interfering with other safety sensors even?

It’s the literal worst engineering possible, a social harm, like Tesla designing an occupancy detector for fire that lets people die in a fire. No, worse, like an occupancy sensor design that overrides and disables the sprinkler system, a “safety” decision ensuring death by fire.

Were Tesla drivers complaining they couldnt sleep while using Autopilot when a seatbelt alarm kept waking them and reminding them they were about to kill and be killed? Tesla cars have an almost unbelievable amount of complaints about safety.

NHTSA records for just one 2023 Tesla model, for example, show owners are livid about ongoing software integrity breaches.

Who is really responsible for so much backwards and harmful Tesla “safety” software being pushed to public roads?

Many people on public roads in America now wonder how safe anyone is when a Tesla is near; how many seconds left before the Tesla has killed again. A Prius driver, for example, was just killed.

According to Kent Police, multiple witnesses stated a Tesla ran a red light at the Central Avenue and Smith Street intersection, colliding with both a gray Prius and a red Prius. Police say the red Prius was reportedly pulling out of a restaurant parking lot, and was hit so hard it was pushed into a nearby wall.

Police referred to it as a homicide investigation, and said they had a warrant issued for tests of the software… no, sorry that’s not right, only of a human who was sitting in the Tesla.

It has the hallmarks of the Tesla AI stop light/sign threat that I’ve written about many times before. One might even say this is a case where, regardless of who is holding the wheel, a robot is being trained to ignore laws and to not stop as expected or required.