iPhone and iPad Security

Post on 09-May-2015

1.749 views 3 download

description

A webcast presentation covering some of the considerations faced when thinking about security of iPhone and iPad devices.

Transcript of iPhone and iPad Security

Mobility WebCastiPhone and iPad Security

Simon GuestDirector, Mobility Solutions

Neudesic, LLCsimon.guest@neudesic.com

Common Questions

I don’t want my employees doing [x]. How do I configure policy?

What happens if I leave my device on the [bus|train|plane]?

How do I secure communication from the device?

I’m writing an application. How do I make my application secure?

What other bad stuff should I be thinking about?

1 2 3 4 5Policy Data Network Application Bad Stuff

Agenda

1 2 3 4 5Policy Data Network Application Bad Stuff

Agenda

I don’t want my employees doing [x] on their device. How do I configure policy?

PolicyPasscode Policy

• First line of defense for device security• Prompts user for code, entered on

startup and wake• With no code, emergency calls only

Configuring on the Device

• Enforce on device (turn on/off)• Simple (4 pin) or Complex

(Alphanumeric)• Wipe on x incorrect attempts (default 10)• Used in combination with auto-lock

PolicyConfiguration Profile settings for Passcode

• Require passcode on device (Yes/No)• Allow simple (4 digit PIN) or alphanumeric• Passcode length (1 – 16 chars)• Minimum number of complex characters• Minimum passcode age (None/1 – 730 days)• Auto lock (None/1-5 mins)• Passcode history (None/1-50 passcodes)• Grace period for device lock (None to 4 hrs)• Max number of failed attempts (4 – 16)

PolicyConfiguration Profile settings for Passcode

• Require passcode on device (Yes/No)• Allow simple (4 digit PIN) or alphanumeric• Passcode length (1 – 16 chars)• Minimum number of complex characters• Minimum passcode age (None/1 – 730 days)• Auto lock (None/1-5 mins)• Passcode history (None/1-50 passcodes)• Grace period for device lock (None to 4 hrs)• Max number of failed attempts (4 – 16)

PolicyConfiguration Profile settings for Passcode

• Require passcode on device (Yes/No)• Allow simple (4 digit PIN) or alphanumeric• Passcode length (1 – 16 chars)• Minimum number of complex characters• Minimum passcode age (None/1 – 730 days)• Auto lock (None/1-5 mins)• Passcode history (None/1-50 passcodes)• Grace period for device lock (None to 4 hrs)• Max number of failed attempts (4 – 16)

PolicyPasscode Policy

• First line of defense for device security• Defaults to 4 digit pin code, entered on

startup and wake

Device Settings

• Enforce on device (turn on/off)• Simple (4 pin) or Complex (Alphanumeric)• Wipe on x incorrect attempts (default 10)• Used in combination with auto-lock

Policy

PolicyRestrictions on Device Features

• Installing Apps, Camera, Facetime, Screen Capture, Sync while Roaming, Voice Dialing, In App Purchases, Multi-player Gaming, Game Center Friends

Restrictions on Applications

• Access to YouTube, iTunes, and Safari (various settings)

Content Rating Restrictions

• Regional setting, with maximum content ratings across Movies, TV Shows, and Apps

PolicyAdditional Settings for Configuration

• WiFi access point• VPN• Email• ActiveSync• LDAP Directory• CalDAV• CardDAV• Subscribed Calendars• Web Clips

Above are not restrictions (with the exception of Web Clip removal)

PolicyAdditional Settings for Security

• SCEP (Simple Certificate Enrollment Protocol)• Auto-enrollment specification defined by

Cisco• Implemented in Windows Server 2008 R2

as Network Device Enrollment Service (NDES)

• iPhone Configuration Profile enables configuration for SCEP server URL. Also used for OTA configuration.

PolicyAdditional Settings for Security

• Advanced• Policy for GPRS access point, username,

and password. Policy for Proxy Server (but this is for GPRS access point only)

• Not possible to set Proxy Server for Wifi/3G networks (potential compromise with “evil profiles”)

Policy

• Distributing Profiles to Users– iPhone Configuration Utility

• USB cable directly to the device

– Export from Configuration Utility and Email• .mobileconfig (none, signed, encrypted for device)• Users do have the ability to get details on what

mobile config is doing

– Web Download “Configure iPhone Now link”• Similar to above, but via URL

Policy

• Mobile Device Management (MDM)– Remote Configuration

• Pushing of configuration profiles to the device

– Remote Query• Device, network, security, and application

information

– Remote Management• Remote wipe, remote lock, clear passcode, OTA

application delivery

Policy

• Mobile Device Management (MDM)– API Level

• MDMS APIs announced with iOS 4.2• Very little public information, only available to MDM

providers via separate agreement from Apple

– Products/Vendors• AirWatch, Sybase Afaria, MobileIron• Microsoft announced MDM support in SCCM 2012

» http://www.zdnet.com/blog/microsoft/microsoft-readies-tool-for-managing-ipads-iphones-and-android-devices/8987

» Beta 2 - http://www.microsoft.com/systemcenter/en/us/configuration-manager/cm-vnext-beta.aspx

1 2 3 4 5Policy Data Network Application Bad Stuff

Agenda

What happens if I leave my device on the [bus|train|plane]?

Data

• Hardware Based Encryption• Anything written to (flash) storage encrypted with a

256-bit AES key• Cannot be disabled by users• Primarily designed for remote wipe (delete the key,

and data is inaccessible)• Savvy hacker can very easily get access to the data,

even if pin-code protected– Boot the device in recovery mode, SSH and various shell

scripts to extract the data

Data

• Data Protection (post iOS 4.2)• Anything written to (flash) storage

encrypted with a 256-bit AES key, derived from the user’s passcode

• Strength of data protection dependent on passcode strength

– Brute force with 4 digit simple PIN. A little more challenging when alphanumeric, including non-alpha characters

– Mitigated by PBKDF2 iterations (50ms derivation = ~20 passwords per second)

• However, only applies to applications that use Data Protection API

Data

• Data Protection API• When writing NSData object to file, include the

NSDataWritingFileProtectionComplete attribute• However, your application now needs to handle

failure– If application is running in background when the device is

locked, you will not be able to access file

Data

• Keychain• The keychain is an encrypted container that holds passwords

for multiple applications and secure services. (Apple Keychain services programming guide)

• Franhofer Institute Paper and Video “Lost Phone? Lost Passwords!”

– http://www.sit.fraunhofer.de/en/Images/sc_iPhone%20Passwords_tcm502-80443.pdf

– http://www.youtube.com/watch?v=uVGiNAs-QbY

• Accessed the keychain using techniques described in last section

– “Jailbroke” the device, booted into tethered Jailbreak mode, copied script to dump contents of Keychain

– Some passwords, not all, were revealed

Data

• Keychain• The Keychain supports several methods of encryption:

– kSecAttrAccessibleAlways – always accessible– kSecAttrAccessibleWhenUnlocked - only accessible when device is

unlocked– kSecAttrAccessibleAfterFirstUnlock - accessible while locked. But if the

device is restarted it must first be unlocked for data to be accessible again– kSecAttrAccessibleWhenUnlockedThisDeviceOnly - only accessible when

device is unlocked – device specific– kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly - accessible while

locked. But if the device is restarted it must first be unlocked for data to be accessible again – device specific

– kSecAttrAccessibleAlwaysThisDeviceOnly – always accessible – device specific

• Resources– http://labs.neohapsis.com/2011/02/28/researchers-steal-iphone-passwords-in-

6-minutes-true-but-not-the-whole-story/

Data

• Keychain• The Keychain supports several methods of encryption:

– kSecAttrAccessibleAlways – always accessible– kSecAttrAccessibleWhenUnlocked - only accessible when device is

unlocked– kSecAttrAccessibleAfterFirstUnlock - accessible while locked. But if the

device is restarted it must first be unlocked for data to be accessible again– kSecAttrAccessibleWhenUnlockedThisDeviceOnly - only accessible when

device is unlocked – device specific– kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly - accessible while

locked. But if the device is restarted it must first be unlocked for data to be accessible again – device specific

– kSecAttrAccessibleAlwaysThisDeviceOnly – always accessible – device specific

• Resources– http://labs.neohapsis.com/2011/02/28/researchers-steal-iphone-passwords-in-

6-minutes-true-but-not-the-whole-story/

Try to avoid – no protection

Recommended for most apps Recommended for apps

with background needs

1 2 3 4 5Policy Data Network Application Bad Stuff

Agenda

How do I secure communication from the device?

Network

• SSL/TLS• SSL v3 / TLS v1 support for Web based applications

• Wireless Security• Supported schemes

– WEP/WPA/WPA2 Enterprise– Recommended: WPA2 Enterprise (128bit AES)

• 802.1x authentication protocols– EAP-TLS, EAP-TTLS, EAP-FAST, EAP-SIM, PEAP v0, v1,

LEAP

Network

• VPN (Virtual Private Network) Support• Supported Schemes

– Cisco IPSec, L2TP/IPSec, PPTP, SSL VPN– Additional AppStore clients from Juniper, Cisco, and F5– Deployable via configuration profile– VPN Proxy also configurable– Support for Split IP Tunneling– VPN on Demand (for cert-based authentication)

• Authentication– Username/Password– X.509 Certificate (Cisco IPSec only)– Two Factor Authentication (RSA SecurID and CRYPTOCard)

• Resources – http://developer.apple.com/library/ios/#featuredarticles/

FA_VPN_Server_Configuration_for_iPhone_OS/Introduction/Introduction.html

1 2 3 4 5Policy Data Network Application Bad Stuff

Agenda

I’m writing an application. How do I make my application secure?

Application

• Authentication and Authorization– Authentication

• No concept of users, accounts, passwords on the device• Unlike Mac OS X, user is assumed to be authenticated (via pincode)• No way of re-prompting user for pincode programmatically, nor locking the

device• Authentication for your own application will have to be custom (against

back end services)

– Authorization• No concept of roles, permissions on the device• Unlike Mac OS X, user is assumed to be authorized (within the sandbox of

the signed application)

– Resources• http://developer.apple.com/library/mac/#documentation/Security/

Conceptual/SecureCodingGuide/Articles/SecuritySvcs.html

Application

• Accessing Secure Server-Side Resources– Authentication

• NSURLConnection does not support NTLM auth• Need to use CFNetwork or 3rd party, such as ASIHTTPRequest

– SSL support• NSURLConnection supports SSL (prefix “https” on NSURL)• Support for bypassing invalid certificates using

continueWithoutCredentialForAuthenticationChallenge• Support for client side certificate requests using

didReceiveAuthenticationChallenge callback

– Resources• http://stackoverflow.com/questions/933331/how-to-use-nsurlconnection-to-

connect-with-ssl-for-an-untrusted-cert• http://markmail.org/message/tnh2g6u5h42ive53• http://jameswilliams.me/developer/blog/2008/08/http-post-via-the-cfnetwork-

stack/

Application

• Password Storage– Don’t store them in

NSUserDefaults– UI Abstracts the password, but

can be easily accessed from the FileSystem/a simple backup/iPhone Explorer

– Use the Keychain instead (albeit referring to the previous section on Keychain)

– Resources• http://software-security.sans.org/

blog/2011/01/05/using-keychain-to-store-passwords-ios-iphone-ipad/

Application

• Cryptography Support– Asymmetric support through Certificate, Key, and Trust Services

• Manage certificates, public and private keys, trust policies• Create, request certificate objects (CERs)• Import certificates, keys, and identities• Create public/private key pairs• Represent trust policies

– SecKeyGeneratePair ExampleOSStatus SecKeyGeneratePair ( CFDictionaryRef parameters, SecKeyRef *publicKey, SecKeyRef *privateKey);

– Resources• http://developer.apple.com/library/ios/#documentation/Security/Reference/

certifkeytrustservices/Reference/reference.html#//apple_ref/doc/uid/TP30000157

Application

• Cryptography Support– Symmetric support through CommonCrypto

• Symmetric Encryption (Shared Key)– From CommonCryptor.h– CCCrypt(CCOperation op, CCAlgorithm alg, CCOptions options, const void *key, size_t

keyLength, const void *iv, const void *dataIn, size_t dataInLength, void *dataOut, size_t dataOutAvailable, size_t *dataOutMoved

– DES, 3DES, AES128

• Digital Signatures (Digest Generation)– From CommonDigest.h– SHA1, SHA224, SHA256, SHA384, SHA512

» CC_SHA256(const void *data, CC_LONG len, unsigned char *md)– MD2, MD4, MD5

» CC_MD5(const void *data, CC_LONG len, unsigned char *md)– CCHmac (from CommonHMAC.h)

» CCHmac(kCCHmacAlgSHA256, [cKey bytes], [cKey length], [cData bytes], [cData length], buffer);

– Resources• http://developer.apple.com/library/mac/#documentation/Darwin/Reference/

ManPages/man3/CCCryptorFinal.3cc.html

Application

• Cryptography Support– Cryptographically secure random numbers

• SecRandomCopyBytes API returns cryptographically secure random number from accelerometer, compass, radio baseband

– Resources• http://developer.apple.com/library/ios/

#documentation/Security/Reference/RandomizationReference/Reference/reference.html

1 2 3 4 5Policy Data Network Application Bad Stuff

Agenda

What other bad stuff should I be thinking about?

Bad Stuff

• Jailbreaking– What is Jailbreaking?

• Process of unlocking a device to gain full access (a.k.a. root access) to a device

• Allowing more control on the device by bypassing previous restrictions

– e.g. custom ringtones, wallpapers, software to capture network packets, VNC server for the device, etc.

• Constant battle between jailbreakers (iPhone Dev Team) and Apple releasing new software updates

– Is it Legal?• In the US, under exemption to DMCA 2010,

although it will void Apple’s device warranty. • In other countries, best to check local laws.

– Is it the same as SIM unlocking?• No. SIM unlocking is about using different SIMs

from different operators.

Bad Stuff

• Jailbreaking in the Enterprise– Tethered vs. Untethered Jailbreaking

• Untethered = does not required USB cable and s/w to reboot device

• Most jailbreaks post 4.2.1 require tether

– Security Risks• Frequent speculation on security for jailbroken devices• Most originate to SSH/default password exploit

– iKee worm (changes wallpaper to Rick Astley background)– Netherlands-based botnet-like worm uploading

/etc/master.passwd file to a server in Lithuania

Bad Stuff

• Plaintext in Configuration Profile– Scenario

• Attacker grabs .mobileconfig from Email or public URL• Investigates XML file for plaintext details (e.g. WLAN

SSID and password)

– Mitigation• Encrypting .mobileconfig files for device-specific

deployments• Placing .mobileconfig files behind authenticated pages

(avoid Google filetype:mobileconfig Password)

Bad Stuff

• Evil Configuration Profile– Scenario

• Attacker generates evil .mobileconfig • Signs using signature-only cert from one of the 224 root certs in the

iPhone keystore• SMS the .mobileconfig to a victim, fake them into installing it

– Mitigation• Create a locked default profile to prevent this• User education• Apple’s removal of certain policy configuration options (e.g. proxy)

– Resources• http://www.enterprisenetworkingplanet.com/netsecur/article.php/

10952_3892776_1/Three-Steps-to-a-Cracked-iPhone.htm

Bad Stuff

• Bypassing PIN code/Forensic Recovery of Disk– Scenario

• Attacker has physical access to your device• Even though locked with a PIN code, the device can still be

placed in recovery code to override the PIN protection

– Mitigation• Physical security of device• Use of Data Protection API by applications installed on device

(mail stores by default)• Correct use of Key Chain algorithms to ensure passwords are not

stored in clear

– Resources• http://www.youtube.com/watch?v=5wS3AMbXRLs

1 2 3 4 5Policy Data Network Application Bad Stuff

Agenda

Conclusion

Conclusion

• A lot to consider for iPhone and iPad Security– Divide the problem in four ways– Policy, data, network, and application– …but also understand about the bad stuff!

• Your device is as secure as the weakest link– Don’t rely on one mechanism (e.g. password policy) in lieu of

the rest

• Think like a hacker– What tools would they have? – What would they try?– What’s the worst that could happen if they got hold of your

device?

How Neudesic Can Help

• Application/Device Security Review– Simulate losing one of your locked devices– We run it through the tools that the hackers have– You get a full report of our findings

• Mobile Strategy Review– CxO Level Mobility Review– Construct mobile landscape of your organization together with the

applications, integration points, and security considerations that make sense

– You get a framework and roadmap for mobile adoption in your organization

Thank You!

Simon Guest

Director, Mobility Solutions

Neudesic, LLC

simon.guest@neudesic.com