Every so often, it seems that Microsoft Security Response Center (MSRC) likes to stick their proverbial foot in their mouth on the topic of vulnerability disclosure. The root issue is that collectively, MSRC does not seem to appreciate either their own history or the bigger picture. As such they have a myopic view on the topic. The latest comes in the form of a new blog titled “A shared responsibility: Protecting customers through Coordinated Vulnerability Disclosure“. The irony in all this is that one word in the title of the blog is where their spiral begins; shared. Let me break down their recent blog with historical context and challenge MSRC on being consistent, and more importantly, fair.
We must begin with two simple truths though. First, vulnerabilities in software are fundamentally the fault of the developers who wrote the software. Second, security researchers have no obligation to spend their time doing pro bono work for a software vendor. It’s literally that simple and direct and there is no arguing these immutable facts which means it isn’t a “shared responsibility” because researchers are not responsible for a vendor’s code mistakes or their customers. Software vendors can strongly desire and encourage the latter but that is the best they can hope for.
Next, let me break down Microsoft’s latest blog and note that bolding is my emphasis. Their blog is flawed even when taken at face value. MSRC likely wrote this entirely based on specific recent events, but as is common, they don’t consider what they said in the bigger context. At the end I will bring in more detail about the recent events that basically remove any remaining cogency. From the MSRC blog:
In recent weeks several zero-day vulnerabilities have been publicly disclosed. The details of these vulnerabilities were not shared with Microsoft prior to release, and the disclosures put our customers at unnecessary risk.
For those not keeping up with news, a security researcher using the alias Nightmare-Eclipse has recently disclosed almost half a dozen local privilege escalation vulnerabilities in Microsoft products, along with functional exploit code, without coordinating with the vendor. Of those, at least three are known to be exploited in the wild. Based on Microsoft’s blog and response they are not happy.
Every year, we work with hundreds of security researchers through Coordinated Vulnerability Disclosure (CVD) – the industry standard that asks researchers to share their findings with affected vendors to give them an opportunity to understand the impact and address it before the details are made public.
CVD is not a “standard” at all, and Microsoft can’t even keep it straight as far as that term goes as you can see shortly. CVD is one of two choices researchers are allowed to make, the other being uncoordinated.
Through this valuable partnership we also ensure researchers are compensated for their responsible disclosures and publicly acknowledged for their expertise.
The vulnerabilities known as RedSun, UnDefend, BlueHammer, YellowKey, GreenPlasma, and MiniPlasma were not responsibly disclosed.
It only took four paragraphs for Microsoft to let their true colors fly, again. They went from “coordinated vulnerability disclosure” which is fair and equitable to both sides to the very loaded term “responsible” that magically has implications that only the researcher can be irresponsible. That is not the case at all. Microsoft’s blog also says that researchers are ‘compensated’ which implies they are all paid if coordinating. That is not true either. Just four paragraphs in and this blog is using manipulative language peppered with bits that are demonstrably false.
We remain firmly opposed to these actions, and any disclosure outside proper coordination that could harm our customers and the digital ecosystem.
Yet, MSRC and many other companies are firmly opposed to those very actions when they decide not to patch a vulnerability at all, instead calling it “working as intended” in various terms. Even in this specific case Microsoft talks about coordination and not wanting to harm customers. Yet of the five vulnerabilities directly attributed to this researcher, four of them still do not have a CVE ID assigned. That is despite Microsoft being a CVE Numbering Authority (CNA) that has an obligation to assign and to then notify MITRE of the assignments, so the information can enter the CVE ecosystem. That is how organizations around the world typically get notified of vulnerabilities and can begin the triage process.
The researcher did not coordinate with Microsoft which is their choice and Microsoft did not coordinate with their customers which is their choice. Yet guess which one they are demonizing? Really this should not be a surprise since with VulnDB I can see over 1,000 vulnerabilities in Microsoft products that don’t have a CVE ID.
Uncoordinated disclosures that put proof-of-concept code for unpatched vulnerabilities into the hands of bad actors are never justifiable and have real-world consequences.
This line is honestly kind of fascinating as it has elements of many logical fallacies baked in including a strawman argument, false-cause, appeal to emotion, slippery slope, and black-or-white. On the surface MSRC’s remark is generally accurate enough but there are plenty of times where a vulnerability is disclosed without any technical details, without exploit code, and is still ultimately exploited in the wild. Take CVE-2024-43456 for example. This Microsoft vulnerability discovery is attributed to Ray Reskusich, Josh Watson, and Philemon Orphee Favrod of Microsoft, was obviously coordinated with the vendor, was not disclosed with exploit code, and yet was still found to be exploited in the wild just nine days later. So yes Microsoft’s statement is correct but even following CVD entirely internally can also result in external exploitation as well.
Our security teams across the company work tirelessly tracking threat actors who look for weaknesses just like these to attack Microsoft and our customers.
Yet, no mention of their security teams auditing Microsoft code to help figure out these vulnerabilities and fix them before external researchers find them.
We invite diverse perspectives that help the security community work together to protect everyone.
This line fully encapsulates the change in narrative from Microsoft since October, 2001. At the time it was Scott Culp who branded uncoordinated disclosure as “information anarchy” on the back of several computer worms that had been actively exploiting vulnerabilities in Microsoft products. Once again, it is important to note that flaws in Microsoft’s products were the root cause issue. As I noted 25 years ago, it was a scare tactic then and it has turned into a gentle plea along with a “woe is us” message now. While that change in narrative is a positive change, Microsoft still refuses to take any form of accountability.
We know the vulnerabilities in their code are the fault of Microsoft. But the other lack of accountability comes in the form of how MSRC alienates some researchers. Depending on the month or year you contact MSRC you may have very different results. In the past there were times where staff were quick to respond, professional, and highly knowledgeable. Other times it was worse than pulling teeth to get the most basic of information from them. I have personally experienced this level of frustration and spent a fair amount of time clarifying disclosures. One great example of this also highlights how Microsoft is quick to blame security researchers, but not so quick to call out the U.S. government for the exact same thing.
In August, 2016, a threat actor dubbed The Shadow Brokers leaked what was claimed to be a toolset from the threat actor ‘Equation Group‘ reportedly part of the U.S. National Security Agency (NSA) that included a substantial number of exploits and malware. Since the exploits were not well documented there was considerable effort and confusion from the security industry in trying to figure out if they were already known or new vulnerabilities. By August, 2017, a full year later, there was still confusion over the vulnerabilities and associated CVE ID assignments. I had begun reaching out to MSRC to try to figure it out around that time.
It took another 14 months to fully resolve the confusion and formal communication MSRC was painful. Ultimately I had to go through backchannels to find someone at Microsoft that would take it seriously and provide concrete information. So again I have to call out and question MSRC in their claims about working “tirelessly tracking threat actors who look for weaknesses just like these to attack Microsoft and our customers.” The only thing tired through that ordeal was me constantly being frustrated that MSRC did not take it seriously or act with urgency.
We realize that we will not always agree on everything, but we are committed to transparency and continue to create opportunities for dialogue.
Sure, begin by publishing your advisories for all vulnerabilities with a CVSS score 5 or lower. We’ll wait! I mean, that was easy. I didn’t have to dig into mails for several other cases where MSRC refused to be transparent about vulnerabilities already disclosed even. To be fair, MSRC is transparent at times, just not consistently enough to make the statement above. If you weren’t aware, Microsoft does not publish advisories for vulnerabilities with lower CVSS scores or “low to medium” severity. That isn’t transparent and it certainly isn’t coordinating vulnerability information with customers.
These conversations happen at researcher appreciation events, security conferences, and the everyday work we do together to understand and address vulnerabilities.
I don’t recall much in the way of conversation from Scott Culp during the “Information Anarchy” phase of MSRC. I also wonder how much conversation happened before Chris Betz of MSRC whined about “responsible” disclosure which was more propaganda than anything else. At the time MSRC said it was an “honor” to be mentioned in one of their advisories which makes me think that is how they “compensate” researchers, at least in their mind.
Our team will continue to support responsible research as we do everything we can to quickly investigate, address, and release updates for vulnerabilities that impact our customers.
There’s that word again… and apparently Microsoft forgets they “banished” the term no less.
We always have and will continue to welcome vulnerability submissions from anyone through our public researcher portal, regardless of past interactions or reputation.
While I don’t know the history and motivation of Nightmare-Eclipse, I can say that I have talked to or read disclosures from several researchers that felt alienated by MSRC. Cases where Microsoft disputed findings, disputed severity, and dragged their feet in providing patches have led to researchers being frustrated and opting not to coordinate. All on top of forgetting that researchers have no obligation to work with a vendor in the first place. So here we are with this new plea on the back of their insecure code manifesting real-world exploitation.
With all that said, let’s examine this specific researcher and their interactions with Microsoft. We only have a they-said / they-said view via blogs from each. However, Nightmare-Eclipse’s blog is clear that they feel alienated by MSRC. They say “when I actively asked you to communicate with me, you refused, humiliated me and made sure to insult me in front of people” and that Microsoft ‘defamed’ them and did not compensate them despite what the MSRC blog says. This all comes after Microsoft deleted Nightmare-Eclipse’s GitHub profile and repositories without giving a reason.
With that additional context it appears that the researcher did try to coordinate, had a bad experience, then released the vulnerabilities and exploit code. After that, Microsoft retaliates by deleting a second account of the researcher’s. Microsoft then tries to frame it as if they are the victim in all of this. I suspect we’ll see more vulnerabilities disclosed by the researcher, without any attempt at coordination. Microsoft is in the ‘find out’ phase of FAFO.