Exchange Server and Office 365: Access to attachments and images possible without authentication

Under certain circumstances, Microsoft Office 365 and Exchange Server allow access to attachments and images in emails without the need for authentication. In most cases it should be difficult to exploit this problem, but the reader L. Herzog writes to me that this problem could be exploited in his environment. L. Herzog described the problem to me and I was able to reproduce it with Office 365 and Exchange Server 2019 (latest updates). The problem was reported to Microsoft at the beginning of January, but it was not classified as critical or important. There is therefore currently no fix.

What is the problem?

The web version of Outlook (outlook.office.com) and OWA of an Exchange server generate a link for images in an email, which can be accessed without prior authentication. If you know the link, you can access images and attachments in an email. However, the links are only valid for approx. 10 minutes and can hardly be guessed, which is why Microsoft has probably classified the problem as a cosmetic defect rather than a security vulnerability. However, there are scenarios in which unauthorized access to images or attachments is possible. Here is an example so that the problem can be understood.

I have sent myself an email with an image and opened it in the web version of Outlook, opening the Chrome developer tools. The domain "attachments.office.net" now appears under the Source code tab in the developer tools. This is the download domain which should also be configured for Exchange Server. The links to the images in the email can now be found under the domain attachments.office.com:

The link can now be copied and accessed on other computers without prior authentication. Here is an example of such a link:

https://attachments.office.net/owa/frank%40frankysweb.de/service.svc/s/GetAttachmentThumbnail?id=AAMkADhiOTBmNWY5LTJjZDYtNGUxOC1iY2I2LThjOTFkY2ViZDJmMABGAAAAAACqEuTD%2F84uQJlfTnDiiGALBwCPvJCIdcncRYIsgFJ3hL2WAAJfmVKcAACPvJCIdcncRYIsgFJ3hL2WAAJfmm5wAAABEgAQADiPQD5c74VDoe%2B%2B3g92WzE%3D&thumbnailType=2&token=eyJhbGciOiJSUzI1NiIsImtpZCI6IkU1RDJGMEY4REE5M0I2NzA5QzQzQTlFOEE2MTQzQzAzRDYyRjlBODAiLCJ0eXAiOiJKV1QiLCJ4NXQiOiI1ZEx3LU5xVHRuQ2NRNm5vcGhROEE5WXZtb0EifQ.eyJvcmlnaW4iOiJodHRwczovL291dGxvb2sub2ZmaWNlLmNvbSIsInVjIjoiOWQ5OTM1ZTk4MjcyNDQ4NGE1ZTg0ODI4ZWZhZGU2OGMiLCJzaWduaW5fc3RhdGUiOiJbXCJrbXNpXCJdIiwidmVyIjoiRXhjaGFuZ2UuQ2FsbGJhY2suVjEiLCJhcHBjdHhzZW5kZXIiOiJPd2FEb3dubG9hZEBiODU5ZjVmNi05OTA0LTQzY2EtYTE4ZC1hOTdiMmQ1ODM5ZTEiLCJpc3NyaW5nIjoiU0lQIiwiYXBwY3R4Ijoie1wibXNleGNocHJvdFwiOlwib3dhXCIsXCJwdWlkXCI6XCIxMTUzODAxMTE3NDI4NTIwMzEzXCIsXCJzY29wZVwiOlwiT3dhRG93bmxvYWRcIixcIm9pZFwiOlwiMDljMjUyNjktYWFjMi00NzEzLWJmZWMtOGEzYzQ0YTM1ZWJlXCIsXCJwcmltYXJ5c2lkXCI6XCJTLTEtNS0yMS0xODc1NjU3MTcwLTQxMDY2NTQ5NDgtMjUwNTI2NDE4Mi0yMTM2NDQyXCJ9IiwibmJmIjoxNzA4OTc3NjAwLCJleHAiOjE3MDg5NzgyMDAsImlzcyI6IjAwMDAwMDAyLTAwMDAtMGZmMS1jZTAwLTAwMDAwMDAwMDAwMEBiODU5ZjVmNi05OTA0LTQzY2EtYTE4ZC1hOTdiMmQ1ODM5ZTEiLCJhdWQiOiIwMDAwMDAwMi0wMDAwLTBmZjEtY2UwMC0wMDAwMDAwMDAwMDAvYXR0YWNobWVudHMub2ZmaWNlLm5ldEBiODU5ZjVmNi05OTA0LTQzY2EtYTE4ZC1hOTdiMmQ1ODM5ZTEiLCJoYXBwIjoib3dhIn0.pKb_b2O0sP2qQcSutLI49tn8jqOE0j3qcrFYD4M8bE_iHd4TnmyZgWK5Xiv9FBIpCw2Wk6vOgmAuLuGc_yet65QWQcnc-pqCmIGSxqZIjbMJQSiPQW5Fn--6obEk-a7bSzdHlbMJkG0WzSDlRua0KngTIigUJmB_V_gpdirnjYB2AcLipY_r9aKriDXIQw3Oy97UIcxkhliAVtxhv6imO4r2E-HsoQOA6XVGZWYGrPkSdhLb32EBZgq0IblTfiItb1fPr7VTC4k9Vm4sYFtpjkrOu3PnOkE-UyLCgWjb9kpuOzAzB7vvURCuGL9AUl53Bjzh3YSDmmNvcO2xjEYVVA&X-OWA-CANARY=bdvoV4IHMRAAAAAAAAAAAFAoC4YFN9wYyMPHZpmfClg-YZZg6lISRIbwSQqv1QEttZFuKmS4x00.&owa=outlook.office.com&scriptVer=20240209002.20&clientId=10B3F6878DF34150B26E9D9E22FA37AC&animation=true

As you can see, the link is extremely long and cannot be easily guessed, but it can happen that such links appear in logs. And this is exactly where the problem lies.

How could this be exploited?

Eins vorweg: Ich teile hier durchaus die Einschätzung von Microsoft, dass es sich hier um keine Schwachstelle der Kategorie „Kritisch“ oder „Wichtig“ handelt. Um das Problem auszunutzen, muss man also an die Links kommen, damit man Bilder und auch Anhänge aus E-Mails ohne Authentifizierung runterladen kann. Dies ist aber gar nicht so einfach, denn es handelt sich hier ja um eine HTTPS Verbindung. Befinde ich mich beispielsweise in einem öffentlichen WLAN, dann wird in allen Logs maximal eine Verbindung zu der Domain attachments.office.net auftauchen, nicht aber der Link wie „https://attachments.office.net/owa/frank%40frankysweb.de/service.svc/s/GetAttachmentThumbnail?id=AAMkADhi….“ denn der komplette Link (außer die Domain) ist bei HTTPS Verbindungen schon verschlüsselt und nur für mich sichtbar.

You would only get the complete link if the HTTPS connection is broken (SSL Inspection, MitM), but this would lead to an SSL error in public networks. In some environments, however, this could be a way of accessing the URLs. For example, if a firewall with SSL inspection is used in the company, the complete URL will be visible in the log files. As an internal admin with access to the log files, you could simply use a small script to download everything that begins with "https://attachments.office.net/owa" and look at it later at your leisure. The URL can also be used to identify the recipient of the attachment or image: https://attachments.office.net/owa/frank%40frankysweb.de/

The generated links are only valid for a good 10 minutes, after which only an HTTP 401 is delivered.

Where could the lack of authentication become a problem?

I think it is undisputed that this problem should be fixed, even if it has not been classified as critical or important. In public networks, the problem can probably only be exploited by using MitM to connect to the HTTPS connection. This would lead to an SSL error, but the user may simply click the message away. In this case, however, the problem described here no longer needs to be exploited, as the entire traffic could now be recorded anyway (not just images and attachments, but complete emails and possibly also login data).

In a company, however, the situation is somewhat different, as there could be several places where the URLs are visible. For example, some virus scanners log the URLs accessed in the log files and report them to the management server. Some XDR systems or browser plugins also log the URLs accessed. Reader L. Herzog was able to extract the URLs from the logs of Sophos Intercept-X and the Central Data Lake, for example, so that the team that administers the endpoint antivirus would also have anonymous access to the images and file attachments of all employees in the company that were displayed in OWA. Although there are no Exchange admins in this team.

Since the URLs do not require authentication, no 2FA or MFA solution is effective here and unauthorized access should be very difficult to detect.

You can have fun and search your logs for "attachments.office.net" or alternatively the Exchange on-prem download domain. Maybe you'll find something there too.

Many thanks to L. Herzog for reporting the problem and for the pleasant e-mail correspondence.