PiOSon POS: How Not to Make an iOS Mobile Point of Sale
description
Transcript of PiOSon POS: How Not to Make an iOS Mobile Point of Sale
© 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