A couple of weeks ago, I came across a phishing campaign that highlights a recurring issue with open redirect vulnerabilities in well-known and trusted services.

The phishing message that was delivered to us, here at the ISC, was a variation on the “we blocked your account to keep it safe, to unblock it, login at this URL” theme, and it was unremarkable besides the URL associated with the embedded link.

The URL in question was:

hxxps[:]//www.google[.]com/travel/clk?pc=AA80OszwkVHH1Tdfi56QAdQ_qVxXAshiA3B9c5Xj-yHvKSRKOZ_ubTR2ikBZgLobE7ppW5UXflJXGMDLd8l_6VMqW29-pVtc74CE_CVpzmjjwpit_N-vSU8PtmXTZ1FKy2YJIg&pcurl=hxxps[:]//purplepantry.hstn[.]me/limeoggy/?eca=handlers@isc.sans.edu

As you have probably guessed, the issue that we will be discussing today centers on the somewhat obscure /travel/clk endpoint on google.com – a component of the Google Travel ecosystem that, despite being designed for legitimate click-through tracking, can (and, as we can clearly see, does) also serve as a conduit for phishing attacks.

As far as I’ve been able to determine, URLs pointing to google.com/travel/clk are used by Google to redirect users of its “hotel search” service to the reservation website of their choice.

The URLs in question always take the following form:

hxxps[:]//www.google[.]com/travel/clk?pc=[token]&pcurl=[target_URL]

When a user clicks any such link, the browser briefly touches down on /travel/clk before being redirected to the destination specified in 'pcurl'. While this sounds like a standard click tracking mechanism, it also creates an opportunity for abuse.

This is because while one might expect the ‘pc’ parameter to verify both the click and the destination, in practice it only controls whether the redirect occurs at all – it does not constrain where the user is sent in any way. Crucially, the ‘pc’ token also lacks any visible expiration mechanism.

What this means is that today, one could take any valid token from the Google hotel search and use it for weeks or months to redirect users from google.com to any URL of their choice.

In fact, this precise “modus operandi” seems to align with the actions of threat actors, since the same token that was present in the phishing e-mail delivered to us on April 30th was also used in another phishing campaign back in February, which we can be sure of since it was present in a public submission to the Any.Run sandbox on February 26th.[1]

Since the same token still works at the time of writing (as do some others, much older ones, which we will discuss later), we can surmise that these tokens either never expire or that they have an impractically long lifespan, allowing attackers to recycle them across multiple campaigns.

Before we move on, let’s take a closer look at the tokens, since the redirects won’t work without them.

A closer inspection of the token structure reveals that it most likely consists of a 5-byte prefix, followed by a 12-byte nonce and a 16-byte authentication tag – these are traits that are typical of an AES-GCM ciphertext generated by Google’s open-source Tink library.[2] While this cryptographic wrapper likely includes some metadata (perhaps even data that could identify the user to whom the original link from which the token was copied was displayed? If so, this could possibly enable Google to link a misused URL to a specific account…), the lack of an obvious expiration check leaves the door open for repeated exploitation.

Since the value is cryptographically protected, a threat actor probably wouldn’t be able to generate a valid token on their own. Nevertheless, we have shown that obtaining a new token is merely a question of visiting the hotel search page and copying it from a valid link…

Given that this is a trivial step, one could wonder about how long has the misuse of /travel/clk redirect functionality been going on… While we won’t be able to answer this question in this post, we can at least state that it certainly started no later than on August 2nd, 2023, since we have a publicly accessible report on JoeSandbox from that day, in which a URL redirecting to what appears to be an obviously malicious domain was submitted.[3]

It should be mentioned that the token that was used in the URL from 2023 still works to this day, so our assumption of the tokens having either a very long or infinite lifetime seems to be valid…

Unfortunately, this is not the first time Google’s open redirects have been abused. In my last diary, I discussed similar issues with Google’s ad redirect mechanisms[4] and I have previously written about a “partially-open” redirect vulnerabilities in both Google Search[5] and YouTube[6], demonstrating a broader pattern of problematic redirect design across Google’s various platforms.

At this point, one might reasonably ask why Google’s services seem to have an overall “open redirect” issue. We can find an answer of sorts in Google’s official position, as stated in their Bug Hunter guidelines. It states that open redirects “pose very little practical risk”[7]:

“Open redirectors take you from a Google URL to another website chosen by whoever constructed the link. Some members of the security community argue that these redirectors aid phishing, because users may be inclined to trust the mouse hover tooltip on a link and then fail to examine the address bar once the navigation takes place.
Our take on this is that tooltips are not a reliable security indicator, and can be tampered with in many ways. For this reason, we invest in technologies to detect and alert users about phishing and abuse instead. More generally, we hold that a small number of properly monitored redirectors offers fairly clear benefits and poses very little practical risk.”

While claiming ‘it’s not our problem that users consider our domains trustworthy and click links that lead to them without hesitation’ strikes me as antithetical to a security-oriented mindset, I do appreciate Google’s stated commitment to user protection. Nonetheless, the premise that a well-monitored redirector is inherently low-risk is hard to reconcile with the /travel/clk mechanism, where publicly identified tokens remain valid months (or years) after misuse.

Even if the risk was, indeed, low, we could still debate whether a redirector that accepts years-old, publicly flagged tokens is truly “properly monitored”, as Google puts it… But it may just be a case of Google interpreting “monitoring” in a different, much more ephemeral and intangible way than I would.

Whether or not the aforementioned company officially agrees with this, the reality is that open and “partially-open” redirects are more than just a theoretical risk. They are a known and actively exploited vector for phishing, as evidenced by the repeated misuse of Google’s own infrastructure. Until the underlying design changes to enforce tighter token lifetimes or more robust target validation, these redirects will continue to offer attackers a convenient way to piggyback on one of the world’s most trusted domains…

It has been said that it’s easy to criticize, but difficult to offer constructive solutions. And, so that no one accuses me of failing to offer a way out, and so that we end up on a positive note, here are at least two pieces of advice (not just for Google):

• For internal security teams: flag or sandbox any google.com/travel/clk links that appear in e-mail (and other types of messages, if you have that capability), at least until Google clarifies how (or if) it now validates redirects.
• For Google: a short-lived, cryptographically-bound pcurl (or a hard allow-list of trusted partner domains) is hardly a definitive security solution, but it would be easy to implement and it would close the door on the current abuse without breaking your analytical mechanisms.

 

[1] https://any.run/report/e43cb3cbca4898a1549c1e7b07747b0f692e5ee17a084cbc03c441ef0cc95b63/945091e7-f769-4d08-9f93-c2ad21fd5969
[2] https://developers.google.com/tink/wire-format
[3] https://www.joesandbox.com/analysis/1284400/0/html
[4] https://isc.sans.edu/diary/31880
[5] https://untrustednetwork.net/en/2024/02/26/google-open-redirect/
[6] https://untrustednetwork.net/en/2019/07/22/half-open-redirect-vulnerability-in-youtube/
[7] https://bughunters.google.com/learn/invalid-reports/web-platform/navigation/6680364896223232/open-redirectors

-----------
Jan Kopriva
LinkedIn
Nettles Consulting