NFC SECURITY ON ANDROID DEVICES
by
MATTHEW QUINLAN
Advisor
DR. ELAARAG
A senior research paper submitted in partial fulfillment of the requirements
for the degree of Bachelor of Science
in the Department of Mathematics and Computer Science
in the College of Arts and Science
at Stetson University
DeLand, Florida
Spring Term
2013
1
TABLE OF CONTENTS
TABLE OF CONTENTS .................................................................................................... 1
LIST OF FIGURES ............................................................................................................ 3
ABSTRACT ........................................................................................................................ 4
1. INTRODUCTION .................................................................................................. 5
2. Related Work .......................................................................................................... 7
3. NFC ....................................................................................................................... 10
3.1 NFC PROTOCOLS ............................................................................................. 11
3.2 NDEF FORMAT .................................................................................................. 13
4. NFC SECURITY ON ANDROID DEVICES ...................................................... 16
4.1 NFC ATTACKS ................................................................................................... 16
4.2 SECURE ELEMENT............................................................................................ 20
4.3 CLONING............................................................................................................. 22
4.4 COMMUNICATION ............................................................................................ 23
5. FUZZING ANDROID’S NFC STACK................................................................ 26
5.1 PROTOCOL LAYER FUZZING ......................................................................... 28
5.2 APPLICATION LAYER FUZZING .................................................................... 29
6. IMPLEMENTATION ........................................................................................... 30
2
6.1 NFC Lab Setup ..................................................................................................... 31
6.2 TEST CASE GENERATION ............................................................................... 32
6.3 PROTOCOL LAYER FUZZING ......................................................................... 34
6.4 APPLICATION LAYER FUZZING .................................................................... 36
7. FUZZING RESULTS ........................................................................................... 39
8. CONCLUSION ..................................................................................................... 40
APPENDIX ....................................................................................................................... 42
FUTURE RESEARCH ..................................................................................................... 43
REFERENCES ................................................................................................................. 44
3
LIST OF FIGURES
Figure 1: NFC Protocol Stack………………………………………………………….. 3.1
Figure 2: Sample NDEF Smart Poster Tag……………………………………………. 3.2
Figure 3: NFC attack surface if NFC can communicate with browser…………………... 5
Figure 4: Galaxy S 3, ACR-122U, and SCL-3711 card reader/writer/emulator………. 5.1
Figure 5: Smart Poster Fuzzing Example using Sulley Fuzzing Framework…………...6.2
Figure 6: Bluetooth Fuzzing Example using Sulley Fuzzing Framework………………6.4
Table 1: Sulley Fuzzing Framework Smart Poster Fuzzing Example ………………….6.3
Table 2: NDEF Message Test Cases………………….....................................................6.4
4
ABSTRACT
In this paper we investigate the impact that the addition of NFC technology has
had on Android mobile devices. We explore the NFC specifications and their inner-
workings. We investigate new attack vectors created by NFC, show real-world case
studies of attackers utilizing attack vectors, and we provide solutions or mitigations to
help reduce these attacks. Researchers have shown that NFC-enabled mobile devices are
prone to various flaws in their NFC stack implementation. We discuss the NFC stack’s
implementation on Android phones and also the changes that it has undergone on newer
versions of Android. Next we will talk about the process of fuzzing the NFC stack on
Android to find various errors and bugs. These flaws in the NFC stack have shown to
result in compromised user data or attackers gaining remote control of the mobile device.
For this research, we implemented two test case generation scripts that utilize the Sulley
Fuzzing Framework to generate/fuzz NDEF test cases. In addition, we have implemented
two python scripts namely an libnfc script and an nfcpy script. These scripts are used to
load test cases and automate the Android fuzzing process. Finally, we propose two
mitigations that help to protect the security and privacy of the user.
5
1. INTRODUCTION
Near Field Communication (NFC) is a newly-emerging technology that has been
recently incorporated into mobile devices. NFC builds upon the existing radio-frequency
identification (RFID) specification. NFC operates on the low-range 13.56 MHz frequency
umbrella and can therefore read 13.56 MHz RFID or NFC tags. The NFC specification is
unique from RFID in that two-way communication is now possible and even at data
transfer speeds of up to 424 kbit/s. Two NFC-enabled devices can communicate as long
as the devices are within range (about 4 centimeters). The speed and convenience of
device to device data transfer has opened up the doors for continued innovation and
adaptation of NFC into more markets. NFC hardware has been integrated into newer
Android smartphones and NFC functionality has already been incorporated into many
mobile Android apps. Google Wallet is one example of an Android app that uses NFC
technology. It is an app that allows you to use your credit cards, gift cards, and other
highly sensitive financial information over NFC to checkout at supported (PayPass) card
terminals. As with any new technology implemented, we must look into NFC’s
implementation and assess the risk of any new attack vectors and possible malicious NFC
apps on mobile devices. We will assess the security of NFC on Android devices and
discover the degree of impact that this new functionality will have on the overall security
of mobile devices.
6
This paper investigates the security of the Android OS version 4.1 codename
Jellybean. Research in this area focuses on NFC security and mobile devices but more
thorough research is needed with a focus on Android. This is especially important due to
its high market share and mass incorporation of NFC technology into smartphones. This
paper recognizes and provides mitigations for the NFC attack vectors introduced. Also
discussed, are the steps and scripts needed to fuzz or, test a numerous variety, of NFC
tags and, in doing so, find bugs or errors in the implementation of NFC on an Android
device.
The rest of this paper is organized as follows. Section 2 presents related work and
research concerning the security of NFC and Android devices. Section 3 covers the
background of NFC as well as information about its workings and protocols. Section 4
presents the NFC attacks on Android and organizes them into four categories. Section 5
describes the background and information necessary to fuzz the NFC stack on Android.
In Section 5.1 we discuss three NFC devices used in this research namely the Samsung
Galaxy S3, the ACR122U, and the SCL271. These devices allow us to read, write, and
emulate NFC tags and even perform tests and attacks against the Android device. Section
6 discusses our implementation, scripts, and frameworks used in the fuzzing process.
This section is about the process of creating/emulating numerous different NFC tags of
the various protocols and types and watching to see how a specific Android device and
operating system reacts to the tag. We are expecting the web browser to open, the pdf
reader to open, the picture viewer to open, etc. This is a more hands-on approach to the
process of finding NFC bugs and exploits on Android. Finally, section 7 presents the
7
fuzzing and research results regarding NFC security on Android devices. It discusses the
changes that have taken place regarding NFC security on Android.
2. Related Work
Several researchers have been concerned about NFC security issues [1-3]. Since
the implementation of NFC technology into mobile devices, researchers have begun
looking for new attack vectors, testing, and performing attacks on NFC-enabled mobile
devices [4-15]. Little research has gone into testing the impact NFC has on the security of
Android NFC-enabled mobile devices [12, 16].
In [1], Miller explores the new attack surface that the addition of NFC adds to
mobile devices. He goes into great detail about both NFC and its various protocols. He
explores, tests, and fuzzes the NFC stacks of both the Galaxy Nexus S and the Nokia N9
NFC phones. He uses the ACR122U and a SCL3711 NFC devices as his NFC card
emulator. He also uses an automated python fuzzing setup for the NFC stack on these
mobile devices. Finally, he presents his success with the Nokia N9 NFC mobile device as
well as his success with Android as a result of the various crashes and interesting test
cases he generated.
Scharinger et al. [15] provides an analysis of the security of NFC technology on
devices. Their research focuses on the misuse of the different operating modes of NFC.
In this research they show several security issues in NFC devices and provide
8
countermeasures that could be implemented to further protect the security and privacy of
the end-user. They provided countermeasures for flaws such as phishing, skimming
secure element data, and denial of service. Their list of proposed countermeasures are
designed to deal with the various issues regarding the security and privacy of NFC
devices.
In [12], Mulliner analyzes the security of NFC-enabled mobile devices. To fuzz
NDEF messages he writes data to an NFC tag, scans the tag with the device he is testing,
and analyzes the output on the device. This method of fuzzing using NFC-tags was used
to analyze various NFC attacks on different mobile devices. Mulliner found that several
security vulnerabilities existed on NFC-enabled mobile phones such as the phishing of
websites, a POC NFC worm, Denial-of-Service attacks, and attacks on the underlying
telephony service. This research presents unique attacks against NFC devices.
Jara et al. explores in [13] the cryptography capabilities of various NFC devices in
hopes of implementing a cryptographic and secure way to transfer NFC data. A variety
of security problems of NFC are discussed as well as solutions provided. These attacks
include social engineering, privacy of the device, eavesdropping, and relay. They also
present great information about the speed and analysis of the timing and overhead of
various cryptographic ciphers. They propose a hybrid security solution for NFC in which
both asymmetric and symmetric cryptographic solutions are used for all of the
communication process.
In [14], Roland presents the advantages and disadvantages of implementing
software card emulation on mobile devices. Due to the lack of security and protection of
9
information against relay-attacks, their research concludes that software card emulation is
not necessary for NFC devices or the p2p mode of NFC. Roland finds that card emulation
cannot adequately protect the data in the card being emulated. He also believes that
restricting the functionality of software card emulation is not a robust defense against
software card emulation attacks as removing this restriction has already been done on
various Cyanogenmod ROMS.
In [11] Roland and Scharinger research the impact of embedding a secure element
or a smartcard into an NFC-enabled mobile device. Their research discusses new attack
scenarios against mobile devices given that a malicious application is installed on the
NFC-enabled mobile device. They present two attack scenarios against the smartcard in
NFC mobile devices namely the relay-attack and denial of service attack. They also
conduct research into various smartcard security frameworks similar to the SEEK for
android project that provides a protected API access to the smartcard to prevent malicious
usage. This research delves into a critical component of NFC hardware, the smartcard.
This research offers insight into the various solutions available for future implementation
that would provide a safe and secure way to access a smartcard’s API.
10
3. NFC
Near Field Communication is an extension of several Radio Frequency
Identification (RFID) communication standards. It essentially combines the RFID
standards and adds additional features which are composed of two new communication
standards. The two primary features added in the standards are peer-to-peer connections
between two active NFC devices and the emulation of a passive proximity RFID tag. The
NFC technology mainly focuses on contact-less smartcards that operate at a frequency of
13.56 MHz. There are three modes of communication using NFC. First, NFC can
communicate using card emulation in which it can emulate a passive RFID smartcard or
token. In NFC terminology a smartphone can become a passive target (for example, an
NFC tag) for an initiator such as an NFC reader. Second, there is reader/writer mode in
which smartcards and NFC tags can be read from and written to. Communication takes
place by an initiator, for example a mobile device, actively generates a radio frequency
(RF) field that powers a passive target such as an NFC tag. The target NFC tag answers
by modulating the existing field provided by the initiator. Depending on the target and
tag, which decides what protocol to use, the initiator may be able to read and write data to
the tag. Third and last, there is the peer-to-peer mode in which two NFC devices act as
active initiators and are able to communicate and send data bi-directionally to one
another. The two NFC devices must be able to generate their own RF field for
11
communication to occur. We will focus on fuzzing the protocol layers of these three
methods of NFC communication. The latter of the three, the P2P protocol or LLCP
(Logical Link Control Protocol) will be our focus in the testing of the NFC security on
Android Smartphone devices.
3.1 NFC PROTOCOLS
NFC communication could be thought of as a bridge between the physical and
digital world. It is with a simple NFC tag’s touch in which a virtual connection is
automatically established using NFC protocols. Understanding new attack vectors in
Android devices requires understanding some of the underlying protocol stack on which
NFC is based. Layer 1, the lowest layer of the NFC stack, will be regarded as the RF,
initialization, and anti-collision layer and will not be discussed as they handle the signal
and starting communication. The protocol layer is the layer for actually transmitting the
data intended to be sent or received with the communication. The data could
theoretically be anything, but a typical data payload; an NDEF message, is covered in the
next section. There are a variety of protocol layer protocols to communicate with the
various types of RFID and NFC tags. As shown in Figure 1, an NFC tag is scanned at
layer 1 it then goes up to layer 2 the protocol layer. At layer 2, each specific protocol for
the various NFC tag’s has a type assigned to it by the NDEF Spec. There are currently 4
various types of tags Types 1,2,3,and 4 and 1 standard NFC tag [17-21]. At layer 3, the
12
application layer, an NDEF message would be created using the type field of the protocol
being used. The appropriate Android application would then read and interact with the
NDEF message created. A response NDEF message could be crafted specifying a type
for the protocol one wishes to use can be sent back down the protocol stack. As an
example of this protocol stack, imagine now at Layer 1 a MiFare Ultralight NFC tag is
scanned by an Android device. At layer 2, the Android device recognizes the protocol
used and communicates with it using the MiFare Ultralight protocol. At layer 3 an NDEF
message with a type 2 field is created that contains communication from the tag. This
communication is then read by an Android phone and communication may be sent back
down the stack.
13
Figure 1: NFC Protocol Stack
3.2 NDEF FORMAT
In layer 3 of the protocol stack, NFC transport has been done and the data has
been delivered to the application layer in the final form of an NFC Data Exchange
Format (NDEF). The NDEF is a simple binary message format that is used to
encapsulate and represent the various RFID protocols and NFC tags in one NDEF format
14
[22]. NDEF contains different identifiers, fields, and flags for communication purposes
and to describe the type of data it contains. URI’s and Smart Posters are two examples of
the various NFC record types. More details about NDEF specifications for the various
types supported in NDEF as well as the specifications for each type can be found in [22-
25].
Figure 2 below contains a sample NDEF record for a Smart Poster NFC tag. This smart
poster has its URL field set to “google.com” and the optional title field set to “hi". Smart
Poster tags are designed to perform an action on the URL when scanned. For Android
devices, the scanning of the following tag will cause the Android browser to
automatically open the given URL.
Figure 2: Sample NDEF Smart Poster Tag
15
In Figure 2 above, the first two lines show the hexadecimal data of the Smart Poster tag
[24]. Below those lines are the hexadecimal values broken down into the NDEF format’s
blocks specified in the NFC Forum’s specifications. For example, the first two nibbles
“d1” in binary is equal to 11010001. Respectively the binary values represent the fields
MB, ME, SR, CF and TNF. The rest of the nibbles follow the NDEF specification and
similarly match to their corresponding field name.
16
4. NFC SECURITY ON ANDROID DEVICES
We have found various attacks against Android NFC-enabled mobile devices. We
organize them in the following four categories of attacks:
1. Fuzzing/NFC software stack errors
2. Secure Element
3. Cloning
4. Communication
For each attack we present the problem leading up to the attack, a case-study of
the attack, and also a solution or mitigation to the attack. This research and information is
useful to the end-user so that they can recognize when a malicious NFC tag as well as
when their mobile device is being attacked. NFC is typically used as a shortcut to trigger
an action. Consequently, NFC can be used as a shortcut to trigger different attacks against
the phone. A problem one can see is that users typically identify tags by scanning them
and observing the action. This research helps to inform users so that they are aware of the
security and privacy features that an NFC-enabled Android device can offer.
4.1 NFC ATTACKS
Web browser phishing and Smart Poster URI spoofing attack
17
Problem:
The Smart poster URI spoofing attack involves writing a Smart Poster tag’s data
by inserting multiple newline or return characters after the title in the title field so that it
appears to the user that they are going to the intended website in the tag title while they
are actually going to a malicious site. Smart Posters are a type of tag that act as shortcuts
in which, when scanned, they perform a default action for that tag or prompt for an action
to be performed. There are many listed types of URI’s (tag types) available that may
either prompt to open an Android app or by default auto-open themselves on the Android
device. This URI spoofing attack is a type of NFC web browser attack in that the URI of
the Smart Posters on NFC devices is automatically opened typically without user
interactions. The malicious intent with these attacks is to mislead or phish the web
browser to make the user believe he is on a legit website. The website however is a
malicious look-alike that may perform malicious actions like stealing user data or even
controlling the user’s device.
Application:
NFC Smart Poster tags can be placed in signs and in public places and contain
unchangeable links to malicious sites. These tags when opened by accident or on
purpose may open up a web browser that will attempt to install malicious content or
perform malicious actions on your device. The web browser may also open up a web
browser that appears like the user’s bank to con them into logging in and revealing their
password.
Solution:
18
The 4.1 version of Android tested was not found to be vulnerable to a URI
spoofing attack. However, due to NFC’s use as a shortcut, it provides a gateway to a web
browser phishing attack when a Smart Poster tag is scanned. Users typically have their
browser, by default, open the URI of a NFC tag when scanned. This URI could be a
malicious site that is then opened by the browser.
A mitigation to the web browser attack would be an option to allow NFC use only
when a user-defined button combination is held down. This would prevent NFC tags and
shortcuts from accidentally being triggered.
Samsung TouchWiz Denial of Service Attack
Problem:
NFC tags act as shortcuts and, at times, when scanned the user is unable to check
if the shortcut is intended to be used maliciously before it is opened. An NFC tag could
abuse a standard NFC app and use it maliciously against the user’s physical phone or
data. The Samsung TouchWiz attack is an example of a combination of a web browser
attack, an Android app being used unintentionally, and a device denial of service attack.
Application:
The USSD (Unstructured Supplementary Service Data) service codes are numbers
a person can dial into their phone. These codes usually beginning with a star or pound
sign and are used for diagnostics or retrieving sensitive phone information. The
TouchWiz attack is a real world attack that occurred on Galaxy S3 devices. This attack
used NFC as a shortcut to trigger this USSD, a developer’s backdoor, for malicious use.
19
One specific and dangerous USSD code was used as an attack vector as it allowed a user
to enter in a series of characters in the phones dialer to cause an un-cancelable factory
reset on the user’s phone. This attack can be demonstrated on a stock Galaxy S3 4.0.4. It
can also be triggered by either the web browser or NFC tel: URI tag.
Solution:
Fuzzing and testing is one way to test for other unknown developer backdoors.
Dangerous TouchWiz service codes such as this need to be removed to protect user data.
Samsung has submitted an update to TouchWiz disabling the USSD service code.
Meanwhile, a configurable user-button configuration to enable NFC would help prevent
an attack like this from being triggered.
Denial of Service (Device)
Problem:
Android and the various services and applications that can read in NFC tags
through the NFC stack may be vulnerable to DOS (denial of service) attacks. These DOS
attacks would take place through malformed NDEF messages or fuzzed LLCP packets.
Application:
Malformed NDEF messages could be placed in public places and if an NFC-
enabled mobile device reads such a tag either on purpose or accident their device will
crash and reboot or even force a factory reset of the user’s device.
Solution:
The solution to this problem is to fuzz NDEF messages and provide fixes to
20
various error and bugs in parsing malformed NDEF messages. Our goal is to find NFC
tags that cause such errors. A mitigation to this problem would be the same as above. An
option to allow NFC use only when a user-defined button combination is held down
would deter users from accidentally scanning a malicious tag.
4.2 SECURE ELEMENT
Denial of Service (Secure Element)
Problem:
NFC-enabled phones currently come with embedded secure elements or
smartcards. Android NFC devices require secure element access for card emulation. This
secure element however is vulnerable to a denial of service attack. The secure element
card is put into TERMINATED state after ten successive authentication failures for card
management. Once in TERMINATED state all installed applets will continue to be
available but card management is no longer possible. As a result, applets cannot be
installed or removed. An authentication to the card manager of the secure element
consists of three secure element commands: SELECT, INITIALIZE UPDATE, and
EXTERNAL AUTHENTICATE. For an embedded secure element, card management
must be available through the secure element API. On Android, access to the secure
element is limited to only a few select Google and manufacturer apps. This means that
these apps are able to make authentication attempts to the secure element. If a malicious
21
app were able to inject code or an exploit and gain access to the secure element api, the
result would be a permanently TERMINATED or locked secure element. Having a
locked secure element would make card emulation unusable on that Android device.
Application:
A game from the Google Play Marketplace is fun and easy. This game is actually
a malicious app which has utilized a new exploit and, in doing so, has escalated its
privileges and gained access to the secure element API. This malicious application then
authenticates incorrectly ten times with the secure element card manager and, in doing so,
has locked and TERMINATED that devices secure element and card emulation
functionality.
Solution:
Secure element access is currently restricted on Android devices. There are
currently several different existing APIs and projects that are being considered for
adoption on Android. These API’s would provide various levels of protection to the API
of the secure element from malicious usage. Access and protection against malicious
usage for the secure element API may come from using frameworks such as the SEEK
for Android project. This project provides a standardized, secure smartcard API for the
Android platform.
22
4.3 CLONING
Cloning tags
Problem:
The NFC specifications give each NFC tag only one “unchangeable” unique ID.
This manufacturer generated and given unique ID is used for identification as well as the
anti-collision algorithms. What is problematic is that this manufacturer given unique ID
is used in communication even when the other device is unauthenticated. This proves to
be a privacy issue as this unique ID is exclusive to that tag and owner. Along with this
privacy issue, NFC tags’ unique ID’s can be easily cloned. NFC tags that have a
programmable unique ID can be purchased online and there exists software NFC tag
emulators that also can completely clone and write unique IDs.
Application:
A new application for Android comes out on the Google Play market that gives
the user the functionality to unlock their Android device by just scanning their personal
NFC tag. This app uses the unique ID of the NFC tag as a key to unlock the owner’s
device. Since the unique ID of the user’s NFC unlock-tag is “given out” that unique ID
can be software emulated or cloned onto another tag. Due to this security hole, a
malicious user can now gain access to that user’s phone.
Solution:
For security, privacy, and anti-collision purposes, an NFC tag should use a fake,
23
randomly generated unique ID while communicating with an unauthorized user of an
NFC tag. The real unique ID assigned to that NFC tag should only be given to and used
by authorized users. Since tags can be cloned, users should never use NFC tags to unlock
their Android device.
4.4 COMMUNICATION
Relay Attack and Information Stealing
Problem:
With the introduction of NFC hardware, the Android OS has become a suitable
platform to access the contents of a RFID or NFC tag remotely. An Android app, once
NFC access control permissions have been given, that app has access to data scanned and
sent by the NFC controller. The app can then read and write tags and communicate with
the secure element (it is only restricted from card emulation mode which has been
restricted for nearly all apps on all Android devices). The relay-attack works by sending
commands (APDU’s) received from the point-of-terminal or RFID/NFC initiator device
and forwarding them over a network socket to a malicious app installed on a victim’s
device. The NFC controller on the victim’s Android device is accessed and the app
relay’s the victim device’s response (APDUs). Through this relay-attack one is able to
access the NFC controller of a device without physical access to the device. This attack
puts the victim’s privacy at risk as the malicious user can now use this forwarded
24
information maliciously.
Application:
A relay-attack in a real-world scenario begins with a mobile malicious game
installed on installed on a device that utilizes an NFC payment system similar to that of
Google Wallet. This malicious game is the relay-application and it is assumed that it has
been given NFC permissions or been escalated to them. Using Google Wallet as an
example, an attacker checks out at the store using paypass and, in doing so, receives
commands from the paypass, the RFID initiator, and forwards these commands to the
victim’s device through a network. The victim’s device is accessible as a result of the
malicious app installed. This app is able to communicate and send data to the NFC
controller of which Google Wallet is manipulating. The victim user may have to enter a
pin or it may be possible to brute force or workaround the pin. The malicious app will
then respond to the attacker’s device with the correct NFC emulation information that
contains the victim’s payment information. The attacker’s phone emulates the data
received from the victim’s phone and then checks-out as if he physically had the victim’s
phone. As one can see the latency between sending and receiving data is the only factor
here as the victim must have a good connection to the internet. This attack is typically
performed using WIFI. As a second step in this attack, an attacker may retrieve all the
data from the victim’s secure element and because they are using Google Wallet the
attacker is able to retrieve all Virtual Google Wallet credit cards that have been linked to
that user’s real credit cards.
Solution:
25
There are two solutions that help mitigate the relay-attack. One solution to the
relay-attack that is already implemented in Google Wallet is that the user has to enter
his/her pin to unlock and open Google Wallet before completing every transaction. It may
be possible, however, to steal and sniff a user’s pin by catching where a user touches
when entering their pin and then replaying that information back. We propose a second
solution to this attack in which an option is present in Android that allows the use of the
NFC controller only when a user-defined button combination is held down.
Eavesdropping Attack
Problem:
NFC and RFID are two communication protocols intended on communicating
with recipients at a close range. However, it is possible for more expensive equipment to
communicate at a longer distance. In this eavesdropping attack, it is possible for an
unintended recipient to intercept and read messages.
Application:
NFC device Alice is trying to communicate private information to NFC device
Bob. Unaware of a third party reader, Alice’s data is eavesdropped by a malicious user’s
long range RF antennae pointed at Alice’s device.
Solution:
There are two solutions to this problem the first is to ensure that no other RFID or
NFC readers are able to intercept your RF field. The second, we propose, is to implement
asymmetric and symmetric encryption on all P2P NFC communication. That way, any
private RF data retrieved will be encrypted.
26
5. FUZZING ANDROID’S NFC STACK
The term fuzzing in our case is used to refer to testing the NFC methods of
communication with valid and invalid data. After each test, we record and observe the
output on the Android device. The process of fuzzing consists of the following. First, we
generate test cases for the various fields we wish to fuzz. In our case, we generate or fuzz
both NDEF messages and specific LLCP protocol packets. Second, we send or playback
the generated test cases on the Android device using our hardware and NFC
communication frameworks. Third, we observe the device’s output through USB
debugging services.
The first place to fuzz the NFC stack on Android is the protocol layer where data
is first communicated up the protocol stack and is parsed and converted into an NDEF
message. The next place to fuzz is the application layer which takes over and actually
reads and handles the NDEF message. Once the application layer receives the NDEF
message the Android NFC service prompts the user to set a default app to open or it
opens the default Android app using the NDEF message.
The NFC stack contains all the code necessary and responsible for parsing and
processing the NFC protocols mentioned in section 3.1. At the lowest level, a general
NFC stack consists of a driver for the NFC chip as well as a library used to communicate
with the driver. Next, a general NFC stack, specifically in the application layer, will
contain the code necessary to parse and process the various types of incoming NDEF
27
messages as well as the appropriate action to take once they are received. In Android, the
NFC stack is layered out as shown in Figure 3 [16].
Figure 3: NFC attack surface if NFC can communicate with browser
The NFC chip driver is located in the underlying Linux kernel in the Android OS.
Next, the library as well as the code responsible for parsing the NDEF payload is located
in a special “NFC Service” (com.android.nfc). This driver and the LLCP and NXP NFC
library stack’s above it are a target for protocol fuzzing. Finally, the application layer of
the NFC stack is triggered and the appropriate action is taken by opening Android Tags,
Android Beam or even Android browser application depending on the NDEF payload
processed.
In Android version 4.0.4, the Android Tags and Android Beam application have
been shown to, without user interaction, automatically open various programs to process
NFC data. There may be bugs in this NFC stack that would allow the remote control of
28
an Android smartphone. A foreseeable difficulty one can see is that Android apps are run
inside a java based virtual machine and memory corruption may not be a possibility.
However, native code will always be involved at the lowest levels (eg. a library or
driver).
There are different approaches to find NFC vulnerabilities and bugs in the Android
smartphone devices, but the best way is to start at the lowest level and work your way up.
In our case, the appropriate low level is the protocol layer of the NFC stack and we will
work our way up to the application layer.
5.1 PROTOCOL LAYER FUZZING
NFC bridges the gap between the physical and digital world. When touching two
NFC enabled devices or a device to a tag a connection is created. In other words, you
physically touch one object to another and through that they are able to connect and
communicate, without pairing, and share information. This background, almost magical,
connection between two different devices without pairing is the focus of protocol
fuzzing. The goal of fuzzing the protocol layer is to send unexpected data to Android
devices trying to abuse this automatic connection. By doing this, we are testing Android
and trying to figure out, crash, and get some sort of output on the Android device.
When fuzzing the protocol level of the NFC stack, the goal is to emulate as many
different types of tags, fields, and protocols as possible. We will be able to fuzz the
29
Capability Container and memory sectors of NFC Tags as well as the LLCP (or P2P
protocol) used by Android devices. When fuzzing, we want to use both valid and invalid
data packets in the protocol. By doing this, we wish to see how the Android library
responds. When an Android phone is placed near an NFC tag a communication is made
and credentials and authorization confirmed before tag data and memory access is
allowed. We will preset fuzzed NFC tag data to the Android device in this Capability
Container and memory sector of NFC Tags.
Another protocol we will fuzz is the Android P2P protocol known as LLCP
(Logical Link Control Protocol) [21]. This protocol is used by Android for P2P
communication between two devices. We are looking to find errors, bugs, or crashes in
the LLCP connection between these two devices. We will modify and fuzz a variety of
LLCP packets used to establish a connection and relay the NDEF message. We are
fuzzing the LLCP packets associated with starting a connection. We will fuzz the LLCP
connect, parameter exchange, connection complete, and receive ready packets of the
LLCP protocol. More information about these packets and their functions can be found
on the NFC-forum website in the LLCP specifications [21]. We will present the P2P
protocol to the Android device using our NFC lab hardware see Section 6.1.
5.2 APPLICATION LAYER FUZZING
Application layer fuzzing involves creating test cases of NDEF messages and
30
scanning them to observe the action taken by, in our case, the Galaxy S3 Android device.
When an NFC tag is scanned by a device the application layer receives an NDEF
message. Knowing this, we can fuzz by creating as many NDEF messages as possible
with as many combination of values in the various fields as possible. The goal here is to
create both invalid and valid NDEF messages that cause undesired output on the Android
device. Perhaps one of these messages will cause the Android NFC stack parser or
arbitrary Android application to execute the code we want, show an error, or crash.
Application layer fuzzing of NFC will continue to be needed as more and more Android
applications are developed with NFC. Pressure is put on the developers as poorly coded
NFC functionality may allow that app to be used for malicious attacks.
6. IMPLEMENTATION
Our implementation of NFC fuzzing uses a hands-on approach utilizing an NFC
lab we created. This approach seems to go well with our low-level protocol fuzzing
purposes. With an external USB NFC card emulator/reader/writer we are able to do card
emulation and P2P LLCP communication which allows as to fuzz the protocol and
application layers. Section 6.1 provides more information about the NFC lab setup.
Along with the hardware, our fuzzing implementation needs a few pieces of
software as well. We need an NFC framework that allows us to communicate using the
NFC communication protocols and our hardware. We utilize python scripts to fuzz
31
(generate) test cases and also to automate the iteration of scanning, recording, and
observing Android device output. We use the Sulley Fuzzing Framework [28] to generate
the various test cases for NDEF messages. We implemented two scripts written in python
that automates the fuzzing and emulation of NFC tags on Android. These Python fuzzing
scripts are implemented for the libnfc and nfcpy frameworks. The scripts, for each test
case we have generated, emulates or communicates using the test case and retrieves the
Android device’s state through USB debugging. There is also an auto-fuzz mode
implemented that generates random, bit-flipped test cases for the protocols or NDEF
messages we are fuzzing.
6.1 NFC Lab Setup
For our purposes in this research we need to emulate various NFC tags and
protocols. To do this we need to be able to do card emulation as well as P2P
communication. Card emulation is where we have a device that emulates an NFC act as
a passive tag. We were able to find two pieces of hardware that, after some tweaking,
could perform both card emulation and P2P LLCP communication. The ACS ACR122U
and the SCL 3711 were used with our Android Galaxy S3 device as an NFC tag
reader/writer/emulator. With tweaking, together these two readers support card emulation
of two types of NFC tags and also Android’s P2P protocol LLCP. Our hardware relies
on the NFC libraries provided by the open source frameworks of libnfc [26] and the
32
nfcpy project [27].
Figure 4: (left to right) Galaxy S 3 NFC Android Device
ACR-122U and SCL-3711 card reader/writer/emulator
6.2 TEST CASE GENERATION
The test cases used in fuzzing were generated using mutation and generation
based fuzzing. Mutation based fuzzing is used when starting with a valid test case and
changing and mutating it as needed. In our case, mutation fuzzing begins with a valid
group of hexadecimal digits and randomly we select a binary bit and flip it. We also have
the capability of injecting a binary bit randomly. Using the bit-flip script we are able to
generate as many test cases as needed. A mutation based python script was used mainly
in protocol fuzzing due to the relatively small size of the packets.
Test cases used by the application layer were generated using a generation-based
33
Python fuzzing script. However, these test cases used a Python Fuzzing framework
known as the Sulley Fuzzing Framework [28]. The Sulley Fuzzing Framework is used to
map out the various payload blocks of the NDEF specification. With Sulley, one is able
to do what is known as smart-fuzzing which allows one to create combinations of test
cases within the parameters they provide.
Figure 5: Smart Poster Fuzzing Example using Sulley Fuzzing Framework
34
Figure 5 above is an example of a Smart Poster fuzzing script written using the
Sulley Fuzzing Framework. This framework relies on block-based fuzzing in which you
define a protocol you wish to fuzz in blocks. Sulley is able to generate data based on the
configurations, number of mutations, and settings the user provides. This script generates
the test cases for an NDEF Smart Poster message. One can see the various NDEF
message components defined inside the Python code.
When generating test cases, we implemented the on-the-fly generation with the
bit-flipped, mutation-based NFC test cases. This feature is implemented into our libnfc
and nfcpy python fuzzing scripts. This way, the fuzzing test cases do not have to be pre-
generated, but can be generated on-the-fly.
6.3 PROTOCOL LAYER FUZZING
The libnfc is an open source NFC library that communicates with USB NFC
hardware to allow the read/write/card emulation of NFC tags. We use it to do card
emulation and, being open source and c code, it allows us to fuzz the Capability
Container of the Type 4 tag and the memory sector of the Type 2 tag. To fuzz the
35
protocol layer of the NFC tags Type 2 and Type 4 we use a modified version of the open
source libnfc framework [26]. A modified version allows us to edit the communication
protocol and use our test cases into the protocol. The libnfc python script we
implemented resides inside this libnfc framework. This script automates the process of
fuzzing Android. Our python script iterates through a list of test cases previously
generated, emulates them using libnfc’s framework, then checks and saves the state of the
Android device. When fuzzing the protocol layer, the NDEF message we send to the
Android device is not important to us at this point. We are interested in the protocol
fuzzing and, in this case, the fuzzed capability container/memory sector. We are
observing whether an NFC tag with a fuzzed container is detected, accessed, and read.
We are seeing if Android detects this emulated NFC tag as a valid tag, ignores the tag,
opens an app, or force closes.
To fuzz the protocol layer of the P2P Logical Link Control Protocol (LLCP) we
used a modified version of the open source nfcpy framework [27]. A modified version of
this framework allows us to inject our test cases into the LLCP protocol packets we are
fuzzing. We are fuzzing the LLCP connect, parameter exchange, connection complete,
and receive ready packets of the LLCP protocol. We are able to use our nfcpy python
script to automate the process of fuzzing Android. Our python script iterates through a
list of test cases previously generated, calls the test case using the nfcpy framework, then
checks and saves the state of the Android device.
In Table 1 below, one can see that we were able to fuzz 6 NFC protocols running
2,000 test cases per protocol for a total of 12,000 test cases for the NFC protocol layers.
36
Next to the number of test cases is the specific amount of bytes in the packet that we are
able to fuzz. During the protocol fuzzing, the Android device will attempt to connect and
communicate with the fuzzed protocol. There were cases where Android would not
accept the LLCP connection or recognize the NFC tag presented.
Table 1: NFC Protocol Fuzzing
Type of Protocol Fuzzing Test Cases Results/Notes
Type 2 (Ultralight) 1. Capability
Container
1. 2000 (18 bytes) 1. Not all tags recognized
Type 4 (DESFire) 1. Memory
1. 2000 (15 bytes)
1. Not all tags recognized
LLCP 1. Connect 2. Parameter
Exchange 3. Connection
Complete 4. Receive Ready
1. 2000 (19 bytes) 2. 2000 (19 bytes) 3. 2000 (6 bytes) 4. 2000 (3 bytes)
Device doesn’t accept fuzzed LLCP connection
6.4 APPLICATION LAYER FUZZING
To fuzz the application layer of Android we decided to use the libnfc framework’s
card emulation mode to emulate the NFC Tag with the NDEF message we generated. Our
libnfc Python NFC Fuzzing script iterates through the list of test cases, emulating each
test case and checking the Android phone’s output via USB (state checking).
37
Table 2: NDEF Message Test Cases
Type of Test Cases Test Cases
NDEF - short text 1626
NDEF - short URI 538
NDEF - short SMS 1265
NDEF – Smart Poster Example 1189
NDEF - short SP 3675
NDEF – Bluetooth OOB Pairing 4275
NDEF - short BT 1246
NDEF - long text 2440
NDEF - long vcard 32572
We were able to run a total of 48,826 test cases against our Android device.
Figure 2 above shows both the type and number of NDEF messages we were able to
generate. We were able to expand on Miller’s research and generate similar test cases
along with adding two additional NDEF test case generation scripts. We implemented a
NDEF Smart Poster fuzzing script, shown in Figure 5, along with a NDEF Bluetooth
pairing fuzzing script shown in Figure 6 below.
38
Figure 6: A Bluetooth Fuzzing Example using Sulley Fuzzing Framework
39
7. FUZZING RESULTS
Although we tested 12,000 test cases on the protocol layer as shown in Table 1
and 48,826 test cases on the application layer of Android as shown in Table 2 the test
cases and fuzz testing research was not able to cause a denial of service, take-over, or
force close on the Android device. We found that the NFC service would crash and
restart when certain invalid NDEF tags were scanned. Since there is no visual indication
and no errors or force closes we did not find this to be noteworthy. During testing we
also found that the device, the Galaxy S3, crashed and rebooted several times. This seems
to be caused by memory deallocation and since it is not reproducible with a specific NFC
tag or test case it is not used. The memory problems seem to occur most often with Type
4 NFC Tags possibly due to the 32KB maximum size compared to the Type 2 NFC Tag’s
size of 144 Bytes.
Our research discovered that the NFC implementation on Android has changed
vastly since Android OS 4.0.4. In subsequent versions, the Google’s Tags Android
application has been removed. This application previously accepted and logged all NFC
tags when scanned. Additionally, prior research has shown that this app was prone to
force closes and errors.
We have found that beginning in Android 4.1 Google has re-done their NFC
implementation and replaced their previous Tags application and instead use an NFC
service to re-direct tags. This NFC service is referred to as the NFC tag dispatch system
40
service. This service redirects a scanned NDEF message to an appropriate Android
application. Eliminating the Tag’s application has shown to stop the force closes, is more
secure, and so far no force closes are apparent to the user when an invalid or corrupt NFC
tag or NDEF message is scanned. We were able to run numerous test cases against the
protocol and application layers. Compared to generating test cases, we found that the
actual fuzz testing portion of the research was the most tedious and took the longest to
run.
8. CONCLUSION
NFC is a new technology and as with any new technology incorporated into
mobile devices we must test both its intended and malicious use. The addition of NFC
has created not only new attack vectors on Android devices, but a shortcut to existing
attack vectors. In this paper we discussed the following areas pertaining to NFC security.
We talked about the attack vectors created by the NFC stack. Next, we went through
case-studies of real-world scenarios and then proposed mitigations to these attacks. Then
we fuzz tested the low-level NFC libraries of the newer versions of the Android OS. In
doing so, we implemented additional LLCP protocol packets to fuzz as well as developed
numerous additional test cases with the Sulley Fuzzing Framework. Lastly, taking these
attack vectors into consideration, we propose the following two solutions that, if
implemented, will protect the security and privacy of the user. The first mitigation we
41
propose concerns implementing an option on Android devices that allows NFC use only
when a user-defined button combination is held down. This mitigation will prevent social
engineering attacks that use Smart Poster tags to automatically open malicious webpages.
It also helps to prevent relay-attacks as the user-defined button combination must be held
down in order to use NFC functionality. The second mitigation, we propose is optional
until the use of the Secure Element is given to Android devices. This mitigation proposes
adding asymmetric and symmetric cryptography to P2P NFC communication so that no
eavesdropping or data insertion is possible. The implementation of these mitigations will
help protect the privacy and security of the end-user of Android devices. We also
recommend that users with Android NFC-enabled smartphones keep their devices up to
date and use at least the Android Jellybean OS version 4.1 which has updated NFC
security features.
42
APPENDIX
This page is intentionally left blank.
43
FUTURE RESEARCH
In future research, we think that continued fuzz testing of NFC tags on Android
might show more bugs and errors in the NFC and LLCP protocols. We believe more
fuzzing needs to be done and more test cases generated to ensure that NFC protocols are
firmly and officially tested. We find that, with this NFC lab hardware, more fuzzing can
be done on NFC enabled mobile devices other than Android. We also believe as the NFC
technology develops virtualization should be utilized to speed up and expand the fuzzing
process.
44
REFERENCES
[1] M. Roland, J. Langer and J. Scharinger, "Security Vulnerabilities of the NDEF
Signature Record Type," in Proceedings of the 3rd International Workshop on Near
Field Communication (NFC), 2011.
[2] E. Haselsteiner, K. Breitfuß. Security in Near Field Communication (NFC). In
Workshop on RFID Security, 2006.
[3] M. Saeed and C. Walter, "A Record Composition/Decomposition attack on the NDEF
Signature Record Type Definition," in Proceedings of the International Conference on
Internet Technology and Secured Transactions (ICITST), 2011.
[4] S. Burkard, "Near Field Communication in Smartphones".
[5] L. Francis, G. Hancke, K. Mayes and K. Markantonakis, "Potential misuse of NFC
enabled mobile phones with embedded security elements as contactless attack
platforms," in Proceedings of the International Conference on Internet Technology
and Secured Transactions, 2009.
[6] R. Verdult and F. Kooman, "Practical attacks on NFC enabled cell phones," in
Proceedings of the 3rd International Workshop on Near Field Communication (NFC),
2011.
[7] G. Van Damme, K. Wouters and B. Preneel, "Practical Experiences with NFC
Security on mobile Phones," in Proceedings of the RFIDSec’09 on RFID Security,
2009.
45
[8] A. F. de Azevedo Figueiredo Cruz, “Nfc and mobile payments today,”
http://www.di.fc.ul.pt/nuno/THESIS/AndreCruz MSIT11.pdf
[9] G. Madlmayr, J. Langer, C. Kantner, J. Scharinger. NFC Devices: Security and
Privacy. In Third International Conference on Availability, Reliability and Security,
pages 642–647, 2008.
[10] M. Lange, S. Liebergeld, A. Lackorzynski, A. Warg, and M. Peter. L4Android: A
Generic Operating System Framework for Secure Smartphones. In Proceedings of
the 1st Workshop on Security and Privacy in Smartphones and Mobile Devices,
CCS-SPSM’11, 2011.
[11] M. Roland, J. Langer and J. Scharinger, "Practical Attack Scenarios on Secure
Element-Enabled Mobile Devices," in Proceedings of the 4th International Workshop
on Near Field Communication (NFC), 2012
[12] C. Mulliner, "Vulnerability Analysis and Attacks on NFC-Enabled Mobile Phones,"
in Proceedings of the ARES '09 International Conference on Availability, Reliability
and Security, 2009.
[13] A. J. Jara, A. F. Alcolea, M. A. Zamora and A. F. G. Skarmeta, "Evaluation of the
security capabilities on NFC-powered devices," in Proceeding of the 2010
European Workshop on Smart Objects: Systems, Technologies and Applications
(RFID Sys Tech), 2010.
[14] M. Roland: Software Card Emulation in NFC-enabled Mobile Phones: Great Ad-
vantage or Security Nightmare?. In Proceedings of the 4th International Workshop
on Security and Privacy on Spontaneous Interaction and Mobile Phone Use.
46
http://www.medien.ifi.lmu.de/iwssi2012/papers/iwssi-spmu2012-roland.pdf, June
2012.
[15] M. Roland, J. Langer and J. Scharinger, "Practical Attack Scenarios on Secure
Element-Enabled Mobile Devices," in Proceedings of the 4th International Workshop
on Near Field Communication (NFC), 2012.
[16] Exploring the NFC Attack Surface http://media.blackhat.com/bh-us-
12/Briefings/C_Miller/BH_US_12_Miller_NFC_attack_surface_WP.pdf
[17] Type 1 Tag Operation Specification http://www.nfc-forum.org/specs/
[18] Type 2 Tag Operation Specification http://www.nfc-forum.org/specs/
[19] Type 3 Tag Operation Specification http://www.nfc-forum.org/specs/
[20] Type 4 Tag Operation Specification http://www.nfc-forum.org/specs/
[21] Logical Link Control Protocol NFCForum-TS-LLCP_1.1http://www.nfc-
forum.org/specs/
[22] NFC Data Exchange Format (NDEF) http://www.nfc-forum.org/specs/
[23] NFC Record Type Definition (RTD) http://www.nfc-forum.org/specs/
[24] NFC Smart Poster Record Type Definition (RTD) http://www.nfc-forum.org/specs/
[25] Text Record Type Definition http://www.nfc-forum.org/specs/
[26] libnfc libraries http://www.libnfc.org/
[27] nfcpy project https://launchpad.net/nfcpy
[28] Sulley Fuzzing Framework https://github.com/OpenRCE/sulley