PiOSon POS: How Not to Make an iOS Mobile Point of Sale

1. PiOSon POS:How Not to Make an iOSMobile Point of Sale Mike Park Managing Security Consultant Trustwave SpiderLabs

2. Who Am I • Mike Park • Managing Consultant, Application Security Services, TrustwaveSpiderLabs • 14+ Years of App development and security experience • Java, C\C++, ObjC, python, ruby, javascript • x86 and ARM v7 ASM with some exploit development and reverse engineering • Specializing in Mobile Application and Platform Penetration Testing

3. The Business Problem:

4. Lines Suck

5. Lines Suck • Customers who wait in line • Stand around • Abandoned sales • In a hurry • Inefficient use of resources – Person at the cash can be crazy busy while sales people stand around

6. What to Do? • What if every employee could have a cash register, instead of just one?

7. The Technical Problem:

8. MOBILE!! • Give every worker a ‘cash register’ that fits in their pocket

9. MOBILE!! • Give every worker a ‘cash register’ that fits in their pocket • Less line ups • Rolling totals • Fast pay • Look up product information immediately • Assist more customers == more money • Common now in retail, theatre, restaurants, rental car agencies at the airport…

10. MOBILE!! You just need to build it….

11. The Security Problem:

12. A New Target for Thieves

13. A New Target for Thieves

14. A New Target for Thieves • Because every worker has a ‘cash register’ in their pocket • More registers == More points of attack • Works best with Credit and Debit Cards, so more Card numbers being processed • From the Trustwave Global Security Report 2013, Retail is targeted in 45% of attacks, and Point of Sale is targeted 47% of the time • If you include Food and Beverage at 24% then industries that would make the most use of Mobile POS are targeted 70% of the time. • POS is already a major target for ‘cyber’ crime, this is just another form factor

15. The Case Study:

16. POS Gone Wrong • This is based on multiple, real penetration tests conducted by SpiderLabsAppSec team • No one app tested had all of these issues • A few had almost all of them • Composite to show just how bad things can get • Names have been changed to protect the innocent.

17. What do they have in common? • Accept Credit card via a mag-stripe reader or direct input • Allow employee’s to login to take orders • Store details of orders and transactions • Sync with backend systems, either in real-time or via store and forward. • Created fast to get to market first • Need to be done cheaply and pushed out to hundreds of locations • Run on iOS devices (iPod or iPads) to look hip and trendy….

18. What could go wrong???

19. PiOSon POS Overview

20. PiOSon POS • What does it do? • Typical workflow of a POS application: • Employee Logs In • Employee takes order information • Employee accepts credit card data • Employee completes the transaction. • Serious flaws can exist at each step if the app is created with haste or on the cheap • Some require jailbreak, but most do not.

21. PiOSon POS • A Word on Jailbreaking • “iOS7 is not jailbroken so I am safe” • iOS7 IS jailbroken on older devices, such as iPhone 4. • iOS7 does not have a PUBLIC jailbreak – there are known but unpublished jailbreaks for all versions of iOS7 • An exploit for iOS7 would be worth literally hundreds of thousands on the exploit market – you would not know about one anyway. • There are alternatives to jailbreaking that could work…. • “Apple doesn’t have Malware so I’m safe” • See above • “Jailbreak” is the public term for local root exploit. Never assume that because it doesn’t publicly exist that it doesn’t actually exist.

22. PiOSoned Login

23. PiOSon POS • Bad Authentication

24. PiOSon POS • Bad Authentication • How it works: • Employee is presented with a screen to enter their employee id • If the (4 digit) id matches, they are logged in and can use the device – no password required • Looked up in a local database • What could go wrong: • An attacker can gain access to the database WITHOUT a jailbreak using tools like libusbmux or iFunbox • Leaked information about ALL employees, regardless of store • 4 digits = only 10000 combinations and easily brute forced • Bad assumptions, bad design: • Can be used offline • Only employees will have access to devices

25. PiOSon POS • Everyone’s Employee ID..

26. PiOSon POS • Bad Authentication, Part 2 • How it works: • Seemed to also use the iPod’s device ID as part of the login to the backend system, to correlate where orders came from. • For some reason stored EVERY device ID for EVERY device in a local database • What could go wrong: • Leaked information about every device ID • What could you use a Device ID for? Build custom malware using a developer account built to a specific device, install and run without going through the App Store • Repurposed apps, like Jekyll. Spyware like FinSpy or FinFisher work this way. • Bad assumptions, bad design: • Can be used offline • Only employees will have access to devices • Device ID is not sensitive data – it is.

27. PiOSon POS • Everyone’s Device ID..

28. PiOSoned Transactions

29. PiOSon POS • Bad Transaction Handling: • How it works: • Employee is presented with a screen to items for a single transaction with a customer • They can select the type of item to purchase, the quantity and apply any discounts • The transaction is saved locally then either synced immediately with a store server, or synched later if in offline mode • Moves to payment (see next) • What could go wrong: • Allowed for arbitrary amounts, including negative amounts • Trusted a local list of prices when in offline mode • All of this can be accessed and altered WITHOUT a jailbreak • Bad assumptions, bad design: • Can be used offline • Only employees will have access to devices • Negative purchases must be ‘Returns’….

30. PiOSon POS • Bad Transaction Handling, Part 2 • How it works: • When synching with the backend, did not do full certpath verification or certificate pinning – easy to MITM • Uploaded data in JSON and trusted certain discount fields.

31. PiOSon POS • Bad Transaction Handling, Part 3 • How it works: • On the server, discount was accepted – giving me $3.00

32. PiOSoned Credit Card Acceptance

33. PiOSon POS • Bad Credit Card Handling: • How it works: • Employee or Client can either swipe their card or enter the number and CVV by hand • If swiped, the card’s PAN data is read, card information is encrypted using the server’s public key and stored then forwarded (immediately or later on in offline mode) • If typed in, the card number and CVV are read from a text field, card information is encrypted using the server’s public key and stored then forwarded (immediately or later on in offline mode) • What could go wrong: • ALL CARD DATA CAN BE INTERCEPTED BEFORE ENCRYPTION • Although this requires a jailbreak, lots of legacy systems still exist • Allows for the mass capture of credit card data by rogue devices. • Bad assumptions, bad design: • Can be used offline, only checks for Luhn compliance • Only employees will have access to devices • Cheap card readers that don’t encrypt at the head. • iOS7 will protect me

34. PiOSon POS • Bad Credit Card Handling, Part 2: • How the attack works: • Get a copy of the app and run class-dump-z against it. • Look for a function where you know the Credit Card information is going to be in the clear – Encrypt() perhaps? • Build the hooking code • Install on a device • ?? • Profit • Get the code on the device: • Temporarily steal or swap out a device • Jailbreak - ~10 minutes • Install malware - ~!2 minutes. • Return the device to service

35. PiOSon POS • Bad Credit Card Handling: • Getting the interesting function to hook with class-dump-z:

36. PiOSon POS • Bad Credit Card Handling: • Writing the hook code (uses Mobilesubstrate):

37. PiOSon POS • Bad Credit Card Handling: • Wait for someone to swipe or type and get credit card numbers: • …and grab them. • Exfiltration using Bluetooth, GameKit, Wifi, steal the device back… • Malicious insider?

38. PiOSon POS • Bad Credit Card Handling, Part 2: • More Bad assumptions, bad design: • If the device can’t read the card, allow the client or employee to type the credit card information into the device by hand. • Signing with a certificate installed on the device….

39. PiOSon POS • Input Card by Hand.. • Screenshot of sensitive data • Automatically captured • The encryption handler for the card data is hooked, capturing the card data first.

40. The Antidote to PiOSon POS?

41. PiOSon POS Antidote Never…

42. PiOSon POS Antidote Never…

43. PiOSon POS Antidote Never…

44. PiOSon POS Antidote Never Encrypt Credit Card Data In Software!!!

45. PiOSon POS Antidote • Better Choices in Design: • Never accept credit card information via user input: • If the reader or card is not working, send the user to the main cash. • If you accept card data entry via user input, then it is UNENCRYPTED in the device, even for a short period of time. • This will make you a target. • Never use a card reader that is not encrypting card data in hardware: • All card readers are capable of encrypting at the head, some are easier than others. • Cheap is not better – low initial costs, but high costs for key management. • These may require HSM to roll keys, while some better readers can do it OTA. • NEVER code around the foibles of the card reader – use a better reader.

46. PiOSon POS Antidote • Better Authentication and Storage Choices: • Use at least proper username and password for login: • Never store the ‘password’ in plaintext on the device. • Authenticate to the backend server as the user, not the device. • Don’t use Basic Auth • Consider Certificate Pinning to prevent MITM • Encrypt all device databases and files: • Consider PBKDF2 for encrypting and decrypting data and files. • Encrypt both the sensitive data itself as well as the entire database • For all of the above, do not store the key with the lock…

47. PiOSon POS Antidote • Better Transactions: • Sign all transaction: • Prevent data from being changed in transit by applying a digital signature. • Transaction in real time, rather than store and forward. • Check veracity of prices on the back end, not based on user-supplied data. • Is offline mode REALLY needed?

48. PiOSon POS Antidote • Always make the following assumptions (applies to all software, not just mobile POS): • Assume the software will run on a compromised device: • Design it to operate in the most secure manner, even if on a compromised device in the hands of an attacker – remember Shannon’s Maxim. • Assume the channel will be listened in on (hello NSA!): • Design and code it to operate in the most secure manner, even if the attacker can intercept and MITM the channel to the server. • Assume the device will be easily obtained by an attacker: • Design and code it to operate in the most secure manner, even if the attacker can gain physical access to the device. • Remember the Insider Threat – depending on the study, around 80% of attacks occur from insiders • Minimum wage retail worker+ easy access to easily hacked software + big bucks for credit card data = trouble

49. PiOSon POS Antidote • Always make the following assumptions, part 2: • Cheaper is not better: • Cheap card readers may end up being more expensive when key management is taken into account – don’t make up for bad initial choices by making more bad choices (not to encrypt at the head). • Cheaper devices + Cheaper card readers + the bad choices this forces = pwned. • Other Mitigating Controls: • Use an MDM to lock down and monitor the device. • Restrict the access to the devices network – can only login at the store it is registered too, only during business hours. • Wipe and restore from known good back ups regularly. • Anything that reduces the time and opportunity for the attacker to operate. • Location based encryption?

50. Thanks