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.
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.
It is my understanding that this happened and that no bad patches were actually merged.
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.
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.
If it were an obvious phishing URL, like a variation on the company domain, then fine (maybe). But it wasn't.
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.
You're talking about vulnerabilities in components, or other software, here. The user, by himself, is doing nothing wrong.
Why don't you just restrict employees to the intranet, then? Why do you give them free roam on the whole internet, but then you tell them "don't click the wrong link!".
Phishing happens when the user does something which is actively wrong. When the user opens an Word/Excel with VBA from an untrusted source and bypasses security restrictions. If they execute/install something unsigned and untrusted from some random site.
Click = fail is just wrong. Links are how the internet works. You aren't teaching anything.
How do you do this without a browser vulnerability (and assuming it's not also XSS/CSRF like the previous point)?
Also to distinguish between #3 and, XSS in #2 was intended to mean "persistent stored XSS" as opposed to "reflected XSS". In the case of reflected XSS, this can be chained with CSP bypasses and insecure cookies to grab out e.g. bearer tokens.
My overall point is that heap fung shui 0day not required for 1-click ownage. In practice, I've not had to burn browser 0day to compromise organizations or their customers.
1. It sounds like they'd have to be pretty well targeted against the precise systems of that particular company in order to work. Which would tend to suggest more targeted spear-phishing attacks and extensive recon being done against the company systems somehow before anybody launched a real black-hat attack.
2. At that point, it feels hard to blame the individual employee versus whoever misconfigured those corporate services in the first place. Though I would guess it's fairly common for those kind of things to happen due to many systems being set up without the help of true experts and the unlikeliness of a real attack against them without either a highly-skilled black hat targeting them or securing the services of a skilled and prices pen test team.
2. I agree. Individual employees are not at all to blame. Companies who are blaming their employees for getting phished are doing it wrong. The correct action to take is to inform employees and build the other kinds of mitigations mentioned elsewhere in this topic tree.
To test if employees are easy to pish, or was it for real (black hat)?
I'm usually not testing only whether employees are easy to phish (the answer is pretty much 100% yes). I'm testing end-to-end: can you as a company prevent me from phishing through email protections? Can you detect when I'm phishing your employees? Will your employees report potential phishing emails? Can you figure out (without me telling you) which employees were targeted and which attacks were successful? Can you figure out which credentials/machines would need to be quarantined/rotated/examined?
Even more fun if you were allowed to social engineer your way into the office and steal someone's powered on not-screenlocked laptop :-)
It's particularly annoying where I work, as the company itself sends out a completely unreasonable amount of internal spam every.single.day - often with bad spelling/grammar, and very often with the contents being a single image with rendered text (why?!?!).
Yes, clicking on links is dangerous[0].
0. https://www.bleepingcomputer.com/news/security/google-fixes-...
How can I tell whether I can click on a link? Sometimes there's even something like linkprotector.outlook.com/[very_long_url] in corporate emails.
My usual approach if I'm unsure whether a link is malicious would be to open it in a private window (and probably in a different browser from the one I usually employ), or if I really think it's phishy, I would open it from within throwaway VM.
So, the blanket "click and fail" policy seems pointless to me. If I enter some login/PII, then I can agree I've failed the test. But a click on a link cannot be considered failure.
They weren't, though - their own paper explicitly says they used newly created Gmail addresses for the patches...
"We submit the three patches using a random Gmail account to the Linux community and seek their feedback—whether the patches look good to them."
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.