Penetration Test Report (Cure53): pentest report casebox 1

Pentest-Report CaseBox 06. - 07.2014
Cure53, Dr.-Ing. Mario Heiderich / Dipl.-Ing. Johannes Dahse
Index
Intro
Scope
Identified Vulnerabilities
CB -01-001 Arbitrary File Disclosure in Preview ( Critica l)
CB -01-002 Weak Hash in Password Recovery leading to Auth Bypass ( Critica l)
CB -01-003 “ F ”- Grade SSL Cer t allows for feasible Eavesdropping Attacks ( High )
CB -01-004 XSS via unfiltered Folder - and Action - Name ( High )
CB -01-005 XSS in Conten t Field for user - created Actions ( High )
CB -01-006 Persisten t XSS via HTML Upload and Usage o f “ pw ” Parameter ( High )
CB -01-007 Header Injection via Download and malicious Filenames ( Low )
CB -01-009 User Profile and other Forms vulnerable to CSRF Attacks ( High )
CB -01-010 User ’ s Firs t - and Las t - Name vulnerable to XSS Attacks ( Critica l)
CB -01-011 Persisten t XSS via SVG Profile Photo Upload ( High )
CB -01-012 Multiple Apache SOLR Query Injections in the Search Class ( Medium )
CB -01-014 Remote Code Execution in AutoSetFields Plugin ( Critica l)
CB -01-015 Permission Restriction Bypass using CaseBox AP I ( Critica l)
CB -01-020 Flash XSS via Sencha Ex t JS Vulnerability ( High )
CB -01-021 Persisten t XSS via Upload and File Rename Feature ( Medium )
CB -01-022 Permission Restriction Bypass in AP I Objects class ( High )
CB -01-023 Persisten t XSS through Preview o f Objec t Field Data ( Medium )
CB -01-024 Persisten t Passive XSS in Item Title ( High )
CB -01-025 Persisten t XSS via File Name in Upload Queue ( Medium )
CB -01-027 Apache SOLR Injection Deletes al l Documents ( High )
CB -01-029 Second - Order SQL Injection in getUserData () ( Critica l)
Miscellaneous Issues
CB -01-008 Information Disclosure based on enabled PHP Error Display ( Low )
CB -01-011 Insufficien t Sal t and Password Hashing Complexity ( Medium )
CB -01-013 Weak Restrictions allow uploading PHP Files to Webroo t ( Medium )
CB -01-014 Information Disclosure in Browser . php with Invalid File N ames ( Low )
CB -01-015 Potentia l Cross - Site Scripting in AP I Response Handler ( Low )
CB -01-016 Potentia l Second - Order Cross - Site Scripting in TSV Auth ( Low )
CB -01-017 Source Code leaks IP Address o f Debug Servers ( Low )
CB -01-018 Remote MySQL connection on Virtua l Machines ( Medium )
CB -01-019 Unsanitized CORE _ NAME could lead to Vulnerabilities ( Medium )
CB -01-026 Missing SSL Verification in Yubikey Secre t Key Reques t ( Medium )
CB -01-028 Limited Path Traversa l Vulnerability in CB \ Files ( Low )
CB -01-030 Missing HTTP Security Headers and Name - Randomization ( Low )
Conclusion
Intro
“Casebox is being developed jointly by HURIDOCS and KETSE.com since 2011. It
started as a project to provide a sophisticated case management solution to one NGO,
and was subsequently expanded to become a flexible task, document and record
management system.”
From https :/ / www . casebox . org / abou t/
“CaseBox is designed to support the needs of litigation NGOs which are looking for an
integrated and web-based application to manage their caseload. … CaseBox can also
be provided to NGOs at a hosted “software as a service” solution, including technical
support, customisations, and upgrades. Please contact us, if you are interested in such
a solution.”
From https://www.huridocs.org/casebox/
This penetration test was carried out by two testers of the Cure53 team over the period
of ten days. Within the test scope thirty vulnerabilities and weaknesses were identified.
Among them, six were classified as critical. The tests were carried out against the
CaseBox application itself, the VMs made available for testing and development - as well
as the test and “tryout”-servers. Ultimately a dedicated test-sandbox was also used. Due
to the combination of the available demo app, testing VMs and access to the source
code, the testing team was capable of providing an extensive coverage of the tested
environment.
The threat model applied for this penetration test included external attackers, eager to
get access to the documents and information shared on a CaseBox platform as well as
internal attackers, eager to get access to information assigned to different users. Thus,
attacks against server, application, authentication mechanisms as well as Cross-Site
Scripting vectors triggered by logged in users were in scope for this penetration test.
Scope
• CaseBox Web Application
◦ https :/ / dev . casebox . org / demo / login .php
◦ rmack: casebox
◦ ladkins: casebox
◦ rstone: casebox
• CaseBox Source Code
◦ https :/ / github . com / KETSE /casebox
• CaseBox Development VM
◦ https :/ / www . casebox . org / d l / casebox - ov f .zip
• CaseBox Web Application (Audit Core)
◦ https :/ / dev . casebox . org / audi t/
Identified 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 vulnerability is additionally given a unique identifier
for the purpose of facilitating future follow-up correspondence.
CB-01-001 Arbitrary File Disclosure in Preview (Critical)
The CaseBox software provides a script that enables displaying a preview of uploaded
files within the web application itself. This preview.php file makes it possible to read any
file on the web server. By using path traversal (../)1, it is possible to escape out of the
preview directory and access files in different directories.
if ($ext !== 'html') {
$f = realpath(FILES_PREVIEW_DIR.$_GET['f']);
if (file_exists($f)) {
$finfo = finfo_open(FILEINFO_MIME_TYPE);
header('Content-type: '.finfo_file($finfo, $f));
echo file_get_contents($f);
}
exit(0);
}
Critically, this vulnerability allows one to read log files stored in /var/www/casebox/logs/
or config files, among others. It applies to files such as the httpsdocs/config.ini which
reveals the database credentials:
Example I:
https :/ / dev . casebox . org / demo / preview . php ? f =../../../.. / logs / ss l _ access _ log
66.249.93.115 [28/Jun/2014:17:15:50 +0200] "GET /dev/photo/2.jpg HTTP/1.1" 200
66.249.93.115 [28/Jun/2014:17:15:50 +0200] "GET /dev/photo/3.jpg HTTP/1.1" 200
109.185.98.86 [28/Jun/2014:17:21:26 +0200] "GET /ipc/ HTTP/1.1" 200
109.185.98.86 [28/Jun/2014:17:21:27 +0200] "GET /ipc/remote/api.php HTTP/1.1" 200
Example II & III:
https :/ / dev . casebox . org / demo / preview . php ? f =../../../.. / data / solr / con f / solrconfig .xml
https :/ / dev . casebox . org / demo / preview . php ? f =../../../.. / httpsdocs / config .ini
[database]
db_host = 127.0.0.1
db_port = 3306
db_user = local
db_pass = h0st
Furthermore, files uploaded by all users can be accessed. This signifies access to all
files of all installed CaseBox cores.
1 http :/ / en . wikipedia . org / wik i / Directory _ traversa l _ attack
Example IV:
https :/ / dev . casebox . org / demo / preview . php ? f =../../../.. / data / files / cla /2014/04/15/29992
The uploaded files’ names are numerical and stored under their creation date and core
name. Because the numbers are incremented, they are easily brute forced. To narrow
down the numbers’ range, the cron_extract_files_content.log file can be used to reveal
some file names. It is critically important to exclusively allow file downloads from the
preview directory and prohibit path traversal attacks.
Note: The issue was resolved during the pentest and verified as fixed by Cure53.
CB-01-002 Weak Hash in Password Recovery leading to Auth Bypass (Critical)
The token in the password recovery functionality is very weak and can be predicted by
an attacker who seeks to reset the password of an arbitrary user. Thus, it is possible to
take over any user account with no brute force implementation or guessing required. The
token is generated by a md5 hash of the user ID, the user email address, and the
current time in the recover_password.php file.
$