Independent Security Report (iSR)

Independent Security
Report (iSR)
Prepared for:
iSEC Partners Final Report — Independent Security Report (iSR)
Page 2 of 10
©2014, 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.
August 5, 2014
Wickr
Version 1.5
iSEC Partners Final Report — Independent Security Report (iSR)
Page 3 of 10
Table of Contents
1 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2 Engagement Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1
Testing Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Goals and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3
Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3 Engagement Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1
Assertion One, Strong End-to-End Encryption: TRUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.2
Assertion Two, No Backdoors: TRUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
A Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
August 5, 2014
Wickr
Version 1.5
iSEC Partners Final Report — Independent Security Report (iSR)
1
Page 4 of 10
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, 2014. 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 ﬁrst 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, speciﬁc to the Android and iOS applications reviewed in March, and was granted access to source code modiﬁcations, 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.
August 5, 2014
Wickr
Version 1.5
iSEC Partners Final Report — Independent Security Report (iSR)
2
Engagement Structure
2.1
Testing Methodology
Page 5 of 10
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 compo-
nents) 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 traﬃc analysis, excluding end-to-end correlation attacks
◦ Server and User impersonation or spooﬁng
◦ Log retention, whitening and other forms of data-exposure
– Privacy policy review, Encryption and Key Management: iSEC reviewed the use of Encryp-
tion within the Wickr application, this included but was not limited to:
◦ Key generation and storage
◦ Common crypto weaknesses such as ﬁxed 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 ﬁle system storage
· Logging
· Database storage
August 5, 2014
Wickr
Version 1.5
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 conﬁguration in AndroidManifest.xml
· File system permissions
◦ Unsafe storage of sensitive data, including, but not limited to:
· Local ﬁle 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 Sniﬀer
• Mobile End Points Testing: iSEC performed a best-eﬀort assessment of the interactions between the mobile application(s) and associated server end points.
August 5, 2014
Wickr
Version 1.5
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
· Insuﬃcient protections against session ﬁxation
◦ Denial of service vulnerabilities
◦ Inappropriate use or exposure of sensitive customer data
◦ Injection attacks (including SQL, LDAP, XML)
◦ Transport security weaknesses including:
· Insuﬃcient certiﬁcation chain validation
· Weak cipher suite conﬁguration
– 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 2.1.0 beta for iOS in March 2014. 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 ﬂaws, encryption, privacy and overall design assumptions. Bypassing
the deletion of messages, searching for memory corruption ﬂaws 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 Veriﬁcation" feature that was not present in the prior release.
August 5, 2014
Wickr
Version 1.5
iSEC Partners Final Report — Independent Security Report (iSR)
3
Page 8 of 10
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 ﬁndings from
the report were directly and solely used as the basis of the aﬃrmations 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 eﬀort 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
Veriﬁcation'' 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 email when using the ``Advanced Key Veriﬁcation'' mode. When long
term keys are changed, the new keys must be validated. The ``Advanced Key Veriﬁcation'' 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 conﬁdentiality of client-to-server messages from malicious third
parties. While the TLS implementation could be improved by including certiﬁcate pinning
and preferring ciphersuites that enable Perfect Forward Secrecy (PFS), these issues are largely
mitigated in the additional encryption layer.
August 5, 2014
Wickr
Version 1.5
iSEC Partners Final Report — Independent Security Report (iSR)
3.2
Page 9 of 10
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 veriﬁed 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 diﬃcult. 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.
August 5, 2014
Wickr
Version 1.5
iSEC Partners Final Report — Independent Security Report (iSR)
Page 10 of 10
Appendices
A
Glossary
AES: Advanced Encryption Standard.
ECDH 521: Elliptic Curve Diﬃe-Hellman, 521 bits.
RSA: RSA Public key Cryptosystem designed by Ron Rivest, Adi Shamir and Leonard Adleman and
independently discovered by Cliﬀord 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 ﬁrst 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 bypass-
ing normal authentication, securing illegal remote access to a computer, obtaining access to
plaintext, and so on, while attempting to remain undetected. 5
4 https://en.wikipedia.org/wiki/End-to-end_encryption
5 https://en.wikipedia.org/wiki/Backdoor_(computing)
August 5, 2014
Wickr
Version 1.5

Download Report