Live data from Hacker News

Open letter from researchers involved in the “hypocrite commit” debacle

lore.kernel.org

381–384 of 384 posts

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#381

Earlier quoted context omitted.

Just 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.

> Just clicking the link is enough to fail? Yes, clicking on links is dangerous[0]. 0. https://www.bleepingcomputer.com/news/security/google-fixes-...

So, we don't click on links anymore? Anywhere on the internet? Just about any site can deliver a malicious link.

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.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#382
post #279

Earlier quoted context omitted.

Agreed. 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.

I'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…

That exploit could happen ANYWHERE on the web. Any freaking link. Anything on a newspaper website, or social network.

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.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#383
post #360

Earlier quoted context omitted.

If anything they wasted time and energy of project maintainers. This alone should be enough to see the behavior is inexcusable.

Ya, they wasted a bit of their time. That wasn't very nice. But it's hardly the great crime it's being made out to be, and what they did was a huge public service. It's impossible to over-state the importance of linux kernel security.

You don't get to decide what you think is important and then burden others pushing it. If you think testing security in random attack way is important tell the people who run the project. They are the ones qualified to make the calls.

It's just a scammy move at best. To me it's borderline criminal to sabotage a project like that.

Post reply on HN