Visual Tools DVR3.0.6.16, vx series 4.2.19.2 – Multiple Vulnerabilities

  • 作者: Andrea Fabrizi
    日期: 2012-10-16
  • 类别:
    平台:
  • 来源:https://www.exploit-db.com/exploits/22005/
  • # 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.
    **************************************************************