Mobile Payment Security

Transcription

1 Mobile Payment Security Maurice Aarts & Nikita Abdullin Black Hat Sessions, 23 June 2016, Ede - NL

2 Content Introduction EMV & NFC for HCE Platform / ecosystem overview Attacker model Attacks and countermeasures Tools Things to keep in mind Conclusions 2

3 Content Introduction EMV & NFC for HCE Platform / ecosystem overview Attacker model Attacks and countermeasures Tools Things to keep in mind Conclusions 3

4 NFC transaction evolution (1) Secure Element transaction Issues: Coordination between multiple parties Issuers vs. SE vendors Mixed device support 4

5 NFC transaction evolution (2) Secure Element transaction HCE transaction 5

6 NFC transaction evolution HCE benefits HCE transaction Issuing banks are independent from SE vendors Agile development cycles and continuous application improvement 6

7 A security comparison Device Smartcard (Secure- Element) Hardware Security Software Security Smart Phone Can we run secure applications in a smartphone? 7

8 Conceptual transaction protection Terminal App User Transaction details Signed transaction Key Sign Approval request User approval Approve (PIN) Assets Key proves transaction participation PIN proves user consent 8

9 Android Payment Ecosystem Server for: Provisioning Authentication Key generation Risk mitigation data Point of Sale (PoS) Transaction info Payment network 9

10 Content Introduction EMV & NFC for HCE Platform / ecosystem overview Attacker model Attacks and countermeasures Tools Things to keep in mind Conclusions 10

11 Platform / ecosystem overview Sandbox Permissions App signing KeyStore 11

12 Main malware threats 1. Sign manipulated transactions Malware intercepts and change details in valid transaction 2. Sign arbitrary transactions Malware invokes signing function 3. Extract key Malware reads key Attacks are scalable! Malware Key Crypto App Mobile phone OS 12

13 Android vulnerabilities Source: 13

14 Rooting Rooting = getting system level access to all resources Files Memory Peripherals Interfaces All OS protection voids with rooting Rooting is achieved by exploiting an OS bug All attacks start by rooting 14

15 Rooting impact Any phone may be rooted Any application may be reversed Any asset may be compromised Is there any hope for mobile software security? 15

16 Content Introduction EMV & NFC for HCE Platform / ecosystem overview Attacker model Attacks and countermeasures Tools Things to keep in mind Conclusions 16

17 Attacker Model Varying levels of expertise From buyer of an exploit pack to expert black-box criminal attacker Can eventually achieve full control of the device Can mount scalable attacks Can interact with the legitimate users (spear-phishing, etc.) 17

18 Content Introduction EMV & NFC for HCE Platform / ecosystem overview Attacker model Attacks and countermeasures Tools Things to keep in mind Conclusions 18

19 Attacks vs. countermeasures Main concept: Endless psychological warfare on attackers Developer time / effort to release a new version vs. Deterrence / frustration of the attacker o Attacker has a budget, too o Compartmentalization of the assets limits damage o Agile development cycle helps to stay ahead of the attackers 19

20 Root Detection 20

21 Root Detection Attack! 1. Change device property to release-keys 2. Rename each of the files if they exist. An attacker doesn t care if the file is called Superuser.apk or Xp@suwn$55.apk, as long as it works. 3. Change the name of the su binary to something else, e.g. p0wn which will not trigger the check. 21

22 Debug and Emulation Detection What if we could modify these checks? 22

23 Hooking? Caller [e.g. read(x)==3 ] x Callee [e.g. x=3 ] Hook [e.g. read(x+7) ] 23

24 What can we do with hooking? 1. Inspect and log calls 2. Prevent calls o E.g. skip setting a flag that indicates security violation 3. Modify parameters o E.g. redirect communications to a malicious server 4. Modify return values o E.g. always return true after password check 5. Replace a function o E.g. hide suspicious files from the application 24

25 Debug and Emulation Detection We can just let checkdebuggable() and checkemulator() always return false! 25

26 Other anti-tamper techniques Run-time integrity checks (anti-instrumentation) Self-checking code (inline self-checks) Check APK package and binary code hashes Use vendor-supplied device profiling & risk assessment mechanisms Anti-debugging checks For Java: ask Android Framework Try to self-debug or do other profiling for native code Check environment variables & properties 26

27 Attacks on anti-tamper Make the environment more stealthy Move/rename binaries Intercept APIs in user-mode Use less invasive techniques Stealthy DBI approaches that do not use splicing Customize system images, emulators Android Kernel modules with kernel-mode hooks 27

28 Code Obfuscation (1) Goal: complicate human analysis of code Name obfuscation: make names meaningless e.g. encrypt( byte[] plain ); m1( byte[] p1 ); information lost, manual improvement possible String obfuscation: make strings incomprehensible e.g. String algo = AES/CBC/PKCS5Padding ; String s1 = m2( 802e8)Qjrq_zgF)2LUx ); automatic decryption possible if encryption is static Flow obfuscation: prevent decompiling and hide logic e.g. insert jump statements in binary incompatible with source code constructs; exploit decompiler analysis engines binary analysis and partial reconstruction still possible 28

29 Code Obfuscation (2) Goal: complicate human analysis of code Java Reflection/Class loaders: load bytecode dynamically e.g. com.my.core.crypto.rand(); a.getclass( ).getmethod( ); dynamic analysis or AST transformations needed to get the original code Native code obfuscation all state-of-the-art techniques, even slow ones o Self-modifying code o CFG flattening o Opaque predicates & bogus code inlining o Arithmetic transformations o Stack/register variable manipulation o dynamic analysis or advanced automation needed to get the original code+cfg 29

30 Code Obfuscation (3) Each of the lines represents control flow transfer between basic blocks of code Obfuscators can make CFG analysis much harder 30

31 Code Obfuscation (4) Goal: complicate human analysis of code A CFG in IDA, Chris Domas, Repsych: Psychological Warfare in Reverse Engineering, 2015 Impact: reverse engineering slowed down 31

32 Attacks on code obfuscation Automated deobfuscation Popular obfuscator tools will have deobfuscators Scriptable disassemblers/decompilers/debuggers Run-time code dumping Advanced program analysis Symbolic execution SAT/SMT solvers Java: bytecode runs on top of JVM, so attacks on the JVM level More manual effort 32

33 Device Binding Attackers may want to exfiltrate data + code and run it on another device So capture an unique fingerprint from inside the device Serial numbers/model strings/version/patch level/ Make cryptography device-dependent Use the device binding data in key derivation, etc. Use hardware-backed features when possible Hardware-backed KeyStore / TEE / 33

34 Attacks on Device Binding Identify code that does device binding scans Which code queries the serial number, etc. Intercept the device fingerprint if it is used in a different place from where it is captured Copy & spoof all well-known device properties on the OS level As the standard Android emulator source code already does 34

35 Secure Element - Overview Resists logical and physical attacks Strong mitigation of key exposure risk 35

36 Trusted Execution Environment Overview TEE is the new trend Clear split between Rich OS and TEE Resists logical attacks Fair mitigation of key exposure risk 36

37 Obfuscation: White-box Crypto (1) 37

38 Obfuscation: White-box Crypto (2) Strengths Algorithm code size multiplies Manual reverse engineering is tedious Diversification across instances Attack does not scale well Weaknesses White-box hides the key, not the function Attackers may still copy the entire WB function and run it externally (code lifting) Immature technology Attacks have already emerged (automation, side channel, fault injection, ) E. Sanfelix et al. Unboxing the White-Box. Practical attacks against Obfuscated Ciphers. Attacks-Against-Obfuscated-Ciphers-wp.pdf 38

39 Content Introduction EMV & NFC for HCE Platform / ecosystem overview Attacker model Attacks and countermeasures Tools Things to keep in mind Conclusions 39

40 Tools Static analysis Decompilation / Disassembly / Unpacking Dynamic analysis Debugging Tracing (code / API / ) DBI / Hooking Anti-anti-debugging / anti-root-detection / anti-anti-emulation Emulation / Replay Side channel / Fault Injection Domain-specific Libraries and helpers: EMV, NFC, crypto 40

41 Android attack tools Rooting tool e.g. Towelroot Development kit Inspection tool e.g. Androguard Decompiler e.g. JEB Riscure Disassembler e.g. IDA, JEB Inspector Debugger e.g. GDB, JDWP Side Channel / Fault Instrumenting Analysis e.g. ADBI, DDI, Frida, Substrate, Xposed, LD_PRELOAD 41

42 Content Introduction EMV & NFC for HCE Platform / ecosystem overview Attacker model Attacks and countermeasures Tools Things to keep in mind Conclusions 42

43 Things to Keep in Mind Distance in time and space raises attacker cost Limited Use Payment Credentials/Keys must be limited Back-end risk management & security controls Security is a moving target Development process has to outrun the attackers Continuous security evaluation Mobile platform security is far from smart card standards 43

44 Content Introduction EMV & NFC for HCE Platform / ecosystem overview Attacker model Attacks and countermeasures Tools Things to keep in mind Conclusions 44

45 Conclusion Smart phones are not secure platforms Mobile payment apps need additional security Several new concepts are emerging that may enable secure apps Evaluation can help identify & mitigate risk 45

46 Contact: Maurice Aarts Nikita Abdullin Riscure B.V. Frontier Building, Delftechpark XJ Delft The Netherlands Phone: Riscure North America 550 Kearny Street, Suite 330 San Francisco CA USA Phone:

47 Riscure is Hiring! Visit: