Beware of risk severity miscalculations: the Microsoft Teams GIF attack scenario ?
During this period of confinement, the number of users of remote audio-visual collaboration tools has increased considerably.
Security researchers are well aware of this and have increased their efforts in researching security issues related to these products.
Microsoft Teams is no exception, with the article Beware of the GIF: Account Takeover Vulnerability in Microsoft Teams by CyberArk published on April 27 (https://www.cyberark.com/threat-research-blog/beware-of-the-gif-account-takeover-vulnerability-in-microsoft-teams/).
Notably, the researchers reported the following weaknesses to Microsoft on March 23:
- You can put the web address of a GIF image in a message and Teams will download it automatically.
- When Teams interacts with a host that ends with teams.microsoft.com, one of the user authentication tokens will be automatically transmitted.
Source : https://www.cyberark.com/threat-research-blog/beware-of-the-gif-account-takeover-vulnerability-in-microsoft-teams/
On their own, these weaknesses have no impact.
They are quite classic behaviors of this kind of application, but Microsoft has nevertheless decided to restrict the sending of tokens to teams.microsoft.com only from the following April 20th.
The problem that made it possible to build a complete attack scenario was indeed communicated the same day :
- aadsync-test.teams.microsoft.com and data-dev.teams.microsoft.com point to IP addresses that an attacker can easily spoof.
The researchers did not reveal the addresses, but they were most likely private or local addresses, such as 192.168.1.1 or 127.0.0.1.
This problem was solved the same day by Microsoft and concerns its infrastructure rather than the Teams application.
The researchers also explained that it was necessary to create a valid TLS certificate for these domains, and that this is easy to do… for public IP addresses.
On the other hand, they forgot to mention that this is certainly more complicated to do for private addresses, where one must first attack the company’s certificate delivery system or PKI from the internal network.
Even if the address was public, it would have to be spoofed first, which on the Internet proves to be a much more complicated task.
These incorrectly configured domain names could have been used to carry out other attacks, for example phishing attacks, but in any case and certainly to carry out the scenario described in the article it was much easier to set up in the laboratory than in a real case.
Considering the difficulty of implementing such an attack, we can only applaud the fact that Microsoft reacted and corrected the problem during the day, well aware that it is currently, perhaps more than usual, the target of attacks.