Google patched last month an Android bug that can let hackers spread malware to a nearby phone via a little-known Android OS feature called NFC beaming.
NFC beaming works via an internal Android OS service known as Android Beam. This service allows an Android device to send data such as images, files, videos, or even apps, to another nearby device using NFC (Near-Field Communication) radio waves, as an alternative to WiFi or Bluetooth.
Typically, apps (APK files) sent via NFC beaming are stored on disk and a notification is shown on screen. The notification asks the device owner if he wants to allow the NFC service to install an app from an unknown source.
But, in January this year, a security researcher named Y. Shafranovich discovered that apps sent via NFC beaming on Android 8 (Oreo) or later versions would not show this prompt. Instead, the notification would allow the user to install the app with one tap, without any security warning.
While the lack of one prompt sounds unimportant, this is a major issue in Android’s security model. Android devices aren’t allowed to install apps from “unknown sources” — as anything installed from outside the official Play Store is considered untrusted and unverified.
If users want to install an app from outside the Play Store, they have to visit the “Install apps from unknown sources” section of their Android OS and enable the feature.
Until Android 8, this “Install from unknown sources” option was a system-wide setting, the same for all apps. But, starting with Android 8, Google redesigned this mechanism into an app-based setting.
In modern Android versions, users can visit the “Install unknown apps” section in Android’s security settings, and allow specific apps to install other apps. For example, in the image below, the Chrome and Dropbox Android apps are allowed to install apps, similar to the Play Store app, without being blocked.
The CVE-2019-2114 bug resided in the fact that the Android Beam app was also whitelisted, receiving the same level of trust as the official Play Store app.
Google said this wasn’t meant to happen, as the Android Beam service was never meant as a way to install applications, but merely as a way to transfer data from device to device.
The October 2019 Android patches removed the Android Beam service from the OS whitelist of trusted sources.
However, many millions of users remain at risk. If users have the NFC service and the Android Beam service enabled, a nearby attacker could plant malware (malicious apps) on their phones.
Since there’s no prompt for an install from an unknown source, tapping the notification starts the malicious app’s installation. There’s a danger that many users might misinterpret the message as coming from the Play Store, and install the app, thinking it’s an update.
HOW TO PROTECT YOURSELF
There are good news and bad news. The bad news is that the NFC feature is enabled by default on mostly all newly-sold devices. Many Android smartphone owners may not even be aware that NFC is enabled even right now.
The good news is that NFC connections are initiated only when two devices are put near each other at a distance of 4 cm (1.5 inches) or smaller. This means an attacker needs to get his phone really close to a victim’s, something that may not always be possible.
To stay safe, any user can disable both the NFC feature and the Android Beam service.
If they use their Android phones as access cards, or as a contactless payment solutions, they can leave NFC enabled, but disable the Android Beam service — see image below. This blocks NFC file beaming, but still allows other NFC operations.
So, there’s no need to panic. Just disable Android Beam and NFC if you don’t need them, or update your phone to receive the October 2019 security updates and continue using both NFC and Beam as usual.
A technical report on CVE-2019-2114 is available here.
2019-01-30: Initial report submitted to the vendor
2019-01-31: Vendor response received – issue under investigation
2019-02-01: Issue rated as High by the vendor
2019-03-02: Checking bug status, vendor communication
2019-04-06: Checking bug status, vendor communication
2019-04-29: Checking bug status, fix is still being worked on
2019-06-29: Checking bug status, vendor communication
2019-07-01: Vendor indicating that a patch is forthcoming, CVE assigned
2019-07-08: Notified vendor about upcoming talk
2019-07-10: Vendor informing that the fix has been delayed by a month
2019-07-28: Draft blog post sent to the vendor for review
2019-07-31: Blog post comments received from the vendor
2019-09-04: Follow-up communication with the vendor
2019-10-07: Fix released
2019-10-24: Public disclosure