Microsoft fixes flaw after being called irresponsible by Tenable CEO – Source: www.bleepingcomputer.com

Microsoft fixed a security flaw in the Power Platform Custom Connectors feature that let unauthenticated attackers access cross-tenant applications and Azure customers’ sensitive data after being called “grossly irresponsible” by Tenable’s CEO.

The root cause of the issue stemmed from inadequate access control measures for Azure Function hosts launched by connectors within the Power Platform. These connectors use custom C# code integrated into a Microsoft-managed Azure Function featuring an HTTP trigger.

Although customer interaction with custom connectors usually happens via authenticated APIs, the API endpoints facilitated requests to the Azure Function without enforcing authentication.

This created an opportunity for attackers to exploit unsecured Azure Function hosts and intercept OAuth client IDs and secrets.

“It should be noted that this is not exclusively an issue of information disclosure, as being able to access and interact with the unsecured Function hosts, and trigger behavior defined by custom connector code, could have further impact,” says cybersecurity firm Tenable which discovered the flaw and reported it on March 30th.

“However, because of the nature of the service, the impact would vary for each individual connector, and would be difficult to quantify without exhaustive testing.”

“To give you an idea of how bad this is, our team very quickly discovered authentication secrets to a bank. They were so concerned about the seriousness and the ethics of the issue that we immediately notified Microsoft,” Tenable CEO Amit Yoran added.

Tenable also shared proof of concept exploit code and information on the steps required to find vulnerable connector hostnames and how to craft the POST requests to interact with the unsecured API endpoints.

While investigating Tenable’s report, the company initially found that the researcher was the only one who exploited the issue. After further analysis in July, Microsoft determined that there were some Azure Functions in a “soft delete” state that had not been properly mitigated.

Microsoft finally resolved the issue for all customers on August 2nd after an initial fix deployed by Redmond on June 7th was tagged by Tenable as incomplete.

“This issue has been fully addressed for all customers and no customer remediation action is required,” Microsoft said on Friday.

Redmond has since notified all impacted customers through the Microsoft 365 Admin Center starting August 4th.

Even though Microsoft says the information disclosure issue was addressed for all Azure customers, Tenable believes the fix applies only to newly deployed Power Apps and Power Automation custom connectors.

“Microsoft has fixed the issue for newly deployed connectors by requiring Azure Function keys to access the Function hosts and their HTTP trigger,” Tenable says.

“We would refer customers who require additional details regarding the nature of the deployed remediations to Microsoft for authoritative answers.”

Fix only came after public criticism

Microsoft addressed the flaw after a five-month period, but not before the CEO of Tenable voiced vehement criticism against the initial response. Yoran condemned Microsoft’s approach as “grossly irresponsible” and “blatantly negligent.”

To make matters even worse, Redmond’s initial commitment to fixing the issue in September deviated by a large margin from the expected 90-day deadline, typically adhered to by most vendors when it comes to patching security vulnerabilities.

This extended delay added to the concerns and raised additional questions about the timeliness of Microsoft’s response to security issues affecting its products.

“Did Microsoft quickly fix the issue that could effectively lead to the breach of multiple customers’ networks and services? Of course not. They took more than 90 days to implement a partial fix – and only for new applications loaded in the service,” Yoran said.

“That means that as of today, the bank I referenced above is still vulnerable, more than 120 days since we reported the issue, as are all of the other organizations that had launched the service prior to the fix.

“And, to the best of our knowledge, they still have no idea they are at risk and therefore can’t make an informed decision about compensating controls and other risk mitigating actions.”