96 lines
No EOL
4 KiB
Text
96 lines
No EOL
4 KiB
Text
# Exploit Title: Visual Tools DVR multiple vulnerabilities
|
||
# Date: 2012-10-15
|
||
# Exploit Author: Andrea Fabrizi
|
||
# Vendor Homepage: http://www.visual-tools.com/
|
||
# Version: VS Series <= 3.0.6.16, VX Series <= 4.2.19.2
|
||
# Tested on: VS Series 3.0.6.16/VX Series 4.2.19.2
|
||
|
||
Visual Tools develops, manufactures and commercializes video
|
||
surveillance and video observations systems under the global brand
|
||
name VideoSafe Technology or under other companies<65> brand names.
|
||
|
||
The DVR systems are based on x86 Debian GNU Linux embedded (aka
|
||
emdebian) and the entire framework and software are written using
|
||
Python.
|
||
|
||
After a full reverse engineering of the firmware i discovered some
|
||
interesting vulnerabilities, that allow an unauthorized user to access
|
||
the DVR web interface and gain a root shell on the system. At the time
|
||
i write this advisory, all DVR products commercialized by Visual
|
||
Tools, based on this firmware, are vulnerable.
|
||
|
||
1]======== Administration password disclosure ========
|
||
The system expose an hidden cgi that disclose the
|
||
Operator/Supervisor/Administrator password if invoked during the first
|
||
ten minutes after system boot.
|
||
|
||
- http://DVR_ADDRESS/cgi-bin/util/passwords.py
|
||
|
||
Is possible to write a simple script that check the cgi, every five
|
||
minutes for example, waiting for the device reboot, that sooner or
|
||
later, will happen :)
|
||
|
||
2]======== Default Administration password ========
|
||
As the previous vulnerability, also in this case is possible to access
|
||
any DVR system, during the first ten minutes after system boot, using
|
||
an hard-coded password.
|
||
|
||
The default password is: elefante (valid for
|
||
Operator/Supervisor/Administrator account)
|
||
|
||
3]======== Log files disclosure ========
|
||
The system expose an hidden cgi that allow any unauthenticated user to
|
||
get the system log files. By default the script does not works,
|
||
because the zip file is generated into the cgi-bin directory.
|
||
But... taking advantage of a directory traversal vulnerability that
|
||
affect the same script, is possible to write the zip file into the
|
||
apache root directory, and download it directly via browser.
|
||
|
||
- http://DVR_ADDRESS/cgi-bin/util/ziplogs.py?filename=../../html/logs
|
||
- http://DVR_ADDRESS/logs.zip (the zip file generated)
|
||
|
||
Moreover, the file "service.log" contains the Session ID of the
|
||
authenticated user, that can be used to hijack an existing session.
|
||
|
||
4]======== recv_ip_filtering.py command injection ========
|
||
Is possible, for authenticated users, to exploit a command injection
|
||
vulnerability that affects the script
|
||
/cgi-bin/conf/recv_ip_filtering.py.
|
||
This script, used to add or remove ip addresses from the local
|
||
iptables, accept one parameter that contains a list of IPs separated
|
||
by space, so is not possible to execute directly a command that
|
||
contains a space char.
|
||
A workaround can be done passing the command through an http header
|
||
(user-agent for example), and invoking the corresponding environment
|
||
variable.
|
||
|
||
This is a sample request:
|
||
POST http://DVR_ADDRESS/cgi-bin/conf/recv_ip_filtering.py HTTP/1.1
|
||
User-Agent: [COMMAND]
|
||
Cookie: language=en; session=VALID_SESSION_ID; user=administrator;
|
||
current_page=main/400_Mconf/200_Mnetwork
|
||
Content-Type: application/x-www-form-urlencoded
|
||
Content-Length: 90
|
||
|
||
iplistFields=192.168.0.1+192.168.0.2%3b$HTTP_USER_AGENT%3b
|
||
|
||
The command will be executed with the privilege of the apache user.
|
||
|
||
5]======== init_diskmgr insecure permissions ========
|
||
The script "/home/apache/DiskManager/cron/init_diskmgr", writable by
|
||
the apache user, is executed by crontab every 15 minutes, with root
|
||
privileges.
|
||
So, editing the script and waiting the scheduled execution, is
|
||
possible to run command on the system with root privileges.
|
||
|
||
By default the ssh access is denied because the /etc/shadow don't
|
||
contains the root password shadow, but exploiting this vulnerability
|
||
is possible to add it and gain ssh access to the system.
|
||
|
||
|
||
**************************************************************
|
||
TIME-LINE
|
||
|
||
- 21/09/2012: Vendor contact. No response.
|
||
- 15/10/2012: Disclosure.
|
||
************************************************************** |