Obscurities with MS Teams part 2

Some features of MS Teams are only validated in the frontend and not in the backend, allowing us to tamper with some messages and functions, by directly interacting with the endpoints. Everything combined might increase the plausibility for social engineering attacks.

tl;dr

MS Teams does not verify most of the messages. This allows to do the following.

  • Sent files cross-tenant (via SharePoint)
  • Manipulate messages by replacing the message text at a later point
  • Manipulate quotes
  • Spoof URLs
  • Spoof filenames and file extensions
  • Spoof URL previews

Introduction

Shortly after releasing the blogpost about Skype / Teams, I got a DM from @malacupa stating, that there might be a way to send files crosstenant via teams. So we are going to have a look at that and also at some other strange things in MS Teams.

Some of the points mentioned here got already handled at the mr.d0x blogs here:

https://mrd0x.com/twitter-recap-part-1/
https://mrd0x.com/phishing-o365-spoofed-cloud-attachments/
https://mrd0x.com/microsoft-teams-abuse/

A few days ago, jumpsec published a blogpost about the IDOR filesend vulnerability in Teams. However, as the blogpost was already a while in draft (4 months, lession learned :) ), I am releasing anyway. \

Update 2023-06-23: After releasing, I got a hint to this blogpost. Cool stuff:

https://posts.inthecyber.com/leveraging-microsoft-teams-for-initial-access-42beb07f12c4

Sent files crosstenant (via SharePoint)

If we interact with a contact in another tenant, the Teams frontend does only show a limited function set. Amongst others “Sent a file” is not there, however we can simply send files even cross tenant.

Background: File sharing in Teams is made via SharePoint, meaning the file is hosted on a SharePoint and only a link is shared with the recipient.

So how can we send files crosstenant? We could upload the file to OneDrive, so basically SharePoint and share it from there by sending the link, or we just use the Teams functionality.

If we look at the crosstenant GUI we will see the limited functionality. Missing the file send functions

We can send a file to a user in the same tenant. Sending a file in the same tenant

If we look at that request, we see that there is a UUID in the URL for the conversation id.

Locating the conversation UUID

By simply sending the same request to another conversation UUID the file will be transmitted even crosstenant. And as a comfort feature, you do not need to care about the clientmessageid, timestamps, etc. They are all getting ignored, just the POST request send to the new URI.

Receiving the file on the victim side

NOTE the missing file sending icon, as it is crosstenant

Simple.

Exfiltration

As file sending is also working in the other direction, it is possible to exfiltrate files via TEAMs / SharePoint. Simple and easy. If you are BlueTeam, are you monitoring for this…

Spoof filenames and file extensions

Additional to the crosstenant file share, we can tamper with the filenames and spoof the extensions. Teams believe in itself, so it shows the correct icon for the file and the name. As SharePoint filesharing links do not contain the filename, it is not possible to see what file might get opened.

Edit the link in the share request. Change the filename, type, etc. Edited request for the fileshare

On victim side, there is no possibility to see the real filename / extension directly. URL preview on victim side

Woah, the bill.pdf is a pptx instead, maybe with some juicy macros.

Opened file on victim side

However, most of the files are opened in the browser or on a special “ready to download” page. Of course, there are some exceptions :) .

Macros might be back

From time to time, you will see companies which have rules for trusted locations in their office instances like *.SharePoint.com. So this might enable VBA Macros in documents, even if signed is enforced, as the combination is an OR.

MS proved flowchart for macro execution policies

https://learn.microsoft.com/en-gb/DeployOffice/security/internet-macros-blocked

Even by using a AAD Developer Tenant, the file sharing is via https://<<TENANT>>-my.SharePoint.com/<<...SNIPPED...>>.

Another interesting approach might be simply signing an office document with a self-signed or leaked certificate.
https://outflank.nl/blog/2023/04/25/so-you-think-you-can-block-macros/

Manipulate messages by replacing the message text at a later point

If we resend a message with the same messageid, we can change the text of this message. Teams will update the existing message on all sides without notification. One caveat is, that it will order the messages by an internal timestamp, meaning that a edited message might be at another position in the flow.

This could be used to generate some chaos or used to later hide links, etc.

Sending a phishing crosstenant, view from victim side

We can now send a new message text with the same clientmessageid via the POST method, which is important, as the EDIT function in Teams will use a PUT method. Sending a new message with the same clientmessageid

The Chatlog gets updated, the URL is gone and our edited message is now at the end. There is no refresh of the page needed, it will update immediately. Updated view from the victim side

With this some interesting options came up, like a Newsticker, or ASCII cinema. (the RickRoll was borrowed from here)

Manipulate quotes

If we intercept a quotation, we can change the text of it. There is no validation, meaning we can simply change the meaning and everything still looks legit and also the normal functions like highlighting are working.

Intercepted quotation request

In the request we just change the quotation text itemprop and do whatever we want to show up.

Updated view from the victim side

Note that clicking on the quote will even show the correct text in a red frame, as the link is made via an id and not the text.

Spoof URLs

If we intercept a message with a link, we can change shown part and the link.

Intercepted and tampered request

View from the victim side

Conclusion

It is still strange to me, that the security features, which were implemented for email appliances over decades are just ignored for messengers.

Actual the best advice is to change the default setting for external collaboration to a allowlist approach and block unknown senders.

Links

Work and inspiration from others: