Date post: | 18-Jan-2017 |
Category: |
Mobile |
Upload: | patrice-kerremans |
View: | 73 times |
Download: | 0 times |
Three and a half Roses - Patrice Kerremans
MOBILE SECURITYPATRICE KERREMANS
* Cloud part not yet included
Three and a half Roses - Patrice Kerremans
58% OF ALL DATA SECURITY THREATS COME FROM THE EXTENDED ENTERPRISEClear swift Report
Three and a half Roses - Patrice Kerremans
7% OF DATA SECURITY BREACHES COMES FROM FORMER EMPLOYEESClear swift Report
Three and a half Roses - Patrice Kerremans
7%
58%
35%
Extended Enterprise
Former Employees
Other
65%
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
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!
Three and a half Roses - Patrice Kerremans
MOBILE APP SECURITY
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
IT’S OUR RESPONSIBILITY
Three and a half Roses - Patrice Kerremans
SUPPLEMENTARY REQUIREMENTS FOR MOBILE DEVELOPMENT
‣ Covers:
‣ Security
‣ Privacy
‣ Performance
‣ Stability
‣ Architecture
‣ Development
High-level stuff, but refers to detailed documents (ie PCI)
Three and a half Roses - Patrice Kerremans
SOME EXAMPLES
Three and a half Roses - Patrice Kerremans
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.
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
SECURE CODING
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
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.
Three and a half Roses - Patrice Kerremans
BCMC
Three and a half Roses - Patrice Kerremans
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)
Three and a half Roses - Patrice Kerremans
BACK TO THE MISHAPS
Three and a half Roses - Patrice Kerremans
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/
Three and a half Roses - Patrice Kerremans
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.
Three and a half Roses - Patrice Kerremans
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.
Three and a half Roses - Patrice Kerremans
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!
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
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/
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
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.
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
TEXT
RAM IS NOT PROTECTED, NOR WIPED
▸ This is ostensibly far fetched, but may be a requirement from BCMC
Three and a half Roses - Patrice Kerremans
TEXT
LOGGING PASSWORDS
▸ pleeeeeeaaaaaase NEVER EVER log passwords
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
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.
Three and a half Roses - Patrice Kerremans
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)
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
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/
Three and a half Roses - Patrice Kerremans
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.
Three and a half Roses - Patrice Kerremans
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!
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
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
Three and a half Roses - Patrice Kerremans
▸ 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"));}