-- MARKDOWN --
- [1 - Server-Side Request Forgery](#1-ssrf)
- [2 - URL preview spoofing](#2-spoofing)
- [3 - IP address leak](#3-ip-address-leak-android)
- [4 - Message of Death (DoS)](#4-denial-of-service-aka-message-of-death-android)
In Teams, this preview is actually generated server-side by Microsoft (which is possible due to the lack of E2E encryption), so the feature cannot be abused to leak information from the user's local network (e.g. the Node.js debug server). However, while investigating this feature, I stumbled upon a few unrelated vulnerabilities in its implementation.
# 1 SSRF
**Description:** While we can't leak information from the user's local network, we could theoretically leak information from Microsoft's local network. Getting slightly distracted from my original goal, I tested the `/urlp/v1/url/info` endpoint for Server-Side Request Forgery and was quite surprised to see that this obvious attack vector has not been protected against.
**Impact:** The URL is not filtered, leading to a limited SSRF (response time, code, size and open graph data leaked), which can be used for internal portscanning and sending HTTP-based exploits to the discovered web services.
Having a slightly closer look at the link preview, I identified 3 more vulnerabilities:
# 2 Spoofing
**Description:** The preview link target can be set to any location independent of the main link, preview image and description, the displayed hostname or onhover text.
**Impact:** When clicking the preview, a different link is opened than what was expected by the user. This can be used either for improved phishing attacks, or to hide malicious links.
- Earlier this year, we discovered a [critical vulnerability in WinSCP](https://positive.security/blog/url-open-rce#bonus-vulnerability-winscp) (CVE-2021-3331, fixed in v5.17.10), which can be triggered with the allowed `ftps://` URI scheme. Since there is no `ftps://` default handler in Windows, it's a bit surprising that this scheme is explicitly allowed in Teams and it might be a good idea for its developers to remove it from the internal `allowedHrefProtocols`-list for further hardening
- The displayed hostname is updated to the current link target when Teams is restarted or the channel reloaded. During a live conversation, the hostname can be spoofed by editing an already sent link to point to a different (spoofed) target
- The displayed hostname's TLD is truncated in the desktop/web client, providing additional spoofing possibilities
# 3 IP Address Leak (Android)
**Description:** When creating a link preview, the backend fetches the referenced preview thumbnail and makes it available from a Microsoft domain. This ensures that the IP address and user agent data is not leaked when the receiving client loads the thumbnail. However, by intercepting the sending of the message, it's possible to point the thumbnail URL to a non-Microsoft domain. The Android client does not check the domain/does not have a CSP restricting the allowed domains and loads the thumbnail image from any domain.
**Impact:** Allows leaking an user's IP address and user agent data by sending a message with a specially crafted link preview (for Teams users on Android).
**Note:** This issue seems patched now. See the [disclosure section](#disclosure) below.
# 4 Denial of Service aka Message of Death (Android)
**Description:** When receiving a message that includes a link preview with an invalid preview link target (e.g. "boom" instead of "https://..."), the Android app crashes. The app keeps crashing when trying to open the chat/channel with the malicious message, which makes the chat/channel unusable for Android users.
**Impact:** Allows DoS'ing users and channels with a single message (for Teams users on Android).
All four issues have been reported to Microsoft on March 10, 2021 via the MSRC program.
Only the Android IP address leak has seemingly been patched.
`2021-03-10`: We report the issues to Microsoft
`2021-03-12` - `2021-03-25`: Back-and-forth on details of the spoofing issue
`2021-03-25`: MS closes the DoS ticket without a patch:
Thank you again for submitting this issue to Microsoft. We determined that this issue does not require immediate security service and we assessed this as low severity for temporary DoS that requires restart of application. A fix for this issue will be considered in a future version of this product or service. At this time, we will not be providing ongoing updates of the status of the fix for this issue, and we have closed this case.
`2021-03-25`: MS closes the SSRF ticket without a patch:
Microsoft has decided that it will not be fixing this vulnerability in the current version and we are closing this case. At this time, you are able to blog about/discuss this case and/or present your findings publicly about the current version.
`2021-04-04`: MS closes the IP address leak ticket without a patch:
MSRC has investigated this issue and concluded that this does not pose an immediate threat that requires urgent attention due to the general data sensitivity of the IP address data. We have shared the report with the team responsible for maintaining the product or service. They will review for a potential fix and take appropriate action as needed to help keep customers protected.
`2021-04-14`: MS closes the URL preview spoofing ticket without a patch:
MSRC has investigated this issue and concluded that this does not pose an immediate threat that requires urgent attention because once the user clicks on the URL, they would have to go to that malicious URL which would be a giveaway that it's not the one the user was expecting.
`2021-12-15`: We retest all issues; only the IP address leak seems patched
`2021-12-22`: We are publishing this blog post
While the discovered vulnerabilities have a limited impact, it's surprising both that such simple attack vectors have seemingly not been tested for before, and that Microsoft does not have the willingness or resources to protect their users from them.