This week, we check out the recent vulnerabilities in Microsoft Teams and Instagram, the
awesome-apisecurity repo in GitHub, and the upcoming DevSecCon24 conference.
Vulnerability: Microsoft Teams
Microsoft Power Apps and Power Automate services are meant to provide easy tools to add custom applications and flows to Teams. A small bug in Power Apps snowballed into a big issue, allowing attackers to create a Teams tab, steal the victim’s tokens through a rogue
iFrame, and then use that token to gain persistent read/write access to the victim’s email, Teams chats, OneDrive, Sharepoint, and a variety of other services.
Here’s a quick video on Grant’s proof of concept for gaining access to another user’s OneDrive file:
The Teams tabs were checking the location of iFrames and ensuring that those began with
https://make.powerapps.com. However, Grant could circumvent this by simply creating a subdomain that starts with that string but is hosted on his own domain, like
https://make.powerapps.com.fakecorp.ca/. This allowed him to get his custom code to run on a Teams tab and get access to the victim’s tokens.
He could then use the
https://apps.powerapps.com/auth/onbehalfof endpoint to silently exchange the tokens into tokens from other systems, such as:
- Dynamics apps subdomains
Grant then used these tokens to access private data. For example, he could use the service flow token to create a Power Automate flow to access the Outlook mails, Teams messages, and OneDrive and SharePoint files of another user. The whole process looked like this:
Grant’s write-up is fascinating (do read it for more details) and shows how trivial-looking things here and there can turn into a serious exploit opportunity. Luckily, Microsoft has since fixed the issue.
Lessons learned here:
- Perform strict data validation on any URLs, parameters, and payloads.
- Adhere to the zero trust approach. Every API must assume that other application components have been compromised instead of blindly trusting them.
- Ask for explicit user approvals on the first token use and token exchange.
Facebook continues to patch broken object-level authorization (BOLA, aka IDOR) in their GraphQL APIs. This time, they paid the $30,000 prize to Mayur Fartade for finding a bug that allowed a malicious user to view targeted media on Instagram.
Attackers could get access to details of private and archived Instagram posts, stories, Reels, or IGTV of other users if they knew the media ID of the resource.
Here are the steps that he followed:
- Obtain the media ID of the target post, Reel, IGTV, or story, either by brute-forcing or by other means.
- Send a
POSTrequest with the following parameters to the endpoint
[MEDIA_ID]is the media id of the post/reel/IGTV/story,
doc_idis redacted from the example.
- The API returns
save_count, and other details of the media, even if the resource is not supposed to be accessible or had already been archived.
Fartade also found another endpoint with similar behavior. Instagram has since fixed the issue.
- Authentication is not enough. Make sure that any resource access also enforces authorization checks to ensure that only users who are supposed to have access to the resource can access it.
GitHub has plenty of repositories that collect links to useful resources on a certain topic handily accessible in one place.
One such GitHub repository is awesome-apisec by André Rainho. This repository pulls together a collection of API security resources, such as tools, cheat sheets, checklists, labs, videos, and so on.
Worth checking out and bookmarking it for future reference.
DevSecCon24 is another industry event gone all online this year and thus available wherever you are.
There’s a lot of DevSecOps content at the event and at least one session specifically on API security, “It’s Time for API Security as Code!” by Isabelle Mauny on Thursday Jun 24, 10:35 AM – 11:15 AM GMT +1.
You can read the abstract and register for free here.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy