48

Our work e-mail server has started rewriting links in incoming mail through a redirecting gateway, for "security reasons": if I receive an e-mail containing a link to https://security.stackexchange.com, the link gets rewritten to

https://es.sonicurlprotection-fra.com/click?PV=2&MSGID=202209021358500174760&URLID=1&ESV=10.0.18.7423&IV=D329C6F4AF0738E931FA9F0EAAD309B2&TT=1662127131399&ESN=kgatDRmAwf3NdgkHDeepamZT4x4VYB71UZXeLJNkMQ0%3D&KV=1536961729280&B64_ENCODED_URL=aHR0cHM6Ly9zZWN1cml0eS5zdGFja2V4Y2hhbmdlLmNvbQ&HK=B0A81618C6DD8CBAFF5376A265D02328AB2DA6B2A64AA8DA59F1662AC2089052

before the mail arrives into my Inbox. Clicking on this opaque blob redirects me to https://security.stackexchange.com.

Presumably, the idea is that if the target address turns out to be malicious then the mail server provider (Sonicwall) can decide to block the link even retroactively in messages that have already been delivered.

Is this kind of link tracking considered good security practice? Are there any authoritative opinions on it from researchers, for instance? At a first thought, I can come up with many disadvantages, and minimal advantages (but I am no security expert).

I have tried looking for opinions online, but the only articles I find come from people that are trying to sell similar technology, so they might be biased: for instance this, this and this.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
Federico Poloni
  • 829
  • 9
  • 15
  • 42
    One immediate drawback I can see is that it becomes harder to differentiate legitimate and illegitimate URL. (Not saying the displayed URL should be trusted anyway.) – Yuriko Sep 02 '22 at 14:21
  • 25
    @Yuriko Yes, and it is not the only drawback; for instance, breaking PGP signatures, privacy issues (Godaddy can track every time I clicked on a link in my e-mail and from where), training users to click mindlessly on long URL blobs. – Federico Poloni Sep 02 '22 at 14:24
  • 4
    Also see [Is a safelinks.protection.outlook.com link phishing?](/questions/230309/is-a-safelinks-protection-outlook-com-link-phishing) for a discussion of the issues with Outlook's ATP Safe Links. – Wes Toleman Sep 03 '22 at 04:34
  • 9
    The overwhelming and obvious downside is that these days, when anyone gets a link from "fexed.com" or "amazoon.com" (note the spellings) we all know instantly it's a silly spam. The system in question eliminates this; you have utterly no idea what you are clicking. You have to click to find out - **which is a terrifying concept**! – Fattie Sep 04 '22 at 16:29
  • @Fattie: *"... when anyone gets a link from "fexed.com" or "amazoon.com" (note the spellings) we all know instantly it's a silly spam."* - I think you overestimate the knowledge of the average user confronted with phishing. Also, attackers are not stupid and so you'll find links like amazon-secure.com, signin-ebay.com ... which are even less obvious. – Steffen Ullrich Sep 05 '22 at 05:46
  • 2
    an other con: it may render the url unusable. For example: the URL could be only accessible from a vpn/specific host that blocks connections to the internet, so clicking the url/copying it into a VM/browser with the VPN can lead you to a network error and you then have to copy the text of the URL instead (and if who sent you the link overrode the text you'd have to manually de-encode the url hoping it contains the proper url encoded and not just an identifier for it). – GACy20 Sep 05 '22 at 07:53
  • @GACy20 Good point, it is not a common setup but it's definitely a concern. In this case, one of the parameters is the Base64 encoded target URL, so it can be decoded in theory (but it's very annoying to do it by hand). – Federico Poloni Sep 05 '22 at 11:01
  • @SteffenUllrich - with a redirect rewritten url, you or I as expert users, literally *cannot know* (!) what the url is until it is clicked on! – Fattie Sep 05 '22 at 12:32
  • @Fattie: *"with a redirect rewritten url, you or I as expert users, literally cannot know (!) what the url is until it is clicked on!"* - I fully agree with you. But most users are not experts. And these non-experts will not able to properly assess the risk of the original URL either. I don't think that URL rewriting is the best option (see my answer), but I think it is for most users a better option than to only check the URL when the mail got received by the mail server. – Steffen Ullrich Sep 05 '22 at 12:57
  • 1
    Steffen - I don't agree (additionally, for the other reasons mentioned), but fair enough! – Fattie Sep 05 '22 at 13:06
  • 1
    The URL rewriter at my office would rewrite as: `https://urldefense.com/v3/__https://security.stackexchange.com/__;!!FJ-Y8qCqXTj2!ZyGwmg41ZCZnQyUjh2eAlfom5kAzczd-Y84kDJ--tARE96plVVtad8zdOPA5JxPRu_H4oleTSNcYY_0egK1SkvGNPQZFknzZ_l59$` which does eliminated at least _some_ of the problems. – Martin Bonner supports Monica Sep 05 '22 at 15:00
  • @MartinBonnersupportsMonica This format suggests another interesting question: what is the use of all the other parameters, apart from the one that encodes the URL? If the true purpose is only preventing connections to URLs in a blacklist, and not tracking users, why do they need additional parameters? What do those strings encode? – Federico Poloni Sep 05 '22 at 15:14

4 Answers4

46

This practice actually has a bunch of security downsides that make it problematic.

First, modifying the email breaks any sort of digital signature on it, such as DKIM. This can be used by the mail server or the mail client to verify that the author is who they say they are. For example, if your mail client says, "This email is from stackexchange.com," then you can know that the email may be legitimate if it looks like a StackExchange email, but this can't be done if you modify the email.

Second, it also means that the URL no longer points to the actual domain. This makes phishing easier, since every illegitimate link looks just like a legitimate link: it goes to some rewritten domain. If the user is expecting a link to an internal domain, they can no longer determine if the link is legitimate just by looking at the hostname in the URL.

A better practice would be to use some sort of endpoint software or trusted DNS server which logs all domains used or disallows known malicious sites. This is common in a lot of places and avoids the security downsides of tampering with data. You can also scan them when they come into the server and look for suspicious looking URLs, such as those which look like some sort of impersonation attack on legitimate domains or those which are known to be associated with malware or phishing.

I also should point out that you should not under any circumstances use a TLS intercepting proxy as Steffen Ulrich suggests. Security research has found numerous vulnerabilities in these devices, including weak algorithms, insecure protocol versions, and lack of certificate validation, any of which can mean that data can just be decrypted by an attacker. What's more, they are often just functionally broken and don't speak the protocol correctly, which I can tell you from years of dealing with end user problems as a Git contributor.

bk2204
  • 7,828
  • 16
  • 15
  • 2
    *"... should not under any circumstances use a TLS intercepting proxy as Steffen Ulrich suggests. Security research has found numerous vulnerabilities in these devices,"* - TLS interception is a trade-off between having reduced visibility and impacting privacy. And severe vulnerabilities have been found in many security software - like VPN, antivirus, firewalls ... . Does this mean none of these should be used? And of course vulnerabilities are also often found in mail servers, browsers, office programs ... - should these not be used too? Have fun using anything with this kind of argument. – Steffen Ullrich Sep 03 '22 at 15:15
  • The proposal with denying access to a domain by using the DNS server is a good point. But it has its limits since it only sees the domain without having any context and without knowing the full URL and its content. This helps with phishing on domains registered by the attacker, but not with a common type of phishing where the attacker misuses some path in a compromised domain. For example Cisco Umbrella started with a pure DNS based approach (by buying OpenDNS) but after a while has also added a TLS intercepting web proxy to it to provide more visibility. – Steffen Ullrich Sep 03 '22 at 15:28
  • 2
    @SteffenUllrich: If TLS interceptors are to be tolerated, the original certificate should be added as an attribute to the intercepting certificate so the browser/user can inspect it. It also turns out that by doing so this closes most of the vulnerabilities (although not TLS version downgrade). – Joshua Sep 03 '22 at 16:10
  • @Joshua: Good idea, but there is no mechanism in the browser for this. It cannot be simply added to the newly created certificate chain since the browser will ignore it it. It cannot be added to some TLS extension since none is defined for this purpose - and even if it is defined browsers need to support this. I know of one commercial product which makes it possible via a special URL to get the original site certificate as seen from the intercepting proxy - but even this is not necessarily the same as the original certificate served with a specific connection. Still, better than nothing. – Steffen Ullrich Sep 03 '22 at 17:18
  • 1
    @SteffenUllrich: The back pressure against TLS interceptors will continue until until such a thing is done. (Manual inspection doesn't help. Closing the vulnerabilities requires an automatable version.) – Joshua Sep 03 '22 at 17:33
  • 1
    @Joshua: I'm not sure. From my experience the amount of TLS interception actually increased - because the amount of TLS increased and there is the need for visibility in order to detect attacks. But let's just disagree and stop the discussion - this is not the right place for it. – Steffen Ullrich Sep 03 '22 at 17:52
  • Most services like this don't actually modify the message on the server - they just change how it is presented to the client application when the message is requested. This means signatures still work, provided you trust the connection to your own mail server. The client can also be aware of the redirect, and display the target URL on hover rather than the redirection URL. – MooseBoys Sep 05 '22 at 08:24
  • @MooseBoys I don't know what is stored on the server, but the IMAP interface serves me the modified links. I use Thunderbird and check signatures locally, so there is no way this would work. (And, on the other hand, Thunderbird displays a warning that the link might be malicious, when a link text says `security.stackexchange.com` and the link itself goes somewhere else.) – Federico Poloni Sep 05 '22 at 12:48
13

This is done by a number of providers; however it has a number of downsides that mean it is often preferable to just scan for bad links rather than modify them.

  1. It breaks PGP or SMIME digital signatures. This is a big one, as it prevents end-to-end verification unless encrypted. DKIM signatures can be validated by your mail gateway before modification, and warning headers added by wrapping a mime-multipart-inline around the signed wrapper, but body modification will definitely break signatures.
  2. It prevents users from visually verifying valid URLs. You have no way to spot phishing URLs yourself any more, and have passed complete agency to the monitoring software.
  3. It may break use-once URLs. Some security systems send out use-once URLs to access things. If this system checks a link by downloading it to check before passing on, it is possible that this can result in a double-retrieval which will prevent the end use from accessing a use-once URL. I have seen this happen with Sympa (mailing list software)
  4. You would likely get just as good protection by checking for dubious URLs, and adding a Subject tag or mail header (or quarantining the entire email) if something looks suspicious.

On the one hand, it is good that some sort of scanning is taking place. That's better than nothing! But the way it has been implemented possibly has too many downsides and so I would not call it best practice. Scanning inbound emails, and checking for suspicious URLs, is definitely best practice but not necessarily making modifications to the incoming email.

Steve Shipway
  • 241
  • 1
  • 5
  • 3
    The one-use thing is an excellent point. A common example is Slack, the robot links of which are staggeringly badly and inconveniently programmed and constantly fail in casual use due to the once-only aspect of the way they are done. The system in question destroys the ability to use systems like Slack. – Fattie Sep 04 '22 at 16:31
  • The one-use problem is not specific to only URL rewriting but happens also when the link is checked at the moment the mail is received by the firewall, i.e. even if no modifications are made to the mail. And the proposed change of the subject in suspicious mails (#4) has also the problem of breaking signatures (#1). – Steffen Ullrich Sep 05 '22 at 18:49
4

The best security can be provided if the link gets analyzed at the moment it is visited. At this time the most recent reputation information about link and domain are available. And ideally the actual content behind the URL from the perspective of the visitor should be included in the decision too. This can be achieved if all web traffic of the user is analyzed in a TLS intercepting web proxy, as often included in corporate firewalls. Since everything is passed through the proxy no explicit URL rewriting need to be done.

Passing all web traffic over an analyzing proxy can not be done in all situations though, especially not if the access device is not in full control of the company - like when using devices not in full control of the company (BYOD). And TLS interception might be seen as a problem too, sometimes for performance reasons and often for privacy.

The second best option is thus not to have the actual content of the page from the perspective of the user, but at least analyze the link at the time of access to get the latest reputation information and to also check the content of the page from the perspective of the analyzer. This might be the same as seen from the user, but some sites detect analyzers and provide them different (innocent) content than the actual victims. This second best option can be achieved with URL rewriting in the receiving mail server. It might also be achievable with a plugin in the mail client or the browser which checks the link against some API or rewrites the link only at the time of access. Such plugins are specific for the mail client or browser though, need to be explicitly installed (might be done automatically on company managed devices) and might not be available for all clients.

URL rewriting (and plugin and web proxies) also allow interaction with the user, i.e. if the decision is not fully clear the user might be warned about potential problems but might be offered to continue if they are sure that the link is trusted. This reduces the impact of false positives.

URL rewriting in the receiving mail server has its clear problems though: anything which relies on the mail being unchanged (i.e. PGP, S/MIME or DKIM signatures) will complain about a changed mail. And URL rewriting is not possible with encrypted mails, while a web proxy still protects in this case too.

The worst option (apart from no checks at all) is to check the link ONLY when the mail arrives at the mail server. At this time there are much less reputation information available about the link, so the chance of missing a problem is much higher. Also the decision at this time is final, i.e. either the mail is blocked (or the link removed) or passed through without changes. So false positives must be reduced as much as possible which leads to an even higher rate of false negatives, i.e. of not detecting attacks. Of course, filtering obviously bad mails at this early stage is a good idea, and this option can also be used together with URL rewriting or access via proxy.

In summary: None of the offered solutions is perfect, each has its own problems. URL rewriting is a good alternative if analysis of all traffic in an TLS intercepting web proxy or if the installation of a security plugin in the mail client is not an option. It has its problems though with any kind of signed mails.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 1
    I disagree. Delivery-time checks are great. They can convict messages and prevent annoyances from reaching any inboxes. However, as you note, they are insufficient, especially wrt more sophisticated attacks. That's where click-time checks come in. Because you can't be assured that links will be clicked from within a network with its own inspection, rewrites become important as a final line of defense. (To your final point: DKIM should be vetted before rewrites, but PGP & S/MIME signatures will indeed break. Good thing they're really rare.) – Adam Katz Sep 02 '22 at 15:44
  • 4
    Would this not better be achieved with [Safe Browsing](https://en.wikipedia.org/wiki/Google_Safe_Browsing) or similar technologies that are already available? Scanning links locally browser-side has the same benefits and fewer drawbacks, in my view. – Federico Poloni Sep 02 '22 at 16:34
  • 3
    @FedericoPoloni: That's basically the browser plugin approach (Safe Browsing is special here in that it gets shipped with the browser). As for Safe Browsing - it is fine but it is out of control of the companies and there are no ways to add company specific thread intelligence. – Steffen Ullrich Sep 02 '22 at 17:15
  • 1
    @AdamKatz: you are right that delivery-time checks are valuable because they allow an early blocking of unwanted mails. I made it more clear that this is the worst option if it is the ONLY option, but that it adds value when used in addition to the others. – Steffen Ullrich Sep 02 '22 at 17:19
  • @SteffenUllrich Why would browser extensions be outside of the control of the companies installing the browser? – Bergi Sep 03 '22 at 12:39
  • 2
    You have only discussed a class of options at the network or mail handler level, but not all options. For example, you didn't discuss the option of leaving the email alone and letting the user decide, or of having the user install a browser plugin. – usul Sep 03 '22 at 13:28
  • @usul: *"didn't discuss the option of leaving the email alone and letting the user decide"* - that's basically the *"no checks at all"* part I mentioned in *"The worst option (apart from no checks at all)"*. Of course, not doing anything is always an option but usually the worst one since it basically burdens all responsibility on the end user. This will cause needless stress for end users and most end users will not be able to deal with this. Awareness campaigns help only a bit. *"or of having the user install a browser plugin."* - This also loads all responsibility on the end user. – Steffen Ullrich Sep 03 '22 at 15:07
  • @Bergi: "Why would browser extensions be outside of the control of the companies installing the browser?"* - You are correct. I made the note that they might be automatically installed on company managed devices. – Steffen Ullrich Sep 03 '22 at 15:11
3

This is a profoundly annoying practice. Especially if the rewriting rules are misconfigured to rewrite URLs sent to parties that have no means to reach the redirecting server.

Good luck configuring it correctly in a complex corporate setup.

In relation to security, if a security feature is preventing people from doing their work, they either find workarounds (with much worse security implications) or just stop doing at least some of their work.

Other answers mentioned a great deal of other problems of this security approach, so one can conclude that this "solution" goes somewhere in the range between:

  • "Security theater"-type solution
  • "Not our fault"-type solution, where people responsible for security are forcing others to use less secure, unofficial practices (e.g. external mail providers) in order to blame these unofficial practices for breaches when the breaches occur.
fraxinus
  • 3,425
  • 5
  • 20