Security Researchers Can Do Better When Discussing Microsoft 365 Flaws

Instead of Discussing Individual Vulnerabilities, Focus on How They Affect a Tenant

I like and respect the work of security researchers. With the nagging conscience of the IT industry, security researchers do a good job of holding large technology companies to account when those companies do a poor job of protecting customer data. The role of the researchers is intensely valuable, and their activity usually delivers a great service to the community.

However, in 2023, I would appreciate it if security researchers paid a tad more attention to the big picture when they rush to reveal flaws that they think exist in Microsoft 365. I don’t deny that flaws exist in Microsoft 365. They do. That’s a natural (but problematic) state for such a large software service composed of multiple workloads running on a global scale. A colossal number of servers run within Microsoft 365 to process data for over 345 million paid Office 365 users (the last number given by Microsoft in April 2022). Exchange Online alone runs 300,000 physical mailbox servers to process 9.2 billion messages daily. There’s no excuse for an obvious software flaw, but you can appreciate that the scale and demands of a service that changes on a constant basis might reveal issues from time to time.

Publish and Be Damned

The problem I’ve noted in 2022 is that some security researchers do not consider the practicalities of how a flaw might affect Microsoft 365 operations when they report details of a potential vulnerability. Instead, they rush to reveal their findings in almost indecent haste. So much so that the suspicion that the revelation is more about grabbing eyeballs than helping the community. Or in some cases, the need for the security company to drive sales, secure investment, or otherwise gain some advantage.

Some examples of what I mean are:

• The GIFShell attack against Teams purported to demonstrate that it is possible for a hacker to send an infected GIF file to a user in another Teams organization. The technique works, but it depends on the attacker being able to infect a PC first. It’s also very easy for an organization to block inbound chat from untrusted organizations, a salient fact that the researcher either didn’t know or failed to mention.
• Another flurry of research interest centered on the fact that Teams stores access tokens in clear text. I don’t disagree that this is poor practice, but it is not the “severe security vulnerability” that the researcher hyped it to be. Once again, an attacker had to compromise a PC before they could scan the system for access tokens, and it’s surely the case that an attacker has more lucrative targets if they can penetrate a PC?
• Security researchers became worried about Office 365 message encryption in October. It’s bad that Microsoft doesn’t use better protection for Office files here, but the probability of data compromise using the method outlined by the researchers is infinitesimal.

Another example is the Autodiscover “Great credentials leak” in October 2021. This was an old issue but it’s a client-side problem that mobile device vendors fixed long ago.

Spoofing Like It’s 1995

All of which brings me to a May 22, 2022 report from Black Hills Information Security titled “Spoofing Microsoft 365 Like It’s 1995” written by Steve Borosh. The point being made is that Microsoft 365 tenants should make sure that Exchange Online isn’t open to phishing attempts. That’s good advice that I strongly support.

Borosh focuses on Exchange Online’s Direct Send feature that allows applications and devices to send email to recipients in the same organization (tenant). He says that: “With Microsoft direct send, we’re able to send emails on behalf of external or internal users to other internal users inside enterprises using Microsoft 365; in essence, spoofing emails into many organizations.” And further asserts that a vulnerability exists because “Microsoft utilizes “smart hosts” for Exchange typically located at an address like company-com.mail.protection.outlook.com that allows unauthenticated SMTP relays to internal users.”

As you’re probably aware, Microsoft is doing its best to remove basic authentication from Exchange Online connection protocols. SMTP AUTH has a current exemption, but that will disappear in the future and organizations will need to use a different method to send messages via Exchange Online. Direct send is one. Replacing SMTP AUTH with Graph-based APIs is another. Using a connector is a third. The problem with multi-function devices and applications is that it can be difficult to update them to use a different method. Direct Send takes some of the pain out of the process, which is why I guess it exists.

In any case, Borosh correctly points out that Direct Send can send messages from outside an organization, which is the basic purpose of email. Exchange Online Protection processes these messages like any other inbound email to ensure that they meet the organization’s requirements for acceptance and to eliminate malware and spam.

Borosh advances a case that attackers could exploit Direct Send to deliver phishing messages to target mailboxes and describes using a mail flow rule to turn off Exchange Online Protection spam filtering by setting the Spam Confidence Level (SCL) value for messages generated by a specific domain to -1 (meaning bypass). In other words, because the SCL is bypassed, Exchange considers it a message that is free of spam and malware and delivers it to the destination. He demonstrates how to send a message through Direct Send with PowerShell (Windows, Linux, and Azure Cloud Shell).

All of this is true, and it’s possible that some tenant administrators have gone down the path of creating a mail flow rule to set the SCL value to zero for messages from specific domains. However, it’s a terrible idea. Mail flow rules should never interfere with the SCL value assigned to messages unless a good and valid reason exists for this to happen. And if a mail flow run needs to set a specific SCL for messages, make sure that the conditions when this happens are as tight as possible. For instance, the SCL is only set for messages coming from a specific sender.

Setting an SCL value to prove a point is not a valid reason. Exchange Online Protection exists for a reason in every Microsoft 365 tenant that uses Exchange Online. Why would you ever want to remove that protection?

A Potential but Unlikely Hole

The bottom line is that Direct Send is a potential hole. But it’s a hole that competent tenant administrators close by using Exchange Online Protection to block bad messages in the way that it’s designed to function. I don’t consider this to be a product vulnerability. Instead, it’s an exploitable weakness if people are unwise enough to remove protections.

The report doesn’t cite any examples of phishing attacks conducted using Direct Send when tenants let their guard down. Phishing happens all the time, and because the attackers vary and evolve their techniques, some phishing gets through. The latest that landed in my mailbox was an opportunity to pay a subscription for support from the Geek Squad. Exchange Online delivered this message to my inbox after Exchange Online Protection flagged it with a safety tip because I don’t normally receive email from the sender.

I used the Outlook report message add-on to report the phishing message to Microsoft, but viewing its content (Figure 1), I wonder how it got past Exchange Online Protection. In light of this kind of threat, we don’t have to make life harder by partially disabling spam filtering.

There’s value to consider in Borosh’s report, but I also think that it’s another example of a security researcher publishing without thinking about the full picture. Sure, if a specific set of circumstances exist, phishing messages will get through. But how likely is this to happen? I have my doubts. It would be nice in 2023 if security researchers asked how likely anyone can exploit a flaw before they publish.