Google Maps open redirect flaw abused by spammers

By | 8:28 AM Leave a Comment

This morning I received a Skype message from a friend that I’d not heard from in quite a while. They didn’t have much to say though, they just sent me a link, out of the blue.

Being a career geek I’m no stranger to no-frills, taciturn, often blunt, communication with my peers… but this was from somebody friendly, somebody who worked in marketing for goodness sake.

There was no way this was legit.

Skype

If you look closely you’ll see that the scammer’s have used Google’s soon-to-be-discontinued URL shortening service, goo.gl.

URL shorteners work by sending your browser through at least one HTTP redirect. They’re an obvious choice for somebody wanting to hide a phishy, scammy or otherwise iffy link because they’re a form of obfuscation that users have been trained to understand and trust.

In this case, the fact that the link comes from somebody you know adds an extra veneer of legitimacy.

Of course Google doesn’t stand for iffy links, so spammy goo.gl URLs are almost as easy to report as they are to create.

Crooks can get around that by using the shortener to redirect to another HTTP redirect, perhaps on a legitimate but compromised domain, before bouncing victims to a not-at-all-trustworthy-looking domain that’s hosting the scam.

With a little help from curl -I, I followed the chain of URL redirects to see where I’d end up.

There were two redirections in the chain before the final you-wouldn’t-click-it-if-you-saw-it Russian URL hosting an English language scam. The scam was the usual breathless guff and faux endorsements – in this case lies about the folks on Shark Tank – trying very, very hard to convince me that a turmeric diet pill can overcome my daily efforts to eat all the biscuits.

Must be some pill.

Much more interesting than the shortener at the start, or the scam at the end, was the URL in the middle of the redirect chain.

It turns out that its URL shortening service isn’t the only way that Google is assisting this scammer unwittingly.

Terminal

Between the legitimate Google URL shortener you’d probably trust, and the Russian URL you probably wouldn’t, the redirection chain bounces you through another Google URL belonging to Google Maps.

The crooks have turned a service designed for shortening and sharing Google Maps URLs into an impromptu redirection service for sharing whatever the heck they like, thanks to an open redirection vulnerability in the maps.app.goo.gl service.

Open redirect vulnerabilities allow attackers to abuse code that’s intended to perform an HTTP redirect to a specific something into code that redirects to anything.

For example, here’s a Google Maps URL that redirects to example.org:

https://maps.app.goo.gl/?link=https%3A%2F%2Fexample.org

Because this isn’t an official Google redirection service there’s no easy-to-use interface where the URLs can be reported.

The scammers also don’t have to risk unmasking themselves in the Google surveillance apparatus when they set up their URLs because they don’t have to use a Google-owned interface or API to do it, they can just concoct them at will.

Open redirects aren’t as dangerous as SQL injection, XSS or CSRF vulnerabilities but they are common, easily avoided and, undoubtedly, useful to crooks.

And not just for obscuring scam URLs.

Just last week I wrote about how open redirects on a multitude of US government websites are being abused to stuff Google Search results pages with links to porn sites.

Open redirects

The lesson for Google is the same as it was for those government websites, and anyone else with code that allows HTTP redirects: Any and all user input should be treated as hostile until it has been checked and sanitised.

To avoid being abused, code that performs redirections should only send users to URLs that match a specific pattern or list of links thought to be OK.

In the case of Google maps that should be simple – if the URL in the link parameter isn’t a Google Map, there’s no reason to allow the redirection.

Google appears to have known about this flaw since September 2017.



from Naked Security https://ift.tt/2w2m2eF

0 comments:

Post a Comment