590 likes | 1k Views
Mobile Security Project Murat Lostar. OWASP. About me. Murat Lostar 1986 – Software development 1992 – Network and systems 1998 – Information security 2009 – ISACA-Istanbul Founding President 2013 – Cloud Security Alliance – Turkey Founding President
E N D
Mobile Security Project Murat Lostar OWASP
About me • Murat Lostar • 1986 – Software development • 1992 – Network and systems • 1998 – Information security • 2009 – ISACA-Istanbul Founding President • 2013 – Cloud Security Alliance – Turkey Founding President • Have/had many certifications: Microsoft, Sun, IBM, Cisco, ISACA, ISC2
About my company • Lostar Information Security • Established in 1998 • Appx 15 pax. Two teams • Technical: Pen tests, technical design, etc • Process: Focus on people and processes • Based on ISO 27001, ISO 20000, ISO 22301, COBIT, etc • Services only (does not distribute, resell products)
About OWASP • Open Web Application Security Project (owasp.org) • Worldwide, not-for-profit • Mission: Make software security visible • so that individuals and organizations worldwide can make informed decisions about true software security risks • (All) Materials free and open software license • 36,000+ Participants (worldwide) • Has chapters! (Not yet in Malta)
Why this title? http://www.cnet.com/news/snapchat-update-to-close-loophole-after-mass-hack/
OWASP Mobile Security Project • Branch of OWASP • Focused on securing mobile applications • Compiled list of top ten mobile security threats • owasp.org/index.php/OWASP_Mobile_Security_Project
Overview (OWASP Mobile Security) • Focus: • Mobile Apps, Server Side Infrastructures. • Purpose: • Taking precautions on mobile platform and carrier inherent risks when threat modeling and building controls.Primarily at the application layer. • Target Profile: • Developers.
Scope (OWASP Mobile Security) • Top 10 Mobile Risks • Top 10 Mobile Controls • Mobile Tools • Mobile Cheat Sheet Series • Secure Mobile Development • Mobile Threat Model (BETA)
Top 10 Mobile Risks - Methodology • Exploitability : Taking advantage of a situation • Prevalence : Commonness • Detectability : Ease of discovery • Impact : Potential effect • owasp.org/index.php/OWASP_Risk_Rating_Methodology
10. Lack of Binary Protections • An adversary could use an automated tool to reverse engineer the code of application and modify it. • To prevent lack of binary: • Jailbreak Detection Controls • Checksum Controls • Certificate Pinning Controls • Debugger Detection Controls
9. Improper Session Handling • It’s similar to poor authentication. Once you are authenticated and given a session, that session allows one access to the application. Therefore, sessions must be protected just as carefully as like authentication mechanism. • To protect sessions: • Invalidate Sessions on the Backend • Timeout Protection • Properly Rotate Cookies • Secure Token Creation
8. Security Decisions via Untrusted Inputs • In most cases, mobile applications accept data from Inter Process Communication (IPC) mechanism. • In general, should be adhered to the following design patterns: • Restrict access to a trusted applications. • Sensitive actions should require user interaction. • All IPC entries should be validated. • Do not pass any sensitive information through IPC.
7. Client Side Injection • Client-side attacks and particularly code injection at the client, might be the first thing a threat agent try. • To prevent from injections, see below titles: • SQLite Injection • JavaScript Injection (XSS, etc) • Local File Inclusion • Intent Injection/Fuzzing(Android) • XML Injection(iOS) • Format String Injection(iOS) • Classic C Attacks(iOS)
6. Broken Cryptography • Insecure use of cryptography is common in most any application that uses encryption. There are several mistakes in this area: • The Creation and Use of Custom Encryption Algorithms • Use of Insecure and/or Deprecated Algorithms • Poor Key Management
5. Poor AuthZ and AuthN • Authenticating a user locally can lead to client-side bypass vulnerabilities. • Ensure all authentication requests are performed server-side. • Persistent authentication should never be implemented by storing password on the device.
4. Unintended Data Leakage • This includes all manner of vulnerabilities that can be introduced by the OS, frameworks, compiler environment, new hardware, etc, all without a developers knowledge. • It is especially important to discern what a given OS or framework does by default. By identifying this and applying mitigating controls, you can avoid unintended data leakage.
3. Insufficient Transport Layer Protection • When this data is exchanged it traverses both the carrier network and the internet. For sensitive data, if the application is coded poorly, threat agents can use techniques to view this sensitive data while it's travelling across the wire. • Enforce the use of SSL/TLS for all transport channels for sensitive data. • Use valid certificates signed by a trusted CA provider. • Do not send sensitive data over alternate channels, such as SMS, MMS, or notifications.
2. Insecure Data Storage • Lost/stolen or exploit/malware involved phones threat for this risk. • A malicious agent hooks up an unprotected device to a computer with commonly available software, and can see sensitive information. • Never store credentials on the phone file system. • Where storage or caching of information is necessary use encryption library (CommonCrypto, javax.crypto, setStorageEncryption).
1. Weak Server Side Controls • Including both the application and malicious users could send insecure data to server. • Weak controls could cause several easy to exploit vulnerabilities (like server side injection) that are high risk. • Secure coding and configuration practices must be used on server-side of the mobile application.
1. ID & Protect Sensitive Data • Use ‘javax.crypto’ library. • Use ‘setStorageEncryption’ API. • Avoid using MODE_WORLD_READABLE shared preferences properties. • Use ‘CommonCrypto’ library. • Use ‘Keychain’ API. • Use SQLcipher for SQLite encryption. • Avoid using NSUserDefaults. • Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure.
2. Protect Authentication Credentials • Use the latest versions of the authorization standards. • Encrypt the tokens in transit (using SSL/TLS). • Be sure, authentication requests are performed server-side. • Ifyousavepassword on device, encrypt itand usekey-store mechanisms provided by the mobile OS. • Ensure passwords and keys are not visible in cache or logsanddontstorethem inside thebinary.
3. Protect Data in Transit • Sensitive data passing through insecure channels could be intercepted. • Enforce the use of SSL/TLS • Avoidusingmixed SSL sessions. • Use certificates signed by trusted CA providers. • Ensurecertificatesarevalid. • SMS, MMS or notifications should not be used to send sensitive data
4. Strong AuthN, AuthZ and Session Management • Require appropriate strength user authentication to the application. • Ensure that the session management is handled correctly after the initial authentication. • Use unpredictable session identifiers with high entropy. • Use context to add security to authentication (IP Location). • Where possible, use additional authentication factors for giving access to sensitive data or interfaces (voice, fingerprint etc.). • Use authentication that ties back to the end user identity.
5. Secure Services and Server • Carry out a specific check for data transferred between the mobile device and web-server back-ends and other external interfaces. • Backend services for mobile apps should be tested for vulnerabilities periodically. • Ensure that the backend platform is running with lastest security patches. • Ensure adequate logs are retained on the backend. • Employ rate limiting and throttling on a per-user/IP basis. • Test for DoS vulnerabilities.
6. Secure 3rd Party Integration • Data leakage. Users may install applications that may be malicious and can transmit personal data for malicious purposes. • Vet the security/authenticity of any third party code/libraries used in your mobile application. • Track all third party frameworks/APIs used in the mobile application for security patches. • Pay particular attention to validating all data received from and sent to non-trusted third party apps before processing within the application.
7. Collect Consent for Use of User Data • Unintentional disclosure of personal or private information, illegal data processing. • Create a privacy policy. • Check whether your application is collecting PII. • Audit communication mechanisms to check for unintended leaks. • Keep a record of consent to the transfer of PII.
8. Protect For Pay Services • Logs should be protected from unauthorised access. • Check for anomalous usage patterns in paid-for resource usage and trigger re-authentication. • Consider using a white-list model by default for paid-for resource addressing. • Authenticate all API calls to paid-for resources
8. Protect For Pay Services • Ensure that wallet API callbacks do not pass cleartext account/pricing/ billing/item information. • Warn user and obtain consent for any cost implications for app behaviour. • Implement best practices to minimize signalling load on base stations.
9. Secure Application Distro / Update • Applications must be designed and provisioned to allow updates for security patches. • Most app-stores monitor apps for insecure code and are able to remotely remove apps at short notice in case of an incident. • Provide feedback channels for users to report security problems with apps.
10. Avoid / Safely Use Interpreters • Run interpreters at minimal privilege levels. • Define comprehensive escape syntax as appropriate. • Fuzz test interpreters. • Sandbox interpreters.
Mobile Tools • iMas: • Research project from the MITRE Corp. Focused on open source iOS security controls. • Research outcomes include an open source secure application framework, including an application container, developer and validation tools/techniques. • github.com/project-imas/about
Mobile Tools • iGoat: • Learning tool for iOS developers. It has a similar conceptual flow to WebGoat. • Purpose is learning about security weaknesses in iOS by breaking things as well as fixing them. • code.google.com/p/owasp-igoat/
Mobile Tools • DVIA: • Damn Vulnerable iOS Application project started by Prateek Gianchandani which gives mobile testers and developers an iOS application to practice attacking/defending skill sets. • damnvulnerableiosapp.com
Mobile Tools • GoatDroid: • A fully functional and self-contained training environment for performing security testing against Android application. • The Project has 2 application: • FourGoats • Herd Financial • github.com/jackMannino/OWASP-GoatDroid-Project
Mobile Tools • Androick: • Research project from PHONESEC Ltd. This tool allows any user to analyze an Android application. • sourceforge.net/projects/androick
Mobile Tools • MobiSec: • Project is a live environment for testing mobile environments, including devices, applications, and supporting infrastructure.
More on OWASP • Mobile Threat Model
More on OWASP… • Mobile Threat Model • Mobile Application Architecture • Mobile Data • Threat Agent Identification • Methods of Attack • Controls