MOBILE SECURITY. As seen by FortConsult. Lars Syberg Head of Security Services

Transcription

1 MOBILE SECURITY As seen by FortConsult Lars Syberg Head of Security Services FortConsult A/S Tranevej 16, 2400 Copenhagen, Denmark

2

3 About FortConsult Founded in 2002, 35 employees in mainland Europe / CIS Advanced penetration test and review Focussed on ATM security and mobile/embedded PCI SSC: PCI, PA, ASV, P2PE, card personalization Do not sell any products or remediation only assessment Customer base includes many of the big banks /processors: Nordea, Danske Bank, Sberbank, ATOS, VTB bank, Unicredit, Credit Europe, Nets, Evry, SIBS

4 NCC Group Global IT assurance company, 18 offices worldwide Listed on London Stock Exchange Approx employees (world largest pentest team) Customer base includes many of the world largest brands Specialized in IT Security assurance: Penetration test PCI DDoS testing Security Review Fully owned entities includes: Matasano Security(US) isec Partners(US) FortConsult (DK)

5 Mobile evolution 1 st generation usage: Browsing, need for information 2 nd generation usage: Corporate , consumer selfser vice 3 rd generation usage: Corporate and data, internal data and business processes And we got here without any questions

6 3rd Generation mobile

7 We have secured data for 10 years First we protected everything behind firewall Then: Outsourcing Web-apps Cloud

8 Lost / stolen devices Virus & Malware Insecure apps Data easily transfered to cloud Too many permissions inside apps Open Wi-Fi Networks and Public Hotspots Insecure File transfer Missing usage policies Too many permissions inside apps

9 Lost/Stolen Devices? AES 256-bit cr ypto engine with a M asterkey fused-in the Apple CPU W ithout Passcode, there is no encr yption To decr ypt the data, both the CPU with its unique key and the Lost and stolen devices have been the highest risk until now (yes, people passcode are needed are looking at the data on found devices) Erase All function deletes the M asterkey Now this is managed pretty well Encryption default when using passcode (IOS) Find my Iphone (now with apple account) / Android device manager (find, wipe)

10 Malware (& virus)

11

12 All modern mobile OS-es have a robust architecture - but IOS and Windows 8 have the leadership Address Space Layout Randomization (ASLR) Stack Smashing Protection (SSP) Automatic Reference Counting (ARC) Data Execution Prevention (DEP) Sandboxing App distribution is the big difference OS update is another 64 bit takes it to a new level But you only get all the security features if the developer sets the right flag

13 ios Security overview Probably the first Trusted Computed Based platform widely deployed (and accepted) Impressive security architecture and features Hardware and software based Secure Boot Chain Boot loaders (BootRom, LLB, iboot) are signed and verified during the boot process Ensures that only Apple's signed code can be installed on a device System Software Personalization OTA software upgrade Software integrity is verified online using a challenge-response protocol Unable to downgrade App Code Signing All apps are verified and signed by Apple Code signing extends ios chain of trust to applications Runtime Process Security Apps are running in their own sandbox, access to system only permitted through the API calls User (and apps) restricted permissions mobile user instead of root Not allowed to share data between apps, IPC using URL schemes (not a security feature!) ASLR compilation on by default Encryption and Data Protection Hardware-based AES 256 crypto engine (not on older devices) Full-Disk encryption + File Data Protection Keychain securely stores passwords, certificates and keys User's passcode is used as a master encryption key Protection classes are used to determine when files and keychain items are accessible Prior to ios 7, only the Mail.app leveraged Data Protection by default Network Security SSL, VPN, WiFi,Bluetooth Mobile Device Management MDM framework enforces security configuration using OTA configuration profiles

14 Android security Secure Boot Chain OEM specific implementations for locked boot loaders (). The boot loaders are signed and verified using ARM TrustZone features Ensures that only Android OEM software can be installed. However this is valid as long as the boot loader is not unlocked. Secure Software Updates OTA Software Updates. OEM specific Application Code Signing All applications are signed on Google Play market. At submission, the application is verified automatically for potential malicious activities. - As long as Allow installation of the applications from Unknown Sources is not enabled! Runtime Process Security Applications run in their own sandbox without having escalated privileges The sandboxing is ensured by the Dalvik Runtime engine (Dalvik is a Java-based runtime engine but it is not 100% compatible with Java) Applications are allowed to share data in-between using IPC features (Inter-Process Communication). It can be dangerous, if the application is not developed securely.(also in IOS 8) Encryption Full-Disk encryption based on Linux dmcrypt/luks (Linux Unified Key Setup) using AES. Network Security SSL/TLS with APIs available to do Certificate Pinning Harder to bypass than Apple ios due to the multiple possibilities of implementing it. MDM supported

15 Jailbreaking / rooting ios jailbreaking is the process of removing the limitations imposed by Apple on devices running the ios operating system through the use of hardware/software exploits wikipedia Removes the signature checking The integrity of the running system and apps is not guaranteed anymore Unlocks the root user The end user owns the device The Apps also own the device (i.e. malware) Is popular because allows the installation of cracked apps Jailbreaking is the most anticipated feature of any ios release All major ios versions for all ios devices have been jailbroken Old ios devices (<=iphone4,ipad1) will always be jailbreakable hardware exploit on BootRom allows root access at boot level using a custom ramdisk Jailbreak may be able on a passcode-locked device

16 Who is taking the lead

17 Lost / stolen devices Virus & Malware Insecure apps lets wait with that Data easily transfered to the Cloud Open Wi-Fi Networks and Public Hotspots Insecure File transfer Tracking Missing usage policies

18 Legal user tracking (phone/in-air)

19 Cloud storage It s so much integrated What is the alternative? Employees take decisions Pictures, documents, passwords, attachments (oh, and we don t want to enter passwords)

20

21 MDM What ever happened to the network perimeter? Is that one of our devices? Is that really one of our users? Where is our data? Yes, I know that is a clever app! How many devices you said you have? Who s in charge of these!@(*#^)* things anyway?

22 MDM typical features Policy enforcement Password-enabled Encryption Authentication Firewall Antivirus Mobile VPN Security Management Remote wipe Remote lock Secure configuration Software Management: Configuration Updates Patches/fixes Backup/restore Provisioning Authorized software monitoring Transcode Network Service Management: Procure and provision Help desk/support Activation Deactivation Shipping Imaging

23 MDM in ios Framework and protocol for device management Has taken off after ios 4 Over-The-Air configuration profiles utilizing APNS Implemented by third-party vendors (MDM servers) Cloud-based and/or In-Premise Common API for all MDM providers 3 rd parties usually build more features Closed protocol have been reverse-engineered Everything controlled from Apple s servers

24 Device Management After enrollment is completed, the server communicates with the device using APNS 1. Server requests push notification through Apple 2. Apple pushes notifications to the device 3. Device connects to server 4. Server and client exchange commands and responses The protocol is overall secure APNS authenticates server and devices using certificates and tokens Impossible to forge push messages Messages in step 4 over SSL

25 Deployment violates security policies DMZ access to LDAP, file servers, PKI servers, DB servers, Exchange using Remote Powershell commands MDM db in the same db server with critical databases (i.e. credit card data) Compromise one server in the DMZ, access critical internal services Cloud-based solutions may store sensitive data outside the organization

26 MDM in Android Since Android 2.2 (API level 8), the Android platform offers system-level device management capabilities through the Device Administration APIs. Around 30 Policies and API s OEM Vendors have their own add-on Samsung MDM features: Samsung Enterprise (E-SDK) allows developers to take advantage of the additional security features available in Security Enhanced Android (SE Android) and develop custom enterprise applications for their Samsung devices. The E-SDK provides developers with the capability of leveraging features which enhance the manageability, security, accessibility. Within the E-SDK are 890+ APIs and 410+ policies for increased device control, whereas standard Android provides 30+ policies and APIs Samsung KNOX - Security Enhancements for Android provides an enhanced mechanism to enforce the separation of information based on confidentiality and integrity requirements.

27 MDM in Android E-SDK are 890+ APIs and 410+ policies for.. Android = open, access to lower level also for MDM providers

28 No training of developers No knowledge of secure coding principles Don t do the No same understanding mistakes of as platform before features Bad session management Reuse of old code No protection of code Local storage of (unencrypted data) Wrong key management on device Non encrypted communication Not the same security features as normal

29 OWASP mobile top 10 A1: Insecure Data Storage A2: Weak Server Side Controls A3: Insufficient Transport Layer Protection A4: Client Side Injection A5: Poor Authorization and Authentication A6: Improper Session Handling A7: Security Decisions Via Untrusted Inputs A8: Side Channel Data Leakage A9: Broken Cryptography A10: Sensitive Information Disclosure

30 LinkedIn steals data cross app / iphone

31 Apps stealing from each other Components accessed via Intents can be public or private. The default is dependent on the intent-filter and it is easy to mistakenly allow the component to be or become public. Regardless of what Intent filters are defined, publicly accessible Activities can be directly invoked with bad data so input validation is important. Do not put sensitive data into Intents used to start Activities. A malicious program can insert an Intent filter with higher priority and grab the data

32 Remember Prevent installation of non-app store apps Enable tracking, encryption and passwords Update Simple usage strategy, cloud storage guide Avoid hotspots or use VPN Test apps after development and train developers Remember that mobile is still a very secure alternative to an uncontrolled windows machine

33