PTK 1.0.5 Cross Site Scripting / Unrestricted Access

2012-03-30T00:00:00
ID PACKETSTORM:111360
Type packetstorm
Reporter anonymous
Modified 2012-03-30T00:00:00

Description

                                        
                                            `# 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  
`