Ridiculous vulnerability disclosure process with CrowdStrike Falcon Sensor
modzero.com
modzero.com
Personally, I would've released the PoC back in July when they said the problem was resolved. No need to ask if the quote can be used, it's exactly what they told the security researchers after all.
It created a lot of friction but I kind of understand the policy.
Effectively paying people (and heaping ego gratification on top of that) to be silent about found vulnerabilities.
1. You tested someone else's servers, and not software running on your own computer, and you didn't get permission or adhere to the rules of engagement the target established. Now you're not a researcher, you're an intruder, subject to CFAA. There's a bright line in US law between your computer and someone else's computer.
2. You tested software running on your own computer, but you acquired that software by agreeing to a contract prohibiting research, reverse engineering, or disclosure (ie: any NDA). Now you've violated a contract, and can be sued civilly for doing so. This comes up a fair bit when testing stuff on behalf of big enterprises, where all the software acquisitions come with big, enforceable contracts. I've had to cave a bunch of times on disclosures because of this; most memorably, I got locked in a vendor's suite at Black Hat an hour before my talk redacting things, because that vendor had a binding contract with my consulting client.
3. You were wrong about the vulnerability, or it could plausibly be argued that you were wrong, and you made a big stink about it. You're still a researcher, but you've also possibly defamed the target, which is a tort that you can be sued for.
4. You disclosed a vulnerability that you'd previously leaked, or provided exploit tooling regarding, to a criminal enterprise. Now you're not a researcher, you're an accomplice to the criminal enterprise. This has come up with people writing exploits for carding rings --- they weren't (or couldn't be proved to be) carders themselves, but they explicitly and knowingly enabled the carding.
As you can see, disclosing vulnerabilities isn't the least scary thing you can do with speech in the US, but it's not that much more scary than, say, leaving a nasty Yelp review for a dentist's office (something that also gets people sued). Just (a) don't test servers and (b) don't give secret bugs to organized criminals.
The thing that seems a little iffy for me with crowdstrike is that it’s an agent that calls back to services. It seems plausible that I could unintentionally break something in their environment while testing their software.
I like how you wrapped it up though and totally agree.
Dropping a zero day on the public is never acceptable, regardless of how disingenuous a device manufacturer is being. 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 ("As the issue was not considered valid, we informed CrowdStrike that we would release the advisory to the public.")
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 us releasing our findings to the public, right?"
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 understanding the mindset of the people here who want to see this as a two party adversarial kind of relationship between Modzero and CrowdStrike. It's not!)
Modzero was even following a more conservative playbook here: not setting a deadline from the start, but only talking about release once the vendor indicated there was no issue (anymore).
Telling people that the product they rely on has vulnerabilities is clearly not the same thing as "release the vulnerability report" though, is it? I still remain amazed at the absolutism in the arguments here. There is a spectrum of responses that can be explored before dropping bombs. But everyone wants to see stuff burn?
Without the necessary details telling the public about a vulnerability is like shouting at a wall. Publishing the details forces vendors to release fixes when they deny the existence of the vulnerability.
This isn't some hidden password or evil DoS attack, this is an attack only processes with admin access can leverage on infected machines. This command is either executed by a computer user (which should flag a warning in the management software) or it's executed by a virus with admin permissions that went undetected by the antivirus solution on the machine. The stakes are low enough and the vendor is irresponsible enough that I don't see a problem with publishing a PoC when vendors lie about these kinds of bugs.
Of course remote exploitation and auth bypass PoCs shouldn't be released into the wild without trying to get a patch out first, but even still vendors like D-Link just don't seem to care if you don't at least threaten them with releasing the details to the public.
If one publicly discloses some mitigation it's usually enough to give malicious actors enough to go on anyway.
If vendor denies there is a problem despite repeated submissions of evidence then customers are already at risk indefinitely.
They were already at risk and didn't even know before disclosure. If anyone's to blame for anything, it's the corporation. They were told a vulnerability existed. If it got to the point people are releasing things to the public, it's certainly because they neglected to do what needed to be done.
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?
Under those circumstances? Yes. How else would I learn that my systems are vulnerable?
Always assume a bad guy has the 0-day before a security researcher.
Nothing starts your week better than "After the latest definitions update, Falcon heuristic started quarantining your core business tools as suspicious".
For some reason java.exe startup was A-OK though so I started using JEdit again.
Aggravatingly, it would occasionally disappear my builds and then flag me to IT. My dude, I am hired as a developer of native windows C++ applications why the hell is this trash on my would-be workstation-class machine?
That's what it feels like with some of these policies.
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.
Questions i would ask in your example: 1) Was the core business tool excluded from the more intrusive protection modules or does the tool have a significant risk surface? 2) What was the threshold set for quarantining? Does it make sense in this case? 3) Is/should your device be part of a "Developer" policy that is more permissive? Are all users of the tool impacted? 4) Does this happen frequently? If so, should definitions be manually pushed in batches so everyone is not nerfed at once. 5) What is the process for the developer to report/fix the false positive? Is the response time sufficient?
I'm probably forgetting a few. The point is, shit happens (especially with technology). You respond, fix, and hopefully learn. If shit happens a lot, its either because the tool owner doesn't give a shit or the product is shit itself. The delicate balance of security and business operations/innovation is all about weighing and evaluating risk/benefit.
The examples shown were behavior based, not hash based. It didn't look up a file in a dictionary, it detected priviledge elevations and such.
No product is perfect, but if you have a need to be protected (especially if you are at risk from adversaries such as in banking, health care, government work, or against corporate espionage) I'm quite confident in saying that you're much better off with it than without.
The same company would also, at random times, attempt to phish us or send us fake emails to get us to click on links, to help educate us on the kinds of threats our customers faced I consider myself fairly savvy, and even I fell for one of them.
I ended up leaving for a variety of reasons, but "losing faith in the product" was not one of them.
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.
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?
CrowdStrike has done loads to damage their own credibility to anyone paying attention, but because they've chosen to be favorable to certain power players along political lines there are folks out there that treat them like the be-all-end-all of the industry.
As someone in-industry, hearing people parrot press releases from CrowdStrike has me looking at them sideways.
Edit/Addendum: Just to lay bare my opinion of them... CrowdStrike is a clown-ass company run by clown-ass people and with a clown-ass product.
In practice, most implementations cause more harm than good. Some of them even add vulnerabilities themselves.
- 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
As someone who was once part of an endpoint security team, I wouldn't be so quick to judge.
If CrowdStrike operates like any anti-virus software company, there are multiple teams. There would be a small engine team, a team that deals with Windows integration, then there would be a much much bigger malware analyst team(s), then another team that deals with 'active machine learning' (CrowdStrike's bread and butter). Then some senior managers oversee them all.
It's possible that the engine team and the analyst team have a case of 'left hand doesn't know what the right hand is doing.' They both got the report, and they behave differently as the engine team has a different goal from the analyst's team.
From the analyst team's point of view, their job is to detect all potentially malicious threat, sources be damned. While the engine team takes their sweet time, the analyst team just figures "hey this binary attacks our software. We don't know if the engine team would have fix the bug then, or if the bug is even real. We should blacklist it just-in-case or else when the binary in the public, some joker with an auto scanner will use this binary to show they got around our detection. Then our team would get blame for it. Better be safe than sorry."
Yes we all know detecting binary PoC are close to useless, but if you don't do it, then you'd get a flood of (useless) reports later...
Do no harm and cover your ass. No one is going to complain a false positive on a custom PoC binary....right?
Everything else, yeah those are pretty shitty.
From the blog post- >The PoC that has been sent to CrowdStrike was flagged as malicious. The msiexec call of the deinstaller was also flagged as malicious.
Everything else I have no opinion I wish to share. There are many posters in this thread that would satisfy your desire to engage on the other issues.
I've heard there are workarounds to disable or remove CrowdStrike, but I was too concerned that the IT overlords would come after me at my previous employer.
But I do understand why those are in place:
1. There are lots of those who have no idea what they are doing in the organization. And/or
2. Some high up who have no idea what they are doing want to show their value. Such move typically happens after someone with Chief Security Officer or similar get hired. Or they do know but simply don't care.
This is just about the main thing that bugs me with this kind of tool: sure you can blame the vendor, but the data is still stolen.
And companies are happy to have checked that box and won't bother implementing actually useful policies.
I wanted to install netcat to troubleshoot networking issues between windows and docker containers I was running.
Right when it was downloaded from scoop, it got deleted and I got a scary automated email.
My manager called me immediately, in the end it was cleared quickly but I did learn to be very carefull about what I try to download.
At first I didn't understand why netcat was being detected by the AV but then I remembered it can be used to set up a reverse shell.
On CrowdStrike's end, it's much more likely that their systems changed a few heuristics so now it flags certain msiexecs as malicious. Most anti-virus type software are highly nondeterministic in the way they operate, with tiny changes in detection engines able to cause large changes in the way some threats are detected.
Even modzero themselves admitted that the vulnerability is not of great severity so the motivation for the security triage team to put more resources in validating a non-severe bug are probably very low. They likely just tried to run the exploit, and didn't think much of it after it didn't work.
Also if modzero is not participating in a bug bounty program then CrowdStrike has no obligation in providing them with free trials or such in verifying a vulnerability fix.
I'm no fan of CrowdStrike (in fact, one of the more memorable moments for me at my previous job was my boss calling them "ClownStrike"), but it seems as if this is just a bit of overzealous entitlement from modzero as well as not enough testing on CrowdStrike's end.
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 sure they'll work it out if this gets noticed.
My first direct experience with CrowdStrike was the announcement of VENOM back in 2015 [1], which they coordinated with a few friendlies like FireEye but left most of us in the dark about (I was at Palo Alto Networks, not exactly a small company). Looks like they still struggle with this stuff.
1. https://web.archive.org/web/20150514062749/https://venom.cro..., possibly the origin of named and marketed vulnerabilities.
Well, Crowdstrike is supposed to catch and prevent that...
Heartbleed is older (2014).
I mean, that half is the carrot to get vendors to play ball and actually fix their shitty code occasionally. It lets unaffiliated white hat security researchers who are just trying to get sec issues fixed actually get some focus time from the various sauron-esque eyes that are corporate attention by converting a 'bug report' into an 'impending pr nightmare bomb with a known timer'. It's a similar hack to complaining on twitter to deal with a marketing department instead of calling in to a customer service line that's just trying to get you to go away.
> It has pissed researchers off for decades, as it implies that not following the "responsible" process makes one per se "irresponsible".
The point of calling it responsible is to defend the researchers who have massively less power in the relationship against the vendors. Even now you'll see whitehats lambasted for eventually disclosing after a vendor dragged their ass. Beyond that, yeah you can't please everyone.
Lots of people with better reputations than Bright have publicly lobbied against disclosure of any sort. Bruce Schneier is a great example of this; if you're an old industry head, Marcus Ranum is another name here. The point isn't that everybody agrees with me about "Responsible Disclosure"; it's that everybody who matters does.
And project zero puts an emphasis on disclosure, not coordination. When the ticker runs out they nearly always disclose, regardless of where coordination is at. That's what Peter Bright was ultimately complaining about; they disclosed like a week before one of the relevant patch tuesdays.
Like I've said, the primary point isn't the coordination. That's the carrot to get the vendors to play game on a sane schedule because otherwise the vendor holds all the cards.
The point of calling it "responsible" has nothing to do with defending researchers; it's literally the opposite. The norms of "responsible" disclosure were absolutely not the norms of vulnerability reearchers of the time. The term was invented back in the early aughts by @stake, then the largest software security consultancy in the world (my company, Matasano, was essentially a spin-off of @stake; one of my cofounders was an @stake cofounder).
This is one of those things, like "Zero Trust Networking", where people read the term, (reasonably) believe they understand what the words mean, and then axiomatically derive the concept. But, no, the concept has its own history and its own meaning; the words have little to do with it (except that here, it's especially obvious what's problematic about the words themselves).
The industry has largely moved away from "Responsible" disclosure to "Coordinated" disclosure, for all the reasons I've given here. Even CERT, the most conservative organization in software security, uses the new term now.
Later edit
This originally read The norms of "responsible" disclosure were absolutely not the norms of "Responsible Disclosure", which was a typo.
Yes, CERT has moved using CVD, but I argue that's because of their conservationism. They don't want to rock the boat and tend towards vendor friendly, neutral language. That makes sense for their niche.
And just throwing it out there that the older term that's actively being erased because its implications are unfriendly to entrenched interests isn't the "Orwellian" one.
Here's the 2002 I-D that Weld worked on with Steve Christey standardizing the term. It's notable for being roughly contemporaneous with @stake firing Dan Geer over, as I recall, somehow alienating Microsoft, one of @stake's larger clients.
https://cve.mitre.org/data/board/archives/2002-02/msg00026.h...
Your link, for what it's worth, doesn't use the term at all. But even if it had, it wouldn't change anything.
Just to keep this on track: your claim was that "Coordinated Disclosure" --- the near-universal standard term for what used to be called "Responsible Disclosure" --- is an "Orwellian re-imagining". Leaving aside the fact that there's nothing intrinsically "Orwellian" about renaming something, the fact remains: "Responsible Disclosure" was researcher-hostile and patronizing, and has been chucked out the window by almost everybody who matters in vulnerability research.
We've managed to hash out a hot topic from, like, 2012 on this thread, which is great, it's progress, we move forward bit by bit here on HN, just like Joel Spolsky once said; "fire and motion". But we can probably be done now.
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 company policy" more than any literal technical restriction.
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.
This is trivial.
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).
If you don't want people to modify the machine - don't give them admin access.
If you give them admin access... don't assume they won't modify the machine.
For comparison - I worked software security for 5 years dealing with fortune 100 banks. I have zero faith in the industry. It's mostly a shell game for liability.
I can absolutely do the things I mentioned above. At best, it's a discussion of how hard I'll have to work. So again... this is basically a "hey - you're about to violate company policy" notice.
One could perhaps call this a "communication problem", but I'd like to think most people would call it lying
This is very speculative. There's no reason to bend over backwards to imagine a way in which "ClownStrike" (your boss gets it!) didn't flag a specific PoC without fixing the underlying issue. If CS insists on such opacity, the best assumption is actually the opposite.
How's that not about liability?
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 also need to be very clear that the moment a company, or it's authorized representative, flags something as a wontfix or "not a security issue", full and immediate disclosure is fair game.
- 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 way to upload your own JavaScript)
- "I can do things if I open a console in a browser" (can't do anything because CORS policy only allowed for read-only endpoints)
- "You can make requests with CURL and not official client"
Every week, there was at least one variation of one of those reports. "Hackers" also got very defensive about their "findings" and acted like we don't want to pay them for some "mega hack of the year 0day total domination of user device" vulnerabilities.
Not once has anyone found even a minor vulnerability, just wannabes trying to get quick cash. Until we had H1 we had zero reports, with H1 we had moronic reports every other day.
- "An attacker could spoof an email from you to a user." (POC video shows Yahoo webmail succeeding. We try the same thing in Gmail, and it gets sent to the spam folder because it fails SPF and DKIM.)
- "If I try logging in as a user with an invalid email too many times, it locks them out of their account. That's a denial of service." (Well, yeah, and that's a bummer, but it beats allowing an attacker unlimited attempts.)
I'll say, though, that H1 has been super helpful at screening the worse reports. Sometimes they'll initially block reports like the above, but the researcher will insist that this time it's for real. I don't feel too bad closing those reports as invalid.
In all, I'm a very happy H1 customer. They've been good to work with.
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.
Would you even consider signing an NDA if I sent you one? I surely hope not.
what with non-disclosure being literally the opposite of disclosure & everything
that is precisely the choice made by the team in the article, because the NDA was bad, for the reasons you described
so it sounds like everyone is OK with this, the authoring team is just describing that issue, along with other issues, with the bug disclosure process (like lying about there being no vulnerability while simultaneously fixing it)
Just say no to NDAs.
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 you're reasonably secure. If you have 0 layers of security and thus 0 holes in them, you might arguably say you have 0 vulnerabilities, but you would be less secure than the 5 vulnerability system. In the early days of computing you would log in with your username only, no password. Their threat model didn't consider intentional attacks, thus there were no vulnerabilities, but anyone could use anyone else's account.
>Uninstall protection prevents unauthorized users from uninstalling the Falcon Agent
>The “Maintenance Manager” role is available which grants permission to access the maintenance tokens. This role must be enabled against the Falcon user’s account in order to obtain maintenance tokens or manage policy related to Uninstall Protection.
Putting those 2 sentences together seems to lead to the conclusion that if someone doesn't have the "Maintenance Manager" role, that person will be prevented from uninstalling the Falcon Agent. It's unclear to me if all admin users are considered to have the Maintenance Manager role.
https://www.crowdstrike.com/blog/tech-center/uninstall-prote...
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.
Funny, I find it interesting that they want to pay a bugbounty even though nobody asked for it. But I guess paying hush money is just cheaper than having to seriously fix the issue.
They did fix the issue, though.
And if these guys were to go though the NDA route, The company may choose just not to fix it at all, and tell these researchers to be quiet about it. And you'd never know there was such a exploit ever.
They objected to having to sign an NDA, when there was no clear incentive to legally bind themselves in that manner.
NDA? HackerOne? Personal Information with Identity and Credit History Verification, Cookies and Disclosure Agreements, and 3rd party terms? Why is it at all "interesting" that a security researcher is not interested in giving all of up in order to tell CrowdStrike that their core product is broken in a way that is completely inimical to its mission purpose?
"Can you notify my lawyer by FAX, please? And can you get the document notarized first? Kthxbai".
What planet did they get their MBA from?
https://thegrayzone.com/2021/10/30/crowdstrike-one-of-russia...
https://thegrayzone.com/2020/05/11/bombshell-crowdstrike-adm...
To elaborate further: "Leaked emails reveal British journalist Paul Mason plotting with an intel contractor to destroy The Grayzone through “relentless deplatforming” and a “full nuclear legal” attack. The scheme is part of a wider planned assault on the UK left."
https://thegrayzone.com/2022/06/07/paul-masons-covert-intell...
edit: cleared by MI5 just like every other BBC journalist in Britain, but moreso, seeing as he was the economics editor for BBC Newsnight, then for Channel 4 News.
https://www.cambridgeclarion.org/press_cuttings/mi5.bbc.staf...
https://www.cambridgeclarion.org/press_cuttings/mi5.bbc.page...
https://www.bbc.com/news/stories-43754737
edit: to be clear, when I say he's a spy, I mean that he is being paid by British intelligence to report on the operations of left wing organizations, sabotage them, push them into doing extreme and unpopular things which also hopefully constitute grounds for arresting targeted individuals, and to say obnoxious things that piss normies off as a representative of "the left" in mainstream media.
edit: allegedly.