Microsoft 365 Tenants Should Control Teams External Access
In September 2022, I reported on how a proof of concept attack called GIFshell had exploited a weakness in the Teams external access mechanism. At the time, I recommended that organizations blunt any such attacks by restricting external access to specific known domains. When Microsoft introduced federated chat in 2019, they choose to make open access the default, meaning that users in any Microsoft 365 tenant supporting Teams could contact users in any other tenant.
I understand why Microsoft wants to encourage free and easy cross-tenant collaboration, but being totally open is a tad too far. I think organizations should restrict access to a set of known tenants where a proven need exists to allow federated chat (Figure 1). You can maintain the list in the Teams admin center or using PowerShell. In this article, I explain how to use PowerShell to find the set of domains for guest accounts known to the tenant and add those domains to the allowed list.
New Weakness Exposed
In their article, security researchers JumpSec Labs discuss how they exploit Teams external access to introduce malware into a federated chat. My reading of the situation is that the exploit depends on two weaknesses:
- The Teams client reads security settings from the server and applies them without further checks. This weakness was first reported in October 2020 and still appears to be active. Essentially, the client asks the server for the set of policy controls applicable to the signed in user. When the server responds, an attacker can intercept the conversation and remove some of the restrictions that Teams wants the client to apply.
- With some security controls removed, a federated chat from an attacker to a target victim can post files containing malware. Normally, federated chats don’t allow participants to post files (Figure 2) because it’s an obvious way for someone outside the tenant to upload files to the recipient’s OneDrive for Business account. By interfering with the set of policy controls transmitted by the server to the client, the attacker is able to send a file, just like participants in an internal Teams chat can.
As the JumpSec researchers point out, being able to inject malware into a Teams chat negates all the warnings that organizations have hammered into user ears to not open attachments from unknown email senders or to click on links in messages. Everything smells much safer in the context of a Teams chat, especially with a rich lashing of social engineering applied on top to make the recipient happy and content to communicate with the attacker.
Simple Solution
The researchers reported the problem to Microsoft, who deemed that that it “did not meet the bar for immediate servicing.” That’s interesting because Microsoft said the same thing about the GIFShel proof of concept.
However, the salient fact is that a simple fix exists. Don’t open your tenant up for federated chat from all and sundry. Establish and maintain a list of acceptable domains based on business necessity. Why anyone would buy into the simplistic and overly optimistic view of the world that leads to tenants opening themselves up for federated chat from any other tenant is beyond me. It’s like painting a large target on Teams users to invite attackers to engage in some social engineering to compromise accounts and potentially the Microsoft 365 tenant.
We live in a dangerous world. Don’t make it easier for attackers to function by leaving doors open. That just doesn’t make sense.
Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.
One Reply to “Security Researchers Demonstrate Exploit Against Teams External Access”