Summary

I found a vulnerability in the popular Shazam application that allowed an attacker to steal the precise location of a user simply by clicking a link! This was probably one of my most underrated vulnerabilities yet - it affected over 100 million users (at the time) and could access device features, protected by app permissions, from a single click of a link. In fact, getting creative it was also possible to make this a zero click vulnerability but unfortunately Apple and Google rejected this vulnerability for any reward under their bounty programs. (don't worry the issue was still resolved)

The report to Shazam's security team was made in December 2018 (3 months after acquisition by Apple). Instead of the expected triage reply I was directed to raise the issue with security@apple.com - after a bit of back and forth the vulnerability was finally fixed on March 26, 2019. It took another 8 months before Apple gave recognition and confirmed this was not eligible under their bug bounty program. Despite having a previous bounty program Apple chose not to pay out and Google's own Google Play Security Rewards Program did not see your location data as a big enough security risk to award a bounty..

The vulnerability affected both Android and iOS devices, this was tracked under CVE-2019-8791 and CVE-2019-8792

Understanding the vulnerability

Shazam uses deeplinks throughout the app as part of its navigation. I found that a particular exported deeplink (which was responsible for loading a website inside an webview) was not validating its parameter, allowing external resources to be in control. This webview included a few javascript interfaces that allowed content to communicate with the Android & iOS API's making it possible to pull back device specific information and the last known precise location of the user.

The deeplink in question is shazam://launchurl?url= The url parameter could either be a website or a script starting with javascript scheme. Once the webview loads, the app would attach a javascript interface called WebViewJavascriptBridge which was accessible under the window object.

After decompiling the mobile app and working out how these interfaces operated I found that this object had 2 primary functions - setMessageHandler and sendMessage.

setMessageHandler was a function that we could override to catch the response of an action requested through the sendMessage function. This function expected a JSON object passed through it containing an additional two parameters; type and data. After some further R&D I was soon able to knock up a small proof of concept:

Proof of concept

An attack flow could look something similar to this

Attack flow

Impact

This brings us on to how powerful this issue really was. With such a simple execution plan, attackers could have de-anonymized it's targets with ease. In the wrong hands, it could be dangerous. In the right hands, criminals who hide online behind a fake alias could be identified. But that turns this privacy issue into an ethical one and hey, I'm just a hacker!

Whilst I do love helping keep the internet a safer space, I normally choose bug bounty programs over vulnerability disclosure programs just for the fact you get rewarded at the end. A little bit disappointed on the no bounty decision given how popular the app is and what could be achieved but I still managed to learn a lot about javascript interfaces at the time which has helped me further down the line.

Any one had a similar experience in the past? Would love to hear - leave your comments below!