© 2012

Presented by:

PiOSon POS:How Not to Make an iOS

Mobile Point of Sale

Mike ParkManaging Security Consultant

Trustwave SpiderLabs

© 2012

Who Am I• Mike Park• Managing Consultant, Application Security Services, Trustwave

SpiderLabs• 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

© 2012© 2012

The Business Problem:

© 2012

Lines Suck

© 2012

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

© 2012

What to Do?• What if every employee could have a cash

register, instead of just one?

© 2012© 2012

The Technical Problem:

© 2012

MOBILE!!• Give every worker a ‘cash register’ that

fits in their pocket

© 2012

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…

© 2012

MOBILE!!

You just need to build it….

© 2012© 2012

The Security Problem:

© 2012

A New Target for Thieves

© 2012

A New Target for Thieves

© 2012

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

© 2012© 2012

The Case Study:

© 2012

POS Gone Wrong

– This is based on multiple, real penetration tests conducted by SpiderLabs AppSec 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.

© 2012

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….

© 2012

What could go wrong???

© 2012© 2012

PiOSon POS Overview

© 2012

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.

© 2012

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.

© 2012© 2012

PiOSoned Login

© 2012

PiOSon POS

• Bad Authentication

© 2012

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

© 2012

PiOSon POS• Everyone’s Employee ID..

© 2012

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.

© 2012

PiOSon POS• Everyone’s Device ID..

© 2012© 2012

PiOSoned Transactions

© 2012

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’….

© 2012

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.

© 2012

PiOSon POS

• Bad Transaction Handling, Part 3

– How it works:• On the server, discount was accepted – giving me $3.00

© 2012© 2012

PiOSoned Credit Card Acceptance

© 2012

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

© 2012

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

© 2012

PiOSon POS

• Bad Credit Card Handling:

– Getting the interesting function to hook with class-dump-z:

© 2012

PiOSon POS

• Bad Credit Card Handling:

– Writing the hook code (uses Mobilesubstrate):

© 2012

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?

© 2012

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….

© 2012

PiOSon POS

• Screenshot of sensitive data

• Automatically captured• The encryption handler

for the card data is hooked, capturing the card data first.

• Input Card by Hand..

© 2012© 2012

The Antidote to PiOSon POS?

© 2012

PiOSon POS Antidote

Never…

© 2012

PiOSon POS Antidote

Never…

© 2012

PiOSon POS Antidote

Never…

© 2012

PiOSon POS Antidote

Never EncryptCredit Card Data

In Software!!!

© 2012

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.

© 2012

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…

© 2012

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?

© 2012

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

© 2012

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?

© 2012© 2012

Thanks

© 2012

Resources

• Download the Global Security Report: http://www.trustwave.com/GSR

• Read our Blog: http://blog.spiderlabs.com

• Follow us on Twitter: @SpiderLabs