Broke into its unsecured cloud storage systems?
More like strolled in for a recce and decided to spraypaint the walls while they were there.
Does "maintaining an attractive nuisance" mean anything anymore?
And this is exactly why SRI is so important & needs to be enforced across all browsers as standard... and flag any sites that don't do this.
More fundamentally, the idea of uncontrolled/3rd party resources being pulled in on client-side without any checks at all is just ludicrous in this day and age. This is precisely what happened in BA's massive keylogging hack, and I'm sure loads of other high-profile examples are just a search away...
Just looked into SRI and that seems like some cool ass stuff. I am a bit concerned that W3 consider SHA384 as the baseline hash... seems like a bit of overkill, especially when considering mobile devices and power consumption. Maybe SHA computing has been optimized in hardware? But then again, scripts don't tend to be that big I guess.
But re-refreshing myself with the BA breakin, their core website was broken into and had their own HTML hacked to pull a script loaded from a non-related domain that kinda looked like it might belong to British Airways...
So, I'm not sure how SRI would have helped here. This wasn't a third-party hosted script that was changed. This was their first-party website hacked to load a third-party script.
The correct solution would have been to (carefully) monitor changes to critical files.. and I'm assuming that their payment pages should have fallen under PCI 11.5(a).
SHA is optimized rather aggressively, and many platforms do have specific hardware to do it.
Even "real time" systems are doing extensive SHA hashing these days to verify that data and code hasn't become corrupted - though mostly guarding against accident rather than deliberate attack.
>especially when considering mobile devices and power consumption. Maybe SHA computing has been optimized in hardware?
Yes. Pretty much all relevant ARM devices support ARM NEON, which is a SIMD extension that includes acceleration of SHA384 and SHA512.
this is exactly why SRI is so important
I'm assuming that Twilio weren't serving their SDK directly from the unsecured S3 bucket and therefore that this was some sort of internal copy. If, by chance, it were the master copy and the change went undetected and was then made public via the official route, the malicious code would have been included in the hash.
SRI can detect changes made after code has been published; if the code has been changed by the back door before it's published, it doesn't really help. That's not to say you shouldn't use it for the cases it covers.
The definition being used here is in regards to the compromise of sensitive user data. By that definition this attack was benign since it didn't infiltrate anything, extract anything, or attempt to damage anything. It was a dry run.
The logic used to determine malicious code isn't quite the same as malicious intent. Code is quantifiable, whereas intent is intangible.
"<CORPNAME> believes the security of our customers' accounts is of paramount importance," a spokesperson told us.
"Haha, just kidding. We can't be bothered even put a simple password on that crap," the spokesperson continued. "Since we got caught and called out, we'll make a show of locking stuff down for while. But that's inconvenient as hell, so once you lot move on to the next breach we'll be back to business as usual."
Biting the hand that feeds IT © 1998–2020