If you own an electric guitar, at some point you had it setup – if you know what a setup is and why is needed in the first place thatis. A setup can be done at the factory or store (think of sane defaults), you can have a luthier set it up (acquisition of external knowledge on a project basis) or you can learn to set it up yourself (acquiring in-house knowledge, which be repeated over and over again as needed). Depending on your circumstances, each of these approaches has pros and cons – as in no silver bullet solution exists. All of the above assume that you do know what you need a guitar setup – the difference between a well setup instrument and an impoperly setup one is massive. When the local independent music scene was of my backwater city was kicking off, we used to trade equipment between bands the whole time. “”Hey! I need a set of .09s! “I have a set of .11s” “Sure, give them to me and oh, we hit the stage in 15 minutes” was a more than common occurence. Setups and intonation be damned, at least we had the attitude and everyone had a nice run, before actually learning that they do need a guitar setup.
I have blogged in the past about the cloud’s inherent shared responsibility model – effectively you get the tools you need, you use them as you see fit. It can be argued that, especially for young, scrappy companies, the necessary know how is not there and that these tools can be cumbersome and unyieldy (something to be expected in toolkits aimed to cover a ton of uses cases, with a focus on the more complex side of the scale) – so even if you do know of their existence, you might not be able to properly configure them – even if sane defaults are there. I need to share something temporarily with the Data team? Sure, let me make a globally R/W S3 bucket with them, I will delete it once they are done. Then, the bucket becomes a part of a workflow, and either workflow stays as-as or you forget that the workflow is using an insecure S3 configuration and, a few time units later, once you put something of value there, you realize you have a breach.
“Hey, is this not similar to the good-ole chmod 777 of your time?” I hear some folks screaming? Indeed it is, however there is a major difference. The chmod 777 file of yesteryear was contained in one system or at worst, one cluster. A cluster could have had a number o users, each and everyone of them a potential abuser of this insecure configuration but, even for the biggest, meanest cluster your can imagine, the number of users DWARFS the number of users on a low-tier Cloud Provider which in turn is DWARFED by the number of users of the 800-pound gorillas of cloud computing. To top this off, in certain cases, you do not even have to be a user to exploit this – just having access to the internet is enough to detect said holes and exploit them. So, from the looks of it, it turns out not only this is close to 777, actually it is closer to 4777 – for those rusty on numerical permissions, you can do whatever you want with the file (read, write, execute) and the file is setup to impersonate a different user (way more often than not, root).
The toolkit to detect and exploit such misconfigurations exists for a long time. Threat actor can and will act upon them, in a much shorter timeframe than you anticipate, so skipping security altogether (the 4777 above in full effect) will lead to a ton of tears and fallout, that would make you wish you had taken the time to choose security defaults – provided they exist.
Please, do not get me started on pigs.
Athanasios Kostopoulos 
wow!! 1Phrack #71 is out!
LikeLike