Microsoft Power Apps misconfiguration exposes data from 38 million records
The leaked data included personal information for COVID-19 contact tracing and vaccination appointments, social security numbers for job applicants, employee IDs, names and email addresses.
Image: Microsoft
A lack of proper security configuration with Microsoft’s Power Apps has led to the exposure of data from some 38 million records, according to security firm UpGuard. In a report published Monday, UpGuard said that the misconfiguration of the low-code development platform exposed such information as COVID-19 contact tracing, vaccination appointments, social security numbers for job applicants, employee IDs, and millions of names and email addresses.
Among the organizations whose data was exposed were government agencies in Indiana, Maryland and New York City, as well as private companies such as American Airlines, J.B. Hunt and even Microsoft itself.
SEE: Business leader as developer: The rise of no-code and low-code software (free PDF) (TechRepublic)
Microsoft Power Apps is a low-code development tool designed to help people with little programming experience build web and mobile apps for their organizations. As part of the process, Microsoft allows customers to set up Power Apps portals as public websites to give internal and external users secure access to the required data. And therein lies the crux of the security snafu.
To allow access to the data, Power Apps uses an OData (Open Data Protocol) API. The API retrieves data from Power Apps lists, which pull the data from tables in a database. However, access to the data tables had been set to public by default. To control who can retrieve the data, customers were supposed to actively configure and enable a Table Permissions setting. And apparently many failed to do that, thus allowing any anonymous user to freely access the data.
As Microsoft explains in a technical document about lists in Power Apps: “To secure a list, you must configure Table Permissions for the table for which records are being displayed and also set the Enable Table Permissions Boolean value on the list record to true.” The document also warns: “Use caution when enabling OData feeds without table permissions for sensitive information. OData feed is accessible anonymously and without authorization checks if Enable Table Permissions is disabled.”
Certainly, user misconfigurations and mistakes are a common cause of security issues. But as vendors push low-code and no-code development products for non-technical customers, the chances of errors rise. This is especially true as organizations increasingly turn to the cloud to set up applications and data access.
“The rush to the cloud has exposed many organizations’ inexperience with the various cloud platforms and risks from their default configurations,” said Cerberus Sentinel Solutions Architecture VP Chris Clements. “Developing in a public cloud can have efficiency and scaling advantages, but it also often removes the ‘safety net’ of development conducted inside internal networks protected by outside access by the perimeter firewall.”
SEE: An inside look at Microsoft’s Power Platform Process Advisor (TechRepublic)
Following its initial research starting on May 24, 2021, UpGuard said it submitted a vulnerability report to the Microsoft Security Resource Center a month later on June 24. The report contained the steps required to identify OData feeds that allowed anonymous access to list data and URLs for accounts that were exposing sensitive data.
In response, the case was closed by Microsoft on June 29, with an analyst for the company telling UpGuard that it had “determined that this behavior is considered to be by design.” Following further back and forth between UpGuard and Microsoft, some of the affected organizations were notified of the security issue. Ultimately, Microsoft made changes to Power Apps portals so that table permissions are now enabled by default. The company also launched a tool to help Power Apps customers check their permission settings.
A Microsoft spokesperson said only a small subset of customers configured the portal as described in UpGuard’s report and that Microsoft worked closely with those customers to make sure they were using the proper privacy settings. The spokesperson added that customers are notified about public feed availability when discovered so they can review and remediate if necessary. Further, Microsoft’s primary portal designer, Design Studio, uses strong privacy settings by default, according to the company, which said that it’s in the process of ensuring that alternative designer tools default to similar strong settings.
“While we understand (and agree with) Microsoft’s position that the issue here is not strictly a software vulnerability, it is a platform issue that requires code changes to the product, and thus should go in the same workstream as vulnerabilities,” UpGuard said in its report. “It is a better resolution to change the product in response to observed user behaviors than to label systemic loss of data confidentiality an end user misconfiguration, allowing the problem to persist and exposing end users to the cybersecurity risk of a data breach.”
Microsoft Weekly Newsletter
Be your company’s Microsoft insider by reading these Windows and Office tips, tricks, and cheat sheets. Delivered Mondays and Wednesdays