Ethical hackers at Orca Security have added their voices to a growing number of concerns in the community over how tech companies go about fixing responsibly disclosed vulnerabilities in a timely manner, after going public with a critical shell injection vulnerability leading to remote code execution (RCE) in Microsoft Azure Synapse – tracked as CVE-2022-29972 – that has taken the best part of six months to get on top of.
The Azure Synapse Analytics service imports and processes data from other sources, such as Azure Data Lake, Amazon S3 or CosmosDB, into instances or workspaces that connect out to the data source via an integration runtime, which can be hosted either on-premise or in the Azure Cloud.
CVE-2022-29972, dubbed SynLapse, affected Synapse Analytics in Azure and Azure Data Factory. If successfully exploited, it would have enabled attackers to bypass tenant separation and obtain credentials to other Azure Synapse accounts, control their Azure Synapse workspaces, execute code on targeted machines, and leak customer credentials.
What is more, said Orca researcher Tzah Pahima, an attacker would have been able to accomplish all this while knowing nothing more than the name of an Azure Synapse workspace.
Pahima and Orca have raised concerns because despite first approaching Microsoft on 4 January 2022, a fix has taken more than 100 days to materialise.
According to Orca’s timeline, the team waited over a month from disclosure to the Microsoft Security Research Centre (MSRC) until Microsoft requested additional details to aid its investigation on 19 February, and again on 4 March. It then took until the end of March to deploy an initial patch, which Orca claims it bypassed on 30 March.
On 4 April – 90 days after disclosure – it again notified Microsoft that the vulnerability still existed, and after a series of meetings between the two organisations, a replacement patch dropped on 7 April. The Orca team bypassed it three days later, on 10 April. On 15 April, a third patch was deployed, which fixed the RCE and reported attack vectors.
In a coordinated disclosure, Orca and MSRC went public with SynLapse on 9 May, as reported at the time, although held off from disclosing technical details to give users time to patch. It is important to note that there is no evidence the vulnerability was ever exploited in the wild.
But the story did not end there, and at the end of May, Microsoft deployed a more consistent fix for the problem and implemented a number of recommendations that Pahima made during the process – including implementing least privilege access to internal management servers, and moving the shared integration runtime to a sandboxed ephemeral virtual machine (VM), meaning that even if an attacker was able to run code on the integration runtime, the code could never be shared between different Azure tenants.
“In the light of this information, we now believe that Azure Synapse Analytics provides sufficient tenant isolation,” said Pahima. “As such, we have removed alerting on Synapse from within the Orca Cloud Security Platform. Microsoft continues to work on additional isolation and hardening.
“SynLapse, and previous critical cloud vulnerabilities such as Azure AutoWarp, AWS Superglue and AWS BreakingFormation, show that nothing is bulletproof and there are numerous ways attackers can reach your cloud environment. That is why it is important to have complete visibility into your cloud estate, including the most critical attack paths.”
Despite the fraught experience, Pahima said there were no hard feelings between the two, although clearly there are lessons to be learned.
“During this process, we worked with a number of different groups within Microsoft,” he said. “Microsoft was a great partner in working to resolve SynLapse and we appreciate their collaborative spirit, transparency, and dedication to helping make the cloud more secure for our joint customers.”
