Penetration Test Report (LeastAuthority): LeastAuthority GlobaLeaks audit report

Report of Security Audit of GlobaLeaks
(cid:127) Principal Investigators:
(cid:127) Nathan Wilcox <nathan@LeastAuthority.com>
(cid:127) Zooko Wilcox-O'Hearn <zooko@LeastAuthority.com>
(cid:127) Taylor Hornby <taylor@LeastAuthority.com>
(cid:127) Darius Bacon <darius@LeastAuthority.com>
Contents
Overview 3
Report Revision 3
Audit Scope 3
Methodology and Disclosure 3
Process 4
Issue Investigation and Remediation 4
Coverage 6
Target Code 6
Revision 6
Dependencies 6
Target Configuration 6
Findings 8
Vulnerabilities 8
Issue Format 8
Issue A. Plaintext is Written to Disk Before Encryption 9
Issue B. SHA256 of Plaintext File is Saved when Encryption is Enabled 11
Issue C. Receipts are Vulnerable to Guessing 13
Issue D. A Receiver Can Suppress File Encryption With No Warning to Others 15
Issue E. Parallel Requests Bypass Exponentially Increasing Login Delay 16
Issue F. Tip Files Can Be Downloaded Without Authenticating 17
Issue G. Unescaped Characters Put Into Content-Disposition Header 19
Issue H. Plaintext File Kept on Server when Whistleblower Does Not Finish 21
Submitting Tip
Issue I. User Input Written to Logs 23
Issue J: Attacker May Be Able To Extract Secrets Through Side-Channel Attacks 25
Issue J.1: Timing Leak of File Download Token 26
Issue J.2: Timing Leak of Collection Download Token 27
Issue J.3: Timing Leak of XSRF Token 28
Issue J.4: Timing Leak of Session ID 29
Issue J.5: Timing Leak of Usernames 30
Issue J.6: Timing Leak of Receipt Hashes 31
Issue K: Secrets Generated with Non-CSPRNG 32
Design and Implementation Analysis 34
Commendations 34
Recommendations 34
Coding Practices 34
Future Work 36
Online Guessing Attacks 36
Side-Channel Attacks 36
Eliminating Threads 36
Open Questions & Concerns 36
Appendix A. Work Log 39
Prior to This Audit 39
2014-01-28 to 2014-02-03 39
2014-02-04 39
2014-02-05 39
2014-02-06 40
2014-02-07 41
2014-02-10 41
2014-02-11 41
2014-02-12 41
2014-02-13 41
2014-02-14 42
2014-02-17 42
2014-02-18 42
2014-02-19 42
2014-02-20 42
Appendix B. Brainstorming Notes 43
Appendix C. Script for Issue E 46
Appendix D. Side-Channel Attack Proof of Concept 47
Appendix E. Computing Multiple Target Guessing Success Probabilities 49
Overview
Least Authority performed a security audit of GlobaLeaks on behalf of the Open Technology Fund. The
audit consisted primarily of developer interviews, design analysis, and code review. We also experimented
with software locally to test hypotheses.
Report Revision
This report is the final draft of the audit findings, delivered on 2014-03-21. Several unfinished revisions
were shared with the development team throughout the audit.
Audit Scope
The focus for this audit was the GLBackend and GLClient codebases. Interactive and automated
penetration testing targeted installations local to the auditors.
Methodology and Disclosure
Our audit techniques included manual code analysis, user interface interaction, and whitebox penetration
testing. After delivering this report to the development team, we continue to work with them on
remediations.
We promote a very transparent process, and all of our findings will find their way onto the public
GlobaLeaks Issue Tracker, once we believe sufficient remediation protects existing users. Additionally, we
will collaborate with that team to publish this report.
Process
The process Least Authority uses for security audits follows these phases:
1.Project Discovery and Developer Interviews
First, we look at the project's web site to get a high level understanding of what functionality the
software under review provides. We then meet with with the developers to gain an appreciation of
their vision of the software.
2.Familiarization and Exploration
In this phase we install and use the relevant software, exploring the user interactions and roles.
While we do this, we brainstorm threat models and attack surfaces.
3.Background Research
After our initial exploration, we read design documentation, review other audit results, search for
similar projects, examine source code dependencies, skim open issue tickets, and generally
investigate details other than the implementation.
4.Design and Implementation Investigation
In this phase we hypothesize what vulnerabilities may be present, creating Issue entries, and for
each we follow the following Issue Investigation and Remediation process.
5.Report Delivery
At this point in our schedule, we wrap up our investigative work. Any unresolved issues or open
questions remain documented in the report. After delivering a report to the development team, we
refrain from editing the report, even when there are factual errors, misspellings, or other
embarrassments. Instead, we document those changes after the fact either in an Addendum Report,
or more typically in project specific development issue tracking tickets specific to the security
findings.
6.Remediation
During this phase we collaborate with the developers to implement appropriate mitigations and
remediations. It may be the case that the actual mitigations or remediations do not follow our report
recommendations, due to the nature of design, code, operational deployment, and other engineering
changes, as well as mistakes or misunderstandings.
7.Publication
Only after we agree with the development team that all vulnerabilities with sufficient impact have
been appropriately mitigated do we publish our results.
Issue Investigation and Remediation
The auditors follow a conservative, transparent process for analyzing potential security vulnerabilities and
seeing them through successful remediation. Whenever a potential issue is discovered, we immediately
create an Issue entry for it in this document, even though we have not yet verified the feasibility and
impact of the issue.
This process is conservative because we document our suspicions early even if they are later shown to
not represent exploitable vulnerabilities. The process is transparent because we share intermediate
revisions of this document directly with GlobaLeaks, regardless of the state of polish. Additionally, we
attempt to communicate our evolving understanding and refinement of an issue through the Status field
(see Issue Format next).
We generally follow a process of first documenting the suspicion with unresolved questions, then verifying
the issue through code analysis, live experimentation, or automated tests. Code analysis is the most
tentative verification, and we strive to provide test code, log captures, or screenshots demonstrating our
verification. After this we analyze the feasibility of an attack in a live system. Next we search for immediate
mitigations that live deployments can take, and finally we suggest the requirements for remediation
engineering for future releases.
The mitigation and remediation recommendations should be scrutinized by the developers and
deployment engineers, and successful mitigation and remediation is an ongoing collaborative process
after we deliver our report, and before the details are made public.
Coverage
Our coverage focused on user interface and usability exploration, then GLBackend code, examining
exception handling, concurrency issues, entropy API usage, cross-site request forgery, session
management, logging, side channels, and persistent storage.
We also examined the client codebase to perform some basic XSS testing, examined clock skew between
client and server, and studied the Angular templating system.
Our depth of coverage of these areas is modest to moderate.
A detailed log of our investigations is in Appendix A. Work Log.
Target Code
Revision
This audit targets the GLBackend 2.52.3 and GLClient 2.52.3 release revisions, which comprise the
server and browser-client components of GlobaLeaks.
Dependencies
Although our primary focus was on the application code, we examined dependency code and behavior
where relevant to a particular line of investigation.
The GLBackend dependencies are:
Twisted
An asynchronous I/O and scheduling framework.
apscheduler
Advanced Python Scheduler