96 lines
4.1 KiB
Text
Executable file
96 lines
4.1 KiB
Text
Executable file
# 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? 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.
|
|
**************************************************************
|