Penetration Test Report (Cure53): pentest report securedrop

Pentest-Report SecureDrop 12.2013
Cure53, Dr.-Ing. Mario Heiderich / Nikolai K. / Fabian Fäßler
Index
Intro
Scope
Tes t Chronicle
Vulnerabilities
SD -01-001 No HTTP Security Headers on Apache Error Pages ( Medium )
SD -01-002 Missing HTTP Security Headers and Name - Randomization ( Low )
SD -01-005 Missing HTTP Security Headers for 404 Pages ( Medium )
SD -01-006 Possible path confusion / traversa l via imprecise store . verify () ( Medium )
SD -01-008 HTML Links on SecureDrop static sites leak Referrer ( Medium )
SD -01-011 IPTABLES configuration allows outbound traffic ( Medium )
SD -01-012 Flask cookies leak ( server - side ) session values ( L ow )
Miscellaneous
SD -01-003 Overly permissive Database privileges for “ securedrop ” user ( Low )
SD -01-004 Lax Permissions for google - authenticator Files ( Low )
SD -01-007 Considerations abou t TBB Configuration Settings ( Medium )
SD -01-009 Possible Attacks via unfiltered File - Names in ZIP - File Creation ( Low )
SD -01-010 Denia l - O f - Service for Source via UTF -8 in Journalis t - Message ( Medium )
Conclusion
Intro
“SecureDrop is an open-source whistle-blower submission system managed by
Freedom of the Press Foundation that media organizations use to securely accept
documents from anonymous sources. It was originally coded by the late Aaron Swartz.”
From https :/ / github . com / freedomofpress /securedrop
This test was carried out by three Cure53 testers and took place over a 5-day period
between 2nd and 6th of December 2013.
The test focused on application and server security matters directly related to the code
and features of the SecureDrop application. The Cure53 team was granted an access to
an existing system setup, including a submission form, a document interface and
console access to the App- and the Monitor-Server1. The tests were performed from both
black-box and white-box perspectives. While testing the application, the Cure53 team
1 https :/ / github . com / freedomofpress / securedrop / blob / master / docs / instal l .md
had consulted a set of sources used for the tested setup. Furthermore, our team was
able to navigate the servers’ directories via SSH access with a high-privilege user
account. The Cure53 team further followed the full installation and setup manual in order
to live-experience all components that are crucial to the SecureDrop communication
system. Those included the use and analysis of Tails USB sticks and a server setup on a
set of AWS instances.
This report does not mention vulnerabilities already reported in “DeadDrop/StrongBox
Security Assessment” by Czeskis et al., regardless of their fix status2. We similarly do not
elaborate on the SecureDrop documentation, installation process, code management or
hypothetical technical proficiency of SecureDrop users, such as the perceived degree of
concurrence between the complexity of the installation and the technical acumen and
background of an average user. We embrace a similar threat model to that outlined by
Czeskis and agree on the assumptions made about the attacker’s strengths,
competencies and exceptionally high motivation. However, we equally consider a
scenario in which a journalist goes rogue or is bribed by a third party - the potential
cases that position him or her as inclined to unveil secrets behind a source. This
inevitably led to a discussion about possibly infected PGP keys briefly mentioned in the
conclusion of this Report.
The penetration-test yielded an outcome of eleven weaknesses. Significantly, none of
them are considered critical. The SecureDrop team managed to fix several of the
reported issues during the penetration-test already, thus allowing for a timely verification
from the Cure53 team’s side.
Scope
● SecureDrop Application
○ https :/ / github . com / freedomofpress /securedrop
● Source Interface
○ http://jgdevcded4x6dl37.onion
● Document Interface
○ http://ugdhee7iyiiokyty.onion:8080
● Admin app server
○ http://vhvxgl6apivhewlx.onion
● Admin monitor server
○ http://4mgzyj4p6mcl67qt.onion
2 http :/ / homes . cs . washington . edu /~ aczeskis / research / pubs / UW - CSE -13-08-02 .PDF
Test Chronicle
● 2013/12/02 - Penetration-Test starts
● 2013/12/02 - Source code audit against Python files begins
● 2013/12/02 - Checking for safe random number generation
● 2013/12/02 - Auditing Tails Browser Configuration for leaks
● 2013/12/02 - Checking HTTP Security headers
● 2013/12/02 - Checking for insecure defaults in install files
● 2013/12/02 - Checking for unnecessary privilege spills
● 2013/12/02 - Analyzing transport security issues
● 2013/12/02 - Checking file permissions on default install
● 2013/12/02 - Checking general app-server setup/perms and chroot configuration
● 2013/12/02 - Testing session security and file upload security
● 2013/12/02 - Searching RCE bugs via Flask
● 2013/12/02 - Seeking XSS and SQLI Bugs via File Upload
● 2013/12/03 - Checking OSSEC configuration on app-server
● 2013/12/03 - Quick audit of the OSSEC sourcecode
● 2013/12/02 - Checking general monitor-server setup and permissions
● 2013/12/03 - Verifying whether WFP in Tor applies to SecureDrop
● 2013/12/03 - Analyzing 404 headers for possible misconfiguration
● 2013/12/03 - Analyzing a recurring 500 error during a submission check
● 2013/12/03 - Referer leakage analysis, link injections, link hijacking
● 2013/12/03 - More tests against possible LFI / directory traversal via verify()
● 2013/12/03 - Tests against freshly released Tails 0.2.2 OS version
● 2013/12/03 - Further research on possible traffic analysis / confirmation attacks
● 2013/12/04 - Tests against command injection via OpenPGP
● 2013/12/04 - Studies on possibly poisoned PGP keys / chameleon-keys
● 2013/12/04 - Tests against possible python routing bugs
● 2013/12/04 - Tests with broken UTF-8 / Unicode
● 2013/12/04 - Tests of the recently fixed messaging feature
● 2013/12/04 - Ongoing source code audit
● 2013/12/04 - Tests against possible path-traversal in ZIP files
● 2013/12/05 - Ongoing monitor-server checks
● 2013/12/05 - Reviewing iptables configuration
● 2013/12/05 - Ongoing source-code audit
● 2013/12/05 - Reviewing dependencies
● 2013/12/05 - Reviewing the Flask session backend
● 2013/12/06 - Tests against cookie security and possible leaks
● 2013/12/06 - Final source-code audit
● 2013/12/06 - Checks against recent commits
● 2013/12/06 - Finalization of the Pentest-Report
● 2013/12/06 - End of the Penetration-Test
Vulnerabilities
The following sections list both vulnerabilities and implementation issues spotted during
the testing period. Note that findings are listed in a chronological order rather than by
their degree of severity and impact, which is simply given in brackets following the title
heading for each vulnerability. Each listed vulnerability is given a unique identifier for the
purpose of facilitating follow-up correspondence.
SD-01-001 No HTTP Security Headers on Apache Error Pages (Medium)
The SecureDrop submission interface uses several HTTP Security headers to ensure
additional level of protection against Clickjacking, XSS and similar attacks. However,
upon submitting a faulty request, an Apache default error page will be delivered.
Application Headers:
HTTP/1.1 200 OK
Date: Mon, 02 Dec 2013 12:08:45 GMT
Server: Apache
Expires: -1
Pragma: no-cache
Cache-Control: no-cache, no-store, must-revalidate, max-age=0, no-cache, no-
store, must-revalidate
Set-Cookie: session=.eJw9zE0LgjAAgOG […] OdyUvKGRk; HttpOnly; Path=/
x-frame-options: DENY
Access-Control-Allow-Origin: http://jgdevcded4x6dl37.onion:80 < redundant
X-XSS-Protection: 1; mode=block
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 1090
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
Error-Page Headers:
HTTP/1.1 500 Internal Server Error
Date: Mon, 02 Dec 2013 12:02:23 GMT
Server: Apache
x-frame-options: DENY
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 343
Connection: close
Content-Type: text/htm