In today’s digitally-connected society, smartphones have become an extension of us. Advanced camera and video capabilities in particular are playing a massive role in this, as users are able to quickly take out their phones and capture any moment in real-time with the simple click of a button. However, this presents a double-edged sword as these mobile devices are constantly collecting, storing, and sharing various types of data – with and without our knowing – making our devices goldmines for attackers.
In order to better understand how smartphone cameras may be opening users up to privacy risks, the Checkmarx Security Research Team cracked into the applications themselves that control these cameras to identify potential abuse scenarios. Having a Google Pixel 2 XL and Pixel 3 on-hand, our team began researching the Google Camera app [1], ultimately finding multiple concerning vulnerabilities stemming from permission bypass issues. After further digging, we also found that these same vulnerabilities impact the camera apps of other smartphone vendors in the Android ecosystem – namely Samsung – presenting significant implications to hundreds-of-millions of smartphone users.
In this blog, we’ll explain the vulnerabilities discovered (CVE-2019-2234), provide details of how they were exploited, explain the consequences, and note how users can safeguard their devices. This blog is also accompanied by a proof-of-concept (PoC) video, as well as a technical report of the findings that were shared with Google, Samsung, and other Android-based smartphone OEMs.
Google & Samsung Camera Vulnerabilities
After a detailed analysis of the Google Camera app, our team found that by manipulating specific actions and intents [2], an attacker can control the app to take photos and/or record videos through a rogue application that has no permissions to do so. Additionally, we found that certain attack scenarios enable malicious actors to circumvent various storage permission policies, giving them access to stored videos and photos, as well as GPS metadata embedded in photos, to locate the user by taking a photo or video and parsing the proper EXIF data [3]. This same technique also applied to Samsung’s Camera app.
In doing so, our researchers determined a way to enable a rogue application to force the camera apps to take photos and record video, even if the phone is locked or the screen is turned off. Our researchers could do the same even when a user was is in the middle of a voice call.
The Implications
The ability for an application to retrieve input from the camera, microphone, and GPS location is considered highly invasive by Google themselves. As a result, AOSP created a specific set of permissions that an application must request from the user. Since this was the case, Checkmarx researchers designed an attack scenario that circumvents this permission policy by abusing the Google Camera app itself, forcing it to do the work on behalf of the attacker.
It is known that Android camera applications usually store their photos and videos on the SD card. Since photos and videos are sensitive user information, in order for an application to access them, it needs special permissions: storage permissions. Unfortunately, storage permissions are very broad and these permissions give access to the entire SD card. There are a large number of applications, with legitimate use-cases, that request access to this storage, yet have no special interest in photos or videos. In fact, it’s one of the most common requested permissions observed.
This means that a rogue application can take photos and/or videos without specific camera permissions, and it only needs storage permissions to take things a step further and fetch photos and videos after being taken. Additionally, if the location is enabled in the camera app, the rogue application also has a way to access the current GPS position of the phone and user.
Of course, a video also contains sound. It was interesting to prove that a video could be initiated during a voice call. We could easily record the receiver’s voice during the call and we could record the caller’s voice as well.
A PoC of a Worst-Case Scenario
To properly demonstrate how dangerous this could be for Android users, our research team designed and implemented a proof-of-concept app that doesn’t require any special permission beyond the basic storage permission. Simulating an advanced attacker, the PoC had two working parts: the client-part that represents a malicious app running on an Android device, and a server-part that represents an attacker’s command-and-control (C&C) server.
The malicious app we designed for the demonstration was nothing more than a mockup weather app that could have been malicious by design. When the client starts the app, it essentially creates a persistent connection back to the C&C server and waits for commands and instructions from the attacker, who is operating the C&C server’s console from anywhere in the world. Even closing the app does not terminate the persistent connection.
The operator of the C&C console can see which devices are connected to it, and perform the following actions (among others):
- Take a photo on the victim’s phone and upload (retrieve) it to the C&C server
- Record a video on the victim’s phone and upload (retrieve) it to the C&C server
- Parse all of the latest photos for GPS tags and locate the phone on a global map
- Operate in stealth mode whereby the phone is silenced while taking photos and recording videos
- Wait for a voice call and automatically record:
- Video from the victim’s side
- Audio from both sides of the conversation
Note: The wait for a voice call was implemented via the phone’s proximity sensor that can sense when the phone is held to the victim’s ear. A video of successfully exploiting the vulnerabilities was taken by our research team and can be viewed here. Our team tested both versions of Pixel (2 XL / 3) in our research labs and confirmed that the vulnerabilities are relevant to all Google phone models.
Android Vulnerability: Watch the Explainer Video
Summary of Disclosure and Events
When the vulnerabilities were first discovered, our research team ensured that they could reproduce the process of easily exploiting them. Once that was confirmed, the Checkmarx research team responsibly notified Google of their findings.
Working directly with Google, they notified our research team and confirmed our suspicion that the vulnerabilities were not specific to the Pixel product line. Google informed our research team that the impact was much greater and extended into the broader Android ecosystem, with additional vendors such as Samsung acknowledging that these flaws also impact their Camera apps, and began taking mitigating steps.
Google’s Response
“We appreciate Checkmarx bringing this to our attention and working with Google and Android partners to coordinate disclosure. The issue was addressed on impacted Google devices via a Play Store update to the Google Camera Application in July 2019. A patch has also been made available to all partners.”
Mitigation Recommendation
For proper mitigation and as a general best practice, ensure you update all applications on your device.
Timeline of Disclosure
- Jul 4, 2019 – Submitted a vulnerability report to Android’s Security team at Google
- Jul 4, 2019 – Google confirmed receiving the report
- Jul 4, 2019 – A PoC “malicious app” was sent to Google
- Jul 5, 2019 – A PoC video of an attack scenario was sent to Google
- Jul 13, 2019 – Google set the severity of the finding as “Moderate”
- Jul 18, 2019 – Sent further feedback to Google
- Jul 23, 2019 – Google raised the severity of the finding to “High”
- Aug 1, 2019 – Google confirms our suspicion that the vulnerabilities may affect other Android smartphone vendors and issues CVE-2019-2234
- Aug 18, 2019 – Multiple vendors were contacted regarding the vulnerabilities
- Aug 29, 2019 – Samsung confirmed they are affected
- Nov 2019 – Both Google and Samsung approved the publication
Note: This publication was coordinated with Google and Samsung after their confirmation of a fix being released. Please refer to Google for information regarding the fixed version of the Android OS and Google Camera app.
Final Words
The professionalism shown by both Google and Samsung does not go unnoticed. Both were a pleasure to work with due to their responsiveness, thoroughness, and timeliness.
This type of research activity is part of our ongoing efforts to drive the necessary changes in software security practices among vendors that manufacture consumer-based smartphones and IoT devices, while bringing more security awareness amid the consumers who purchase and use them. Protecting privacy of consumers must be a priority for all of us in today’s increasingly connected world.
References
[1] https://en.wikipedia.org/wiki/Google_Camera
[2] https://developer.android.com/guide/components/intents-filters
[3] https://en.wikipedia.org/wiki/Exif