Microsoft Authenticator for Android Allows Screen Capture

Microsoft offers an application for Android called “Microsoft Authenticator” which is used to setup two-factor authentication (2FA). This application operates in two modes – one allows to generate standard OTP codes like many other apps (Google Authenticator, Authy, etc). The second mode allows a user to register with Azure’s Multi-Factor Authentication (MFA) service, and allows users to authenticate by tapping a prompt on their phone instead of entering an OTP code (similar to Google Prompt).

However, it looks like that the application still allows screenshots to be taken. This is true for setting up the OTP with a manual seed, viewing generated OTP codes, and entering a username + password when setting up Azure MFA. The implication is that if a user’s device ends up running a rogue app, that app can capture the initial OTP seed (if entered manually), the initial username and password for MFA, as well as all generated OTP codes as they are shown by the app, and thus break two factor authentication.

To replicate, try the following:

  1. Open the application.
  2. Setup a new OTP code by adding “other account” + a random seed, and view codes. Alternative, try to sign-up for MFA with a personal account.
  3. Press Power + Volume Down at any sensitive screen and observe a screenshot being taken.

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

Vendor Response

We filed a bug report with the vendor (Microsoft) and here is their response:

Our team assessed the issue, and this does not meet the bar for servicing. We have informed the product team about this issue. MSRC is closing the case.

As for CVE, since there is no fix going for this, we will not be assigning any CVE for this issue.

References:

  • Azure Multi-Factor Authentication – see docs here
  • Google Play Link to the app – see here
  • Google Prompt for Android – see here
  • MSRC Case # 46793
  • Our earlier blogpost about FLAG_SECURE on Android – see here

 

Sensitive Data Exposure via WiFi Broadcasts in Android OS [CVE-2018-9489]

Summary

System broadcasts by Android OS expose information about the user’s device to all applications running on the device. This includes the WiFi network name, BSSID, local IP addresses, DNS server information and the MAC address. Some of this information (MAC address) is no longer available via APIs on Android 6 and higher, and extra permissions are normally required to access the rest of this information. However, by listening to these broadcasts, any application on the device can capture this information thus bypassing any permission checks and existing mitigations.

Because MAC addresses do not change and are tied to hardware, this can be used to uniquely identify and track any Android device even when MAC address randomization is used. The network name and BSSID can be used to geolocate users via a lookup against a database of BSSID such as WiGLE or SkyHook. Other networking information can be used by rogue apps to further explore and attack the local WiFi network.

All versions of Android running on all devices are believed to be affected including forks (such as Amazon’s FireOS for the Kindle). The vendor (Google) fixed these issues in Android P / 9 but does not plan to fix older versions. Users are encouraged to upgrade to Android P / 9 or later. CVE-2018-9489 has been assigned by the vendor to track this issue. Further research is also recommended to determine whether this is being exploited in the wild.

Amazon plans to address this issue as their transition devices to a new version of FireOS.

Background

Android is an open source operating system developed by Google for mobile phones and tablets. It is estimated that over two billion devices exist worldwide running Android. Applications on Android are usually segregated by the OS from each other and the OS itself. However, interaction between processes and/or the OS is still possible via several mechanisms.

In particular, Android provides the use of “Intents” as one of the ways for inter-process communication. A broadcast using an “Intent” allows an application or the OS to send a message system-wide which can be listened to by other applications. While functionality exists to restrict who is allowed to read such messages, application developers often neglect to implement these restrictions properly or mask sensitive data. This leads to a common vulnerability within Android applications where a malicious application running on the same device can spy on and capture messages being broadcast by other applications.

Another security mechanism present in the Android is permissions. These are safeguards designed to protect the privacy of users. Applications must explicitly request access to certain information or features via a special “uses-permission” tag in the application manifest (“AndroidManifest.xml”). Depending on the type of permission (“normal”, “dangerous”, etc”) the OS may display the permission information to the user during installation, or may prompt again during run-time. Some permissions can only be used by system applications and cannot be used by regular developers.

Screenshots of application permissions in Google Play and at run-time:

pic3 pic4 pic6

Vulnerability Details

Android OS broadcasts information about the WiFi connection and the WiFi network interface on a regular basis using two intents: WifiManager’s NETWORK_STATE_CHANGED_ACTION and WifiP2pManager’s WIFI_P2P_THIS_DEVICE_CHANGED_ACTION. This information includes the MAC address of the device, the BSSID and network name of the WiFi access point, and various networking information such as the local IP range, gateway IP and DNS server addresses. This information is available to all applications running on the user’s device.

While applications can also access this information via the WifiManager, this normally requires the “ACCESS_WIFI_STATE” permission in the application manifest. Geolocation via WiFi normally requires the “ACCESS_FINE_LOCATION” or “ACCESS_COARSE_LOCATION” permissions. Also, on Android versions 6.0 and later, the real MAC address of the device is no longer available via APIs and will always return the address “02:00:00:00:00:00”. However, an application listening for system broadcasts does not need these permissions thus allowing this information to be captured without the knowledge of the user and the real MAC address being captured even on Android 6 or higher.

Screenshot of an app trying to obtain MAC address in Android 7.0:

pic7

We performed testing using a test farm of mobile device ranging across multiple types of hardware and Android versions. All devices and versions of Android tested confirmed this behavior, although some some devices do not display the real MAC address in the “NETWORK_STATE_CHANGED_ACTION” intent but they still do within the “WIFI_P2P_THIS_DEVICE_CHANGED_ACTION” intent. We also tested at least one fork (Amazon’s FireOS for the Kindle) and those devices displayed the same behavior.

Because MAC addresses do not change and are tied to hardware, this can be used to uniquely identify and track any Android device even when MAC address randomization is used. The network name and/or BSSID can be used to geolocate users via a lookup against a database like WiGLE or SkyHook. Other networking information can be used by rogue apps to further explore and attack the local WiFi network.

Steps to Replicate by Regular Users

For Android device users, you can replicate these issues as follows:

  1. Install the “Internal Broadcasts Monitor” application developed by Vilius Kraujutis from Google Play.
  2.  Open the application and tap “Start” to monitor broadcasts.
  3.  Observe system broadcasts, specifically “android.net.wifi.STATE_CHANGE” and “android.net.wifi.p2p.THIS_DEVICE_CHANGED”.

Screenshot examples:

pic1  pic2

Steps to Replicate by Developers via Code

To replicate this in code, create a Broadcast receiver and register it to receive these actions (“android.net.wifi.WifiManager.NETWORK_STATE_CHANGED_ACTION” and “android.net.wifi.WifiP2pManager.WIFI_P2P_THIS_DEVICE_CHANGED_ACTION”). Sample code appears below:

public class MainActivity extends Activity {
@Override
public void onCreate(Bundle state) {
    IntentFilter filter = new IntentFilter();        
    filter.addAction(
	android.net.wifi.WifiManager.NETWORK_STATE_CHANGED_ACTION);
    filter.addAction(
	android.net.wifi.WifiP2pManager.WIFI_P2P_THIS_DEVICE_CHANGED_ACTION);
    registerReceiver(receiver, filter);
}
    
BroadcastReceiver receiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
    Log.d(intent.toString());
    ….
}
};

Vendor Response and Mitigation

The vendor (Google) fixed these issues in Android P / 9. Because this would be a breaking API change, the vendor does not plan to fix prior versions of Android. Users are encouraged to upgrade to Android P / 9 or later.

Amazon has responded regarding their Android fork (FireOS) as follows:

We are planning to address the issue as devices transition to the new version of Fire OS

References

Android ID # 77286245
CVE ID: CVE-2018-9489
Google Bug # 77236217
GitHub: Internal Broadcasts Monitor

Credits

We want to thank Vilius Kraujutis for developing the Internal Broadcasts Monitor application and making the source code available in GitHub.

This advisory was written by Yakov Shafranovich.

Timeline

2018-03-28: Initial report submitted to the vendor
2018-03-29: Initial response from the vendor received – issue being investigated
2018-04-03: Follow-up communication with the vendor
2018-04-04: Follow-up communication with the vendor
2018-05-02: Checking on status, response from vendor – issue still under investigation
2018-06-05: Checking status, no response from the vendor
2018-07-01: Checking status, no response from the vendor
2018-07-10: Response from vendor – issue still under investigation; pinged for a timeline
2018-07-12: Pinged the vendor regarding CVE assignment and disclosure plans
2018-07-13: Information about the fix provided by the vendor; follow-up communication
2018-07-14: Additional information provided to the vendor
2018-07-17: Additional information provided to the vendor
2018-07-19: Additional information provided to the vendor, response received
2018-08-09: Fix confirmed
2018-08-16: Initial draft of the advisory provided to the vendor for review
2018-08-21: Follow-up communication with the vendor
2018-08-22: CVE assigned by the vendor, follow-up communication with the vendor
2018-08-23: Final version of the advisory provided to the vendor for review
2018-08-29: Public disclosure / advisory published; added information about Android forks
2018-09-05: Added Amazon’s response

Media Coverage

Gmail for Android Allows Screenshots in Confidential Mode

Google recently added confidential mode for Gmail that allows the sender to restrict how their email gets by the recipients including forbidding printing, etc. However, it looks like that Gmail for android still allows screenshots to be taken for such emails. To replicate, try the following:

  1. Send a confidential email to another Gmail user.
  2. Open the email, press Power + Volume Down. A screenshot will be taken.

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

We did file a bug report with Google and here is their response:

We can not prevent someone from taking a photograph of their phone, using a second camera for example. Preventing taking photos of the content is not part of the feature.

References:
Google bug report # 112838515

Advisory: Crashing Facebook Messenger for Android with an MITM attack

Summary

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

The vendor has no immediate plans to fix this issue.

Vulnerability Details

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

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

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

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

Captured traffic:

test_now

Steps To Replicate (on Ubuntu 18.04)

1. Install the application on the Android device.

2. Install dnsmasq and NGINX on the Linux host:

sudo apt-get install dnsmasq nginx

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

192.168.1.x portal.fb.com

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

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

5. Use mkdir and fallocate to create a large server file in “/var/www/html/” (you may need to use sudo):

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

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

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

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

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

Vendor Response and Mitigation

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

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

References

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

Credits

Text of the advisory written by Yakov Shafranovich.

Timeline

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

Five Tools for Starting Security Analysis of Android Apps

Here are five, easy to use, tools to start security analysis of a Android apps. While they are basic, they allow to do the initial checking for things like lack of SSL, sensitive files, broadcast issues and secrets in code. We also highly recommend buying a cheap Android device for testing instead of/in addition to an emulator.

As always, please obey all relevant laws and do not use these tools for illegal activity.

On-device MITM proxy – PacketCapture

An MITM proxy is used to inspect network traffic going from/to a particular mobile device, or perhaps a specific application on the device. Normally, an MITM proxy requires setting up a separate test machine with the proxy and then pointing traffic from the test device to that machine. However, PacketCapture, is a free and easy to use MITM proxy that runs on the Android device itself, can optionally inspect SSL traffic and can also be selectively applied to a specific app. It lacks the bells and whistles of other proxies, but it is very easy to use. Behind the scenes it works by creating a VPN connection to itself on the device.

One thing to keep in mind: the next version of Android (Android P) will enable TLS by default. Apps can still opt out via a network security policy (see here). Once that changes takes place, you are advised to check the network security policy first before trying this tool.

On-device Broadcasts Monitor – Android Broadcasts Monitor

One of the common pitfalls in Android development is using global broadcasts when exchanging data between different components of the application. Because global broadcasts can be seen by other apps, they can leak sensitive data. An easy way to look for these is to install the Android Broadcasts Monitor app (Google Play link here) which will show you all global broadcasts as they happen.

On-device File Manager

Another useful tool in your toolbox is an on-device file manager. This can be used to check if a particular application leaves any sensitive data on the SD card where it can be accessed by other apps. In particular, you should inspect the “/Android/” directory. We are fans of the Amaze File Manager (source at GitHub) but you can use any other as well.

If you do end up using Amaze, it has a nice feature where you can backup an installed app to the SD card, which allows you to get an APK of an app for further analysis with tools like JADX.

On-device Video Recorder – Telecine

Recording on-device videos comes really useful when making demos or doing bug bounties. One useful tool we use is Telecine by Jake Wharton which can record all screen activity (except FLAG_SECURE). One useful tip is to use “ffmpeg” or a similar tool to downscale the resolution like this example:

ffmpeg -i Telecine_video.mp4 -crf 40 -an final.mp4

Android Decompiler – JADX

JADX is a Java decompiler which can take an Android APK and decompile it back to Java source code. One useful thing this can be used for is to analyze possible secrets that are included in the Android resources (not code). Often, there may be sensitive data that is easier to find instead of searching through source code. The “/strings” and “/raw” folders are usually the best place to start.

Keep in mind that Android uses a custom JVM which is not the same one as normal Java. Therefore things relevant to security like cryptography, SSL connections, etc. do not necessarily behave the same way as in regular JVMs.

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

Summary

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

Details

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

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

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

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

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

Vendor Response

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

Bounty Information

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

References

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

Credits

Advisory written by Yakov Shafranovich.

Timeline

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

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

Summary

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

Details

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

To observe the issue on v3.01:

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

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

Screenshots of captured traffic attached:

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

Vendor Response

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

References

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

Bounty Information

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

Credits

Advisory written by Yakov Shafranovich.

Timeline

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

Multiple Instances of Download Protection Bypass in Google’s Chrome

Summary

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

Background

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

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

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

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

Details

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

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

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

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

These issues were fixed in Chrome M51 and M52.

References

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

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

Bounty Information

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

Credits

Advisory written by Yakov Shafranovich.

Timeline Summary

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

 

Research: Auto-detection of Compressed Files in Apple’s macOS

Summary

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.

Background

[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.

Details

The following two things were discovered:

  1. 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:
      • .AS
      • .CPGZ
      • .PAX
      • .XIP (a Gatekeeper warning will be shown for non-signed files)
    • DMG files when renamed as:
      • .CDR
      • .DART
      • .DC42
      • .DISKCOPY42
      • .DMG
      • .DMGPART
      • .DVDR
      • .IMG
      • .IMGPART
      • .ISO
      • .NDIF
      • .SMI
      • .SPARSEBUNDLE
      • .SPARSEIMAGE
      • .TOAST
      • .UDIF
  2. 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:
    • PKG
    • MPKG

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).

Recommendations

There are two issues:

  1. 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.
  2. 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

Vendor Responses

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

Other Vendors:

  • 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

References

Apple Product Security Followup Numbers: 638059697,  640528823 and 640528841

Cisco Bug # CSCve34034 / CVE # CVE-2018-0237

Credits

Advisory written by Yakov Shafranovich.

Timeline Summary

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