FLAG_SECURE and Accessibility Services (a11y)

About four years ago, we first blogged about FLAG_SECURE in Android applications and how it can be used to protect sensitive screens from being captured in screenshots. One of the reasons that prompted our original blog post is the fact that FLAG_SECURE was not intended for security of screenshots but is rather a side effect of DRM.

Since then we have reported the lack of FLAG_SECURE as an issue to multiple Android app vendors. Our most recent blog post was about the fact that Google’s 2FA application (“Google Authenticator”) lacked FLAG_SECURE. We disclosed this specific issue (“Google Authenticator”) because of recent reports of malware attacking such applications using Android’s accessibility services (a11y). Yanick Fratantonio (who had a lot more experience with these services) went through the trouble of putting together a POC, as well as writing a truly excellent blog post about how FLAG_SECURE does NOT protect against attacks using these services.

After reviewing both our research and disclosures published by others, there seem to have been an assumption going around for a while that FLAG_SECURE should protect against such attacks (a11y) but no actual data to back this up. To be clear, FLAG_SECURE should still protect against malware using the MediaProjection API to record video or take screenshots, but it DOES NOT protect against attacks using Android’s accessibility services (a11y).

We amended our earlier posts to make this distinction clear and would like to thank Yanick Fratantonio for bringing this up.

Google Authenticator for Android Allows Screen Capture

Google offers an application for Android called “Google Authenticator” which is used to setup two-factor authentication (2FA). This application is used to generate standard OTP codes usually used for 2FA.

It appears that Google Authenticator allows screenshots to be taken of OTP codes. The implication is that if a user’s device ends up running a rogue app, that app can capture all generated OTP codes as they are shown by the app, and thus break two factor authentication.

[EDITED: 2020-03-23: This is only true for rogue apps with screenshot permissions (MediaProjection) BUT not those using accessibility (a11y) permissions. This is especially true since many such rogue apps use Android accessibility to scrape screenshots from running apps. However, using FLAG_SECURE may prevent that behavior even via accessibility permissions, although more research is needed to confirm that.]

UPDATE (2020-03-03): Disclosed publicly because of recent media reports

UPDATE #2 (2020-03-04): Multiple people noted that Microsoft Authenticator has the same issue. We blogged about that back in 2018 and the issue remains unfixed.

UPDATE #3 (2020-03-23): Although FLAG_SECURE may protect against malicious apps using the MediaProjection APIs, HOWEVER, as per the comment below from Yanick Fratantonio and his blog post, FLAG_SECURE doesn’t protect against attacks using accessibility services. See our follow-up post here.

Steps to Replicate

To replicate, try the following:

  1. Open the application.
  2. Add an account.
  3. Press Power + Volume Down at any sensitive screen and observe a screenshot being taken.

The underlying reason is because the app is not using “FLAG_SECURE” for such screens (more information on FLAG_SECURE can be found in our earlier blog post). By contrast, many Android apps with higher security requirements use it.

Vendor Response

We filed a bug report with the vendor (Google) and the vendor filed an internal bug. The vendor never informed us whether the bug was fixed. Testing on the most recent version reveals that the bug is still present.

Screen Shot 2020-03-03 at 10.00.33 PM

References

  • GitHub issue filed by someone else – see here
  • Google Play link to the app – see here
  • Google Security Case # 8-2193000017345
  • Our earlier blog post about FLAG_SECURE on Android – see here
  • ZDNet report regarding Cerberus malware attacking this app – see here

Timeline

  • 2014-10-10: GitHub issue filed by someone else
  • 2017-05-10: Issue filed with the vendor, triaged and bug filed
  • 2017-05-11: Follow-up discussion regarding other vendor apps
  • 2017-05-12: Response regarding bounty received
  • 2020-02-27: Media story regarding malware targeting this app
  • 2020-03-03: Public disclosure
  • 2020-03-04: Added comment regarding Microsoft Authenticator
  • 2020-03-23: Added clarification regarding screenshot permissions and accessibility permissions

 

NFC Beaming Bypasses Security Controls in Android [CVE-2019-2114]

Summary

NFC beaming of applications between devices using Android OS bypasses some security controls (the “install unknown application” prompt). A rogue device like a payment terminal can use this vulnerability to infect devices with malware.

Affected versions of Android are version 8 (Oreo) and higher. The vendor assigned CVE-2019-2114 to track this issue and released a fix in the October 2019 security bulletin. Users are encouraged to update their devices to mitigate this vulnerability.

Background

Android is an open source operating system developed by Google for mobile phones and tablets. It is estimated that over two billion devices exist worldwide running Android. Most Android devices are restricted in which applications can be installed by users – in particular, they must originate from the Google Play Store. Prior to version 8 (Oreo) a system-wide setting existed in the OS which allowed users to override this control and grant them ability to install applications from any source (“Settings” -> “Security”). In Android 8 (Oreo) this has been changed, and users must grant permission to each application that is trying to perform such install as opposed to a system-wide setting. See example:

Some Android devices support NFC (Near Field Communication) – set of protocols that allow devices to communicate within a very short distance. This is used for applications like contactless payments, pairing of devices and access control. Android devices also support NFC for transferring data between two devices including contracts, photos and applications via a feature called Android Beam.

Vulnerability Details

In Android 8 (Oreo) a new feature was introduced that requires users to opt-in to the “Install unknown apps” permission on a app by app basis. However, it appears that any system application that is signed by Google will be automatically whitelisted and would not prompt the user for this permission. On a standard Android OS device, the NFC service is one such system application that has the permission to install other applications. This means, that an Android phone that has NFC and Android Beam enabled, then touching a malicious phone or a malicious NFC payment terminal to the device may allow malware to be installed by bypassing the “install unknown apps” prompt.

To see these permissions, use any Android phone with NFC and running v8 or higher, go to “Settings”, search for “Install unknown apps” to find the permission. Tap through to view apps, and make sure to select “Show system” in the dropdown menu. You will see that the “NFC Service” is listed as being allowed to install applications by default (since it is a system application). See example:

image

Steps to Replicate

To actually replicate a malicious drive-by install, do the following:

  1. Setup two phones with NFC and Android beam enabled.
  2. Download any APK file on the “sender” phone (something like
    this APK from GitHub).
  3. Go to the file manager in the “sender” phone, tap the file and select “Share”. Then select “Android Beam” as the sharing method,
  4. Bring two phones together and complete the transfer.
  5. After this is done, go to the receiver phone, tap the “Beam completed” notification, and tap the file. It will skip directly to the install prompt, bypassing the “Install unknown apps” check.

Tested on Android 9 and Android 8.10.

Vendor Response and Mitigation

The vendor (Google) classified this issue as High and assigned CVE-2019-2114 to track this issue. A fix was released in the October 2019 security bulletin. Users are encouraged to update their devices to mitigate this vulnerability. After applying the update, users are encouraged to check the “Install unknown apps” permission in settings to make sure the NFC Service is listed as “not allowed” to install applications.

This issue only affects Android version 8 (Oreo) or higher.

References

Android bulletin: October 2019 (2019-10-06)
CVE ID: CVE-2019-2114
Google Bug # 123651515 (Android ID # A-123700348)
Google Blog: Blog post about the changes in the “install unknown apps” permission

Bounty Information

This issue satisfied the requirements of the Android Security Rewards Program and a bounty payment has been paid by the vendor.

Credits

This advisory was written by Y. Shafranovich.

Timeline

2019-01-30: Initial report submitted to the vendor
2019-01-31: Vendor response received – issue under investigation
2019-02-01: Issue rated as High by the vendor
2019-03-02: Checking bug status, vendor communication
2019-04-06: Checking bug status, vendor communication
2019-04-29: Checking bug status, fix is still being worked on
2019-06-29: Checking bug status, vendor communication
2019-07-01: Vendor indicating that a patch is forthcoming, CVE assigned
2019-07-08: Notified vendor about upcoming talk
2019-07-10: Vendor informing that the fix has been delayed by a month
2019-07-28: Draft blog post sent to the vendor for review
2019-07-31: Blog post comments received from the vendor
2019-09-04: Follow-up communication with the vendor
2019-10-07: Fix released
2019-10-24: Public disclosure

Media Coverage

See:

Fixes for CVE-2018-9581 and CVE-2018-9489 in Android 10

Two privacy issues with broadcasts in Android OS are expected to be fixed in Android Q / 10 which will be released in early September of 2019. You can see the details in Google’s security bulletin available here. Some of these fixes were not available for earlier version of Android.

We originally discovered these in the Spring of 2018 and they were disclosed via a talk at BSides DE late last year. Details are available as follows:

 

 

Brief Notes on Gmail for Android and Confidential Mode

Recently Google launched “Confidential Mode” for Gmail which seeks to protect sensitive information from unauthorized access – details here.

Some brief notes:

  • On the web version of Gmail, when replying to a confidential message, the reply is also sent as confidential. However, when using Gmail for Android that is not true – instead you get a warning that the message will not be sent with confidential mode.
  • When viewing confidential mode emails with Gmail for Android, FLAG_SECURE is not used (see our post here). That means other applications on the same device with the screen capture permissions can capture this content as well. This was reported to Google (issue # 112838515) and they do not consider it a security issue.

Upcoming Advisory for an Android OS Vulnerability – CVE-2019-2114

We will be releasing an advisory on a security vulnerability that was reported to the Google, specifically in Android OS. This issue is being tracked under CVE-2019-2114. The advisory is expected to be published later this year once a fix is released by the vendor.

UPDATE: The advisory and fix for this issue have been released – see our blog post here.

Two Bugs in Google Chrome

Summary

Google Chrome has two places (credits pages and default sites) where HTTP links are used instead of HTTPS, which can lead to MITM attacks on a hostile network. The vendor doesn’t consider these to be security bugs and they remain unfixed.

Bug Details – Default Sites

On startup, Chrome for Android displays a search bat and 8 icons of commonly accessed sites. If the browser has not yet collected any history data, those icons default to the ones provided by a Google-hosted service (“https://www.gstatic.com/chrome/ntp/suggested_sites_DEFAULT_5.json“). These default sites are country specific. However, not all of these links use HTTPS – some use HTTP. As the result if a user is on a hostile network and taps any of these sites, the connection can be intercepted by an MITM attacker.

While this issue was seen in Android, it may affect other platforms.

Screenshots:

Screenshot_20171122-215523 Screen Shot 2019-05-27 at 12.37.41 PM

Bug Details – Credits Page

Chrome has a credits page (“chrome://credits“) that contains licensing information and links to various open source projects. Not all of these links use HTTPS, instead some use HTTP. As the result if a user is on a hostile network and taps any of these sites, the connection can be intercepted by an MITM attacker. This can be seen by going to the URL (“chrome://credits“) or going to “Help”, “About”, “Open Source Licenses”.

This impacts all platforms that Chrome supports including Linux, Windows, Android, iOS, MacOS and ChromeOS.

Screenshots:

Screenshot_20190527-123241 Screenshot_20190527-123253  Screenshot_20190527-123307

Vendor Response

The vendor doesn’t consider these to be security bugs and they remain unfixed.

References

Chromium Bugs: 788055 and 927139

Credits

Advisory written by Y. Shafranovich.

Timeline

2017-11-22: Default sites bug (#788055) reported to the vendor
2017-11-23: Initial vendor response (#788055), not considered a security bug
2017-11-23: Vendor response (#788055)
2019-01-30: Credits bug (#927139) reported to the vendor
2019-01-30: Initial vendor response (#927139), not considered a security bug
2019-01-30: Vendor response (#927139)
2019-04-01: Checking with vendor regarding disclosure (#788055)
2019-05-27: Public disclosure for both

Third Party Android App Storing Facebook Data Insecurely (Facebook Data Abuse Program)

Summary

A third-party Android application with Facebook API access was found to be copying user data into storage outside of Facebook, and storing it insecurely in two separate locations. This issue was reported to Facebook via their Data Abuse Bounty program and the insecure storage locations have been secured on November 12th, 2018. The Facebook app associated with this application has been removed from the Facebook platform but the Android application remains available in Google’s Play Store. The number of affected users is unknown. [ADDED: 02/15/2019 – Google has been notified].

Background

In April 2018, FaceBook announced a new Data Abuse Bounty program that rewards “people with first-hand knowledge and proof of cases where a Facebook platform app collects and transfers people’s data to another party to be sold, stolen or used for scams or political influence“.

In September 2018, we found an Android application in the Google Play store that purports to provide additional functionality to Facebook users that is not available through the platform. At the time of writing, the application had more than 1,000,000 downloads. After downloading the application, and examining it using JADX, we found that the application was using Facebook APIs to access data for the logged in user and copying to several storage locations outside of Facebook. Upon further examination, it was clear that at least two of such locations (a Firebase database and an API server) were making this data available without any authentication and without HTTPS. This would allow an attacker to mass download the user data accumulated by the application from its users.

We do not know for sure how many users have been impacted or exposed, but one of the databases accessed contained over 1,000,000 records. [ADDED: 02/15/2019 – The application purported to provide additional statistical information about the logged-in user’s Facebook account. There is a privacy policy within the application but it is ambiguous about the transfer of data].

Issue #1 – Storing user data in an public Firebase database

During our examination of the application, we located a Firebase database that the application was communicating with. The database was configured in test mode, which allowed anonymous public access by visiting the URL of “https://DATABASE.firebaseio.com/.json“. As seen in the attached screenshot, the database contained data obtained from Facebook. Aside from confirming the initial permission issue, we did not access or explore this database any further.

Screenshot:

likulator1

Issue #2 – Storing user data in a non-SSL server without authentication

During our examination of application, it become clear that the server that the application was communicating with, did not use SSL and was being accessed without authentication. As seen below, this would allow an attacker to download the data collected by the application from Facebook via a regular browser as well as spy on any connections between the application and the server. Aside from confirming the initial permission issue, we did not access or explore this database any further.

likulator2

likulator3

Vendor Response and Mitigation

We contacted the Facebook Data Abuse Bounty program but did not contact the vendor directly. After Facebook completed its review, the two insecure locations have been secured on November 12th, 2018. The Facebook app associated with this application has been removed from the Facebook platform but the Android application remains available in Google’s Play Store. [ADDED: 02/15/2019 – Google has been notified].

This discovery qualified under the terms of the Facebook Data Abuse Bounty Program and a bounty payment has been received.

References

Facebook report # 10101718616795015
Google reference # 8-7487000025062

Credits

This advisory was written by Yakov Shafranovich.

Timeline

2018-09-17: Initial report submitted to Facebook, initial response received
2018-11-12: Issued fixed
2018-11-27: Bounty decision received; sent disclosure request
2018-11-30: Facebook asked for additional time before disclosure
2019-01-15: Investigation has been finalized, FaceBook asked for a copy of the disclosure
2019-02-03: Draft disclosure shared for review
2019-02-14: Public Disclosure
2019-02-15: Minor updates; notification sent to Google

Content Injection in Amazon Kindle’s FireOS [CVE-2019-7399]

Summary

The FireOS operating system provided by Amazon for Fire tablet devices can be injected with malicious content by an MITM attacker. An attacker can also capture the serial number of the device. The root cause is lack of HTTPS for legal content (terms of use and privacy policy) within the settings section.

The issue was discovered in FireOS v5.3.6.3 and fixed by the vendor in v5.3.6.4 that was released in November 2018. Devices will automatically update to the latest version. CVE-2019-7399 has been assigned by MITRE to track this issue.

Vulnerability Details

FireOS is an operating system provided by Amazon for the Fire tablet devices.  It is a customized fork of Android. While monitoring network traffic on a test device, we observed that several calls from the settings section (terms of use and privacy policy) are done without HTTPS and can be injected with malicious content by an MITM attacker. It is also possible for the attacker to observe this traffic and capture the serial number (DSN) of the device.

Screenshots of the captured traffic:

Screenshot_2018-09-03-13-11-20 Screenshot_2018-09-03-13-11-26

Steps To Replicate (on Ubuntu 18.04)

1. Install the application on the Android device but do not start it.

2. Install dnsmasq and NGINX on the Linux host:

sudo apt-get install dnsmasq nginx

3. Modify the /etc/hosts file to add the following entry to map the domain name to the Linux host:

192.168.1.x www.kindle.com
192.168.1.x kindle.com

4. Configure /etc/dnsmasq.conf file to listen on the IP and restart DNSMASQ

listen-address=192.168.1.x
sudo /etc/init.d/dnsmasq restart

5. Add a file with malicious content (you may need to use sudo):

cd /var/www/html
mkdir support
echo powned >support/privacy
echo powned >support/terms

6. Modify the settings on the Kindle device to static, set DNS to point to “192.168.1.x”. AT THIS POINT – the Kindle device will resolve DNS against the Linux computer and serve the large servers file

7. Tap “Settings”, “Legal and Compliance”, and tap either “Terms of Use” or “Privacy”. Observe injected content.

Vendor Response and Mitigation

The issue was discovered in FireOS v5.3.6.3 and fixed by the vendor in v5.3.6.4 that was released in November 2018. Devices will automatically update to the latest version. MITRE assigned CVE-2019-7399 to track this issue.

References

Amazon tracking # PO135449968
CVE-ID: CVE-2019-7399

Credits

Text of the advisory written by Yakov Shafranovich.

Timeline

2018-09-03: Initial report to the vendor
2018-09-04: Report triaged and being reviewed by the vendor
2018-09-17: Communication from the vendor, issue still being reviewed
2019-01-10: Fix confirmed, communication regarding disclosure
2019-01-30: Vendor pinged about CVE assignment
2019-02-03: Draft advisory sent for review
2019-02-04: CVE issued by MITRE
2019-02-07: Public disclosure; minor syntax updates

Wickr Me for Android Allowed Screen Capture

Wickr offers a suite of applications which provide secure instant messaging, voice and audio calls. The Android version of Wickr Me Messenger allowed screenshots to be taken by other apps on the device because FLAG_SECURE option wasn’t used.

To replicate, try the following:

  1. Open the application.
  2. Press Power + Volume Down at any sensitive screen and observe a screenshot being taken.

The underlying reason is because the app is not using “FLAG_SECURE” for such screens (more information on FLAG_SECURE can be found in our earlier blog post). By contrast, many Android apps with higher security requirements use it.

Vendor Response and Mitigation

This issue was reported in May 2016 against version 2.6.4.1, and was fixed in September 2018 in version 4.55.1. A bounty has been paid.

References:

  • Google Play Link to the app – see here
  • Our earlier blogpost about FLAG_SECURE on Android – see here