Live data from Hacker News

Ridiculous vulnerability disclosure process with CrowdStrike Falcon Sensor

modzero.com

151–160 of 167 posts

Re: Ridiculous vulnerability disclosure process with CrowdStrike Falcon Sensor

#151
post #96

Earlier quoted context omitted.

> Bug disclosure without a known remedy has to be an absolute last resort kind of thing, and it's actually a little upsetting that modzero used that tactic as a kind of threat I don't think it is upsetting at all. "We found a vulnerability" "There's no vulnerability" "No, you misunderstand, here's how it works and how to exploit" "Naah, no vulnerability" "Ok, if there's no vulnerability as you claim, you don't mind u…

The thing is, "releasing our findings to the public" puts the vendor's customers at risk, it's not just some imagined Just Punishment For The Guilty, innocents get hurt. Imagine if you took a new job and they had a bunch of hardware sitting around from such a vendor. Would you be OK if someone published an exploit for your systems? (In this case, the vulnerability seems minor, so it's sort of academic. But I'm not un…

I feel like you're arguing from an absolute.

Yes, we're all arguing in favor of responsible disclosure, but if the vendor is not communicating in good faith, what else can you do?

Re: Ridiculous vulnerability disclosure process with CrowdStrike Falcon Sensor

#152
post #133

Earlier quoted context omitted.

Seriously. I don't think the researcher realizes how many people try to bypass hackerone because H1 would have flagged their finding as invalid. Using h1 isn't about bug bounties, it's about not having to spend a 1-2 of your team's full time engineers triaging security researcher reports.

We had some of the dumbest H1 "findings" at some companies that I worked: - Service that is explicitly out of scope of program is "leaking" default CloudFront headers. - Android application can be decompiled (that's it, not secret is there, just the fact that it's possible) - "I can do something bad IF I had a way to load malicious JavaScript" (no, CSRF protection was one and correctly implemented) (there is also no…

My favorite was an e-mail titled "[Critical Urgent] Vulnerability Report 1 : Clickjacking On Login Lead to Account Takeover Of Any User/Cross Site Scripting Attacks/DOM Based Xss/Csrf Attacks/Deletion OF Account/User Account Privilege Escalation/Victim Privilege Escalation/Malware Execution/Victim PC Hijack/Unauthorized Access To Any User Account/Account Takeover Of All The Users Registered On Your Application"

The finding that we didn't include the "X-Frame-Options: DENY" header was correct, but the app simply doesn't work in an iframe anyways, so it wasn't exploitable.

It certainly wouldn't result in all the other things listed.

Re: Ridiculous vulnerability disclosure process with CrowdStrike Falcon Sensor

#153
post #96

Earlier quoted context omitted.

> Bug disclosure without a known remedy has to be an absolute last resort kind of thing, and it's actually a little upsetting that modzero used that tactic as a kind of threat I don't think it is upsetting at all. "We found a vulnerability" "There's no vulnerability" "No, you misunderstand, here's how it works and how to exploit" "Naah, no vulnerability" "Ok, if there's no vulnerability as you claim, you don't mind u…

The thing is, "releasing our findings to the public" puts the vendor's customers at risk, it's not just some imagined Just Punishment For The Guilty, innocents get hurt. Imagine if you took a new job and they had a bunch of hardware sitting around from such a vendor. Would you be OK if someone published an exploit for your systems? (In this case, the vulnerability seems minor, so it's sort of academic. But I'm not un…

> Would you be OK if someone published an exploit for your systems?

Under those circumstances? Yes. How else would I learn that my systems are vulnerable?

Re: Ridiculous vulnerability disclosure process with CrowdStrike Falcon Sensor

#154

I hate that the component the vulnerability was in even exists. As far as I'm concerned, if a program tries to keep a local administrator from uninstalling it, for any reason , it's malware.

Sorry, but I disagree. You have to look at the customer base crowdstrike is serving which can be wide and varied. There exist environments where the user "needs" admin privileges but should not be able to uninstall the sensor. Think corp where users code etc, but they dont have the admin staff to do some more complicated IT security. In that instance this is just what is needed. Also, privilege escalation exist and t…

Agreed. Windows just does not have the permission granularity necessary for non-standard usecases

Re: Ridiculous vulnerability disclosure process with CrowdStrike Falcon Sensor

#155
post #90
post #71

Earlier quoted context omitted.

Well in this case the vulnerability is the ability to uninstall the program when you're not supposed to be able to uninstall it. So yes, if the program didn't exist at all, there would be no way to uninstall it in an unauthorized manor. So the vulnerability wouldn't exist. You wouldn't necessarily be any more secure though. If you have 10 layers of security and 5 have holes in them, you have 5 vulnerabilities, but yo…

What is the vulnerability here? An admin user can do admin stuff. Shocking.

On Windows, there are things that even the Administrator user can't do, at least not directly.

One example I know off the top of my head because I know from experience is accessing Bluetooth encryption keys in the registry. Even if you launched Regedit as Administrator, you'll get ACCESS DENIED reading them. But if you use `psexec` to start Regedit as the SYSTEM user, you'll have access.

My guess is that CrowdStrike installs itself with permissions that prevent Administrator from uninstalling it.

Re: Ridiculous vulnerability disclosure process with CrowdStrike Falcon Sensor

#156
post #18

Earlier quoted context omitted.

10% of Falcon is blocking dumb shit people do. 90% is blocking things people are supposed to be doing, and have been doing successfully so far. Nothing starts your week better than "After the latest definitions update, Falcon heuristic started quarantining your core business tools as suspicious".

They fixed it with an update this month, but CrowdStrike was hooking /every/ single call to NtCreateUserProcess on my work machine last month, and you /know/ how electron-based apps work. VSCode took so long to launch its sub processes it would pop up a crash reporter. "Hello World" compiled from C++ would take a minute to launch sometimes. WSL straight up could not be started because the TTY timed out waiting for it…

> They fixed it with an update this month, but CrowdStrike was hooking /every/ single call to NtCreateUserProcess on my work machine last month, and you /know/ how electron-based apps work. VSCode took so long to launch its sub processes it would pop up a crash reporter. "Hello World" compiled from C++ would take a minute to launch sometimes. WSL straight up could not be started because the TTY timed out waiting for it.

There's nothing wrong in hooking ~EvErY~ call to NtCreateUserProcess or even a thousand other functions in and of itself. The issue is what they're doing inside those hooks.

We have installed another product that also hooks +@EvErY sInglE@+ call to NtCreateUserProcess and to couple dozen other functions and you know what? VSCode works just fine. WSL too. Edge and Chrome too.

Sure there's a measurable effect on performance but nothing like you're describing.

Re: Ridiculous vulnerability disclosure process with CrowdStrike Falcon Sensor

#157
post #10

Earlier quoted context omitted.

It’s the snake oil industry. They don’t sell security, they sell CISO get out of jail cards in the form of client agents that constantly remind you of their divine presence by being on top of the CPU utilization sorted process list.

I would agree for some of the old guard antivirus (looking at you McCrappy) but with the better ones you are also paying for a huge amount of analytics and reporting. If you are dealing with a breach (even a small one) it can be really really nice (and reassuring especially for people at higher levels) to have nice easy to consume data on what the chain of attack was and where it started.

Nothing you mentioned on the plus side is actually increasing security. It's really just compliance and potentially containment. Some things that could be done to increase security:

- penetration tests paired with employee security training incorporating those results

- updating every piece of software and IOT device as frequently as possible

- don't use products that execute macros when you open documents and train users to click the allow button

- have a functioning SSO system in place and don't rely on something being on the "internal network" as a security measure. Don't have credentials shared between employees, use SSO instead.

- universal usage of MFA and password managers

Re: Ridiculous vulnerability disclosure process with CrowdStrike Falcon Sensor

#158

Earlier quoted context omitted.

> Even modzero themselves admitted that the vulnerability is not of great severity They're wrong. It's not at all uncommon for companies to give employees admin, and privilege escalation tends to be easy on Windows anyway. > CrowdStrike has no obligation in providing them with free trials or such in verifying a vulnerability fix Sure, and modzero has no obligation to responsibly disclose, and now here we are. I'm sur…

I mean... as a user on the machine, if I have admin rights there's very, very little they can meaningfully do to stop me from removing their software. Hooking a token into their uninstaller is hardly sufficient... I have SO much surface area to attack that I don't genuinely think you can call this anything other than trivial. For an admin user, I'd take this token prompt more as a "Hey - you're about to violate compa…

> I can steal the network, change the registry, simply delete their binaries, update shared dlls, or any number of other easy hacks to get them offline.

That's a bold claim. Mostly incorrect, but bold. A proper Windows endpoint protection software's Registry filter will prevent you from modifying its Registry data; its filesystem minifilter will prevent you from modifying its files; its EXEs will use the Windows mitigation policy that loads only Microsoft-signed DLLs; its connection with its management server will be encrypted and signed with known keys/certifications (rather than trusting everything from the Windows Certificate Store), etc.

An admin can still bypass all of that with enough effort but it's not nearly as trivial as you say. What is trivial that you can't actually do the things you said and it's common knowledge (in the field).

Re: Ridiculous vulnerability disclosure process with CrowdStrike Falcon Sensor

#159
I’m so sick of dealing with these snake oil salesmen products. CrowdStrike, Trend Micro Deep Shit, McAfee, SentinelOne, BlackBerry Cylance, etc. They are all pushing their users to install proprietary kernel modules and low quality effort solutions. They market this crap as low on resource usage that just hums along.. if you want to introduce random performance issues and crashes, then I would recommend using one of these trash solutions.

Re: Ridiculous vulnerability disclosure process with CrowdStrike Falcon Sensor

#160

Earlier quoted context omitted.

Can I ask, since you're as a person who has administered endpoint protection products: how much legitimate stuff do they actually catch?

I work in offense and they can be a huge impediment. Significant work goes into bypassing or staying undetected from these products. While not all the detection occurs at runtime, they report a lot of data back from the endpoint so historical detection can happen. However what I see is essentially their true positive and false negative rate, I would be interested to know what the false positive rate is.

Yeah, I guess this all boils down to your threat model in the end. As your post seems to indicate, if a dedicated attacker targets you, they're probably going to be able to work around the endpoint protection anyways.

I'm more curious about the case if your org is a few thousand people and you receive random low-effort attacks distributed across those people, will endpoint protection be a panacea?

Post reply on HN