Penetration Test Report (Cure53): pentest report globaleaks

Pentest-Report Globaleaks 06.2013
Cure53, Dr.-Ing. Mario Heiderich / Gareth Heyes / Abraham Aranguren / Krzysztof Kotowicz
Index
Introduction
Scope
Tes t Chronicle
Vulnerabilities
GL 01-001 Receiver Login allows password - less authentication ( Critica l)
GL 01-002 XSS via sniffing and JSON injection in authentication page ( Medium )
GL 01-003 Unsafe File - Downloads in Receiver - Area causing Loca l XSS ( Medium )
GL 01-004 Possible information leakage through Browser / Proxy Cache ( Medium )
GL 01-014 Lack o f protection agains t brute - forcing admin role password ( Medium )
Miscellaneous
GL 01-005 Log - File contains un - encoded HTML characters ( Low )
GL 01-006 Whistleblower uploads allow flooding the server hard - disk ( Medium )
GL 01-007 Crafted File - Uploads allow Conten t - Type Spoofing ( Low )
GL 01-008 X - Frame - Options header no t presen t ( Low )
GL 01-009 Login / File upload sections do no t have CSRF tokens ( Low )
GL 01-010 Admin role does no t have a username ( Low )
GL 01-011 Admin - Uploads functiona l despite conten t filter / validation ( Low )
GL 01-012 Defaul t admin credentials and search engine indexing ( Medium )
GL 01-013 Potentia l Arbitrary File writes on non - defaul t configuration ( Low )
GL 01-015 Application log file contains administrator password ( Low )
GL 01-016 Weak filesystem permissions enable loca l attacks ( Medium )
GL 01-017 Readable hard - coded credentials migh t compromise users ( Low )
Conclusion
Introduction
“GlobaLeaks is an open source software system intended to enable anonymous whistle-
blowing. The GlobaLeaks organization, in addition to developing a whistle-blowing
software suite, aims to promote whistleblowing to the public.”1
The penetration test against the Globaleaks system was carried out by four members of
the Cure53 team and involved source code analysis as well as application-testing with a
pre-installed VM. The VM contained the latest available version of either Globaleaks
Backend components and the client side implementation (at the time of testing, the
version 0.2.0.19-2 was available).
The application was tested in an Intranet-setup - so all URLs used in code examples
point to a local HTTP domain - instead of .onion domains. During the penetration test,
constant communication with the Globaleaks developer team was maintained, critical
flaws were reported directly after their identification and fixed soon after. The test was
carried for an overall period of ten days and focused on logical flaws, DOMXSS
problems, upload security and general injection bugs.
The penetration test resulted in a surprisingly low amount of actual vulnerabilities - and a
larger amount of general recommendations and unexploitable minor problems that might
aid an attacker in leaking data or preparing the setup for an actual attack and therefore
need to be addressed. The most important finding during this penetration test was a
logic flaw that enabled an attacker to log in as a receiver (a role allowing insight in tips
submitted by a whistleblower) without requiring a password.
Scope
• Globaleaks Client
◦ URL: https :/ / github . com / globaleaks /GLClient
• Globaleaks Backend
◦ URL: https :/ / github . com / globaleaks /GLBackend
Test Chronicle
• 2013/06/02 - Initial Briefing
• 2013/06/02 - Testing auth and ACL - session switching/ privilege escalation
• 2013/06/02 - Trivial XSS tests, initial source code audit
• 2013/06/02 - Testing against SQLite truncation attacks
• 2013/06/02 - Tests against the image upload feature
• 2013/06/02 - Cookie injections, attempts to case XSS via cookie.auth_landing_page
• 2013/06/02 - Testing possibilities for unauthorized logo upload
• 2013/06/03 - Initial server testing and fuzzing
1 Wikipedia: Globaleaks https :/ / en . wikipedia . org / wik i /GlobaLeaks
• 2013/06/03 - Searching for vulnerabilities against cyclone
• 2013/06/03 - Web server HTTP verb support analysis
• 2013/06/03 - Analysis of default options
• 2013/06/03 - Testing WB account
• 2013/06/03 - Testing authentication page
• 2013/06/03 - Testing admin account
• 2013/06/03 - Testing receiver account
• 2013/06/03 - File comments tested for XSS - all encoded no html allowed
• 2013/06/03 - Http header inspection
• 2013/06/03 - Cookie based switching of user account tested for higher privs
• 2013/06/03 - Tested JSON responses
• 2013/06/03 - Tested X-Session is actually used in XHR requests
• 2013/06/03 - Custom url feature doesn’t seem to use anchors for links no XSS
• 2013/06/04 - Code review of file manipulation and string concatenation
• 2013/06/04 - Attempting header injection attacks
• 2013/06/04 - Testing file upload file names
• 2013/06/04 - Character conversions in JSON requests and new lines
• 2013/06/04 - Testing invalid tip urls
• 2013/06/04 - Testing information leakage through browser caching
• 2013/06/04 - Analysis of database code
• 2013/06/05 - Analysis of used functionality from underlying python libraries
• 2013/06/05 - RCE attempts via Storm Pickle data types
• 2013/06/05 - Tested hash path on IE for unencoded < and >
• 2013/06/05 - Testing field types for XSS
• 2013/06/05 - Auth testing null/undefined values in JSON
• 2013/06/05 - Tested CRLF and similar characters in uploaded file names
• 2013/06/06 - Tested new line escapes in filename and mime type
• 2013/06/06 - Job modules: Code analysis with brief look at apscheduler library
• 2013/06/06 - Filesystem permission analysis
• 2013/06/06 - Checking password storage
• 2013/06/06 - Code review for cryptographic features used & id generation
• 2013/06/06 - Code review for GLBackend
• 2013/06/07 - Brief look at source code for cyclone file uploads
• 2013/06/07 - Brief look at how the globaleaks user is created
• 2013/06/07 - Tests against DOMXSS via AngularJS and scope.$eval()
• 2013/06/07 - Analysis of file creation permissions
• 2013/06/07 - Code review for GLClient
• 2013/06/08 - Finalization Pentest-Report
Vulnerabilities
The following sections list the vulnerabilities and implementation issues we spotted
during our tests. Note that the found issues are being listed in chronological order
instead of being ordered by severity and impact.
GL01-001 Receiver Login allows password-less authentication (Critical)
The Globaleaks login system for receivers allows authentication without valid password
because of a logic bug in the authentication-handling code:
The current implementation doesn’t set the login state to false in case the submitted
password is not correct - only the number of invalid login requests is being incremented.
The JSON response returns a valid user_id and session_id for any correct user +
incorrect pass combination - meaning an attacker can login with any password in case a
valid username (email address) is known and used.
URL: http ://127.0.0.1:8082/# /login
Username: test@test.test
[CREDENTIAL_REDACTED] (any string suffices here)
Sample JSON request:
{"username":"test@test.test","password":"invalidpassword","role":"receiver"}
Sample response:
{"user_id": "fca3966f-ffef-4d4a-8d7a-6b24aefbe586", "session_id":
"BNfKRpuRzMjOqjro1CsTtHEmNKSpalNRbqRyoC4QcA"} < valid user and session ID
Expected response:
{"error_message": "Authentication Failed", "error_code": 29}
The affected code can be found in the file globaleaks/handlers/authentication.py:
if not security.check_password(password, receiver.password, receiver.username):
security.insert_random_delay()
receiver.failed_login += 1
if receiver.failed_login >= GLSetting.failed_login_alarm:
log.err("Warning: Receiver %s has failed %d times the password" %\
(username, receiver.failed_login) )
# this require a forced commi ... ception would cause a rollback!
store.commit()
raise errors.InvalidAuthRequest
else: < login state is not set to logout in case password doesn’t match
log.debug("Receiver: Authorized receiver %s" % username)
receiver.failed_login = 0
receiver.last_access = utils.datetime_now()
return unicode(receiver.id)
The vulnerability was reported and confirmed immediately