Black Hat Microsoft 365 guest accounts aren't nearly as secure as Redmond would lead customers to believe, as low-code security expert Michael Bargury demonstrated at Black Hat.

Guest accounts are commonly used by Microsoft shops to give non-employees access to their 365 tenancy with limited permissions, usually just access to a Teams channel and Sharepoint. There are a few other things that guest accounts can get into to, however, and it's Power Apps, Microsoft's low-code platform, where problems can bubble. 

Guest accounts, by default, don't have Power Apps licenses assigned to them, but there's an easy way around this, Bargury said during the Black Hat talk, "All You Need is Guest": Power Apps trial licenses. 

Armed with a compromised or obtained guest account and a Power Apps trial license (available free to anyone who wants one from the Power Apps website), all an attacker needs to do is log in to Power Apps and switch directories to the target tenant they're a guest user on, and voila: they can see a list of all the Power Apps connections their account has access to, and can even create applications inside the tenant. With enough work, the attacker can potentially make off with gobs of internal data.

"But wait," you may be thinking at this point, "that shouldn't matter if a company is practicing good access management." That would be true, but it's here that Bargury's experience as co-founder and CTO of Zenity, a low-code/no-code security and governance platform, comes into play: he says many companies aren't. 

While Microsoft shares some responsibility for allowing Power Apps trial users to gain access to - and create - apps in guest tenancies without appropriate controls, "business users are building things in Power Apps and not properly restricting access," Bargury said. 

Bargury added that many organizations embed credentials into Power Apps to make them easier for various employees to use, and argued many business users who create apps don't understand the implications of simply sharing them across a whole organization - which includes guest accounts - instead of being granular in granting access. 

"It's important to note that all of this is made possible by user mistakes," Bargury told us. 

If you have Power Apps in your infrastructure, double check what guests can access.

From trial license to data breach

All of what Bargury demonstrated in the first bit of his talk was relatively straightforward: the attacker gets access to a guest account on the target Microsoft 365 tenant, snags a Power Apps trial license, and hopes that the Power Apps users in their target tenant have provided access to some juicy internal apps. 

It's here that Microsoft's default data loss prevention policies (DLP) come into play: they block connectors in existing apps from being accessed by 365 trial accounts. As mentioned above, however, guest accounts on a trial license can create their own Power Apps, and with some clever API manipulation can essentially side-step DLP policies, we're told, to go right to the source: the connectors themselves, which are all too willing to dump any and all data contained in the databases they're linked to.

During his talk, Bargury demonstrated the use of a tool he built called Powerpwn that was able to gain access to, and dump data from, all sorts of Azure and SQL databases used by Power Apps, including a test database that contained customer information like social security numbers. 

Permission: Impossible - or at least less likely, please

Bargury told us Microsoft has been a strong and willing collaborator in addressing the weaknesses he discovered, and that the Azure titan is working on a patch for the Power Apps DLP bypasses that he discovered, in addition to working to prevent guest accounts from creating Power Apps apps as well.

As for Power Apps users, it's time to start cutting down on those doling out organization-wide access to internal apps, regardless of what Microsoft fixes or doesn't. It also might not be a bad idea to start requiring users to sign in to individual Power Apps, or at least not embedding shared credentials into apps the entire company can use. 

Along with his talk, Bargury provided sample code, additional details, and code to help companies determine if such vulnerabilities exist in their own environments. ®

https://www.theregister.com//2023/08/10/microsoft_365_guest_accounts_power/