Security professionals critical of Microsoft claim that a lack of transparency and speed in response to reports of system vulnerabilities is putting customers at risk.
Ars Technica reports that Microsoft is facing increasing criticism from security professionals who claim that the company’s lack of transparency and adequate response time to online threats and vulnerabilities is placing customers at risk.
A recent blog post from Orca Security revealed that Microsoft took up to five months and three patches before managing to fix a critical vulnerability in its Azure product. Orca Security reportedly warned Microsoft of the flaw in early January. The bug resided in the Synapse Analytics component of the cloud service and gave anyone with an Azure account the ability to access the resources of other customers.
Orca Security researcher Tzah Pahima listed the sort of access an attacker could gain due to the bug:
- Gain authorization inside other customer accounts while acting as their Synapse workspace. We could have accessed even more resources inside a customer’s account depending on the configuration.
- Leak credentials customers stored in their Synapse workspace.
- Communicate with other customers’ integration runtimes. We could leverage this to run remote code (RCE) on any customer’s integration runtimes.
- Take control of the Azure batch pool managing all of the shared integration runtimes. We could run code on every instance.
However, despite this bug being both critical and time-sensitive, Microsoft was slow to understand the severity of the bug. The company reportedly botched the first two patches and failed to fix the bug until an update published on Tuesday. Pahima published a timeline of the process:
- January 4 – The Orca Security research team disclosed the vulnerability to the Microsoft Security Response Center (MSRC), along with keys and certificates we were able to extract.
- February 19 & March 4 – MSRC requested additional details to aid its investigation. Each time, we responded the next day.
- Late March – MSRC deployed the initial patch.
- March 30 – Orca was able to bypass the patch. Synapse remained vulnerable.
- March 31 – Azure awards us $60,000 for our discovery.
- April 4 (90 days after disclosure) – Orca Security notifies Microsoft that keys and certificates are still valid. Orca still had Synapse management server access.
- April 7 – Orca met with MSRC to clarify the implications of the vulnerability and the required steps to fix it in its entirety.
- April 10 – MSRC patches the bypass, and finally revokes the Synapse management server certificate. Orca was able to bypass the patch yet again. Synapse remained vulnerable.
- April 15 – MSRC deploys the 3rd patch, fixing the RCE and reported attack vectors.
- May 9 – Both Orca Security and MSRC publish blogs outlining the vulnerability, mitigations, and recommendations for customers.
- End of May – Microsoft deploys more comprehensive tenant isolation including ephemeral instances and scoped tokens for the shared Azure Integration Runtimes.
A similar story was told by the security firm Tenable which claimed that Microsoft failed to fix a separate vulnerability also related to Azure Synapse. Tenable Chairman and CEO Amit Yoran complained of a “lack of transparency in cybersecurity” from Microsoft in a post titled Microsoft’s Vulnerability Practices Put Customers At Risk.
Yoran wrote:
Both of these vulnerabilities were exploitable by anyone using the Azure Synapse service. After evaluating the situation, Microsoft decided to silently patch one of the problems, downplaying the risk. It was only after being told that we were going to go public, that their story changed… 89 days after the initial vulnerability notification…when they privately acknowledged the severity of the security issue. To date, Microsoft customers have not been notified.
Read more at Ars Technica here.
Lucas Nolan is a reporter for Breitbart News covering issues of free speech and online censorship. Follow him on Twitter @LucasNolan or contact via secure email at the address lucasnolan@protonmail.com