Disclosure- We at Lightsprocket 100% believe in the responsible disclosure of what we consider to be vulnerabilities or security flaws. As such, this article was disclosed to Microsoft as VULN-041203 and Microsoft was given opportunity to respond before we posted this article.
During a recent engagement we worked through a phishing investigation. The question that was asked – How was a customer getting obviously positive phishing emails delivered directly to their inbox. The answer was a commonly used feature, but its functionality was misunderstood.
Outlook Safe Senders List allows complete email protection bypass.
During our research, we determined that if you have a email address in your Outlook safe sender list. Exchange online (Office365) flags the email with a Spam Confidence Level (SCL) of -1. This SCL -1, as easily seen in the email message headers, bypasses all scanning rulesets. This bypass, allows any compromised email address that is on a safe sender list to send in malicious / spoofed emails and successfully phish a office365 mailbox recipient.
Our Analysis-
Vulnerability:
Anyone added to the Outlook safe-senders list, automatically bypasses all scanning. Safe Senders list sets SCL= -1 in email header.
Risk:
It is extremely common for hackers to use compromised mailboxes to reach out to existing email contacts and send them malicious mail. Hackers depend on these existing relationships to increase the potential of being successful in their phishing attempts.
Safe senders list is a user controlled or organization controlled setting via group policy. Some organizations have outdated rule sets that have outlook configured to add anyone a person sends to automatically added to safe sender. If this is in group policy, it is checked and grayed out for the user. If left to the user, the user can turn the option on to automatic.
It is possible that an organization has trusted certain outside domains with safe sender or individuals have trusted certain people they correspond with often as safe senders without realizing the impact / exposure since safe sender rules bypass scan engines.
Reproduction:
We reproduced this safe sender bypass by adding an email address to a test accounts safe senders list.
In Office365 rules, we put in a rule to create a spam confidence level 9 on any email that does not pass spf or dkim/dmarc.
Our test domain that Office365 is using has DNS records setup including SPF, Dmarc/ DKIM setup with fail actions requested as Quarantine.
We set rules up to check for SPF and Dmarc/ Dkim and also created a rule to quarantine any item that came from outside the org with an email domain matching the email domain of the Office365 org (e.g. if [email protected] was sent inbound to a Office365 user [email protected] it would quarantine that message).
To spoof that safe sender email address, we connected to Office365 via telnet from a system not associated with any SPF IP whitelist rule and issued email send commands with From and RCPT To commands appropriately to deliver the message to our test mailbox.
The first time we sent via telnet, Microsoft Exchange was nice enough to inform us that our IP address was blocked from sending and to read a Microsoft article on the subject. Following the article, we submitted our telnet host IP where we were sending our email from to Microsoft via the Office365 Anti-Spam IP Delist Portal (https://sender.office.com). After a confirmation email and an hour wait, we were able to telnet to Microsoft’s Office365 mail server and successfully deliver our test email via telnet port 25.
Reviewing the header, you see the SCL-1 flag and the message is delivered directly into the inbox. You see the Authentication results showing Dkim not signed and Dmarc = fail action = quarantine. Lastly, you notice SPF: Fail, does not designate as permitted sender.
Analysis in Office365 Exchange admin reveals that the Spam Filtering Verdict is: SFE (Filtering was skipped and message was allowed because it was sent from an address in a user’s Safe Senders list.)
We also see explicit SPF and DMARC failures with the fail action= quarantine requested.
We determined if we impersonated a person inside the org and sent to inside the org, as long as that person was on the safe sender list, the same bypass of rules took place. The main difference is the email would get tool tipped, since we had a phishing tool tip policy enabled in our Office365 tenant, but otherwise look authentic to the email recipient.
Further testing of email rules included testing moving to quarantine if failed SPF or sender with email from address being same domain as inside of the org would deliver directly to inbox.
Remediation:
In our efforts to resolve the only viable Office365 action we found was to go into Office365 Exchange Admin center and create a rule at the top most position that drops email inbound to the organization from outside that fails SPF / Dmarc / Dkim checks.
The only rule that we found would block this delivery was to put a rule #1 in place where the policy must be drop email if SPF/Dmarc fails.
If you fail to drop the email, it will deliver to the mailbox regardless of what other treatments / rules you apply to it.
Note- We were able to Policy a email to quarantine with a rule, but because of the policy rule – the email was not visible to the test users quarantine view. Is is as designed according to Microsoft since it is an Administrative quarantine action.
Other recommendations:
Organizations should rely on whitelisting in rules with extreme caution. At no point in time should a group policy be set to automatically enable safe senders in Office365 (e.g. Automatically trust anyone I send to). If a group policy is set, remove it. Never ever add your Office365 email domain to the safe senders list.
Review users safe senders lists with PowerShell:
Get-MailboxJunkEmailConfiguration -identity [email protected] | Select -ExpandProperty TrustedRecipientsAndDomainsConsider adding a third party email filtering solution to your Office365 environment such as Proofpoint, Mimecast, or others available in the market to better guarantee email scanning is accomplished and not left to chance safe sender bypass by an end user.
Microsoft’s response to our submission:
We proposed a solution to Microsoft where they need to implement a way for Office365 exchange admins to override safe sender rules and enforce email scanning engines for spoof / malicious content. Admins should have control and allow their environment to adhere to a senders SPF and Dmarc suggestions of quarantine or drop regardless of an individual users safe sender list.
Microsoft replied to our finding with the following message:
Thank you for contacting the Microsoft Security Response Center (MSRC). What you’re reporting appears to be an issue that is by design, but does not meet the definition of a security vulnerability. From the description of your report, it is the admin or IT manager who would add an email to the Safe Sender List. Microsoft does not control who is or who is not added to your organization’s Safe Sender list. We suggest you refer to your admin or IT manager is you have questions about your organization’s group policy for the Safe Sender List.
MSRC – Microsoft Security Response Center
As such, this thread is being closed and no longer monitored.
Conclusion:
For many org’s it is still not yet feasible to fully drop any message that does not meet SPF / Dmarc checks. We deem this to be a credible vector with increased risk for successfully spoofing and phishing Office365 email customers, especially those actively utilizing safe sender lists.
Microsoft needs to implement additional rulesets that give Office365 administrators control of safe sender settings and enforce scan engines to do their work to protect the Office365 customer.
We hope you found this article useful in understanding how a seemingly simple design feature can pose risk inside your organization and sparks thought about your organizations security posture.