The Axios supply chain attack used individually targeted social engineering(simonwillison.net) |
The Axios supply chain attack used individually targeted social engineering(simonwillison.net) |
I've got plenty of machines, including that one shitty laptop I trust even less than the rest. Arguably the only way to operate securely is to consider that most devices in your house (and at work) are compromised and hostile, that most networks are trying to fuck you up (for example not HTTP at my home: simply none, it's not allowed) and that they're really out there to get you. And, yet, to have a setup that works.
Same things with my phones: I've got one real phone, with two apps I added to it. Country's mandatory EID app and brokerage's 2FA app. And that's it. Nothing else. Nada. Zilch. One phone, two apps. No email account. Nothing.
Then I've got another phone, with another subscription, where I've got Telegram, that app to see the targets at the shooting range (long distance shooting: there are webcams in front of targets so you can see where you hit), the home automation apps, etc. All those shitty phone apps developped by clueless devs: they go on that phone. The email? Some throwaway email account I don't care about. You can 0-day that phone: I wouldn't give a shit. And I tell people: "My name on Telegram ain't my real name" and they love it. Non-technical people: they begin to understand and they love it.
People are going to need to step up their security game big times now for I think we're in for quite a wild ride.
I know it's bad but I'm not going to say there's not some schadenfreude seeing what happens to those who were calling others "paranoid".
I mean: we're talking about people "quickly installing software (as admin/root)" on their main machine.
The road is going to be long for it's an entire shift of mindset that's now required.
Convenience vs security: you pick. Video call vs major project compromised: you pick.
The relevant part is:
* they scheduled a meeting with me to connect. the meeting was on ms teams. the meeting had what seemed to be a group of people that were involved.
* the meeting said something on my system was out of date. i installed the missing item as i presumed it was something to do with teams, and this was the RAT.
Oh dear.
Up to usual Microsoft Teams standards
Use the browser sandbox to protect yourself.
Everything was normal messaging. Back and forth. Got the invite to schedule a google meet. All looked like all the other things.
Day of meeting, click the google meet button in the email.. redirect to a browser screen showing that google meet needs an update, this is the microsoft store.
Rush, hurry, meeting will be late!
except it was not the msoft store it was all fake.
I wish indeed and other job sites shared more info about these (like fake company signed up with a fake email from a vpn to publish this job listing that possibly infected 1,000 computers- and some are reporting X Y Or Z (ransom, whatever)
The time pressure means I'm less likely to pay attention to what I'm installing.
As a DevOps, I have seen the quote about "premature optimisation's root of all evil" in real life quite often. In fact, optimising one bottleneck quickly yields another one -moving the goalpost further-, potentially increasing business-impact if the flow is not contained properly.
Especially during incidents, _rushing_ to fix often yields more problems. I've seen people isolating/shutting-down mildly misbehaving instances. Causing excessive load to the remaining and starting the cascading failure like dominos falling one after another.
Which reminds me a scene from "The Office", where Dwight goes rogue and conducts a "Fire-Drill" by locking doors and deliberately causing smoke. Everyone panics and hell breaks loose. This is at the beginning of the episode, maybe 5-minutes tops. I show this at the incident-management training, this is how people behave in real life. No joke.
To give more concrete aspect on the moving goalpost: SWEs improve transaction processing with multi-threading, but that causes more connections/transactions to the database. Even though theoretical gains are Nx (n-times depending on threads/cores), real life gains are 1.2x-1.3x, because database connections are getting occupied. As the next step, increasing number of DB connections helps, maybe add another master node (risk of having deadlocks increase, but ignore for now for the sake of argument). But then the disk IO becomes the bottleneck due to write-heavy (payments domain). Then we add Redis to reduce load, and maybe some asynchronous processing. At this point complexity increases and we need to solve rare occurrences of duplicate data or race-conditions because it is not single-threaded process anymore...