If I was a hacker, I would just get a job as a night cleaning person at corporate office buildings. And then just help myself to the fucking post-it notes with usernames and passwords on them.
Social engineering is probably 95% of modern attack vectors. And that’s not even unexpected, some highly regarded computer scientists and security researchers concluded this more than a decade ago.
I work in security and I kinda doubt this. There are plenty of issues just like what is outlined here that would be much easier to exploit than social engineering. Social engineering costs a lot more than GET /secrets.json.
There is good reason to be concerned about both, but 95% sounds way off and makes it sound like companies should allocate significantly more time to defend against social engineering, when they should first try to ensure social engineering is the easiest way to exploit their system. I can tell you from about a decade of experience that it typically isn’t.
It’s way easier to convince someone that you are just a lost user who needs access than it is to try to probe an organization’s IT security from the outside.
This is only going to get worse with the ability to replicate other’s voices and images. People already consistently fall for text message and email social engineering. Now someone just needs to build a model off a CSO doing interviews for a few hours and then call their phone explaining there has been a breach. Sure, 80% of good tech professionals won’t fall for it, but the other 20% that just got hired out of their league and are fearing for their jobs will immediately do what they are told, especially if the breach is elaborate enough to convince them it’s an internal security thing.
Yes social engineering can be incredibly effective. I completely agree, but there is a bit of an obsession with it these days and imo it’s over indexed, because at the end of the day the type of social engineering detailed in that report typically just provides access.
In some cases, the target is important enough and has enough organizational power that accessing the network as them is sufficient, but that’s not often the case. What that means is that in those other cases social engineering (which in that report you cited is often just phishing) is providing, typically, internal network access. An attacker will have to move through the network and exploit software typically to continue their attack. There are many points in this chain that the weakness lies in software or configuration. If effort was placed on making those systems better it would likely see better results than hyper focusing on the social engineering, which is significantly more difficult to stop, especially with all of the things you mentioned on the horizon.
My point is then that even if it is a part of 74% of breaches, according to Verizon, it’s not necessarily sufficient and is often paired with software level exploits.
And I know this because my company does plenty of red teaming, and we use social engineering but at the end of the day the more interesting result comes from a software exploit or just abusing a weak configuration.
You are right and what some people miss is that social engineering being the vector to gain foothold doesn’t mean that it was sufficient to allow the breach. Almost always you need some other weakness (or a series of them). Except when the weaknesses are so had that you don’t need a foothold at all (like this case), or when the social engineering gives you everything (rare, but you might convince you someone to give you access to data etc.).
A whole separate conversation is deserved by how effective (or not) social engineering training is. Quite a few good papers about the topic came out in the last fee years.
I think that’s less about “hacking” and more about modern day devs being overworked by their hot-shit team lead and clueless PMs and creating “temporary” solutions that become permanent in the long run.
This bucket was probably something they set up early in the dev cycle so they could iterate components without needing to implement an auth system first and then got rushed into releasing before it could be fixed. That’s almost always how this stuff happens; whether it’s a core element or a rushed DR test.
And then there is meningspunktet.dk which had all the time in the world to do whatever they wanted, and even get their hosting paid for by a university. They still leaked everyones email, phone, full legal name and location on day one and only fixed it because I pointed it out.
Many years ago, I discovered that my then-employer’s “home built” e-commerce system had all user and admin passwords displayed in plaintext at home/admin/passwords.
When I brought this to the attention of leadership, they called the “developer” in and he said “oh, well, that’s IP locked, so no one on the web can access it!” When I pulled it up on my phone, he insisted my phone was on the work WiFi, despite it being clearly verifiable that was not the case. (The same work WiFi that had an open public connection, which is the one my phone would have been on, if it were on it…)
He did fix that, but many other issues remained. Eventually a new COO hired someone competent as his ‘backup’, replaced our website and finally suggested he pursue other employment opportunities before he could no longer voluntarily pursue them. (There was concern he might sabotage.)
Believe it or not a lot of hacking is more like this than you think.
Security by obscurity.
If I was a hacker, I would just get a job as a night cleaning person at corporate office buildings. And then just help myself to the fucking post-it notes with usernames and passwords on them.
https://youtu.be/jgYYOUC10aM
Social engineering is probably 95% of modern attack vectors. And that’s not even unexpected, some highly regarded computer scientists and security researchers concluded this more than a decade ago.
When the technical side reaches a certain level of security, the humans become the weakest link.
*if
We reached that part a long time ago.
Clearly the authors of this app did not. Hence “if.”
This has been the case for 40+ years. Humans are almost always the weakest link.
we built this shit. thus we are always to blame.
I work in security and I kinda doubt this. There are plenty of issues just like what is outlined here that would be much easier to exploit than social engineering. Social engineering costs a lot more than
GET /secrets.json.There is good reason to be concerned about both, but 95% sounds way off and makes it sound like companies should allocate significantly more time to defend against social engineering, when they should first try to ensure social engineering is the easiest way to exploit their system. I can tell you from about a decade of experience that it typically isn’t.
https://www.infosecinstitute.com/resources/security-awareness/human-error-responsible-data-breaches/
You’re right. It’s 74%.
https://www.cybersecuritydive.com/news/clorox-380-million-suit-cognizant-cyberattack/753837/
It’s way easier to convince someone that you are just a lost user who needs access than it is to try to probe an organization’s IT security from the outside.
This is only going to get worse with the ability to replicate other’s voices and images. People already consistently fall for text message and email social engineering. Now someone just needs to build a model off a CSO doing interviews for a few hours and then call their phone explaining there has been a breach. Sure, 80% of good tech professionals won’t fall for it, but the other 20% that just got hired out of their league and are fearing for their jobs will immediately do what they are told, especially if the breach is elaborate enough to convince them it’s an internal security thing.
Yes social engineering can be incredibly effective. I completely agree, but there is a bit of an obsession with it these days and imo it’s over indexed, because at the end of the day the type of social engineering detailed in that report typically just provides access.
In some cases, the target is important enough and has enough organizational power that accessing the network as them is sufficient, but that’s not often the case. What that means is that in those other cases social engineering (which in that report you cited is often just phishing) is providing, typically, internal network access. An attacker will have to move through the network and exploit software typically to continue their attack. There are many points in this chain that the weakness lies in software or configuration. If effort was placed on making those systems better it would likely see better results than hyper focusing on the social engineering, which is significantly more difficult to stop, especially with all of the things you mentioned on the horizon.
My point is then that even if it is a part of 74% of breaches, according to Verizon, it’s not necessarily sufficient and is often paired with software level exploits.
And I know this because my company does plenty of red teaming, and we use social engineering but at the end of the day the more interesting result comes from a software exploit or just abusing a weak configuration.
You are right and what some people miss is that social engineering being the vector to gain foothold doesn’t mean that it was sufficient to allow the breach. Almost always you need some other weakness (or a series of them). Except when the weaknesses are so had that you don’t need a foothold at all (like this case), or when the social engineering gives you everything (rare, but you might convince you someone to give you access to data etc.).
A whole separate conversation is deserved by how effective (or not) social engineering training is. Quite a few good papers about the topic came out in the last fee years.
The percentage is closer to 75% than 95%.
I think that’s less about “hacking” and more about modern day devs being overworked by their hot-shit team lead and clueless PMs and creating “temporary” solutions that become permanent in the long run.
This bucket was probably something they set up early in the dev cycle so they could iterate components without needing to implement an auth system first and then got rushed into releasing before it could be fixed. That’s almost always how this stuff happens; whether it’s a core element or a rushed DR test.
And then there is meningspunktet.dk which had all the time in the world to do whatever they wanted, and even get their hosting paid for by a university. They still leaked everyones email, phone, full legal name and location on day one and only fixed it because I pointed it out.
https://drkt.eu/files/ramblings/meningspunktet-dk.html
Thanks for the writeup - I can’t believe they claimed anything about keeping data safe while building the website so poorly…
Shodan lists 100’000s of publicly accessible security cameras.
Many years ago, I discovered that my then-employer’s “home built” e-commerce system had all user and admin passwords displayed in plaintext at home/admin/passwords.
When I brought this to the attention of leadership, they called the “developer” in and he said “oh, well, that’s IP locked, so no one on the web can access it!” When I pulled it up on my phone, he insisted my phone was on the work WiFi, despite it being clearly verifiable that was not the case. (The same work WiFi that had an open public connection, which is the one my phone would have been on, if it were on it…)
He did fix that, but many other issues remained. Eventually a new COO hired someone competent as his ‘backup’, replaced our website and finally suggested he pursue other employment opportunities before he could no longer voluntarily pursue them. (There was concern he might sabotage.)