# Exploit Title: Multiple PTK DFlabs failures to restrict access to sensitive data
# Author: Anonymous
# Software Link: http://sourceforge.net/projects/ptk-forensics/files/ptk-1.x/ptk-1.0.5/ptk-1.0.5.tar.gz/download
# Version: 1.0.5
# Tested on: Ubuntu

--[A]-- Introduction

PTK DFlabs forensics is an alternative framework for the TSK suite (The
SleuthKit). The following vulnerabilities where discovered in the PTK
DFlabs (ptk-1.0.5.tar.gz) free version. Professional PTK DFlabs versions
might also be affected (Not tested).

--[B]-- Advisory

Sensitive log files, evidences (disk ".dd" images /ram images etc..) and
reports can be retrieved without being authenticated to the PTK DFlabs web
application.

1) Unrestricted Logs Access

Unauthenticated users can download PTK DFlabs logs by guessing their names
since no kind of authorization/authentication check is performed by PTK
DFlabs.
The PTK DFlabs web application saves data in the /log folder. An example of
the path and of the log names is the following:

http://localhost/ptk/log/audit.log
http://localhost/ptk/log/20120304.log

The "audit" log contains information about PTK registered users (e.g.
Investigators). The username disclosure can be used by attackers to perform
more easily a password brute force attack.

PTK DFlabs generates also a log about every day activities using the
following standard: year + month + day + ".log"
This "daily log" contains information about "cases" (a sort of project) and
about the name of the evidences (disk/ram images etc..).

An attacker can use the following script to generate valid log file names
and then download them:

echo
http://localhost/ptk/log/2012{01,02,03,04,05,06,07,08,09,10,11,12}{01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31}.log|
tr " "  "\n" | awk '{print "wget " $1}' | sh

This is an extract from the audit.log file generated by the PTK DFlabs that
discloses the usernames since it can be retrieved without being
authenticated:

04/03/2012 , 10:23:57 , admin , Http request may be crafted , Unauthorized
access to new_investigator
04/03/2012 , 10:03:06 , peter , Http request may be crafted , Login error

This is an extract from the "daily log" (e.g. 20120304.log) generated by
PTK DFlabs that discloses the name of the "case" and the name of the
evidences (disk/ram images etc..):

04/03/2012 , 14:20:23 , test , Http request may be crafted , Login error
04/03/2012 , 14:20:33 , admin , Http request may be crafted , User logged in
04/03/2012 , 14:20:53 , admin , Http request may be crafted , Investigators
modified for case caso1
04/03/2012 , 14:22:39 , admin , Http request may be crafted , New image
memoria added
04/03/2012 , 14:23:47 , admin , Http request may be crafted , Analysis
started on image memoria

2) Unrestricted Evidences Access

Since PTK DFlabs saves forensics evidences (disk .dd images, ram images
etc..) in a not secure manner thus allowing a direct and not authenticated
access, an attacker can use information contained into the "daily log"
generated by PTK DFlabs to retrieve the name of the "case" and the name of
the evidences (disk/ram images etc..) in order to download them from the
/images/ folder.

PTK DFlabs uses the following naming convection to save evidences (disk .dd
images, ram images etc..): case name + _ + image name + . + 3 numbers

As example, the lines of the "daily log" reported in this PoC
(20120304.log) they permit to an attacker to build the path to dowload
every evidences (disk/ram images etc..).
In this example the "case" name is "caso1" and the name of the evidence
(disk/ram images etc..) is "memoria". The attacker has only to interlock
the case and the image name and he has to fuzz the "extension" (3 number
long) in order to download, without being authenticated, every evidences
(disk/ram images etc..).

An example of a valid request is:

http://localhost/ptk/images/caso1_memoria.001

3) Unrestricted Reports Access

Since PTK DFlabs saves even reports in a not secure manner an attacker not
authenticated to the PTK DFlabs web application can retrieve every PTK
DFlabs report from the /report/ folder.
The naming convention for PTK DFlabs reports is: year + month + day + _ +
hour + . + minute + . + second + _ + case name + .pdf

An example of a valid request is:

http://localhost/ptk/report/20120304_16.08.21_caso1.pdf

Note that the attacker only needs to brute force the date and the time
values since the name of the "case" (caso1) can be recovered from log files.

4) Input validation: Reflected XSS

Furthermore also user input is not properly managed and the failure is
exacerbated by the lack of the HttpOnly in the Set-Cookie directive.
An authenticated user while analyzing a disk/ram image can trigger an XSS
with the following request:

Request:

GET
/ptk/lib/modal_bookmark.php?arg1=6&arg2=null&arg3=1&arg4=No|aaa%20-%20No|Memory%20at%20offset%20No.%20Found%20using%20keyword:%20aaa8f8fe"><script>alert(document.cookie)</script>c6692100772


5) Lack of HttpOnly

A Set-Cookie done by PTK DFlabs:

Set-Cookie: PHPSESSID=5sl9ktt7e7qrvbklacurq1drf3; path=/

--[C]-- Lulz

Now, a funny offprint about the supposed security/hardening of PTK DFLabs (
http://ptk.dflabs.com/news.html):

"PTK makes an extensive User Auth Check since its beta version" - DFlabs