From an attacker perspective email remains one of the most reliable channels for reaching their targets. Many security breaches start out with an employee making a poor judgment call to open a dangerous attachment or click on a link from their inbox. Not surprisingly cloud providers of email service invest significant time in building security features to protect against such risks. Safe Links is part of the defenses built into MSFT Defender for Office 365. As the second word implies, it is concerned with links: specifically protecting users from following harmful links embedded in email messages.
Working from first principles, there are two ways one could go about designing that functionality:
- Validate the link when the email is first received by the cloud service
- Validate it when the message is read by the recipient.
In both cases the verb “validate” assumes there is some blackbox that can look at a website and pass judgment on whether it is malicious, perhaps with a confidence score attached. In practice that would be a combination of crowd-sourced blacklists— for example, URLs previously reported as phishing by other users— and machine learning models trained to recognize specific signals of malicious activity..
There are trade-offs to either approach. Scanning as soon as email is received (but before it is delivered to the user inbox) allows for early detection of attacks. By not allowing users to ever see that email, we can short circuit human factors and avoid the risk that someone may be tempted to click on the link. On the other hand, it runs into a common design flaw known as TOCTOU or time-of-check-time-of-use. Here of “time of check” is when the webpage is scanned. “Time of use” is when the user clicks on the link. In between the content that the link points at can change; what started out as a benign page can morph into phishing or serve up browser exploits.
Cloaking malicious content this way would be trivial for attackers, since they have full control over the content returned at all times. At the time they send their phishing email, the server could be configured to serve anodyne, harmless pages. After waiting a few hours— or perhaps waiting until the initial scan, which is quite predictable in the case of MSFT Defender— they can flip a switch to start the attack. (Bonus points for sending email outside business hours, improving the odds that the victim will not accidentally stumble on the link until after the real payload is activated.) There is also a more mundane possibility that the page never changes but the classifiers get it wrong, mistakenly labeling it as harmless until other users manually report the page as malicious. Validating links on every click avoids such hijinks, leveraging most up-to-date information about the destination.
Wrapping links
While validating links every time is the more sound design, it poses a problem for email service providers. They do not have visibility into every possible situation where users are following links from email. In the fantasy universe MSFT sales teams inhibit, all customers read their email on MSFT Outlook on PCs running Windows with a copy of Defender for Endpoint installed for extra safety. In the real world, enterprises have heterogenous environments where employees could be reading email on iPhones, Android, Macs or even on Linux machines without a trace of MSFT software in the picture.
Safe Links solves that problem by rewriting links in the original email before delivering it to the customer inbox. Instead of pointing to the original URL, the links now point to a MSFT website that can perform checks every time it is accessed and only redirect the user to the original site if considered safe. Once the original copy of the message has been altered, it no longer matters which email client or device the user prefers. They will all render messages with modified links pointing back to MSFT servers. (There is a certain irony to MSFT actively modifying customer communications in the name of security, after running a FUD campaign accusing Google of merely reading their customers’ messages. But this is an opt-in enterprise feature that customers actually pay extra for. As with most enterprise IT decisions, it is inflicted on a user population that has little say on the policy decisions affecting their computing environment.)
Safe Links at work
To take an example, consider the fate of a direct link to Google when it appears in a message addressed to an Office 365 user with Defender policies enabled. There are different ways the link can appear, such as plaintext, as hyperlink from text section or image. and image with hyperlink. Here is the message according to the sender:
Here is the same message from the vantage point of the Office 365 recipient:
Visually these look identical. But on closer inspection the links have been altered. This is easiest to observe from the MSFT webmail client. True URLs are displayed in the browser status bar at the bottom of the window when hovering over links:
The alterations are more blatant when links are sent as plaintext email:
In this case Safe Links alters the visual appearance of the message, because the URL appears as plain- text instead of being encoded in the HTML mark-up which is not directly rendered.
Structure of altered links
Modifications follow the same pattern:
- Hostname points to “outlook.com” a domain controlled by MSFT.
- Original URL is included verbatim as one of the query-string parameters
- Email address of the recipient also makes an appearance, in the next parameter
- What is not obvious from the syntactic structure of the link but can be verified experimentally: this link does not require authentication. It is not personalized. Anyone— not just the original recipient— can request that URL from MSFT and will be served a redirect to Google. In other words these links function as semi-open redirectors.
- There is an integrity check in the link. Tampering with any of the query-string parameters or removing them results in an error from the server. (“sdata” field could indicate a Signature over the Data field. It is exactly 32 bytes of base64-encoded content, consistent with an HMAC-SHA256 or similar MAC intended for verification only by MSFT.) This is what happens if the target URL is modified from Google to Bing:
Bad interactions: end-to-end encryption
Given this background, now we can discuss a trivial bypass. S/MIME is a standard for end-to-end encryption and authentication of email traffic. It is ancient in Internet years, dating back to the 1990s. Emerging around the same time as PGP, it is arguably the “enterprisey” buttoned-down response to PGP, compliant with other fashionably enterprise-centric standards of its era. While PGP defined its own format for everything from public-keys to message structure, S/MIME built on X509 for digital certificates and CMS/PKCS7 for ciphertext/signature formatting. (Incidentally both are based on the binary encoding format ASN1.) As with PGP, it has not taken off broadly except in the context of certain high-security enterprise and government/defense settings.
At the nuts and bolts level, S/MIME uses public-key cryptography. Each participant has their own key-pair. Their public-key is embedded in a digital certificate issued by a trusted CA that can vouch for the owner of that public key. If Alice and Bob have each others’ certificates, she can encrypt emails that only Bob can read. She can also digitally sign those messages such that Bob can be confident they could only have originated with Alice.
How does all this interact with Safe Links? There is an obvious case involving encrypted messages: if an incoming message is encrypted such that Bob can only read it after decrypting with his private key— which no one else possesses— then the email service provider can not do any inspection, let alone rewriting, of hyperlinks present. That applies broadly to any link scanning implemented by a middle-man, not just MSFT Safe Links. (Tangent: that restriction only holds for true end-to-end encryption. Cloud providers such as Google have muddied the waters with lobotomized/watered-down variants where private-keys are escrowed to the cloud provider in order to sign/decrypt on behalf of the end user. That is S/MIME in name only and more accurately “encraption.”)
In practice, this bypass is not very useful for a typical adversary running a garden-variety phishing campaign:
- Most targets do not use S/MIME
- For those who do— while few in number, these will be high-value targets with national security implications— the attacker likely does not have access to the victim certificate to properly encrypt the message. (Granted, this is security through obscurity. It will not deter a resourceful attacker.)
- Finally even if they could compose encrypted emails, such messages are likely to raise suspicion. The presence of encryption can be used as a signal in machine learning models as contributing sign of malicious behavior, as in the case of encrypted zip files sent as attachments. Even the recipient may have heightened awareness of unusual behavior if opening the email requires taking unusual steps, such as entering the PIN for their smart-card to perform decryption.
Trivial bypass with signatures
But there is a more subtle interaction between Safe Links and S/MIME. Recall that digital signatures are extremely sensitive to any alteration of the message. Anything that modifies message content would invalidate signatures. It appears that the Safe Links design accounted for this and shows particular restraint: clear-text messages bearing an S/MIME signature are exempt from link-wrapping.
Interestingly, the exemption from Safe Links works regardless of whether the S/MIME certificate used for signing is trusted. In the above above screenshot from Outlook on MacOS, there is an informational message about the presence of a digital signature, accompanied by the reassuring visual indication of security, the ubiquitous lock icon. But taking a closer look via “Details” shows the certificate was explicitly marked as untrusted in MacOS keychain:
Similarly the web UI merely contains a disclaimer about signature status being unverifiable due to a missing S/MIME control. (Notwithstanding the legacy IE/ActiveX terminology of “control” that appears to be a reference to a Chrome extension for using S/MIME with webmail.) This limitation is natural: signature validation is done locally by the email client running on a user device. Safe Links operates in the cloud and must make a decision about rewriting links at the time the email is received, without knowing how the recipient will view it. Without full visibility into the trusted CAs associated with every possible user device, a cloud service can not make an accurate prediction about whether the signing certificate is valid for this purpose. MSFT makes a conservative assumption, namely that the signature may be valid for some device somewhere. It follows that signed messages must be exempt from tampering by Safe Links.
Exploiting cleartext signed messages to evade Safe Links is straightforward. Anyone can roll out their own CA and issue themselves certificates suitable for S/MIME. The main requirement is the presence of a particular OID in the extended key-usage (EKU) attribute indicating that the key is meant for email protection. While such certificates will not be trusted by anyone, the mere existence of a signature is enough to exempt messages from Safe Links and allow links to reach their target without tampering.
Crafting such messages does not require any special capability on the part of the target. Recall that they are signed by the sender— in other words, the attacker— but they are not encrypted. There is no need for the recipient to have S/MIME setup or even know what S/MIME is. Depending on the email client, there may be visual indications in the UI about the presence of a digital signature, as well as its trust status. (Worst case scenario, if there are obtrusive warnings concerning an untrusted signature, attackers can also get free S/MIME certificates from a publicly trusted CA such as Actalis. This is unlikely to be necessary. Given the lessons from Why Johnny Can’t Encrypt, subtle warnings are unlikely to influence trust decisions made by end users.)
Options for mitigation
While this post focused on cloud-hosted Exchange, the same dilemma applies to any so-called “email security” solution predicated on rewriting email contents: it can either break S/MIME signatures or fail-open by allowing all links in signed messages through unchanged. Even the weak, key-escrow model espoused by companies such as Google is of little help. GMail can decrypt incoming messages on behalf of a customer of Google Apps, if the customer willingly relinquishes their end-to-end confidentiality and hands over their private key to Google. But GMail still can not re-sign an altered message that was originally signed by unaffiliated party.
Given the rarity of S/MIME, a pragmatic approach is to allow enterprises to opt into the first option. If their employees are not setup for S/MIME and have no expectation of end-to-end authentication in the first place, this functionality is introducing pure risk with no benefit. In that scenario it makes sense for Exchange to not only rewrite the link, but remove signatures altogether to avoid confusion.
That will not fly in high-security environments where S/MIME is actually deployed and end-to-end encryption is important. In that case, more fine grained controls can be applied to cleartext signed messages. For example, the administrator could require that cleartext signed messages are only allowed if the sender certificate was issued by a handful of trusted CAs.
CP
Random Oracle 