5 ms·
There is a major error made by the research group. It starts and ends here: "we did that because we knew we could not ask the maintainers of Linux for permissio
by createdapril24 5y ago
There is a major error made by the research group. It starts and ends here: "we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches."
I am a Red Teamer and work with companies to understand how their detective/preventative/recovery controls and processes are working. Here's how you resolve this:
You work with maintainers to get their coordination on the research. You work out a mechanism to prevent submitted patches from being merged (e.g. maintainers are notified before bad patches accepted by code review processes are merged).
You do not tell them when the patches are coming. You do not tell them which identities are going to be used for the patches (e.g. from which email addresses). You do not tell them which area of code will be targeted. You set rules and time bounds for the study.
You wait some amount of time before submitting such patches (weeks to months). Realistically this is all that's needed. If hypersensitive, set this up earlier and let it bake longer.
At this point, you submit patches from a variety of addresses (probably not associated with your university - it is easy to create many such identities). You also can coordinate with other researchers, universities, and companies to submit patches under identities as needed. You also study submitting from yandex, gmail, .cn and other email addresses (because isn't that interesting to know?).
The premise that there's some ultimatum between working with the community and performing the research is on its face incorrect. This is either ignorance or laziness on behalf of the researchers. Clearly, they hadn't taken the time to work with the community to work out an approach that could be mutually acceptable.
- drewzero1 5y agoThis is how it should've been done. Like a war game (at least,as depicted in movies like Periscope Down), the organizers of the study and the project maintainers need to agree on (and be aware of!) bounds of the study, without necessarily knowing all of the details.
- ComodoHacker 5y ago>I am a Red Teamer and work with companies OK, how do you test SocEng vectors? Do you obtain consent and coordinate with every employee that might be targeted to receive your e-mail? >You also study submitting from yandex, gmail, .cn and other email addresses No, the point was submitting from a known and respectable entity, which might affect the level of scrutiny. They weren't testing a whole patching process, but a specific human component of it.
- soarfourmore 5y agoYou don’t. You work with the leadership & security team. Any employee that clicks your phishing email gets an extra dose of security training. Those that forward the email to abuse@corp.com get a nice compliment
- alanfranz 5y agoJust clicking the link is enough to fail? No need to enter private info or execute downloaded files? Either your phising emails are badly crafted or you expect employees to see the future.
- llimos 5y agoAgreed. This is something that made me very annoyed when they did it to us. I know exactly what I'm doing, I know that you can't infect a computer from opening a link unless the attacker possesses a new browser 0-day, and expecting your average employee to worry about new browser 0-days is ridiculous. If it were an obvious phishing URL, like a variation on the company domain, then fine (maybe). But it wasn't.
- D2187645 5y agoSame domain cant garunteed to be safe.
- createdapril24 5y agoI've run such phishing campaigns where the link: 1. (Windows specific) Opens up a Windows file share, which causes the person to authenticate to the file share, which through PtH/Responder results in their enterprise credentials being stolen. 2. Exploited a XSS or CSRF attack on an internal/management endpoint. Which in turns allows a pivot from external to internal access. 3. Steals a web session, cached password or authentication token, resulting in compromise of employee credentials to be used elsewhere (e.g. reused to access enterprise VPN). These are just some not-a-browser-0day examples of a single click being game-over dangerous.
- varajelle 5y ago> You work out a mechanism to prevent submitted patches from being merged (e.g. maintainers are notified before bad patches accepted by code review processes are merged). It is my understanding that this happened and that no bad patches were actually merged.
- schwede 5y agoExcept there was no consent from maintainers here.
- pcl 5y agoI agree with the approach you’ve outlined. I also empathize with the plight of the researchers — Linux is a bit different than normal Red Team engagements, in that a normal organization has a hunch of administrative / management layers who typically do not participate in the operations of the system being tested. A VP of engineering at a medium to large company is unlikely to be committing code, much less maintaining the build pipeline etc. This is not the case with Linux. The people “at the top” are also reviewers, and so it’s pretty likely that notifying them will result in a change of behavior. I wonder if there is some way to build some sort of Red Team consent “blind trust” organization, such that willing open source projects could agree to responsible attacks, and the attackers could register their work (including disclosure / mitigation plans) with the blind trust ahead of time.
- neatze 5y agoWhy do you think there will be any change in behavior ? It is not like community members are not for look out for bad commits on every new commit from most committers any way, since at least 2003, I think substantially earlier.
- deleted 5y ago[deleted]
- specialist 5y agoGreat plan. Agree with all. Thanks. In your experience, do you create a "fail safe"? So for this study, some way for the researchers to prevent any of their patches from ever being released.