Cisco just issued an advisory for this a days ago and is also using CVE # CVE-2018-0237 and bug ID CSCve34034 for tracking. We responsible disclosed this issue to them several months ago and the technical details of this issue are available in our earlier blog post.
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.
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:
- Install the application on the device.
- Setup an MITM proxy but do not install the SSL certificate on the device (we used PacketCapture).
- 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.
- Open the app.
- 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:
The vendor fixed this issue and users should install the latest version (3.02 or above).
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.
Advisory written by Yakov Shafranovich.
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
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.
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:
- 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.
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.
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
The issues that were fixed qualified for the Chrome Rewards security bounty program and a bounty has been paid.
Advisory written by Yakov Shafranovich.
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
Compressed files on macOS are autodetected by the operating system even if they are renamed to certain other extensions. This can be used to fool users and antivirus software that relies on file extensions by packaging malicious code inside compressed files with different extensions. The vendor (Apple) does not consider this to be a security issue. Most anti-virus vendors for macOS are not affected by this issue. This was originally discovered in macOS v10.11 (El Capitan) and v10.12 (Sierra), but the latest version of macOS v10.13 (High Sierra) was not tested.
[NOTE: This bug was originally discovered as a result of a different set of bugs in Google’s Chrome browser. While the impact of this particular issue isn’t high, it was interesting enough for us to pursue a coordinated disclosure process. Because of the large number of parties involved, the disclosure coordination process took a long time which is why this article took almost two years to publish.]
On Microsoft Windows, files are identified by their extensions, which appears after the “.” in the filename. On macOS metadata about the file maybe available separately and either a creator code, a type code or a Uniform Type Identifier is used. However, on the Internet (in browsers and email clients) instead of filenames, MIME media types are used with a registry maintained by IANA on behalf of the IETF. Linux systems use a mix of extensions and media types, with some auto-detection / “sniffing” of media types based on file content. Some mappings do exists across the various systems as well.
For example, a ZIP archive would be identified as follows:
- Windows – .zip extension
- Internet/Linux – application/zip media type
- macOS UTI – com.pkware.zip-archive
Additionally, on most desktop OSes, an association exists between a file type and an application that will open it by default. Those associations are maintained differently from OS to OS, but at their core they associate a particular identifier about a file type such as an extension (Windows) or a media type (browsers), and a program assigned to open it by default. Users are used to this arrangement and many security utilities such as antivirus programs will only look inside files that maybe dangerous. For example, a ZIP file on Windows if renamed to a different extension may not necessarily be scanned by default because double clicking on it will not open it.
Another important point is that malware authors may sometimes try to disguise malicious code by compressing it inside an archive such as a ZIP file. The expectation is that when a user downloads it, they will double click and open it using the default program on that platform, and then will execute the malicious code. This is another reason why this functionality deserves a closer look.
The following two things were discovered:
- The compression utility that is part of macOS will open any file extension associated with that program and will try to “sniff” / auto-detect the original file type used. The following file extensions were tested:
- ZIP Files when renamed as:
- .XIP (a Gatekeeper warning will be shown for non-signed files)
- DMG files when renamed as:
- ZIP Files when renamed as:
- The OS itself (macOS) itself will open and execute some file formats even when renamed to a different extension. Gatekeeper protection is not bypassed. The following extensions are affected:
To duplicate the first issue, create a ZIP file containing any content (we used the EICAR test file) and rename to include a file extension as any of the compression formats above for ZIP. (AS, CPGZ, PAX or XIP). Send this file to a macOS computer via USB or email or a link; download and double click. The ZIP file will open correctly. You can also do the same thing but with a DMG file for any of the DMG file formats listed above (DC42, ISO, etc).
To duplicate the second issue, create a PKG file containing some code or take an existing one, rename as .MPKG and transfer to a macOS computer. Double click to execute.
All testing was done in May 2016 on a MacBook Pro running MacOS v10.11.3 (El Capitan), and re-tested again in April 2017 on a MacBook running MacOS v10.12.04 (Sierra). It is unclear whether later versions of MacOS are affected since we did not perform testing on versions past v10.12.04 (Sierra).
There are two issues:
- Human users and anti-malware software are not aware that macOS supports a large number of legacy compression file types and may not be properly looking out for them or scanning them.
- Because of the “sniffing” behavior, it would be trivial for an attacker to package malware inside a well known format like ZIP or DMG rename it to one of these extensions. Anti-virus software may fail to scan such archives because they do not expect a ZIP file to be packaged that way.
The information in this article was originally discovered while analyzing Google’s Chrome browser (details here).
Our recommendations are as follows:
- Apple should consider deprecating or adding a warning for these extensions and removing the “sniffing” support.
- Anti-malware software for macOS should support all of these formats, as well as accounting for the possibility of one format being renamed as another
The vendor (Apple) does not consider this to be a security issue as follows:
After examining your report we do not see any actual security implications. All of the extensions provided in your report are supported disk image formats and will be treated equally.
After examining your report we do not see any actual security implications. Archive Utility opens archive files and the extensions you provided are archive extensions.
After examining your report we do not see any actual security implications. The Installer app makes it clear when executable code is running even if the file has been renamed.
As per advice of Apple’s security team, we also contacted multiple antivirus vendors that provide AV software for macOS to check if they are affected by this issue. Here is what we got back:
Vendors That Responded:
- Avast – not affected
- Avira – not affected
- AVG – related bug for engine versions prior to 4668 has been fixed earlier (see CVE-2017-9977 and our blog post); other products not affected
- BitDefender – not affected
- Cisco – one product impacted, tracked by bug identifier CSCve34034 –
no CVE has been issued– Cisco has issued an advisory and is tracking this under CVE-2018-0237:
- Cisco AMP Virtual Private Cloud Appliance – The Cisco AMP appliance does not rely on the file extension when processing ZIP archives or PKG install packages. However, older versions relied on file extension to detect DMG files and so is susceptible to one of the scan evasion problems described in the advisory. The DMG portion is now fixed in software release 1.4.5.
- ClamXAV (Canimaan Software) – not affected
- Comodo – not affected
- CyberByte – not affected
- Dr. Web – not affected
- ESet – not affected
- F-Secure – not affected
- Intego – not affected
- Kaspersky – not affected
- Malware Bytes – not affected
- Protect Works – not affected
- QuickHeal – not affected
- Sophos – not affected
- Symantec – not affected
- Trend Micro – not affected
- Webroot – not affected
- 360 Total Security – pending
- BullGuard – no response
- EScanAV – no response
- GData – pending
- Google Chrome – safe browsing affected prior to M51 and M52 (see our blog post here)
- MacKeeper – no response
- McAfee – no response
- Panda – no response
- QuikAV – pending
- Total Defense – pending
Apple Product Security Followup Numbers: 638059697, 640528823 and 640528841
Advisory written by Yakov Shafranovich.
2016-03-21: Report # 638059697 submitted
2016-05-04: Reports # 640528823 and 640528841 submitted
2016-05-21: Report # 640528823 rejected
2016-06-22: Report # 638059697 rejected
2016-06-23: Report # 640528841 rejected
2017-03-15: Advisory provided to the vendor for comment
2017-04-23: Retested on macOS Sierra, updated and resent to vendor for comment
2017-04-28: Reply from vendor received
2017-05-01: Retested on a fresh install of macOS Sierra, revised advisory sent to vendor for comment
2017-05-01: Notifications go out to AV vendors
2018-01-24: Second time that notifications go out to AV vendors
2018-02-10: Third and final time that notifications go out to AV vendors
2018-02-10: Final advisory shared with the vendor (Apple) for comment
2018-02-25: Public disclosure
2018-04-23: Updated with the new Cisco advisory and CVE
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.
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:
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:
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.
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.
We would like to thank the vendor for the quick turnaround and fix for this vulnerability. Text of the advisory written by Yakov Shafranovich.
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 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.
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.
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).
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.
This bug qualified for a bounty under the terms of the Google Chrome Rewards bounty program, and a bounty payment has been received.
Advisory written by Yakov Shafranovich.
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
The vulnerability we found in Intel’s Crosswalk toolkit last year (CVE-2016-5672) has been included as a case study in a new book called “Personal Cybersecurity” by Marvin Waschke (Apress: 2017). You can see it here (pp. 186-188).
This was done as an experiment using Google’s Custom Search Engine. This tool provides access to publicly available content that Google indexes from major cloud providers such as AWS, Azure, DropBox, Google Cloud, etc.
More information here: https://wwws.nightwatchcybersecurity.com/tools/
Live example here: https://cse.google.com/cse/publicurl?cx=002972716746423218710:veac6ui3rio
UPDATE: 12/05/2017 – the checkbox to delete media files when deleting chats doesn’t always work. Users are encouraged to delete the WhatsApp directory on the SD card using a file manager to make sure all media files are removed. Facebook has refused to acknowledge this as a security issue and has not plans to fix it.
When dealing with browser security, there is a concept called “the line of death“. This concept means that a user can only trust content that appears within the browser’s address bar or above, and nothing below that line (there is an excellent article from Eric Lawrence who is a Chrome developer explaining this in detail). What that means is that users can click on content above that line safely, but not below since the content appearing below the line may be fake or modified by the attacker. However, it is clear that the rest of the browser UI including menus, settings sections, about box, etc. are static and should be static and safe (unless modified by extensions).
The same concept would apply to mobile apps – part of the UI that are static should be safe as well, although it is harder to tell the static and non static parts apart. This leads add to the issue at hand – what happens when the static parts of the app have hyperlinks that don’t use HTTPS? A user of the app would normally trust those links but if they are on a hostile network, clicking on a plain HTTP link would in fact expose them to a potential MITM attack either via DNS hijacking or MITM interception. That means that if they are using a network where the attacker controls the DNS or the network connection itself, these links can be easily hijacked. You can easily image a scenario, where an attacker blocks WhatsApp or Facebook traffic but redirects users who use the HTTP versions to their own malicious site.
On the other hand, when HTTPS is used for these links, the mobile browser will check if SSL certificates are being served on that link, and whether they are signed by a real CA.