Independent Security. Prepared for:

Transcription

1 Independent Security Report (isr) Prepared for:

2 isec Partners Final Report Independent Security Report (isr) Page 2 of , isec Partners, Inc. Prepared by isec Partners, Inc. for Wickr. Portions of this document and the templates used in its production are the property of isec Partners, Inc. and can not be copied without permission. While precautions have been taken in the preparation of this document, isec Partners, Inc, the publisher, and the author(s) assume no responsibility for errors, omissions, or for damages resulting from the use of the information contained herein. Use of isec Partners services does not guarantee the security of a system, or that computer intrusions will not occur.

3 isec Partners Final Report Independent Security Report (isr) Page 3 of 10 Table of Contents 1 Project Overview Engagement Structure Testing Methodology Goals and Scope Coverage Engagement Findings Assertion One, Strong End-to-End Encryption: TRUE Assertion Two, No Backdoors: TRUE Appendices A Glossary

4 isec Partners Final Report Independent Security Report (isr) Page 4 of 10 1 Project Overview Wickr engaged isec Partners (isec) to perform a source-assisted penetration test of their current ios and Android applications, and the corresponding server-side PHP components. Testing took place between March 10, 2014 and March 28th, A total of nine person weeks were spent on the project. Five person weeks of review were performed on-site and 4 person weeks of review were performed remotely. Wickr provided access to client and remote server test infrastructure as well as desktops with the project's source code upon isec's arrival. isec was not granted access to source code while working remotely. Lack of source code access during the four remote weeks limited the range of activities possible during this portion of the engagement. Wickr also provided a comprehensive walkthrough of the system architecture on the first day of the engagement and Wickr's engineers were available to discuss issues throughout the project. While the entire client application was considered in-scope for the assessment, several features were unavailable at the time of testing, or were deprioritized by Wickr due to time constraints. Wickr's voice calling features were not complete at the time of testing and were neither in scope nor tested. At Wickr's request, time was not spent on bypassing message self-destruct features. Due to the target audience for the application, at Wickr's request, isec attempted to consider complex attacks that are often only employed by nation states, including attacks against Wickr users by a hostile Wickr server and a cursory review of anonymity guarantees. A major Wickr goal of the engagement was to create an Independent Security Report (isr) that discussed two core assertions relating to end-to-end encryption and backdoors. 1 This point-in-time assessment is discussed within section 3 on page 8. In July 2014, isec returned to perform a targeted, three person-day assessment of several security enhancements, specific to the Android and ios applications reviewed in March, and was granted access to source code modifications, developer interviews and test devices. This July review did not examine the security of any newly added features or re-assess the application and server stack in its entirety. 1 This document should not be taken as a form of legal guarantee, as no application is 100% secure.

5 isec Partners Final Report Independent Security Report (isr) Page 5 of 10 2 Engagement Structure 2.1 Testing Methodology isec testing of Wickr was overall a collaborative process supported by Wickr providing source code, consultants receiving overviews of the product features, having developers available for questions and supporting the audit whenever possible. isec used debugging tools, network proxy testing, source code analysis, blackbox testing and other techniques to assess the security and privacy guarantees supported by Wickr. 2.2 Goals and Scope Within the timeframe and schedule described for the original audit, isec performed the following tasks: Privacy and Core Feature Review: Privacy Review: isec performed a review of the mobile applications (and server components) with regards to user privacy. The review focused on, but was not limited to, the following types of issues: Data Retention on the Client Application and Server Infrastructure Opt-In User ID lookup Service Methods and risks of Third-Party integration Basic wire and traffic analysis, excluding end-to-end correlation attacks Server and User impersonation or spoofing Log retention, whitening and other forms of data-exposure Privacy policy review, Encryption and Key Management: isec reviewed the use of Encryption within the Wickr application, this included but was not limited to: Key generation and storage Common crypto weaknesses such as fixed initialization vectors or lack of random numbers Base review of the algorithms used within the system ios Application Testing: ios Testing: isec performed a targeted application review. The review focused on the following types of vulnerabilities: Unsafe storage of sensitive data, including, but not limited to: Local file system storage Logging Database storage

6 isec Partners Final Report Independent Security Report (isr) Page 6 of 10 Preferences storage Browser storage (cookie jar, caches, and history) isec used internally-developed ios tools where applicable: Introspy Android Application Testing: isec performed a sourcecode assisted, targeted application review. The review focused on the following types of issues: Network-facing vulnerabilities, both from listening services and ``pull content'' Misuse of Android IPC and service mechanisms: Intents Intent Filters Activities Broadcasts Services Content Providers Binder Interfaces UNIX IPC mechanisms, such as local sockets Weak permissioning: Android permission systems, including configuration in AndroidManifest.xml File system permissions Unsafe storage of sensitive data, including, but not limited to: Local file system storage Logging Database storage Preferences storage Browser storage (cookie jar, caches, and history) System cache Flash storage isec used internally-developed Android tools where applicable, including fuzzing tools: Package Play Intent Fuzzer Intent Sniffer Mobile End Points Testing: isec performed a best-effort assessment of the interactions between the mobile application(s) and associated server end points.

7 isec Partners Final Report Independent Security Report (isr) Page 7 of 10 isec reviewed the web service APIs for the following common mobile application issues: Weaknesses in authentication, including: Authentication bypass Vulnerability to brute force attacks Improper authorization checks Data enumeration vulnerabilities Common weaknesses in session management (authentication and authorization) including: Improper token invalidation Predictable session tokens Insufficient protections against session fixation Denial of service vulnerabilities Inappropriate use or exposure of sensitive customer data Injection attacks (including SQL, LDAP, XML) Transport security weaknesses including: Insufficient certification chain validation Weak cipher suite configuration isec reviewed the server(s) for the following classes of issues: Account harvesting vulnerabilities Web service API vulnerabilities XML complexity, serialization, and external reference attacks Message replay attacks WSDL/WS-Inspection information disclosure vulnerabilities Incorrect use of WS-Security standards 2.3 Coverage isec initially reviewed version 2 beta 2 for Android and beta for ios in March Overall coverage was adequate for the above scope but not comprehensive. The review was focused on the Wickr mobile clients for ios and Android, along with related testing of the back-end server webservice. Core focus was on application flaws, encryption, privacy and overall design assumptions. Bypassing the deletion of messages, searching for memory corruption flaws and closely examining the server back-end management or hardening was not in scope. isec also was not involved with reviewing the distribution infrastructure security of the application to end users (such as the Google Play Store or Apple App Store). Coverage for the testing in July targeted version 2.4 for both platforms, focusing on a code review of the "Advanced Security/Key Verification" feature that was not present in the prior release.

8 isec Partners Final Report Independent Security Report (isr) Page 8 of 10 3 Engagement Findings As part of the Wickr mobile security assessment, isec was tasked to investigate two assertions, agreed upon prior to the start of the assessment by both Wickr and isec Partners. Vulnerability findings from the report were directly and solely used as the basis of the affirmations below. It must be noted that the assertions included herein are based on a point-in-time assessment of Wickr's mobile application security architecture and implementation which will undoubtedly be changed in the future. isec's assessment was necessarily bounded by time, best effort and largely dependant on the extent to which Wickr was open and transparent with us. 3.1 Assertion One, Strong End-to-End Encryption: TRUE Wickr performs strong end-to-end (mobile to mobile) encryption such that they cannot decrypt communications. isec found this statement true. Wickr uses AES encryption for message level security on top of TLS for transport security. While some weaknesses in this architecture revolve around a trusted central server, which could undermine the strong end-to-end encryption in some low likelihood scenarios, Wickr has recently added several features which allow users to avoid these weaknesses. In the case of long term keys, this is provided if they opt-in to use the ``Advanced Key Verification'' feature. 1. The Wickr client utilizes Trust on First Use (TOFU) for initial communication with peers, and allow users to examine this long term key associated with their identity. Peers can then verify this key via video, SMS or when using the ``Advanced Key Verification'' mode. When long term keys are changed, the new keys must be validated. The ``Advanced Key Verification'' was code reviewed during the July retest. 2. AES encryption is used to protect handset-to-handset communications alongside ECDH 521, TLS, and uses integrity checking. This protects messages from being viewed in plaintext or tampered with if a lower-level security mechanism was compromised, such as a vulnerability in the TLS layer, a compromised Wickr server or malicious Wickr employee. 3. Wickr implements an extra layer of encryption for messages from client-to-server in addition to TLS. This layer protects the confidentiality of client-to-server messages from malicious third parties. While the TLS implementation could be improved by including certificate pinning and preferring ciphersuites that enable Perfect Forward Secrecy (PFS), these issues are largely mitigated in the additional encryption layer.

9 isec Partners Final Report Independent Security Report (isr) Page 9 of Assertion Two, No Backdoors: TRUE No intentional backdoors are present within the tested version or source code provided. isec found this to be true. There are several caveats to this statement: 1. isec reviewed the source code which was provided by Wickr. Although this appeared to be the complete set of code, isec was not involved with a verified build process and cannot verify the code provided to isec was the complete source with absolute certainty. 2 isec has no evidence of code being held back and the Wickr team was very supportive. 2. Third-party code was not reviewed as part of this assessment. This included the packaged version of OpenSSL along with several other libraries not used for cryptographic purposes. 3 2 Due to the nature of closed source cryptographic software and protocols, extending isec's assertions directly to concerned Wickr users beyond this point-in-time document is extremely difficult. Wickr could place backdoors or protocol weaknesses into future versions of the code (either through a national security request, malice or accident), although no evidence of this was found in the code reviewed by isec and Wickr was cooperative throughout this audit. 3 For the sake of this assertion, these libraries are assumed to be safe, although this may not be acceptable for at-risk or paranoid end users.

10 isec Partners Final Report Independent Security Report (isr) Page 10 of 10 Appendices A Glossary AES: Advanced Encryption Standard. ECDH 521: Elliptic Curve Diffie-Hellman, 521 bits. RSA: RSA Public key Cryptosystem designed by Ron Rivest, Adi Shamir and Leonard Adleman and independently discovered by Clifford Cocks. SSL: Secure Socket Layer, supersucceded by TLS. TLS: Transport Layer Security, the successor to SSL. Trust on First Use (TOFU): A method of authentication whereas a trust in the identity is obtained the first time communication is performed. End to End Encryption: End-to-end encryption (E2EE), which is point-to-point encryption, is a digital communications paradigm of uninterrupted protection of data traveling between two communicating parties. It involves the originating party encrypting data to be readable only by the intended recipient, and the receiving party decrypting it, with no involvement in said encryption by third parties. 4 Backdoor: A backdoor in a computer system (or cryptosystem or algorithm) is a method of bypassing normal authentication, securing illegal remote access to a computer, obtaining access to plaintext, and so on, while attempting to remain undetected