Re:Hacking Modems (and Investigating Who Hacked My Modem)
by EligibleDecoy on Tuesday June 04, 2024 @10:27AM
(#40574998)
My bet on the replays was that the attacker misconfigured their payload or something and it was meant to replay command and control requests to obfuscate where the C2 server was
Re:Hacking Modems (and Investigating Who Hacked My Modem)
by underlogic on Tuesday June 04, 2024 @02:36PM
(#40577571)
Did they *pay* him? He kind of saved them, tipped them off to a complete compromise of their security infrastructure which was not trivial to discover. Looks like he got nothing in return for "doing the right thing". How insulting is that? What is their perception of someone walking in to their offices with this essential information? I guarantee his self image and their perception are very different. They see an overly caffeinated attention seeking "nerd" just handed them a 300k exploit in exchange for a gold star and then they ran like smeg to cover their asses and take all the credit internally. He feels like superman, goes home to his basement apt, microwaves some noodles and writes a blogpost. This is a perfect example why you never, never report a 0day.
Re:Hacking Modems (and Investigating Who Hacked My Modem)
by rtev on Tuesday June 04, 2024 @07:58PM
(#40580138)
Sam is a very famous security researcher, so I would be shocked if he wasn’t making upwards of $350,000 a year. These articles he writes make him a significant amount of money via reputation boost.
Re:Hacking Modems (and Investigating Who Hacked My Modem)
by TooMuchOnMyMind on Tuesday June 04, 2024 @02:48PM
(#40577698)
See, this is what you would call ILLEGAL!!! Instead of trying to hack them back, a good and safe idea MIGHT be telling the POLICE! that would make sure that YOU don't go to prison for a crime! I'll list a few of the crimes you have committed!
1. Computer Fraud and Abuse Act (CFAA) | 18 U.S.C. 1030
- Putting it simply, you've broken every line, rule and statement in this
document!
2. Unauthorized computer access
-You've broken this ahem- "millions" of times. Thankfully, "It's usually a
misdemeanor, punishable by up to a year in county jail."
And thats a wrap! Hope you had fun in your year in county jail and even longer in state prison!
Re:Hacking Modems (and Investigating Who Hacked My Modem)
by TeMPOraL on Tuesday June 04, 2024 @04:46PM
(#40578756)
Great writeup. There's just one thing I don't get: the auth part. It seems the author managed to access protected endpoints without any auth, by just repeating the same request over and over until the endpoint randomly accepted it. The part that confuses me is, how could that possibly happen? What possible architecture could this system have to enable this specific failure mode?
I struggle to think of anything, short of auth handling being a separate service injected between a load balancer and the API servers, and someone somehow forgot to include that in autoscaling config; but surely this is not how you do things, is it?
Re:Hacking Modems (and Investigating Who Hacked My Modem)
by spopejoy on Thursday June 06, 2024 @10:16AM
(#40597683)
The article mentions Spring, although I couldn't see anything in the output that would tip me off (like massive java.lang.xxxException traces) ... plus I've seen other mentions of singletons in this discussion --
Are you describing some kind of server-side global object that statefully says a session/api key is "authenticated" and will then allow the request during that time frame? That seems like a bug you could drive container ships through. Yes I know saas s/w sucks out there but this would seem to at least be something an audit could easily flag.
Re:Hacking Modems (and Investigating Who Hacked My Modem)
by gianpaj on Wednesday June 05, 2024 @05:39AM
(#40583058)
This reminded me to turn off "privacy settings" to "keep your vehicle in good condition and observe the vehicle's health" on my Volvo XC40 after the mechanics asked me to turn it on yesterday during the yearly maintenance.
I don't know if they can change some settings remotely, but I prefer to be cautious
Re:Hacking Modems (and Investigating Who Hacked My Modem)
by Namidairo on Wednesday June 05, 2024 @10:27AM
(#40585193)
> Somehow, someone was intercepting and replaying the web traffic from likely every single device on my home network.
Normally I'd laugh and assume device compromise but...
The largest ISP in Australia (Telstra) got caught doing exactly this over a decade ago. People got extra paranoid when they noticed the originating IP was from Rackspace as opposed to within Telstra. Turned out to be a filter vendor scraping with dubious acceptance from customers. The ToS was quietly and promptly updated.
Re:Hacking Modems (and Investigating Who Hacked My Modem)
by lanrat on Wednesday June 05, 2024 @11:48AM
(#40586404)
I observed very similar behavior a few years back when transferring files between two servers under my control on different parts of a large university network.
We also initially thought we were the subject of a breach, but after the investigation we determined that the network's IDS was monitoring all traffic, and upon certain triggers, would make identical requests from external networks.
We found a way to identify all other similar IDSs across the internet and even "weaponize" this behavior. We ended up writing a paper on it: https://ian.ucsd.edu/papers/cset2023_fireye.pdf
1. Computer Fraud and Abuse Act (CFAA) | 18 U.S.C. 1030 - Putting it simply, you've broken every line, rule and statement in this document! 2. Unauthorized computer access -You've broken this ahem- "millions" of times. Thankfully, "It's usually a misdemeanor, punishable by up to a year in county jail."
And thats a wrap! Hope you had fun in your year in county jail and even longer in state prison!
I wonder if it’s a mix of exhilaration and being terrified!
I struggle to think of anything, short of auth handling being a separate service injected between a load balancer and the API servers, and someone somehow forgot to include that in autoscaling config; but surely this is not how you do things, is it?
Global singleton shared across requests, instead of request scoped.
1. [Client 1/You] Auth/write to variable (failed).
2. [Client 2/ISP] Auth/write to variable (success).
3. Verify what the result was (success)
A race condition combined with a global singleton can easily explain such behavior.
Are you describing some kind of server-side global object that statefully says a session/api key is "authenticated" and will then allow the request during that time frame? That seems like a bug you could drive container ships through. Yes I know saas s/w sucks out there but this would seem to at least be something an audit could easily flag.
That's more API endpoints than some first tier public clouds, wow. For a modem.
Somebody wanted (and sorta deserves) promo..
But also not, because the whole platform turned out to be incredibly insecure! Egregious!!!
Normally I'd laugh and assume device compromise but...
The largest ISP in Australia (Telstra) got caught doing exactly this over a decade ago. People got extra paranoid when they noticed the originating IP was from Rackspace as opposed to within Telstra. Turned out to be a filter vendor scraping with dubious acceptance from customers. The ToS was quietly and promptly updated.
We also initially thought we were the subject of a breach, but after the investigation we determined that the network's IDS was monitoring all traffic, and upon certain triggers, would make identical requests from external networks.
We found a way to identify all other similar IDSs across the internet and even "weaponize" this behavior. We ended up writing a paper on it: https://ian.ucsd.edu/papers/cset2023_fireye.pdf