Exploring the NFC Attack Surface Charlie Miller Managing Principal Accuvant Labs charlie.miller@accuvant.com Accuvant labs July 13, 2012 Charlie Miller: Exploring the NFC Attack Surface Introduction 4 NFC protocols 5 Physical and RF layer 6 Initialization, Anti-Collision, and Protocol Activation layer 7 Protocol layer 7 Application layer 8 Example data capture 10 Fuzzing the NFC stack 1 3 Fuzzing setup 15 Fuzzing test cases 16 Results - Nexus S 18 Results - Nokia N9 25 NFC higher level code 26 Nexus S - Android 2.3.3 26 Galaxy Nexus - Android 4. 0. 1 28 Galaxy Nexus - Android 4. 1. 1 32 Nokia N9 - MeeGo 1.2 Harmattan PR1.3 33 Possible attacks 37 Android NFC Stack bug 37 Android Browser 38 N9 Bluetooth pairing 38 N9 bugs 39 Summary 41 Acknowledgements 42 Charlie Miller: Exploring the NFC Attack Surface References 43 Charlie Miller: Exploring the NFC Attack Surface Introduction Near Field Communication (NFC) has been used in mobile devices in some countries for a while, and is now emerging on mobile devices in use in the United States. This technology allows NFC-enabled devices to communicate with each other within close range, typically a few centimeters. NFC is being deployed and adopted as a way to make payments, using a mobile device to communicate credit card information to an NFC enabled terminal. It is a new, cool, technology, but as with the introduction of any new technology, the question that must be asked is what kind of impact the inclusion of this new functionality will have on the attack surface of mobile devices. In this paper we explore this question by introducing NFC and its associated protocols. Next, we describe how to fuzz the NFC protocol stack for two devices as well as provide the results of our testing. Then we see for these devices what software is built on top of the NFC stack. It turns out that through NFC, using technologies like Android Beam or NDEF content sharing, one can force some phones to parse images, videos, contacts, office documents, and even open up web pages in the browser, all without user interaction. In some cases, it is even possible to completely take control of the phone via NFC, including stealing photos, contacts, even sending text messages and making phone calls. The next time you present your phone to pay for your cab, be aware you might have just gotten owned. Charlie Miller: Exploring the NFC Attack Surface NFC protocols Understanding the NFC attack surface first requires some understanding of NFC and the underlying protocols on which it is based. Figure 1 , below, shows a diagram of most of the associated protocols used for NFC transactions. Apptacalmn Layer NFC Foium NDEF Messages Taj Tjrfrtt NFC Forum "ormalled Tag typ* 2 Taj ±1 Iff* A T») Typ* 3 Tag ..I !.i. Is Topaz (Incniiori MIFARE St* 1 WAK . .T.enhiQ. 0010: 0B 55 01 67 6F 6F 67 6C 65 2E 63 6F 6D . U . google . com di - MB, ME, SR, TNF="NFC Forum well-known type" 02 Type length is Payload length 53 70 Type - "Sp" 91 - MB, SR oi Type length 05 Payload length 5 4 Type - "T" 02 Status byte - Length of IANA lang code 65 6e language code = "en" 68 69 "hi" text si - ME, SR oi Type length ob Payload length 55 Type - "U" oi identifier code "http://www." 67 6f 6f 67 6c 65 2e 63 6f 6d = "google.com" - text The previous NDEF example had a single byte devoted to the length of the payload. To support payloads longer than 255 bytes, a longer form of NDEF is used. (You can tell which variant to expect by whether the SR bit is set in the first byte of the NDEF record or not). Below is the beginning of a longer NDEF record. 0000: CI 01 00 00 01 2F 54 02 65 6E 61 61 61 61 61 61.... ci - MB, ME, TNF="NFC Forum well-known type" oi Type length oo oo oi 2f Payload length 54 Type - "T" 02 - Status byte - Length of IANA lang code 65 63 - language code = "en" 6i 6i 6i 6i 6i 61= "aaaaa..." - text Charlie Miller: Exploring the NFC Attack Surface Example data capture Data can be captured in various ways. Perhaps the simplest way (when it works) is to use a Proxmark3 device [14] , see Figure 4, below. y s&s**^" as? Figure 4: Proxmark homemade antenna waiting for a Type 2 transaction from a SCL3711 Below, you can see a trace obtained from an SCL3711 NFC card reader reading from a Mifare Ultralight tag. I added brackets to indicates bytes used for checksum purposes. I also indicate the specification used to interpret the bytes. SENS_REQ 26 SENS_RES (NFCID1 size: double (7 bytes), Bit frame SDD) TAG 4 4 SDD_REQ CL1 93 20 SDD_RES (CT? 04-e3-ef BCC) TAG 88 04 e3 ef <80> Charlie Miller: Exploring the NFC Attack Surface SEL_REQ CL1 93 70 88 04 e3 ef 80 <99 73> SEL_RES - Not complete, type 2 TAG 04 SDD_REQ CL2 95 20 SDD_RES (a2-ef-20-80 BCC) TAG a2 ef 20 80 SEL_REQ CL2 95 70 a2 ef 20 80 ed <72 c8> SEL_RES - complete, type 2 TAG 00 Charlie Miller: Exploring the NFC Attack Surface READ - 08 30 08 <4a 24> READ Response TAG 74 72 61 6c 69 READ - 03 30 03 <99 9a> READ Response TAG el 10 06 00 03 READ - 04 30 04 <26 ee> READ Response TAG 03 17 dl 01 13 READ - 05 30 05 READ - Response TAG 13 54 02 65 6e READ - 06 30 06 <34 cd> READ - Response TAG 6e 73 75 70 2c READ - 04 30 04 <26 ee> READ - Response TAG 03 17 dl 01 13 READ - 05 30 05 READ - Response TAG 13 54 02 65 6e READ - 06 30 06 <34 cd> READ - Response TAG 6e 73 75 70 2c READ - 07 30 07 READ - Response TAG 2c 20 75 6c 74 READ - 08 67 68 74 3f fe 00 17 dl 01 13 54 02 54 02 65 6e 73 75 73 75 70 2c 20 75 20 75 6c 74 72 61 54 02 65 6e 73 75 73 75 70 2c 20 75 20 75 6c 74 72 61 72 61 6c 69 67 68 00 e4 f2 e3 01 <06 d5> 65 6e 73 75 70 70 2c 20 75 6c <2a 00> 6c 74 72 61 6c <16 f6> 6c 69 67 68 74 <65 db> 70 2c 20 75 6c <2a 00> 6c 74 72 61 6c <16 f6> 6c 69 67 68 74 <65 db> 74 3f fe 00 00 <8b 9e> 30 08 <4a 24> READ - Response TAG 74 72 61 6c 69 READ - 09 30 09 READ - Response TAG 69 67 68 74 3f READ - 0a 30 0a <58 07> READ - Response TAG 3f fe 00 00 e4 READ - 0b 30 0b
READ - Response TAG e4 f2 e3 01 e4 READ - Oc 30 0c <6e 62> READ - Respnose TAG e4 f2 e3 01 30 READ - Od 30 Od READ - Response TAG 30 00 00 00 45 READ - 0e 30 Oe <7c 41> READ - Response TAG 45 34 20 46 32 READ - Of 30 Of READ - Response TAG 32 20 45 33 04 67 68 74 3f fe 00 fe 00 00 e4 f2 e3 f2 e3 01 e4 f2 e3 f2 e3 01 30 00 00 00 00 00 45 34 20 34 20 46 32 20 45 20 45 33 04 e3 ef e3 ef 80 a2 ef 20 00 e4 f2 e3 01 <06 d5> 01 e4 f2 e3 01 <15 ca> 01 30 00 00 00 <6a 52> 00 45 34 20 46 46 32 20 45 33 <17 e2> 33 04 e3 ef 80 80 a2 ef 20 80 <01 7e> 80 ed 48 00 00 SLP_REQ 50 00 <57 cd> Pulling out the NDEF data read we find: 03 17 dl 01 13 54 02 65 6e 73 75 70 2c 20 75 6c 74 72 61 6c 69 68 74 3f fe 00 00 e4 f2 e3 01 30 00 00 00 45 34 20 46 32 20 45 04 e3 ef 80 a2 ef 20 80 ed 48 00 00 Examining this NDEF data we can see the contents: Charlie Miller: Exploring the NFC Attack Surface 03 NDEF Message 17 length Record 1 di - MB, ME, SR, TNF="NFC Forum well-known type" oi Type length 13 Payload length 5 4 Type - "T" 02 - Status byte - Length of IANA lang code 65 6e - language code = "en" 73 75 70 2c 20 75 6c 74 72 61 6c 69 67 68 74 3f = "sup, ultralight?" - text Record 2 fe Terminator NDEF Fuzzing the NFC stack When considering the attack surface that the introduction of NFC to a device adds, the most obvious place to start is the NFC software stack itself, the code responsible for parsing the NFC protocols mentioned in the last section. Typically, this code will consist of a driver for the NFC chip, a library used to communicate with the driver, and then the OS code to deal with incoming NFC payloads including dealing with different types of NDEF messages that might arrive. In Android, we see something like Figure 5, below. Figure 5: NFC handling code in Android. Charlie Miller: Exploring the NFC Attack Surface In MeeGo it is similar, as in Figure 6, below. Figure 6: NFC handling code in MeeGo In such a complex stack, there certainly could be bugs lurking in any of this code that could allow remote compromise of NFC enabled devices. Please note that in Android, some of the components are Java apps and so memory corruption is not a possibility, but this will vary from platform to platform. There will always be some native code involved at the lowest levels, though. There are various approaches to trying to find vulnerabilities in the NFC stack. A driver that is proprietary could still be reverse engineered and analyzed. The library for the chip on Android, libnfc.so, is open source, and so could be audited. However, one very effective way to get started is to set up a fuzzing environment and fuzz the NFC protocol stack. Depending on exactly how this is to be carried out, different levels of the protocol stack can be attacked. We considered various approaches such as doing it at the RF level (see [2-3] ) or library injection (as was done for SMS in [16]). After many trials and errors, we settled on using card emulation with a collection of off-the-shelf NFC hardware. Charlie Miller: Exploring the NFC Attack Surface For the tag types which had working card emulation functionality, we could fuzz the protocol level and application level. We could potentially fuzz the Initialization, Anti- Collision, and Protocol Activation layer but there isn't much data there so it was determined not to be a good use of time. We could not fuzz the RF layer without a fully working software defined radio (SDR) NFC stack. Figure 7, below, shows which protocols could be tested with this approach. Physical ChancltriWic* MFC * ■jr.; r I | NFC Forum specification | | I, ■ | .. ill. I International standard Figure 7: Fuzzing using this setup can fuzz any of the areas indicated above Fuzzing setup If you want to simulate various NFC tags, you need to do what is called card emulation. This is where an NFC device acts like a passive tag. We were able to find a couple of pieces of hardware that could perform card emulation in some circumstances. Namely, an SCL 3711 Contactless Mobile Reader could be used with libnfc to do card emulation of a Type 2 Mifare UltraLight tag. An ACS ACR122U can do card emulation using libnfc of a Type 4 Mifare DESFire. Additionally, an SCL3711 can do LLCP transactions using nfcpy. Unfortunately, there is no support for other types of tags using libnfc or nfcpy. It would be interesting to add other tag types into libnfc for testing. Charlie Miller: Exploring the NFC Attack Surface Sometimes the hardware devices would hang and need to be restarted. This cannot be accomplished in software and has to be done in hardware. In order to simulate unplugging and replugging the USB card reader into the computer, we use a USB hub that implements port power control. In particular, we used a DLink DUB-H7 7-Port USB Hub. Therefore, the hardware set-up looks something like that in Figure 8, below. Figure 8: Fuzzing hardware setup The final step in fuzzing is to simulate someone placing the device onto the emulated tag. In some cases, you cannot just emulate the tag with a device already in the RF field of an NFC initiator. In order to simulate a device entering the field, a couple of options are available. The first is to kill the NFC process and restart it when the tag is being emulated. A slightly nicer way is to issue the SIGSTOP and SIGCONT signals, respectively, to simulate removing/placing the Nexus S NFC reader. A final way was to enable and disable the NFC service, in the same way the Settings application does it in Android. Fuzzing test cases In general, there are two ways to generate fuzzing test cases, generation based and mutation based. For generation based, we create test cases from "scratch", using the specification as a guide. For mutation based fuzzing, we take existing valid data and inject faults into it. One of the interesting things about fuzzing is that it turns out using Charlie Miller: Exploring the NFC Attack Surface multiple fuzzers is often superior to using a single fuzzer. Therefore, we use an approach to try to use both mutation and generation based fuzzers as well as incorporate a couple of different types of mutations to add to the valid data. Protocol layer fuzzing On the protocol level, we used only a mutation-based approach since the fields being fuzzed were so simple. We are constrained by the hardware and software which can do device emulation. We only have the ability to emulate Type 2 and Type 4 tags as well as perform basic LLCP connections. For these three types, we can fuzz at a low level, just after the anti-collision. For other types of cards or transactions, we cannot fuzz at a low level. In particular we cannot fuzz Type 1 (Topaz) or Type 3 (FeliCa) protocols at this time. For this low level fuzzing for tags, we used the nfc-emulate-forum-tag2 and nfc-emulate- forum-tag4 programs which come with libnfc, modified to present different data before a valid NDEF was presented. For fuzzing low level Type 2 tags, we fuzz the non-NDEF bytes in the MiFare Ultralight's memory. Namely, this includes the first 16 bytes of the static memory structure (see section 2.1 in [7J). For type 4 tags, we fuzz the Capability Container file, see section 5.1 of [9|. For LLCP, we use modified versions of the nfcpy software suite. In particular, we fuzz the CONNECT packet and the I (Information) packet (see 4.3.10 in [10] ) of the connection. For Android we used the nfcpy script npp-test-client and for for the Nokia N9, we used the snep-test-client. NPP is the NDEF Push Protocol which is used by Android [17] . SNEP is the Simple NDEF Exchange Protocol used by Nokia and other devices [18] . Application layer fuzzing Application layer fuzzing involves creating fuzzed NDEF messages and getting them to the device using one of the available low level protocols. As in the low level protocols, we start with a mutation-based approach. We took many different types of NDEF messages and added mutations to them. Additionally, we utilized a generation-based approach to create more specialized NDEF fuzzing test cases. For this, we utilize the Sulley Fuzzing Framework. We created 11 different test case generation scripts (ndef_*.py) based on a modified version of Sulley. Each will generate many thousands of NDEF test cases to STDOUT. For example, $ . /ndef_short_uri . py | grep -v " A \[" D1010B55 3 6333 6333 93 934 37 3 931 D1010B550 13 6333 6333 93 934373 931 D1010B55 02 3 6333 6333 93 934 37 3 931 D1010B55 33 6333 6333 93 934 37 3 931 Charlie Miller: Exploring the NFC Attack Surface D1010B55043 6333 6333 93 934 37 3 931 D1010B55 53 6333 6333 93 934 37 3 931 D1010B55 63 6333 6333 93 934 37 3 931 D1010B55073 6333 6333 93 934373 931 D1010B550 83 6333 6333 93 934373 931 D1010B55 93 6333 6333 93 934 37 3 931 In the above output, the fifth byte is being mutated. $ . /ndef_short_uri . py | grep "total cases" [10:08.08] fuzzed of 1419 total cases Sulley is designed to do everything from test case generation to sending and monitoring during fuzzing. Since we tend to fuzz esoteric devices, it is not well suited for this, and so my modifications to Sulley are mostly to allow it to print out test cases in a way which are easily read by another program which will be responsible for sending the test cases and monitoring the test device. Results - Nexus S We fuzzed the NFC stack on a Nexus S phone running Android 2.3.3 with the above approaches. This was the most current version when we started fuzzing and I believe is the most up to date version for an AT&T Nexus S using default methods of upgrade. Protocol Layer A total of 12,000 test cases were developed and tested against the low level NFC protocols, see below for details. Device Type Test cases Results/notes Nexus S Type 2 (UL) 4000 18 bytes of MiFare UL memory Mi Fare 1k/4k Cannot emulate at this time Type 4 (DESFire) 4000 15 bytes of Capacity Container ISO 14443A-4 (PDU) Nothing interesting to fuzz Type 1 (Topaz) Cannot emulate at this time Type 3 (FeICa) Cannot emulate at this time LLCP - Connect 2000 19 bytes of information, some crashes Charlie Miller: Exploring the NFC Attack Surface Device Type Test cases Results/notes LLCP - 1 2000 13 bytes of header information, some crashes Application Layer A total of 52362 test cases were performed against the Nexus S. See below for details. Device Type Test cases Results/notes Nexus S NDEF - bitflip 9000 Mutation-based NDEF - short text 1626 Generation-based NDEF - short URI 538 Generation-based NDEF - short SMS 1265 Generation-based NDEF - short SP 3675 Generation-based NDEF - short BT 1246 Generation-based NDEF - long text 2440 Generation-based NDEF - long vcard 32572 Generation-based Android - Crashes The most common crash found was of the Tags application, which is the default Android NFC tag reader application. This application is written in Java and so crashes correspond to Java exceptions and not, for example, memory corruption. See Figure 9, below, for an example of what a crash looks like on the phone. Charlie Miller: Exploring the NFC Attack Surface m □ f # iSi $ n mi ■ 11:05 A Sorry! The application Tags (process com.google.android.tag) has stopped unexpectedly. Please try again. loucn & noia an item ana wnen it vibrates, drag it where you want. Figure 9: Tags application dying The log reveals E/NfcService (17875) : failed to parse record E/NfcService (17875) : java . lang .Array IndexOutOfBoundsException E/NfcService (17875) : at com . android . nfc . NfcService $Nf cServiceHandler . pars eWellKnownUriRe cord (NfcService.j ava : 2 57 ) E/NfcService (17875) : at com . android . nfc . NfcService $Nf cServiceHandler . setTypeOrDataFromNdef (NfcService.j ava : 2 61 6) E/NfcService (17875) : at com . android . nfc . NfcService $Nf cServiceHandler . dispatchTaglnternal (NfcService.j ava : 2713) During low level fuzzing, a different (Java) application, the NFC Service, was also seen to crash, shown in Figure 10, below. The NFC Service is the default Android NFC processing service. . Charlie Miller: Exploring the NFC Attack Surface $ D nil ■ 1:57 A Sorry! The application Nfc Service (process com.android.nfc) has stopped unexpectedly. Please try again. Force close Report Touch & hold an item and when it n> if vibrates, drag it where you want. rjl 3 of 6 Figure 10: The NFC service is prone to Java exceptions The log corresponds to something like the series of exceptions below: D/Ndef PushServer ( 3130): j ava . io . IOException D/NdefPushServer ( 3130): at com . android . inte rnal. nfc. LI cpSocket. receive (LI cpSocket.j ava : 1 93 ) D/NdefPushServer ( 3130): at com . android . nf c . ndefpush . Ndef PushServer $ Connect ionThread . run (Ndef PushServer . j ava : 7 ) D/Ndef PushServer ( 3130): about to close W/dalvikvm( 3130): threadid=8 : thread exiting with uncaught exception (group=0x40015560) E/AndroidRuntime ( 3130): FATAL EXCEPTION: Ndef PushServer E/AndroidRuntime ( 3130): java . lang .NegativeArraySizeException E/AndroidRuntime ( 3130): at com . android . nf c . ndefpush . Ndef PushPro toco 1 . (Ndef PushPro toco 1 . j ava : 97 ) E/AndroidRuntime ( 3130): at com . android . nf c . ndefpush . Ndef PushServer $ Connect ionThread . run (Ndef PushServer . j ava : 8 6 ) Charlie Miller: Exploring the NFC Attack Surface Java exceptions are generally pretty boring from a security perspective. However, we did find a few native code crashes in the handling of LLCP packets. One appears to be a null pointer dereference caused by sending a CC (Connection Complete) packet before a CONNECT packet. Other crashes may be more interesting and occur in libc. One frequent crash address found corresponds to a call to abort() in libc. Normally this isn't very interesting because programs may call abort when they see something has gone wrong, which in fuzzing, is all the time! However, there is a chance it is significant because the exception may indicate memory corruption. One crash log from an interesting Java exception is: D/Ndef PushServer (13178) : starting new server thread D/Ndef PushServer (13178) : about create LLCP service socket D/Ndef PushServer (13178) : created LLCP service socket D/Ndef PushServer (13178) : about to accept D/NFC JNI (13178) : Discovered P2P Target D/NfcService (13178) : LLCP Activation message E/NFC JNI (13178): phLibNf c_Llcp_CheckLlcp ( ) returned OxOOf f [NFCSTATUS_FAILED] I/DEBUG ( 73) : *** *** *** *** *** *** *** *** *** *** *** *** *** *** * * * * * * I/DEBUG ( 73): Build fingerprint: ' google/sojua/crespo : 2 . 3 . 3/ GRI54/ 10553 6: user /release-keys ' I/DEBUG ( 73): pid: 13178, tid: 13178 »> com . android . nfc «< I/DEBUG ( 73): signal 11 (SIGSEGV), code 1 ( SEGV_MAPERR) , fault addr 0000000c I/DEBUG ( 73) rO afd46494 rl 00000004 r2 00000000 r3 afd46450 I/DEBUG ( 73) r4 00295530 r5 afd46450 r6 00000000 r7 40002410 I/DEBUG ( 73) r8 00000001 r9 0000008a 10 00000002 fp bed9725c I/DEBUG ( 73) ip afd46474 sp bed97220 lr afdl0e60 pc afdl3d06 00000030 I/DEBUG ( 73) dO bed9734806293705 dl 0000000080542286 I/DEBUG ( 73) d2 000000060000008a d3 0000001500000075 I/DEBUG ( 73) d4 8040a46f OOOOOOld d5 8040a48f 00000013 I/DEBUG ( 73) d6 8040a4b600000014 d7 8040a4cc00000015 I/DEBUG ( 73) d8 0000000000000000 d9 0000000000000000 I/DEBUG ( 73) dlO 0000000000000000 dll 0000000000000000 I/DEBUG ( 73) dl2 0000000000000000 dl3 0000000000000000 I/DEBUG ( 73) dl4 0000000000000000 dl5 0000000000000000 I/DEBUG ( 73) dl6 0000000740af Oaf dl7 3fe999999999999a I/DEBUG ( 73) dl8 42eccefa43de3400 dl9 3fbc71c71c71c71c I/DEBUG ( 73) d2 4008000000000000 d21 3fd99a27ad32ddf5 I/DEBUG ( 73) d22 3fd24998d6307188 d2 3 3fcc7288e957b53b I/DEBUG ( 73) d2 4 3f c74721cad6b0ed d2 5 3fc39a09d078c69f I/DEBUG ( 73) d2 6 0000000000000000 d2 7 0000000000000000 I/DEBUG ( 73) d2 8 0000000000000000 d2 9 0000000000000000 I/DEBUG ( 73) d3 0000000000000000 d31 0000000000000000 I/DEBUG ( 73) scr 60000012 I/DEBUG ( 73) I/DEBUG ( 73) #00 pc 00013d06 /system/lib /libc. so I/DEBUG ( 73) #01 pc 000144be /system/lib /libc. so I/DEBUG ( 73) #02 pc 0004375c / system/ lib/ libnfc . so I/DEBUG ( 73) #03 pc 00042b84 / system/ lib/ libnfc . so Charlie Miller: Exploring the NFC Attack Surface I/DEBUG ( 73) #04 pc 000433f4 /system/lib/libnf c . so With some investigation you can see that the source code, found in com_android_nfc_NativeNfcManager.cpp, reveals a classic double-free. 2047 /* Llcp methods */ 2048 2049 static j boolean com_android_nf c_Nf cManager_doCheckLlcp ( JNIEnv *e, j object o) 2050 { 2 051 NFCSTATUS ret; j boolean result = JNI_FALSE ; struct nf c_jni_native_data *nat; 2054 struct nf c_jni_callback_data *cb_data; 2055 2056 2 05 7 CONCURRENC Y_LOCK ( ) ; 2058 /* Memory allocation for cb_data */ 2060 cb_data = (struct nf c_jni_callback_data* ) malloc ( sizeof ( nf c_jni_callback_dat a)); if (ret != NFCSTATUS_PENDING && ret != NFCSTATUS_SUCCESS ) 2082 { LOGE ( "phLibNf c_Llcp_CheckLlcp ( ) returned Ox %04x[%s]", ret, nf c_jni_get_status_name ( ret ) ) ; 2084 free(cb_data) ; goto clean_and_return; 2086 } 2101 clean_and_return : 2102 nf c_cb_data_deinit (cb_data) ; 2103 CONCURRENC YJJNLOCK ( ) ; 2104 return result; 2105 } The problem is that nfc_cb_data_deinit also calls free() on the buffer cb_data. This vulnerability was fixed in ICS (4.0.1) by Google without my help. You can see by the logging statement bolded in the crash log, this crash really is from this double free. The fix can be seen in the git here: http://21 8.21 1 .38.204/?p=android/platform/packages/apps/ Nfc.git:a=commitdiff:h=0ce29d75b2e19075f9f287a6bdfd92a7c7e91c13:hp=4467dca565 0a1 70af5020c1 0a8ccb25f86f 1 007f Even though the issue was fixed in ICS, it can still be problematic. For example, all Gingerbread devices with NFC would still have this vulnerability. In fact, over 92% of Android devices still run Gingerbread [19] . Charlie Miller: Exploring the NFC Attack Surface Some other crashes were found during our testing as well which seem likely to be memory corruption vulnerabilities. Due to the fact that logging messages are different than those seen in the last crash we know they are different than the last crash but we could not reliably reproduce them enough to actually find the root cause of these bugs. Some of the backtraces are given below where we've added function names in braces to illustrate more clearly the nature of the crashes. The first one is a call to abort() from dlmalloc. It is typical to call abort from dlmalloc if the heap is corrupted in some manner. I /DEBUG ( 73) #00 pc 00015ca4 /system/lib/libc . so I/DEBUG ( 73) #02 pc 0001423e /system/lib/libc . so I/DEBUG ( 73) #03 pc 000142ac /system/lib/libc . so I/DEBUG ( 73) #04 pc 0001451a /system/lib/libc . so I/DEBUG ( 73) #05 pc OOOlabfO /system/lib/libbinder . so Oneiroid : : Parcel : continueWrite> I/DEBUG ( 73) #06 pc OOOladOc /system/lib/libbinder . so Oneiroid: : Parcel : growData> I/DEBUG ( 73) #07 pc 0001ae68 /system/lib/libbinder . so Ondroid: : Parcel : writelnplace> DEBUG ( 73) : #08 pc 0001aea8 /system/lib/libbinder. so Ondroid : : Parcel : writeStringl6> DEBUG ( 73) : #09 pc 0001aed4 / system/ lib/ libbinder . so Ondroid : : Parcel : writeStringl6> DEBUG ( 73) : #10 pc 0001aef8 /system/lib/libbinder. so Ondroid: : Parcel : writelnterf aceToken> Another crash seen was from a call to abort from dlfree(). This usually occurs due to heap corruption. D/NFC JNI (27180): phLibNf c_Mgt_UnConf igureDriver ( ) returned 0x0000 [NFCSTATUS_SUCCESS] A M A M I/DEBUG ( 73) : #00 pc 00015ca4 /system/lib/libc . so I/DEBUG ( 73) : #01 pc 00013614 /system/lib/libc . so I/DEBUG ( 73) : #02 pc 000144da /system/lib/libc . so I/DEBUG ( 73) : #03 pc 0004996e /system/lib/libdvm. so I/DEBUG ( 73) : #04 pc 00053fda / system/ lib/ libdvm. so I/DEBUG ( 73) : #05 pc 000494da /system/lib/libdvm. so I/DEBUG ( 73) : #06 pc 00005310 /system/lib/libnf c jni. so I /DEBUG ( 73) : #07 pc 000118e4 /system/lib/libc. so <_thread_entry> An almost identical backtrace was observed except instead of abort being called, it actually crashed in dlfree: D/NFC JNI (27180): phLibNf c_Mgt_UnConf igureDriver ( ) returned 0x0000 [NFCSTATUS_SUCCESS] A M A M I/DEBUG ( 73): #00 pc 00013256 /system/lib/libc . so I/DEBUG ( 73): #01 pc 000144da /system/lib/libc . so I/DEBUG ( 73): #02 pc 0004996e /system/lib/libdvm. so Charlie Miller: Exploring the NFC Attack Surface This crash occurs in unlink_large_chunk inside dlfreeQ when dereferencing p->bk. A final call to abort from dlmalloc was seen during initialization, I /DEBUG ( 73) I/DEBUG ( 73) I/DEBUG ( 73) I/DEBUG ( 73) I / DEBUG ( 73) : I/DEBUG ( 73) : #00 pc 00015ca4 /system/lib/libc . so #01 pc 00013e08 /system/lib/libc . so #02 pc 000144be /system/lib/libc . so #03 pc 000509c8 /system/lib/libdvm. so #04 pc 000533f8 /system/lib/libdvm. so #05 pc 00053454 /system/lib/libdvm . so Since these crashes are not reliably reproducible, it is hard to say if they are all separate or a single bug, or even if they are fixed or not, without further testing and analysis. Results - Nokia N9 We also fuzzed the NFC stack on a Nokia N9 running MeeGo 1 .2 Harmattan PR1 .2 with the same approaches described above. Protocol Layer A total of 12,000 test cases were developed and tested against the low level NFC protocols, as described below. Device Type Test cases Results/notes Nokia N9 Type 2 (UL) 4000 18 bytes of MiFare UL memory Mi Fare 1k/4k Cannot emulate at this time Type 4 (DESFire) 4000 15 bytes of Capacity Container ISO 14443A-4 (PDU) Nothing interesting to fuzz Type 1 (Topaz) Cannot emulate at this time Type 3 (FeICa) Cannot emulate at this time LLCP - Connect 2000 19 bytes of information LLCP - I 2000 13 bytes of header information Application Layer A total of 34852 test cases were performed against the Nokia N9. See below for details. Charlie Miller: Exploring the NFC Attack Surface Device Type Test cases Results/notes Nokia N9 NDEF - bitflip 9000 Mutation-based NDEF- short text 1626 Generation-based NDEF - short URI 538 Generation-based NDEF - short SMS 1265 Generation-based NDEF - short SP 3675 Generation-based NDEF - short BT 1246 Generation-based NDEF - long text 2440 Generation-based NDEF - long vcard 15062 Generation-based Crashes No crashes were detected. Nokia N9 stack FTW, or more likely, my method is flawed in some manner. NFC higher level code So far we have considered the NFC stack responsible for communicating and obtaining NDEF messages from the outside world. Clearly this is an important part of the attack surface, but it is really just the first piece of the puzzle. What remains to be seen is what the mobile device does with the NDEF data when it receives it. This section answers that question and sees what other components of the device are related to NFC and can be activated and used without user interaction. Nexus S - Android 2.3.3 The first device we reviewed was a Nexus S running Android 2.3.3. As of now, there is no supported way to update a Nexus S with AT&T baseband to Android 4. This device's support of NFC is pretty basic. Out of the box, NFC is enabled but doesn't do a whole lot. The device will process NFC data presented to it anytime the screen is on (even if the device is locked). Charlie Miller: Exploring the NFC Attack Surface NFC intents are handled by the Tags application, see Figure 11 , below. ■ Q f i i ^ II nil I 11:14 Figure 11 : Tags processing an NFC Smart Poster This Java application just displays the contents but takes no real action. If you tap on the URL, it will open up the application indicated (in this case Browser) with the included data, in this case a URL. By default, the Tags application handles NFC data, but other applications can register for that intent as well. When this happens, depending on the configuration of the app, the new app either handles the NFC data instead of Tags or allows the user to choose which app to handle NFC data, as in Figure 12, below. Charlie Miller: Exploring the NFC Attack Surface ra E y v i ^ D mi i 11:25 Figure 12: The user may choose which app to handle the NFC tag The Tags application can display data from the following categories defined in src/com/ android/apps/tag/message/NdefMessageParser.java in the Android source code: • Text • SMS • Smart Poster • Phone call • Vtag • URL • Image In general, outside of the NFC stack, there is not much on the attack surface of this Android phone. Large portions of the NFC code are written in Java, only a small amount of the codebase is actually native code. Galaxy Nexus - Android 4.0.1 The Galaxy Nexus is an Android phone running Ice Cream Sandwich. It still has some of the same features as the Nexus S, but ICS introduced Android Beam, which greatly increases the attack surface visible through NFC. Out of the box, the device has NFC enabled. It will process NFC data any time the screen is on and the device is unlocked Charlie Miller: Exploring the NFC Attack Surface For some types of NDEF data, it is exactly the same as the the Nexus S running Gingerbread, using com. android. nfc to hand data off to com. google. android. tag to display to the user. These types of data include: • Text • SMS • Phone • Image However, some types of data that used to be handled by Tags are now handled by Android Beam. Android Beam is a way for two NFC-enabled Android devices to quickly share data such as contacts, web pages, You Tube videos, directions, and apps, see [20]. One can determine which apps are enabled with Android Beam by searching the AndroidManifest.xml files to see which apps handle NFC intents. For example, looking at the Android Browser, we see: The only apps that register for these types of intents are Browser, Contacts, and Tags. When two devices are placed close to each other, if one of them is currently showing something that is "beamable", the device will prompt the user if they want to send it, as seen in Figure 13, below. Charlie Miller: Exploring the NFC Attack Surface Touch to beam Figure 13: Android asking a user to share the app they're using, in this case Crime City If the user chooses to beam it, the devices establish an LLCP connection and a simple NDEF message is passed from the device beaming to the other device. The data is sent via Simple NDEF Exchange Protocol (SNEP) with a fallback to NDEF Push Protocol (NPP), see [17.18.21] . In the end, however, the device does not act any differently whether a particular NDEF message is received via LLCP/NPP or simply read from a tag. In other words, the magic of Android Beam has nothing to do with establishing NFC connections between devices but rather relies entirely on how the device is configured to handle different NDEF messages when they arrive. What this means is that now instead of vtags and smart posters being processed by the Tags application, this data is now directly passed to the Contacts or Browser applications. Just to reiterate, this means that on ICS devices, if an attacker can get the device to process an NFC tag, they can get it to visit a web site of their choosing in the Browser with no user interaction. Obviously, the Browser represents an extremely large attack surface, and in ICS, that attack surface is now available through NFC! The Android Browser will parse at least the following formats, if not more: Type File format Web related html CSS js xml Charlie Miller: Exploring the NFC Attack Surface Type File format Image bmp gif ico jpg wbmp svg png Audio mp3 aac amr ogg wav Video mp4 3pg Font ttf eot The way that Android beam works for the other advertised services is simply through URL handlers. In Android you can bring up Google Play (aka Android Marketplace), the Maps application, YouTube, etc. through special URLs passed to the browser. In other words, instead of the attack surface looking like Figure 1 . it really looks like Figure 14, below. Charlie Miller: Exploring the NFC Attack Surface Figure 14: Actual NFC attack surface if NFC can communicate with the browser Galaxy Nexus - Android 4.1.1 We briefly looked at a Galaxy Nexus running Jelly Bean. It is mostly the same as an ICS device. There are two small changes. One is that it supports NFC simple Bluetooth pairing, like the Nokia N9. However, it always prompts before allowing Bluetooth pairing over NFC. Figure 15 shows an example of the prompt. Charlie Miller: Exploring the NFC Attack Surface is ft m 1 8 58 Google \i 7 Are you sure you want to pair the Bluetooth device ? 1 tij Camera Google r3 Figure 15: Android displays a prompt before establishing a Bluetooth Pairing via NFC The other way Jelly Bean NFC differs is in regards to Android Beam. A few more applications are configured to accept NFC intents. The list is below. • BrowserGoogle • Contacts • Gmail • GoogleEarth • Maps • Phonesky • TagGoogle • YouTube Otherwise, the Jelly Bean build performs identically as an ICS build with regards to NFC. Nokia N9 - MeeGo 1.2 Harmattan PR1.3 The Nokia N9 is a phone running the MeeGo operating system. Out of the box it does not have NFC enabled. Once enabled, It will process NFC data anytime the screen is on. If the device is locked, it will process low level NFC data, but handles high level data differently. None of the attacks outlined later work if the N9 has the screen locked. Charlie Miller: Exploring the NFC Attack Surface Typically, when an NFC message is read, a process called conndlgs (Connectivity Dialogues) displays it to the screen, see Figure 16, below. I n Bookmark Its usa today http://usatoday.com View Discard Figure 16: conndlgs and its simple interface The conndlgs process will display options to "view" or "send" which will open up the appropriate corresponding application or cancel. For example, hitting view for text NDEFs opens up the notes application while hitting view for smart poster NDEFs opens up the web browser, called QTWebProcess. One exception to this rule is Bluetooth pairing. When the device receives an NDEF Pairing request, it automatically attempts to pair to the requesting device. Depending on user settings, this may or may not require user interaction, see Figure 17, below. By default, pairing does not require user interaction. Furthermore, if Bluetooth is disabled, when an NDEF Pairing request arrives, the device will enable Bluetooth for the user. Charlie Miller: Exploring the NFC Attack Surface 10:04 NFC Confirm sharing and connecting Figure 17: If the "Confirm sharing and connecting option" is enabled, it forces a prompt before Bluetooth sharing is performed Nokia N9's also have a similar mechanism to Android's Beam called Content Sharing. It is possible for one N9 to share data with another N9 over NFC (for small payloads) or over Bluetooth automatically set up via NFC. Using this mechanism one can force a Nokia N9 to display images in Gallery contacts in Contacts, videos in Videos, and documents such as .txt, .doc, .xls, .pdf, and so forth in Documents. It does not seem to be possible to force it to open the browser but just about everything else is possible. It does not require user interaction, even if the setting "Confirm sharing and connecting" is set to on. The thought of forcing the device to parse arbitrary PDF and MS Office formats is almost as frightening as having it open up web pages! One interesting thing is it doesn't seem to be possible by default to share audio files via the Music app. However, if you want to, you can share audio files by sharing them through the Videos app. Just set a breakpoint at open64 in the obex-client process, call print strcpy($rO, 7home/user/MyDocs/Movies/mv.mp3") hit continue and the audio file will be shared. The following is a list of the file formats which can be shared though content sharing. Charlie Miller: Exploring the NFC Attack Surface App File type Library used (if known) Contacts vCard Gallery png libpng 1.2.42 - Jan 2010 jpg libjpg 6n - 1998 gif libgif 4.1.6 - 2007 bmp tiff libtiff 3.9.4 - Jul 2010 Videos (video-suite) mp4 wmv 3gp mp3 aac flac wma amr wav ogg Documents (office-suite) pdf poppler 16.6 - May 2011 txt doc(x) docximport.so - KDE 4.74 - Dec 2011 xls(x) xlsximport.so - KDE 4.74 ppt(x) powerpointimport.so - KDE 4.74 Charlie Miller: Exploring the NFC Attack Surface V llUNFGLLCFApi. ^ SO nfcd IIQrjFCNDEP.SO N A UbNFGLIBMSG O.SO JIDMFCLLGFCOf S.SO JltJNFGSTAGKA Pl.SO v. IIMFC5TAGK.E HtJNJtP NFC H ALSO UDNFGDAL V J HDNFCD5ALS0 Figure 18: Actual Nokia N9 attack surface Possible attacks Looking at the above discussion, there are a few avenues of attack. We'll discuss a few in detail. In each of them we assume an attacker can get close enough to an active phone to cause an NFC transaction to occur. We also assume that the screen is on and, when necessary, the device is not locked. This might be getting very close to someone using their phone, putting a device next to a legitimate NFC payment terminal, or using some kind of antenna setup to do it across the room, see [22] . From [23], active reads have been made of NFC from a distance of up to 1 .5 meters. Android NFC Stack bug If one were to exploit one of the NFC stack bugs shown earlier in Android, you could imagine exploiting it and getting control of the NFC Service. This isn't necessarily the best process for an attacker to control. If you look at the AndroidManfiest.xml file for com. android. nfc, you see it does not contain Internet permissions. It will be difficult for an attacker to exfiltrate data over the Internet without this permission, although it is possible, see [24] . However, the NFC Service does have BLUETOOTH and BLUETOOTH_ADMIN, so it is probably possible to establish a Bluetooth connection Charlie Miller: Exploring the NFC Attack Surface with the attacker. As we'll see for the N9 below, if an attacker can bluetooth pair with the device, it is possible to take complete control of the device. Android Browser Since an attacker can force an active device to display an arbitrary web page, armed with an Android browser exploit, an attacker can compromise an active device with an NFC tag. In this case, the attacker will be running code in the browser itself and not in the NFC service. N9 Bluetooth pairing If the N9 has NFC enabled and does not have "Confirm sharing and connecting" enabled (see Figure 17) , if you present it a Bluetooth Pairing message, it will automatically pair with the device in the message without user confirmation, even if Bluetooth is disabled. An example of such an NDEF message is [0000] d4 0c 27 6e 6f 6b 69 61 2e 63 6f 6d 3a 62 74 01 . . ' nokia . com : bt . [0010] 00 Id 4f 92 90 e2 20 04 18 31 32 33 34 00 00 00 ..0 1234... [0020] 00 00 00 00 00 00 00 00 00 0c 54 65 73 74 20 6d Test m [0030] 61 63 62 6f 6f 6b acbook In this message, a PIN is given as "1234", a Bluetooth address, and a name of the device are also provided. Once paired, it is possible to use tools such as obexfs, gsmsendsms, or xgnokii to perform actions with the device. Basically, if a user just enables NFC and makes no other changes to the device, it can be completely controlled by an attacker if the attacker can get it read an NFC tag. On the other hand, If you have "Confirm sharing and connecting" enabled, a prompt appears that looks like that seen in Figure 19, below. Charlie Miller: Exploring the NFC Attack Surface Connect? This device will be added as trusted Bluetooth device to enable easy connections via NFC Figure 19: The prompt raised if notification is required A similar attack against a Nokia 621 2 was outlined in [25] except the authors didn't know how to make the device complete the pairing process and so tried additional ways to try to activate the Bluetooth. Also, due to the fact they never succeeded in pairing, they uploaded an app instead of trying to control the device. Finally, on the 6212, by default, the device prompted before pairing where by default the N9 does not. N9 bugs If the victim has the Confirm sharing and connecting feature enabled, then the attacker will have to resort to Content Sharing as an attack vector. Recall that without user interaction, it is possible to force the Nokia N9 to parse and display a variety of file formats, oftentimes in outdated libraries. If one were to try to use PNG files, for example, the version of PNG shipped on the latest N9 firmwares is 1 .2.42. There are at least two critical vulnerabilities that have been found and patched since that release, as shown in [26] . If one wanted to find their own vulnerabilities, they would just have to spend some time fuzzing. To demonstrate this, we briefly fuzzed the Documents application on the Nokia N9. Here are a couple of interesting crashes that we found, as seen in valgrind. Charlie Miller: Exploring the NFC Attack Surface First a crash for PPT rendering, ==3572== Thread 2: ==3572== Invalid free () / delete / delete [] / realloc () ==3572== at 0x48347B4 free (vg replace malloc . c : 3 6 6 ) ==3572== by 0x5DE780F free mem (in /lib/libc-2 . 10 . 1 . so) ==3572== by 0x5DE71F7 libc freeres (in /lib/libc-2 . 10 . 1 . so) ==3572== by 0x48285B7 vgnU freeres (vg preloaded . c : 61 ) ==3572== by 0x5DB5AC3 libc enable asynccancel ( libc-cancellation . c : 6 6 ) ==3572== by 0x6826CAF ??? (in /lib/Iibglib-2.0.so.0.2800.4) ==3572== Address 0x7491f30 is not stack'd, malloc'd or (recently) free'd Here is one for PDF rendering. ==4002== Invalid write of size 1 ==4002== at 0x7290FB4: SplashXPathScanner : : clipAALine ( SplashBitmap* , int*, int*, int) (in /usr/lib/libpoppler . so . 13 . . ) ==4002== Address 0xf8dc5090 is not stack'd, malloc'd or (recently) free'd Finally, here is one in DOC rendering. (Note, this is a 0-day not only for Nokia N9 via NFC, but also for Koffice, which utilizes the same libraries). The following excerpt comes from the file koffice-2.3.3/filters/kword/msword-odf/wv2/src/styles.cpp. bool STD::read( U16 baseSize, U16 totalSize, OLEStreamReader * stream, bool preservePos ) grupxLen = totalSize - ( stream->tell ( ) - startOffset ) ; grupx = new U8 [ grupxLen ] ; int offset = ; for ( U8 i = 0; i < cupx; ++i) { U16 cbUPX = stream->readU16 () ; // size of the next UPX stream->seek ( -2, G_SEEK_CUR ) ; // rewind the "lookahead" cbUPX += 2; // ...and correct the size for ( U16 j = 0; j < cbUPX; ++j ) { grupxf offset + j ] = stream- >readU8 ( ) ; // read the whole UPX } In this function, it allocates a buffer for the array grupx based on a parameter passed to this function. It then fills in this array based on an unsigned short read in directly from the file, stored in the variable cbUPX. In this case, the length of a copy and the data being copied is read directly from the supplied file, which leads to an ideal heap overflow. Depending on the way memory is manipulated, it is possible to get control of the process using this vulnerability. Below demonstrates one such trial. Program received signal SIGSEGV, Segmentation fault. 0xl8ebffaa in ?? () (gdb) bt #0 0xl8ebffaa in ?? () #1 0x41f61f64 in wvWare :: Parser :: ~Parser ( ) () from /usr/lib/libkowv2 . so . 9 #2 0x41f6537c in ?? () from /usr/lib/libkowv2 . so . 9 #3 0x41f6537c in ?? () from /usr/lib/libkowv2 . so . 9 (gdb) x/2i 0x41f61f5c Charlie Miller: Exploring the NFC Attack Surface 0x41f61f5c <_ZN6wvWare6ParserD2Ev+232>: ldr rl2, [r3, #4] 0x41f61f60 <_ZN6wvWare6ParserD2Ev+236>: blx rl2 (gdb) print /x $r3 $3 = 0x41414141 In this case, a value read from the file is used as a pointer. This data where this pointer points is then read and used as a function pointer. With minimal work, this would lead to control of program flow and ultimately code execution. Summary Any time a new way for data to enter a device is added, it opens up the possibility of remote exploitation by an attacker. In the case of NFC, a user would typically think that the new data would be limited to just a few bytes embedded in an NFC tag. This document shows that the new attack surface introduced by NFC is actually quite large. The code responsible for parsing NFC transmissions begins in kernel drivers, proceeds through services meant to handle NFC data, and eventually ends at applications which act on that data. We provide techniques and tools to carry out fuzzing of the low level protocol stacks associated with NFC. At a higher level, for both the Android and MeeGo device we examined, it is possible through the NFC interface to make the device, without user interaction, parse web pages, image files, office documents, videos, etc which most users of NFC would probably be surprised to learn. NFC offers convenience to share files and games as well as make mobile payments. However, since anytime an attacker is in close proximity to a victim, she can force the victim's device to parse one of over 20 different formats without user interaction, it has to raise security concerns. Charlie Miller: Exploring the NFC Attack Surface Acknowledgements This was a long project, mostly out of my comfort zone. I'm sure I'm forgetting some people but here is a list of folks I'd like to thank for their help in no particular order. Accuvant: Gave me a paycheck while letting me do this work Cyber Fast Track: Partially funded all this work Josh Drake: Android exploitation help Crowdstrike (especially Georg Wicherski) For sharing and walking me through their Android browser exploit Michael Ossmann: GNU Radio help Travis Goodspeed: Help with N9 basics Kevin Finisterre: Bluetooth help Corey Benninger and Max Sobell: GNU Radio and basic NFC stuffs Collin Mulliner: For trying to help me do NFC memory injection, although I never used it Adam Laurie: For convincing me that you could do card emulation successfully Jon Larimer: For pointing out one of my crashes corresponded to the double free they fixed in 4.0.1 Shawn Moyer: For proofreading this doc! Charlie Miller: Exploring the NFC Attack Surface References [I] ISO 14443 Part 2: Radio frequency power and signal interface http:// www, waazaa. org/down load/fed- 1 4443-2 . pdf [2] NFC and GNU Radio, part 1, Miller, https://www.openrce.org/repositories/users/ camill8/nfc-usrp.pdf [3] NFC and GNU Radio, part 2, Miller, https://www.openrce.org/repositories/users/ camill8/nfc-usrp-2.pdf [4] ISO 14443 Part 3: Initialization and anticollision http://www.waazaa.org/download/ fcd-14443-3.pdf [5] Type 1 Tag Operation Specification http://apps4android.org/nfc-specifications/ NFCForum-TS-Type-1-Tag L1.pdf [6] Interview: Karsten Nohl http://www.thetechherald.com/articles/lnterview-Karsten- Nohl-Mifare-Classic-researcher-speaks-up/6954/ [7] Type 2 Tag Operation Specification http://apps4android.org/nfc-specifications/ NFCForum-TS-Type-2-Tag L1.pdf [8] Type 3 Tag Operation Specification http://apps4android.org/nfc-specifications/ NFCForum-TS-Type-3-Tag L1.pdf [9] Type 4 Tag Operation Specification http://apps4android.org/nfc-specifications/ NFCForum-TS-Type-4-Tag 2.0.pdf [10] Logical Link Control Protocol NFCForum-TS-LLCP_1 .1 [II] NFC Data Exchange Format (NDEF) http://www.maintag.fr/fichiers/pdf-fr/nfcforum- ts-ndef-1-0.pdf [12] NFC Record Type Definition (RTD) http://www.maintag.fr/fichiers/pdf-fr/nfcforum-ts- rtd-1-0-1.pdf [13] Text Record Type Definition http://www.maintag.fr/fichiers/pdf-fr/nfcforum-ts-rtd- text-1-0.pdf [14] proxmark3 http://proxmark3.com/ [15] NFC Digital Protocol ftp://ftp.heanet.ie/disk1/sourceforge/n/project/nf/nfsresearch/ Open%20NFC/custom_layout1 2.pdf [16] Fuzzing the Phone in your Phone http://www.blackhat.com/presentations/bh- usa-09/MILLER/BHUSA09-Miller-FuzzingPhone-PAPER.pdf [17] Android NPP push protocol http://source.android.com/compatibility/ndef-push- protocol.pdf [18] Simple NDEF Exchange Protocol Technical Specification [1 9] Platform Versions http://developer.android.com/resources/dashboard/platform- versions.html [20] Discover Android http://www.android.com/about/ [21] SNEP protocol and P2P response http://www.libnfc.org/community/topic/559/ android-nfc-snep-protocol-and-p2p-response/ [22] http://201 2.hackitoergosum.org/blog/wp-content/uploads/201 2/04/HES-201 2- rlifchitz-contactless-payments-insecurity.pdf [23] Long range NFC Detection, http://www.youtube.com/watch?v=Wwy8ButHbcU [24] Zero-Permission Android Applications http://leviathansecurity.eom/blog/archives/1 7- Zero-Permission-Android-Applications.html Charlie Miller: Exploring the NFC Attack Surface [25] Practical attacks on NFC enabled cell phones, Verdult and Kooman, http:// www.cs.ru.nl/~rverdult/Practical attacks on NFC enabled cell phones-NFC11.pdf [26] http://www.libpng.org/pub/png/libpng.html Other useful references: Securing Near Field Communications, Kortvedt, http://ntnu.diva-portal.org/smash/get/ diva2:347744/FULLTEXT01 ISO 14443 Library Reference Guide http://www.ti.com/rfid/docs/manuals/refmanuals/ RF-MGR-MNMN-14443-refGuide.pdf Near Field Communication http://en.wikipedia.org/wiki/Near field communication NDEF Push / Android Beam / NFC Tags Demo Applet http://grundid.de/nfc/ Charlie Miller: Exploring the NFC Attack Surface