mobile security: vulnerabilities, dos and don'ts

Three and a half Roses - Patrice Kerremans

MOBILE SECURITYPATRICE KERREMANS

* Cloud part not yet included


58% OF ALL DATA SECURITY THREATS COME FROM THE EXTENDED ENTERPRISEClear swift Report


7% OF DATA SECURITY BREACHES COMES FROM FORMER EMPLOYEESClear swift Report


7%

58%

35%

Extended Enterprise

Former Employees

Other

65%


TEXT

VULNERABLE APIS

▸ poorly secured APIs

▸ Trusting the client application

▸ Security by obscurity

▸ Real thief also come at night and bring flashlights, don't trust obscurity to protect you


TEXT

TRUSTING THE CLIENT BLINDLY

▸ Target was PCI Certified

▸ Got $1.6 Million malware detection tool

▸ Nonetheless malware installed in Target's security and payments system

▸ Alerting procedure existed but failed

▸ Do not trust processes with your life

▸ Do not trust the client


TEXT

CERTIFICATE AUTHORITY BREACHES

▸ Dutch CA was breached in 2011

▸ False certificates were created

▸ Hacker could pose as Google with valid certificate

▸ Trust certificates, but verify

▸ Pinning!


MOBILE APP SECURITY


163% INCREASE OF MOBILE MALWARE IN 2012

78% OF THE TOP 100 ANDROID AND IOS APPS HAVE BEEN HACKED

LESS THAN 5% OF POPULAR APPS CONTAIN PROFESSIONAL-GRADE PROTECTIONS TO

DEFEND AGAINST HACKING ATTACKS

40% OF POPULAR IOS APPS AND 80% OF THE SAME FREE ANDROID APPS WERE FOUND TO HAVE BEEN HACKED

http://autosend.io/mobile-app-security-guide/

2012


167% INCREASE OF MOBILE MALWARE IN 2014

http://www.forbes.com/sites/katevinton/2014/06/24/mobile-malware-is-on-the-rise-mcafee-report-reveals/#722c17d1cca4

2014

It’s only going to get worse :s

http://www.forbes.com/sites/katevinton/2014/06/24/mobile-malware-is-on-the-rise-mcafee-report-reveals/#722c17d1cca4


Using a compromised SSL version Not encrypting data

Encrypting data, but store the key on the

device

including secret keys from 3rd parties in app

logging sensitive data (keys!) No obfuscation Debug code is not

strippedNo verification done on data read from file

No extensive Root detection

No AntiDebug detection

RAM is not protected, nor Wiped

Disable caching in auto correction of OS

of sensitive data

Logging password PIN stored on device Not using HTTPS

SOME MOBILE MISHAPS


IT’S OUR RESPONSIBILITY


SUPPLEMENTARY REQUIREMENTS FOR MOBILE DEVELOPMENT

‣ Covers:

‣ Security

‣ Privacy

‣ Performance

‣ Stability

‣ Architecture

‣ Development

High-level stuff, but refers to detailed documents (ie PCI)


SOME EXAMPLES


TEXT

MUST: PAYMENT CARD INDUSTRY MOBILE PAYMENT ACCEPTANCE SECURITY GUIDELINES (PCI MPA)

All applications must comply with the Payment Card Industry mobile payment acceptance (if accepting payments).

The PCI MPA security guidelines have been introduced to secure mobile applications that offer payment functionalities to customers (many, if not most banking apps).

An important part is that you should never store card information on a device, unless it has been encrypted using a key that isn’t stored on the device.

Storing card information in truncated form is OK.

Another important part is that you should never send Personally Identifiable Information (PII) to cloud services or servers.


TEXT

SOME MORE RULES FROM PCI MPA

▸ 4.2 Create server-side controls and report unauthorized access

▸ 4.3 Prevent escalation of privileges —> Therefore, the device should be monitored for jail-breaking or rooting activity, and when detected the device should be quarantined by a solution that either removes it from the network or removes the payment acceptance application from the device

▸ 4.8 Conform to secure coding, engineering, and testing


SECURE CODING


MOBILE PAYMENT-ACCEPTANCE APPLICATIONS SHOULD CONFORM TO SECURE CODING, ENGINEERING, AND TESTING CONVENTIONS, SUCH AS THE REQUIREMENTS AND TESTING PROCEDURES OUTLINED IN THE PAYMENT APPLICATION DATA SECURITY STANDARD (PA-DSS). OTHER EXAMPLES INCLUDE CERT SECURE CODING STANDARDS , INSTITUTE FOR SECURITY AND OPEN METHODOLOGIES (ISECOM)'S OPEN SOURCE SECURITY TESTING METHODOLOGY MANUAL (OSSTMM) , OR INTERNATIONAL SYSTEMS SECURITY ENGINEERING ASSOCIATION (ISSEA)'S SYSTEMS SECURITY ENGINEERING CAPABILITY MATURITY MODEL (SSE-CMM – ISO/IEC 21827).

PCI Mobile Payment Acceptance Security Guidelines - July 2014

TEXT


TEXT

PA-DSSFor a payment application to be deemed PA-DSS compliant, software vendors must ensure that their software includes the following fourteen protections:

1. Do not retain full magnetic stripe, card validation code or value, or PIN block data. 2. Protect stored cardholder data. 3. Provide secure authentication features. 4. Log payment application activity. 5. Develop secure payment applications. 6. Protect wireless transmissions. 7. Test payment applications to address vulnerabilities and maintain payment application updates. 8. Facilitate secure network implementation. 9. Cardholder data must never be stored on a server connected to The Internet. 10.Facilitate secure remote access to payment application. 11.Encrypt sensitive traffic over public networks. 12.Encrypt all non-console administrative access. 13.Maintain a PA-DSS Implementation Guide for customers, resellers, and integrators. 14.Assign PA-DSS responsibilities for personnel, and maintain training programs for personnel, customers, resellers, and integrators.


BCMC


TEXT

BCMC = BANCONTACT / MISTER CASH

▸ have defined standards for decades with respect to bank cards in Belgium

▸ they now intend to do this for mobile payment apps as well

▸ They offer a neat way to do QR code based peer-to-peer payments

▸ Each app offering their functionality needs to comply with the BCMC security standards (for instance: no root allowed)


BACK TO THE MISHAPS


TEXT

USING A COMPROMISED SSL VERSION

The big problem with android systems is, that the default openssl library is shipped with the android system. Since not all device manufactures updating their android version right away (some never) your app is most likely using an old openssl version that is vulnerable to recent security issues.

http://blog.dev-area.net/2015/08/17/protect-your-android-app-against-ssl-exploits/

To enable TLS 1.1 and 1.2 you need to create a custom SSLSocketFactory that is going to proxy all calls to a default SSLSocketFactory implementation.

http://blog.dev-area.net/2015/08/13/android-4-1-enable-tls-1-1-and-tls-1-2/


TEXT

NOT ENCRYPTING DATA

Data used to be stored on the device in a non-encrypted format.

Either don’t store it (easiest and most secure ;) )

If really needed, store it in encrypted format (strong encryption please AES-256 minimal) & keep key on the server or require user to give PIN/password.


TEXT

LOGGING SENSITIVE DATALogs are very useful for developers

And also for hackers if developers log human readable information to logs!

Never log passwords (was happening before), never log card data or other personal data.


TEXT

WHAT IS PII DATA?

▸ PII = Personally Identifiable Information

▸ Basically any data that may lead to identifying a person

▸ Social Security Number

▸ Card Number (Typically traces back to one person)

▸ First and Last name

▸ Address

▸ IP-Address is often considered PII!


TEXT

WHAT IS PII DATA? - CONTINUED

▸ Zip Code, Age, Gender, Job, Car Type are by themselves non-PII

▸ BUT, combined they can PII

▸ Sometimes zip code and job is enough: 1020, King


TEXT

NO OBFUSCATION

▸ This makes it harder for hackers to find vulnerabilities in the code

▸ Don’t think security by obscurity is enough, but it is an additional level of defense

▸ On android: use pro guard!

▸ http://www.splinter.com.au/2014/09/16/storing-secret-keys/


TEXT

DEBUG CODE IS NOT STRIPPED

▸ Debug code: variable names, method names, class names, line numbers.

▸ Again, keeping debug code in the apps makes it easier for the hackers to find vulnerabilities

▸ When compile for production, don’t include debug information anymore.

./gradlew assembleRelease

set Strip Debug Symbols During Copy to YES for Release/Distribution


TEXT

NO VERIFICATION DONE ON DATA READ FROM FILE

▸ Do not expect data you read from file to be correct

▸ Don’t trust information read from files

▸ If possible sign it with a hash

▸ At the very least, verify what you load


TEXT

NO EXTENSIVE ROOT DETECTION

▸ From the PCI handbook:

Bypassing permissions can allow untrusted security decisions to be made, thus increasing the number of possible attack vectors. Therefore, the device should be monitored for jail-breaking or rooting activity, and when detected the device should be quarantined by a solution that either removes it from the network or removes the payment acceptance application from the device.


TEXT

NO ANTIDEBUG DETECTION

▸ Again, leaving the debug door open, allows hackers to trace the application, getting insights in vulnerabilities

▸ So the app should stop executing when it detects a debugger is attaching/attached to the phone, or when the app is running in an emulator

http://www.cs.northwestern.edu/~ychen/classes/cs450-w15/lectures/MobileObfuscation.pptx


TEXT

RAM IS NOT PROTECTED, NOR WIPED

▸ This is ostensibly far fetched, but may be a requirement from BCMC


TEXT

LOGGING PASSWORDS

▸ pleeeeeeaaaaaase NEVER EVER log passwords


TEXT

NOT USING HTTPS

▸ Anything sent over the wire/air without using HTTPS can be easily intercepted

▸ Hackers can just pose as some WiFi access point and start collecting data packets. Very easy and cheap (you hide it near a bar and start collecting everything).

▸ That’s why we require to do HTTPS


TEXT

PIN STORED ON DEVICE

▸ Don’t store the PIN on the device

▸ Not even in encrypted format

▸ because then it is subject to brute force attacks


TEXT

CARD INFO STORED ON DEVICE

▸ Don’t store the card number on the device

▸ do not just “mask it” on display, truncated it before storing it.


TEXT

SSL PINNING

▸ As we saw before even a Certificate Authority is subject to hacking

▸ To protect us against this, we implement pinning (btw: also a requirement from BCMC)


TEXT

FINALLY

▸ make sure you don’t manipulate sensitive data unless absolutely necessary

▸ encrypt in transit and pin connections

▸ if you need to store sensitive data, encrypt it with a server-side key, or better, store it at server-side.

▸ don’t trust the input your app gets, verify it is authentic

▸ Go through the different links in the document to make sure get a feeling on how you can do proper secure development


TEXT

SERIOUS ABOUT SECURITY

▸ One final example of what it means to be serious about security:how to do password verification securely

▸ https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/


TEXT

REQUIREMENTS

▸ PINs / Passwords should not be recognizable (can be used and other passwords can also be guessed from there)

▸ Not even Administrators, Root users or what have should have access to the passwords

▸ If the database with passwords is stolen it should be very hard to recover the passwords as to give users time to change their passwords.


TEXT

ATTEMPT ONE – STORE THE PASSWORDS UNENCRYPTED

T H E I D I O T S T O R I N G

P A S S W O R D S I N C L E A R

BTW:

Base64 encoding is as good as clear text!


TEXT

ATTEMPT TWO – ENCRYPT THE PASSWORDS IN THE DATABASE

▸ Don’t encrypt your password databases reversibly like this.

▸ The person with the key can reverse decrypt it


TEXT

ATTEMPT THREE – HASH THE PASSWORDS

▸ one way hash makes it impossible (euh, difficult) to know the password

▸ MD5(“mysecretpassword”) = “4cab2a2db6a3c31b01d804def28276e6”

▸ However, hackers have databases of frequently used passwords and their hashes

▸ Brute forcing MD5 isn’t that difficult either anymore.

▸ Using better algorithms (SHA-1, SHA-256) is better, but won’t last for long either


TEXT

ATTEMPT FOUR – SALT AND HASH

PASSWORD

▸ hash(“password”) hash(random_salt + “password”)

▸ but really random (not 1,2,3…)

▸ and a long random salt


TEXT

ATTEMPT FIVE – HASH STRETCHING

▸ hash the password

▸ then hash the hash

▸ then hash the hash of the hash

▸ repeat for 4000 times (or more as hackers get better equipment

▸ this is basically HMAC-SHA-256


▸ don’t go making it unless you’re a security expert

▸ get a security library for this :)

▸ In Java this is built-in by the way…

TEXT

FINAL ATTEMPT - USE A LIBRARY

public static String encode(String key, String data) throws Exception {

Mac sha256_HMAC = Mac.getInstance("HmacSHA256");

SecretKeySpec secret_key = new SecretKeySpec(key.getBytes("UTF-8"), "HmacSHA256"); sha256_HMAC.init(secret_key);

return Hex.encodeHexString(sha256_HMAC.doFinal(data.getBytes("UTF-8")));

}

public static void main(String [] args) throws Exception {

System.out.println(encode("key", "The quick brown fox jumps over the lazy dog"));}