TL;DR: An open redirect vulnerability exists in the remains of Google Web Light service, which is being actively exploited in multiple phishing campaigns. Google decided not to fix it, so it might be advisable to block access to the Web Light domain in corporate environments…

If you are already aware of the principles behind “open redirect” vulnerabilities and want jump straight to the discussion of the Web Light vulnerability and its active exploitation, click here. If you are not, let’s first set the stage by discussing what open redirects are and how they may be used by threat actors…

Open redirect – or CWE-601 – is a type of software vulnerability, which affects web applications that redirect its visitors to URLs, that are dynamically created based on user-controlled input, if these applications don’t sufficiently validate whether these URLs are “trusted”. In basic terms, any such vulnerability allows for creation of links, which point to a vulnerable application and which cause it to automatically redirect the browser of a visitor to another (usually any specified) URL.

If the potential impact of such a vulnerability isn’t clear to you, imagine if a web application of a well-known bank running at “www.mybank.tld” redirected visitors to the domain “login.mybank.tld” using a dynamic redirection mechanism, which would accept the target URL through a “redirect_to” parameter. A URL used for this redirection might look like this.

https://www.mymybank.tld/?redirect_to=https://login.mybank.tld

You might wonder why someone would use the above-mentioned “dynamic” approach to redirection instead of using static links. The truth is that there may be certain benefits to doing so this way – probably the most important one being the ability to precisely track “clickthroughs” to different destinations (e.g., for marketing purposes).

In any case, if the redirection mechanism in our example allowed only for limited redirection to URLs within the second-level domain mybank.tld, it would most likely be quite alright from a security standpoint. However, if the mechanism lacked any sort of validation of the target URL, one could easily create a link, which would point to the trusted site of the bank, but which would result in a redirection to an untrusted (and potentially malicious) site… For example a literal “untrusted” site:

https://www.mymybank.tld/?redirect_to=https://untrustednetwork.net

You can probably see the issue – in such a case, any threat actor out there could create a link pointing to the legitimate website of the bank, which would – when opened – result in redirection to a malicious site of their choosing. This could be quite useful for phishing attacks. Since most people only check the beginning of a URL before opening it, if they saw that a link in an e-mail points to a valid domain of the bank, they might be much more willing to click it than if it pointed to a different/unknown domain. And, in fact, threat actors do actively exploit these vulnerabilities in just this way - by redirecting unsuspecting victims to phishing sites through legitimate domains…

As we can see, although open redirects are hardly the most dangerous type of vulnerabilities in existence, they do sometimes pose a not insignificant risk – especially if the affected application is hosted on a well-known and well-trusted domain. This viewpoint is well-supported by the fact that “Unvalidated Redirects and Forwards” were actually included in the 2010 version of OWASP Top 10 (i.e., they were considered by the security community at large to be one of the 10 most significant risks related to web applications at that time).

Nevertheless, since successful exploitation of these vulnerabilities is dependent on social engineering, and their impact is limited, many organizations consider them either very low risk, or non-issues. For some organizations and some domains, this may be understandable, while for others not so much…

One organization, which takes the overall viewpoint that “a small number of properly monitored redirectors offers fairly clear benefits and poses very little practical risk” is Google.

While I personally disagree with the “very little practical risk” part (especially in connection with any domain owned by Google) I completely understand the “clear benefits” portion of the sentence… Though it should be stressed that the “benefits” are not to users of Google services, but to Google itself, since – as we already mentioned – redirection mechanisms are quite useful for marketing-related tracking.

Although I don’t want to appear petty, it is also worth noting that my views on risks connected with open redirects on Google’s domains are shared by its own AI…

That is beside the point, however.

What is important is that even though Google sees “very little practical risk” in open redirection, it has implemented sufficient security measures for most of its services where open redirection is actually used. I.e., some Google services do allow for redirection to arbitrary URLs, however, if these services are linked to from an external source (e.g., an e-mail or a third-party site), then the user is first asked if the redirection should take place. You can see how this looks by opening either of the following links.

https://www.google.com/url?sa=t&url=https://untrustednetwork.net
https://www.youtube.com/redirect?q=https%3A%2F%2Fwww.untrustednetwork.net

While some aspects of the defensive mechanisms that are in place could potentially be improved upon, they generally provide adequate protection from the most common exploitation approaches and techniques. Problem is that not all Google services and domains are secured in this way.

One service, which does not have any similar protection mechanisms in place, is/was named Google Web Light.

It was first introduced in 2015 and provided a way to load web pages faster in Chrome on Android devices. In simple terms, Web Light served as a specialized proxy server, which “optimized” the transmitted content through compression and filtering in such a way, that according to Google, in their experiments, optimized pages loaded four times faster than the original pages and used 80% fewer bytes. For mobile devices of the time, which were connected to the internet through low-bandwidth links (i.e., over 2G), this undoubtedly made significant difference.

Google offered the service for several years (though only in selected countries) before officially retiring the Web Light crawler in December 2022, when it was decided that the service was no longer needed given the increase in general availability of fast mobile internet and more computationally powerful mobile devices.

However, the fact that the Web Light service as a whole was retired didn’t mean that all of its functions suddenly stopped working. In fact, to this day, the Web Light preview functionality is partially available… though it does not function in precisely the same way as it used to.

If one tries to use the preview functionality these days, it does not provide a preview of a web page through the Web Light crawler as it used to – it can’t since the crawler is no longer being used – but rather simply redirects the visitor to the provided target URL using HTTP 301 response… You can probably see where this is going.

Indeed, the redirection mechanism used on https://googleweblight.com/ appears to be completely open and unrestricted, and – unlike YouTube and Google search – does not display any warning that the browser is about to be redirected. You may try this yourself by opening the following link.

https://googleweblight.com/i?u=untrustednetwork.net

How big of a problem is this? Well, it depends on how trustworthy you consider the domain googleweblight.com to be… It certainly isn’t as bad as if the open redirect existed on google.com (though, by the way, there is at least one on that domain as well). Nevertheless, the fact that the domain name begins with “www.google…”, and that the domain is actually registered by Google lends it at least some level of credibility, both when it comes to people seeing a link to it, as well as when such a link is evaluated by automated security solutions.

Threat actors obviously think that is looks trustworthy too, since I have seen the open redirect on googleweblight.com used in two different phishing campaigns just last week…

As you may see, the links in the two phishing messages pointed to the following URLs:

hxxp[:]//googleweblight[.]com/i?u=hxxps[:]//bafybeicrejl4lniju4uumll6zph6fbntlgnarnd22kyijwfqmcltj2icba.ipfs.cf-ipfs[.]com/webmail.html#[e-mail address]

hxxps[:]//googleweblight[.]com/i?u=hxxps[:]//cloudflare-ipfs[.]com/ipfs/bafybeifrl56eni6oixqpdknl6n2fcatl23jvefr4knsrbaut7opquzcyry/#[e-mail address]

Both of these links still work at the time of writing and lead to generic credential-stealing phishing pages. Note that both of them are hosted on IPFS, even if they are accessed through different gateways…

This is far from the first time that the Google Web Light open redirect mechanism was used in a phishing campaign – analysts from Trustwave mentioned seeing it used in 2022, and I myself came across it in a phishing campaign in 2023. Nevertheless, the fact that even with the limited visibility I have, I came across two messages from different campaigns that exploit this vulnerability in a single week would seem to indicate that the use of this redirection mechanism by phishing authors might be becoming more of a mainstream technique, and thus might warrant some response.

I have therefore reported the fact that the open redirect on the Web Light domain exists and is under active exploitation to Google, along with a recommendation for implementing the same defenses there, as they have on their other services. They responded that the open redirect is intended behavior, and that their “position on open redirectors is described in greater detail in this article”. Since it therefore appears that Google’s “Web Light Open Redirection Service”, as I shall call it from now on, will stay with us for at least the foreseeable future, it might be worth thinking about what we may do about it ourselves.

Since the googleweblight.com domain is connected with a retired service and will therefore hardly be used for anything business-relevant in the near future, the most straightforward approach would seem to be to filter out/quarantine any e-mails with links that point to it and/or to completely block access to it. Although the domain will probably never make it to any commercial or publicly available blocklist, since it is registered by Google, and no content hosted on it is actually malicious, nothing is stopping us from manually adding it to any internal blocklists we may be using within our own organizations…

While we’re on the subject, it might be worthwhile to do the same thing with all public IPFS gateways as well. Since IPFS currently has very low (if any) business relevance for most organization, and threat actors use it quite heavily to host phishing pages, this simple step might help us significantly reduce risk connected with untargeted phishing… But we’ll discuss that in more detail another time.