Introduction
Security Aspects of Android
Android is a privilege-separated operating system, in which each application runs with a distinct system identity (Linux user ID and group ID). Parts of the system are also separated into distinct identities. Linux isolates applications from each other and from the system. Additional finer- grained security features are provided through a "permission" mechanism that enforces restrictions on the specific operations that a particular process can perform, and per-URI permissions for granting ad-hoc access to specific pieces of data. A central design point of the Android security architecture is that no application, by default, has permission to perform any operations that would adversely impact other applications, the operating system, or the user. This includes reading or writing the user's private data (such as contacts or e- mails), reading or writing another application's files, performing network access, keeping the device awake, etc. Because Android sandboxes applications from each other, applications must explicitly share resources and data. They do this by declaring the permissions they need for additional capabilities not provided by the basic sandbox. Applications statically declare the permissions they require, and the Android system prompts the user for consent at the time the application is installed. The application sandbox does not depend on the technology used to build an application. In particular the Dalvik VM is not a security boundary, and any app can run native code (see the Android NDK). All types of applications—Java, native, and hybrid—are sand-boxed in the same way and have the same degree of security from each other.Executive Summary
This report details a vulnerability submitted to Google about the Tags application (app), shipped with the Android OS that is responsible for reading NFC (Near Field Communication) tags, parsing them, and forwarding the results to the relevant application according to its contents. This vulnerability, with CVE-2019-9295 assigned, allows for a rogue application to trick the Tags app into thinking a new NFC tag was just read. It then shows the user a list of actions they can perform with the tags, so the user has to always interact with the app, which is not ideal from an attacker perspective. There are some scenarios where user interaction is not a problem, in fact, it is actually expected like it would be, explained in the attack scenarios. While not a critical vulnerability, this is still something that Android OS users - particularly ones not yet operating on Android 10 yet - should be aware of since the different behaviors for different tags cannot be predicted in the future, which might introduce more serious bugs. According to Google, “As a moderate-severity issue, this vulnerability was addressed in Android 10 only; the fix was not backported to prior versions of Android.” This type of research activity is part of the Checkmarx Security Research Team’s ongoing efforts to drive the necessary changes in software security practices among organizations who develop consumer-based products while bringing more security awareness amid the consumers who use them. Protecting privacy of consumers must be a priority for all of us in today’s increasingly-connected world.Use cases and attack scenarios
In this section, a practical use case is given for the different vulnerabilities found. Sometimes it’s not just about the CVSS score. In some cases, the way a vulnerability can be used or chained augment its real value and usage in the real world.False Tag
This vulnerability allows a malicious app to simulate the receiving of an NFC tag, as if the victim's phone has just read a tag. It can simulate any type of tags (more exactly an NDEF Record), for example, a URI with a telephone number – tel:123456789. The drawback from an attacker's perspective is that the user has to interact and click on the shown tag in order to take the corresponding action. In the case of the previous URI, the user would have to click on the screen so that the call is placed.
Spoofed Tag
To make things less “phishy”, an application was developed that can spoof tags that have been read. The app registers to listen for specific actions, like android.nfc.action.NDEF_DISCOVERED via an intent filter. When a user actually tries to read an NFC tag, the malicious app reads the tag, changes its contents and then calls the default Android Tag viewer. In this scenario, the user is actually expecting to take action after the card has been read, so they have no reason to suspect foul-play. Default Behavior: With malicious app installed:

Caveats
This spoofing method is not without caveats. There is a reason to show the phone number tag and not, let’s say, a URL tag. In a Samsung S8, for example, if we registered an application to receive URL-containing tags, and the user scanned for a NFC card containing a URL, the following screen would appear:
- ACTION_NDEF_DISCOVERED
- ACTION_TECH_DISCOVERED
- ACTION_TAG_DISCOVERED
The NFC Tools Android app is a good place to start searching for tag types:

These are just some examples, there are more types of NFC tags supported.
Research results
com.android.apps.tag
The default app that handles new NFC tags in the android operating system is the Tag Viewer, in the package com.android.apps.tags.Information

TagViewer.java



NdefMessageParser.java

Conclusion
In summary, there are two main attack scenarios:- A popup window that could randomly appear alerting the user that an NFC tag was scanned (generated by a rogue app). The user has to interact with it to choose an application to deal with the
- The user scans a real The rogue app can intercept and change the content of the tag before it is handled by the default OS app. Example: A user scans a tag of a business that contains a phone number. The rogue app can change the phone number to another one on the fly, and the user has no way to know it was altered (except by scanning the tag in an 'uninfected' phone).