Advisory: Crashing Facebook Messenger for Android with an MITM attack

Summary

Facebook Messenger for Android can be crashed via the application’s status check. This can be exploited by an MITM attacker via intercepting that call and returning a large amount of data. This happens because this status check is not done over SSL and the application did not contain logic for checking if the returned data is very large.

The vendor has no immediate plans to fix this issue.

Vulnerability Details

Facebook Messenger for Android is a messaging application provided by Facebook. While monitoring network traffic of a test device running Android, we observed that the application made network calls for checking server status. This call was done over HTTP without the use of SSL / TLS. Example URL:

http://portal.fb.com/mobile/status.php

We were successful in crashing the application by injecting a large packet because the application doesn’t handle large data coming back correctly and doesn’t use SSL for this call.

It is also important to note this would allow someone to block Messenger from being used but without the users realizing they are being blocked, since they will attribute the app crashing to a bug rather than a block.

Captured traffic:

test_now

Steps To Replicate (on Ubuntu 18.04)

1. Install the application on the Android device.

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 PIA’s domain name to the Linux host:

192.168.1.x portal.fb.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. Use mkdir and fallocate to create a large server file in “/var/www/html/” (you may need to use sudo):

cd /var/www/html
mkdir mobile
cd mobile
fallocate -l 2.5G status.php

6. Setup a WiFi access point and set the DNS server setting on the access point to the Linux computer (“192.168.1.x”)

6. Connect the test device to the access point – Android will resolve now DNS against the Linux computer.

7. Re-open the app and try to activate with a phone number. Observe the crash – note that the application and launcher crashes but not the device itself

All testing was done on v169.0.0.27.76 of the Android application using a Linux host running Ubuntu v18.04 and Android test devices running Android v7 and v8.1.

Vendor Response and Mitigation

The vendor doesn’t consider this to be a security issue and doesn’t have immediate plans to fix it:

After talking to the product team, we’ve determined that the crash is due to OOM and the security risk here is not significant enough to qualify for a bounty. The impact here is a denial of service on very specific users on the attacker’s wifi network, which arguably can be done via other local network attacks which we ultimately cannot control. While we agree that this is a software bug and we may consider making changes in the future to prevent this behavior, this issue does not qualify as a part of our bounty program.

References

CVE-ID: no CVE assigned
CWE: CWE-400 – Uncontrolled Resource Consumption (‘Resource Exhaustion’)

Credits

Text of the advisory written by Yakov Shafranovich.

Timeline

2018-06-05: Initial email to the vendor as part of another issue; POC sent
2018-06-12: Initial report triaged by vendor and sent to product team
2018-06-20: Vendor response received
2018-06-25: Draft advisory provided to vendor for review
2018-07-09: Public disclosure

Android OS Didn’t use FLAG_SECURE for Sensitive Settings [CVE-2017-13243]

Summary

Android OS did not use the FLAG_SECURE flag for sensitive settings, potentially exposing sensitive data to other applications on the same device with the screen capture permissions. The vendor (Google) fixed this issue in 2018-02-01 Pixel security update. Google has assigned CVE-2017-13243 to track this issue.

Details

Android OS is a mobile operating systems for phones and tablets developed by Google. The OS has multiple screens where sensitive information maybe shown such as the device lock screen, passwords in the WiFi settings, pairing codes for Bluetooth, etc.

FLAG_SECURE is a special flag available to Android developers that prevents a particular screen within an application from being seen by other application with screen capture permissions, having screenshots taken by the user, or have the screen captured in the “Recent Apps” portion of Android OS. We have published an extensive post last year discussing this feature is and what it does.

During our testing of various Google mobile applications, we found that the lock screen, password entry screen for WiFi, and the screen for entering pairing codes for Bluetooth devices did not use FLAG_SECURE to prevent other applications for capturing that information. By contrast other Google applications like Android Pay and Google Wallet use this flag to prevent capture of sensitive information. Exploiting this bug requires user cooperation in installing a malicious app and activating the actual screen capture process, thus the likelihood of exploitation is low.

To reproduce:
1. Lock the device, OR go to WiFi settings and try to add a network, or try to pair a Bluetooth device.
2. Press Power and volume down to capture screenshot.
3. Confirm that a screenshot can be taken.

All testing was done on Android 7.1.2, security patch level of May 5th, 2017, on Nexus 6P. Vulnerable versions of Android include: 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2 and 8.0.

Vendor Response

This issue was responsibly reported to the vendor and was fixed in the 2018-02-01 Pixel bulletin. The vendor assigned CVE-2017-13243 to track this issue.

Bounty Information

This issue satisfied the requirements of the Android Security Rewards program and a bounty was paid.

References

Android ID # A-38258991
CVE ID: CVE-2017-13243
CVSS scores: 7.5 (CVSS v3.0) / 5.0 (CVSS v2.0)
Google Bug # 38254822
Google Pixel Bulletin: 2018-02-1

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-05-12: Initial report to the vendor
2017-06-15: Follow-up information sent to the vendor
2017-06-19: Follow-up communication with the vendor
2018-01-02: Vendor communicates plan to patch this issue
2018-01-29: Bounty reward issued
2018-02-01: Vendor publishes a patch for this issue
2018-05-24: Public disclosure / advisory published

Content Injection in Samsung Display Solutions Application for Android [CVE-2018-6019]

Summary

Samsung Display Solutions App for Android did not use encryption (SSL) for information transmission, thus allowing an MITM attacker to inject their own content into the app. The vendor fixed this issue and users should install the latest version (3.02 or above). MITRE has assigned CVE-2018-6019 to track this issue.

Details

Samsung makes an Android application that allows users to browse B2B content related to Samsung’s display products. While performing network level testing, we discovered that the content shown in the app was loaded via server calls made by the application without any kind of encryption (SSL). This allowed an MITM attacker to inject their own content into the app.

To observe the issue on v3.01:

  1. Install the application on the device.
  2. Setup an MITM proxy but do not install the SSL certificate on the device (we used PacketCapture).
  3. Start the proxy. At this point all network traffic will be going through the proxy with the SSL traffic being encrypted by a self-signed certificate which is not trusted by the device.
  4. Open the app.
  5. Go back to the proxy and observe captured traffic.

All testing was done on Android 7 and application version 3.01. Network captures were performed using an on-device proxy (PacketCapture) without a trusted SSL certificate.

Screenshots of captured traffic attached:

Screenshot_20171210-193610 Screenshot_20171210-193622 Screenshot_20171210-193627 Screenshot_20171210-193633

Vendor Response

The vendor fixed this issue and users should install the latest version (3.02 or above).

References

CVE ID: CVE-2018-6019
Google Play Link: Google Play Store

Bounty Information

This issue was originally reported to the Samsung Mobile Security Bounty Program but was deemed to be out of scope. However, after being transferred to the Display Solutions team, this issue qualified for the Samsung TV Bounty Program.

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-09-09: Reported to Samsung Mobile Security bounty program
2017-09-09: Automated response from the vendor received
2017-10-18: Engineer assigned to the issue
2017-11-19: Deemed out of scope; reply sent
2017-11-25: Vendor requests additional information; reply sent
2017-11-27: Issue rejected, public disclosure requested
2017-12-06: Reply from vendor received, additional information requested; reply sent
2017-12-07: Additional information requested by the vendor
2017-12-09: Reply sent with screenshots
2018-01-08: Vendor accepts the issue as in scope, and plans remediation
2018-01-11: Issue transferred to the Samsung TV bounty program
2018-01-14: Fixed version released
2018-01-22: CVE requested and received from MITRE
2018-02-14: Vendor requests confirmation of the fix, fix confirmed and reply sent
2018-02-25: Draft advisory sent to vendor for review; bounty payment received
2018-03-01: Public disclosure

Multiple Instances of Download Protection Bypass in Google’s Chrome

Summary

We have found several instances of files bypassing the download protection offered by Google’s Chrome browser. All of these have been reported to the vendor, and whichever were accepted by the vendor were fixed in Chrome M51 and M52.

Background

The Chrome and Chromium browsers are an open-source based web browser offered by Google. Among it’s features it includes a safety feature that detects unsafe downloads to protect the user. This feature works in multiple ways but is controlled via a file in Chrome’s source code (“download_file_types.asciipb”) which defines several options based on what the file extension of the downloaded files are:

  • Platform/OS
  • What kind of warning to show the user
  • Whether this file type is an archive
  • Whether the file can be opened automatically by clicking on it in the download area
  • Whether a ping get sent back to Google for every download of this type (FULL), some downloads (SAMPLED) or not sent at all. This checksum check is used to check against a server-side blacklist of known bad files.

The Chrome Rewards bug bounty program includes a separate section covering download bypass that was added in March of 2016. To be eligible, it needs to be on a supported platform (MacOS or Windows), be dangerous by being clicked and not send a full ping back to Google. In December of 2016, the scope of this was changed to only include file extensions already in the source code for Chrome.

As part of our testing in scope of this program, we tested all file extensions that are included in a default on MacOS v10.11 (El Capitan)  and Windows 2012 R2 / 7 Enterprise. This advisory lists all of the bypasses that we located, reported to the vendor, and the status of whether they were accepted and fixed, or rejected. Most of these were reported prior to the scope change in December 2016, and included patches whenever feasible.

Details

The following extensions were reported but were rejected as being out of scope and were not fixed:

  • ChromeOS: APK
  • Linux: AFM, PFA, TIF
  • MacOS: APP, CONFIGPROFILE, DFONT, ICC, INTERNETCONNECT, MOBILECONFIG, NETWORKCONNECT, OTF, PREFPANE, PROVISIONPROFILE, QTZ, SAFARIEXTZ, SAVER, TTF, WEBBOOKMARK, WEBLOC
  • Windows: CAMP, CDMP, DESKTHEMEPACK, DIAGCAB, DIAGPKG, GMMP, ICC, IMESX, MOV, MSU, OTF, PFB, PFM, PRF, RAT, QDS, QT, RDP, SEARCH-MS, THEMEPACK, THEMES, TTC, TTF, WCX

The following extensions were reported, confirmed to be dangerous and fixed, all on MacOS (the underlying issue has been described in a separate blog post here).

  • AS, CDR, CPGZ, DART, DC42, DISKCOPY42, DMGPART, DVDR, IMG, IMGPART, ISO, MPKG, NDIF, PAX, SMI, SPARSEBUNDLE, SPARSEIMAGE, TOAST, UDIF, XIP

These issues were fixed in Chrome M51 and M52.

References

Chrome Bug Reports (rejected): 671382, 671385, 624224, 596342, 605386, 601255, 601250, 600910, 600615, 600609, 600606, 600601, 600597, 600592, 600590, 600587, 600581, 599880

Chrome Bug Reports (fixed): 596354, 600613, 600907, 600908

Bounty Information

The issues that were fixed qualified for the Chrome Rewards security bounty program and a bounty has been paid.

Credits

Advisory written by Yakov Shafranovich.

Timeline Summary

2016-03-20: First report submitted
2016-03 to 2016-12: multiple other reports submitted, and fixed applied
2016-12-06: Last report submitted
2018-02-26: Public disclosure

 

RCE in DuoLingo’s TinyCards App for Android [CVE-2017-16905]

Summary

The TinyCards Android application provided by DuoLingo can be injected with malicious content by an MITM attacker. Because this application is a web-app framed in an Android WebView, this can lead directly to remote code execution (RCE) within the app. The root cause is lack of SSL being used on app startup when the initial web content is loaded into the WebView.

The vendor has fixed this issue in v1.0 (version code 10) that was released via Google Play Store on November 20th, 2017 and users should install the latest version. MITRE has assigned # CVE-2017-16905 to track this issue.

Vulnerability Details

TinyCards is a flashcard application for preparing for tests and memorizing vocabulary. It is made by DuoLingo, which provides a platform for learning new languages. While monitoring network traffic of a test device running Android, we observed that during application startup an initial HTTP call is made to a non-HTTPS site, which then redirects to an HTTPS version. Further research into the application revealed that the application is essentially a thin browser wrapper using Android’s WebView around a web application loaded remotely.

Because the initial call is done without HTTPS, it is possible for an MITM attacker to intercept this traffic and inject their own content.  Since this is a web app, this can result in remote code execution within the application since all the content is web based.

Screenshots of the captured traffic and relevant source code:

screenshot1screenshot2

Steps To Replicate (on Ubuntu 17.10)

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 tinycards.duolingo.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
echo powned >index.html

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

7. Open the app on the Android device and observe injected content.

All testing was done on v1.0 (version code 9)  of the Android application using a Linux host running Ubuntu v17.10 and Android test device running Android v7.

Vendor Response and Mitigation

To fix this issue, the vendor has changed the initial URL for web content being loaded within the app to use SSL. The vendor has fixed this issue in v1.0 (version code 10) that was released via Google Play Store on November 20th, 2017 and users should install the latest version.

Bounty Information

DuoLingo doesn’t currently offer bounties, however, this bug has fulfilled the requirements of Google Play Security Reward Program and a bounty has been paid from that program.

References

CVE-ID: CVE-2017-16905
HackerOne Reports: 281605 (DuoLingo) and 293444 (Google Play Rewards)

Credits

We would like to thank the vendor for the quick turnaround and fix for this  vulnerability. Text of the advisory written by Yakov Shafranovich.

Timeline

2017-10-21: Report opened with the vendor via HackerOne to clarify scope
2017-11-06: Technical details of vulnerability provided to the vendor via HackerOne
2017-11-07: Report triaged and being reviewed by the vendor
2017-11-20: Vendor patched the issue and asked for testing of the fix
2017-11-20: Fix confirmed, communication regarding disclosure
2017-11-28: Report submitted to Google’s Play Rewards program via HackerOne
2017-11-29: Rejection received due to scope, follow-up communication with Google regarding scope
2017-12-04: Follow-up conversation about disclosure with Google and the vendor
2017-12-05: Disclosure requested from DuoLingo via HackerOne
2018-01-04: Public disclosure on HackerOne, and publication of this advisory

ChromeOS Doesn’t Always Use SSL During Startup [CVE-2017-15397]

Summary

ChromeOS did not use SSL in all network calls originating from the ChromeVox component during startup. This could potentially have allowed an MITM attacker to inject content into ChromeOS or crash the device. The vendor (Google) fixed this issue in Chrome M62. Google has assigned CVE-2017-15397 to track this issue.

Details

ChromeOS is the operating system developed by Google that runs on ChromeBook devices. It is build on top of Linux and around the Chrome browser.

By monitoring network traffic using a proxy we noticed that some network calls originating from the ChromeVox component did not use SSL. These calls occured during the startup process before a user logged in. Because these calls did not use SSL, it would be possible for an MITM attacker, in theory, to either inject their own content into ChromeOS, or crash the device by sending a very large packet. We did not conduct any follow-up testing to confirm either of these two possibilities.

To reproduce:
1. Setup a proxy with WiFi.
2. Switch ChromeOS device to use proxy.
3. Restart the device and on the login screen enable ChromeVox.
4. Observe calls to HTTP without SSL.

All testing was done on an Acer ChromeBook, running Chrome version 51.0.2704.106 *stable) and ChromeOS version 8172.62.0 (stable).

Vendor Response

This issue was responsibly reported to the vendor via the Chromium bug tracker. The vendor fixed this issue in ChromeOS release M62 and assigned CVE-2017-15397 to track it.

References

CVE ID: CVE-2017-15397
Chromium Bug # 627300

Bounty Information

This bug qualified for a bounty under the terms of the Google Chrome Rewards bounty program, and a bounty payment has been received.

Credits

Advisory written by Yakov Shafranovich.

Timeline

2016-07-12: Initial report to the vendor
2017-09-18: Issue patched by the vendor
2017-10-26: CVE assigned by the vendor
2018-01-01: Public disclosure

Advisory: Private Internet Access (PIA) Android App Can Be Crashed via Large Download [CVE-2017-15882]

Summary

The Android application provided by Private Internet Access (PIA) VPN service can be crashed by downloading a large file containing a list of current VPN servers. This can be exploited by an MITM attacker via intercepting and replacing this file. While the file is digitally signed, it is not served over SSL and the application did not contain logic for checking if the provided file is very large.

The vendor has fixed this issue in v1.3.3.1 and users should install the latest version. MITRE has assigned # CVE-2017-15882 to track this issue.

Vulnerability Details

Private Internet Access (PIA) is a commercial VPN service operated by London Trust Media, Inc.  The vendor provides a privacy service to encrypt Internet connections via VPN tunnels and have them terminate on anonymous IP addresses. PIA provides official clients for multiple operating systems including Windows, Chrome, macOS, Linux, iOS and Android.

While monitoring network traffic of a test device running Android, we observed that the official PIA Android client application downloaded from the Google Play store made network calls to a PIA server to retrieve a list of current VPN servers in JSON format. This call was done over HTTP without the use of SSL / TLS. However, the resulting server file was digitally signed via a base-64 encoded signature appearing on the bottom of the file. Example URL:

https://www.privateinternetaccess.com/vpninfo/servers?version=60&os=android

File layout:

[JSON packet with server info]
[newline]
[Base-64 encoded signature]

Because the file download is done without SSL / TLS, it is possible for an MITM attacker to intercept this traffic and inject their own data.  If the data packet is larger than the memory on the device, the application will crash since it did not include a size check to avoid large downloads.

Because of the digital signature, we were not able to modify the actual server data within the JSON packet but we were successful in crashing the application by injecting a large packet.

Steps To Replicate (on Ubuntu 17.10)

1. Install the PIA application on the Android device, sign up for an account and login via the application. DO NOT activate the VPN. Flick away the app.

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 PIA’s domain name to the Linux host:

192.168.1.x www.privateinternetaccess.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. Use mkdir and fallocate to create a large server file in “/var/www/html/” (you may need to use sudo):

cd /var/www/html
mkdir vpninfo
cd vpninfo
fallocate -l 2.5G servers

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

7. Re-open the PIA app and observe the crash.

All testing was done on v1.3.3 of the Android application using a Linux host running Ubuntu v17.10 and Android test devices running Android v7 and v8.

Vendor Response and Mitigation

To fix this issue, the vendor (London Trust Media / PIA) had added a size check when downloading and processing the file containing a list of VPN servers. This fix is available in v1.3.3.1 or later, and has been deployed to the Google Play store. Users should install the latest version to fix this issue.

Bounty Information

This bug has fulfilled the requirements of the vendor’s bounty program and a bounty has been paid.

References

CVE-ID: CVE-2017-15882
CWE: CWE-400 – Uncontrolled Resource Consumption (‘Resource Exhaustion’)

Credits

We would like to thank the vendor for the quick turnaround and fix for this  vulnerability. Text of the advisory written by Yakov Shafranovich.

Timeline

2017-10-03: Email sent to support about the process for reporting security issues because we were not aware of their disclosure guidelines
2017-10-18: Initial reply from the vendor asking for more information
2017-10-18: Information about vulnerability provided to the vendor
2017-10-20: Follow-up communication with the vendor confirming the vulnerability in the latest version; vendor acknowledgement of the vulnerability
2017-10-21: Follow up communication with the vendor
2017-10-22: Fixed version provided by the vendor for testing; fix confirmed
2017-10-23: Bounty payment received
2017-10-24: Follow-up communication regarding public disclosure; fixed version deployed to the app store
2017-10-24: Draft advisory provided to vendor for review
2017-10-25: Public disclosure

Zoho Site24x7 Mobile Network Poller for Android Didn’t Properly Validate SSL [CVE-2017-14582]

Summary

Zoho Site24x7 Mobile Network Poller for Android did not properly validate SSL certificates, and accepted self-signed certificates. This can potentially result in exposure of sensitive data including usernames and passwords to an MITM attacker. The vendor fixed this issue and users should install the latest version (1.1.5 or above). MITRE has assigned CVE-2017-14582 to track this issue.

Details

Zoho Corporation is a SAAS provider of business applications including a service called Site 24×7 for monitoring uptime of websites. As part of this service, the vendor makes available an Android application that can act as a mobile poller to monitor and feed data into the Site 24×7 service. This application requires a Zoho account to use it.

While performing network level testing, we discovered that the calls made by the application to the server during login did not properly validate SSL and accepted self-signed certificates. This potentially exposed the usernames and passwords of those using the app to an MITM attacker.

To replicate the issue on v1.1.4:

  1. Install the application on the device.
  2. Setup an MITM proxy but do not install the SSL certificate on the device (we used PacketCapture).
  3. Start the proxy. At this point all network traffic will be going through the proxy with the SSL traffic being encrypted by a self-signed certificate which is not trusted by the device.
  4. Go back to the app, and try to login.
  5. Flick away the application.
  6. Go back to the proxy and observe captured traffic.

All testing was done on Android 7 and application version 1.1.4. Network captures were performed using an on-device proxy (PacketCapture) without a trusted SSL certificate.

Screenshots appear below:

screen1    screen2

Vendor Response

The issue was reported to the vendor via their bug bounty program. The vendor fixed the issue in v1.1.5 and released the fixed application in Google Play.

References

CVE ID: CVE-2017-14582
Google Play Link: Google Play Store
Zoho Bug Reference # ZVE-2017-0879

Bounty Information

This bug satisfied the requirements of the Zoho Bounty program and a bounty payment is pending.

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-09-10: Initial report to the vendor
2017-09-18: Vendor is working on a fix
2017-09-20: Fixed version released to the Play store
2017-09-20: Re-test on the fixed version
2017-09-23: Request for publication sent
2017-09-27: Request for publication granted
2017-09-27: Public disclosure