Using Metasploit to Access Standalone CCTV Video Surveillance Systems

A new module for the Metasploit Framework discovers and tests the security of numerous standalone CCTV (Closed Circuit Television) video surveillance systems. Such systems are frequently deployed in retail stores, living communities, personal residences, and business environments as part of their physical security policy. However, many of these systems are vulnerable to exploitation that can allow attackers remote access. Such remote access, enabled by default, can allow not only the ability to view real-time video, but control of the cameras (if supported), and provide access to archived footage. Many owners of CCTV video surveillance systems may not even be fully aware of the device’s remote access capabilities as monitoring may be conducted exclusively via the local video console. This further increases the likelihood of attackers gaining/persisting remote access, with no indication to the owner that their video surveillance system and archived footage may be accessed remotely.

This module targets standalone CCTV video surveillance systems by MicroDigital, HIVISION, CTRing, and a substantial number of other rebranded devices.

Background

Here at Gotham Digital Science, we often encounter video surveillance systems during penetration testing engagements – some of which may be exposed to the Internet, either intentionally or by accident. With any video surveillance system it is often interesting (and sometimes very important) to find out exactly what cameras are monitoring/recording within the environment. Furthermore, access to such systems can often be utilized to support physical security testing initiatives.

Technical Details

Interacting with the standalone CCTV system can be achieved via a Win32 thick client, a mobile device (Android/iPhone/Windows Mobile), or an IE ActiveX control in which a user name and password are required. Typically, in over 70% of cases the device is still configured with the default vendor password which allows trivial access to real time video, the ability to control PTZ (pan-tilt-zoom) cameras, and access to any archived footage. Unfortunately (for us) in this case, the default password to the Internet facing systems had been changed, warranting a more aggressive approach.

The first step was to gain a better understanding of the authentication mechanism. As it turned out the ActiveX control was not proxy aware, and did not handle authentication over the HTTP protocol. Enter Wireshark.

Wireshark revealed that the ActiveX client handles authentication over port 5920/TCP by first sending an 8-byte packet (notifying the server to prepare for authentication), followed by a 128-byte packet containing the user name and password (in clear-text). 

The figure above displays the TCP stream of data sent and then received by the ActiveX control. First attempted was the user ‘admin’ with a password of ‘1234’ in which the ActiveX client returned the message “password error”. Next tried was the user name ‘test’ with a password of ‘1234’. This attempt returned the client side response “id error” as well as a different sequence of bytes, as can be observed in the figure below. Note the differences marked in red.

Based on the difference in responses, we know it’s possible to confirm valid users as well as invalid users. But what about other types of authentication responses? There are numerous methods that can be utilized to achieve this such as reverse engineering the ActiveX control, utilizing a generic network proxy, or via a MITM (man-in-the-middle) attack.

In this case, this most time effective solution was to utilize a proxy such as Echo Mirage, a generic network proxy that can be utilized to intercept and modify network data for non-proxy aware applications. As demonstrated in the figure below, this tool can be attached to the running process (iexplorer.exe) and then the response traffic intercepted and modified in order to classify unknown application responses.

Alternatively, MITM attacks leveraging tools such as Ettercap can be utilized to achieve the same result, and depending on the protocol, may be preferred. Beyond just ARP poisoning and sniffing network traffic, Ettercap has the ability to apply filters which can be utilized to intercept and modify packets on the wire. This ability can be leveraged to enumerate the different possible ActiveX client responses as well. The figure below displays a filter utilized to modify a known value (“password error”), with a network response not yet classified, “00 01 05 01 00 00 00 00 “.

if (ip.proto == TCP && tcp.src == 5920) {
replace(“\x00\x01\x03\x01\x00\x00\x00\x00”, “\x00\x01\x05\x01\x00\x00\x00\x00”);
msg(“Filter executed.\n”); }

Executing this Ettercap MITM filter granted access to the ActiveX CCTV camera interface, thus indicating a successful authentication response, however, no video feed was displayed. On the upside though, we have now classified another response type from the server. The table below lists the responses \x00 through \x09. Note there are two responses for successful authentication.

Response Value	ActiveX Client Response
\x00\x01\x00\x01\x00\x00\x00\x00	<no response>
\x00\x01\x01\x01\x00\x00\x00\x00	<authentication successful>
\x00\x01\x02\x01\x00\x00\x00\x00	“id error”
\x00\x01\x03\x01\x00\x00\x00\x00	“password error”
\x00\x01\x04\x01\x00\x00\x00\x00	“no network user”
\x00\x01\x05\x01\x00\x00\x00\x00	<authentication successful>
\x00\x01\x06\x01\x00\x00\x00\x00	<no response>
\x00\x01\x07\x01\x00\x00\x00\x00	<no response>
\x00\x01\x08\x01\x00\x00\x00\x00	<no response>
\x00\x01\x09\x01\x00\x00\x00\x00	<no response>

Now that we can determine valid/invalid users as well as authentication succeeded/failed responses, we can build software to intelligently brute force valid accounts over the proprietary protocol. Enter Metasploit.

Metasploit is an amazing framework that can be adapted for a number of penetration testing activities, including rapid development of custom exploitation modules. In this case, we created a module that allowed us to successfully discover such systems elsewhere in the network, determine valid user accounts, exclude non-valid accounts, and then brute force logins. During this exercise, we discovered that 70% of the instances utilized had default vendor passwords that had not been changed. Thus included within the module is a list of common passwords utilized for such standalone CCTV video surveillance devices. 

msf > use auxiliary/scanner/misc/cctv_dvr_login
msf auxiliary(cctv_dvr_login) > set RHOSTS 10.10.1.14
RHOSTS => 10.10.1.14
msf auxiliary(cctv_dvr_login) > exploit

[*] 10.10.1.14:5920 CCTV_DVR - [001/133] - Trying username:’admin’ with password:”
[-] 10.10.1.14:5920 CCTV_DVR - [001/133] - Failed login as: ‘admin’
[*] 10.10.1.14:5920 CCTV_DVR - [002/133] - Trying username:’user’ with password:”
[-] 10.10.1.14:5920 CCTV_DVR - [002/133] - Invalid user: ‘user’
[*] 10.10.1.14:5920 CCTV_DVR - [003/133] - Trying username:’admin’ with password:’admin’
[-] 10.10.1.14:5920 CCTV_DVR - [003/133] - Failed login as: ‘admin’
[*] 10.10.1.14:5920 CCTV_DVR - [004/133] - Trying username:’admin’ with password:’1111’
[+] 10.10.1.14:5920 Successful login: ‘admin’ : ‘1111’
[*] Confirmed IE ActiveX HTTP interface (CtrWeb.cab v1,1,3,1): http://10.10.1.14:80
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed 

Follow Up

The market for CCTV video surveillance systems is significant with a large number of primary manufactures — and even more distributors selling rebranded equipment, all with similar internal components. After this penetration test we made inquiries to local businesses who sell/install these types of standalone CCTV video surveillance systems. We were told these devices are purchased “by the crate” as they are one of the most cost effective standalone CCTV solutions. A little more homework and passive reconnaissance showed that these devices have a substantial global deployment base with heavy concentrations in the United States, Russia, Japan, China, and South Korea.

In conclusion, physically monitoring sensitive locations within an environment is an important aspect of a well-rounded information security program. However, at the same time such video surveillance devices can themselves be a risk and are often overlooked during security audits and vulnerability/penetration tests. This module exploits one of the common types of standalone CCTV video surveillance systems in use globally. It is likely that other manufacturers and CCTV devices are similarly vulnerable.

Companies who want to protect against this type of attack should change default vendor passwords, use strong passwords, filter access to only trusted hosts, and only expose the CCTV system to the Internet if absolutely necessary. In addition, security professionals can use the new Metasploit module to scan their network for vulnerable systems.

The new CCTV module is already available in the Metasploit Framework. Simply download Metasploit and update to the latest version using the command msfupdate. The module will be added to the commercial Metasploit editions as a part of the normal release cycle later this week.

Debunking NSLog Misconceptions

It is a fairly common occurrence to encounter iOS applications that are logging sensitive data during mobile application security assessments.  Some examples of sensitive data we have seen logged include authentication tokens, session cookies, passwords, etc. We have also noticed that developers sometimes do not fully understand the implications of logging this data using the NSLog function. Lets walk through some of these misconceptions.

1. NSLog data is only displayed in the device console and not stored on the device.

When writing an iOS application, developers commonly use NSLog for debugging purposes and the data is displayed within the device console provided by XCode. Behind the scenes, the data passed to the NSLog function is logged using the Apple System Log (ASL), which is Apple’s alternative for syslogd. On iOS devices, the data logged using ASL appears to be cached until the device is rebooted.

2. NSLog data cannot be read by other applications.

The Apple System Log C library (asl.h), which is available for Mac OS X, is also available on iOS. This library can be used to print out the contents of the ASL and even perform queries to retrieve specific log data. An example of a query would be querying for data logged by specific applications. One might ask, what about the iOS sandbox? Shouldn’t the sandbox prevent applications from accessing data logged by another application? Unfortunately, the iOS sandbox does not protect the ASL and therefore any application is able to view the data logged by another application. The following documentation details the ASL API for writing, reading and querying data from the ASL:

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/asl_search.3.html#//apple_ref/doc/man/3/asl_search

3. iOS prevents applications from utilizing these low level C APIs during their submission review process.

Unfortunately, it does not look like Apple has a strict restriction on iOS applications utilizing the ASL C library in order to retrieve data from the ASL. There are applications currently in the App Store that are able to read and perform queries on ASL data. One example of such an application is the “AppSwitch” application. 

So let us recap,

• iOS application data logged using NSLog utilizes the Apple System Log (ASL) which caches the data logged until the device is rebooted
• The ASL data can be read and queried through a C API available for iOS applications. This API is not restricted by Apple’s application review process.
• The ASL data is not sandboxed and therefore any iOS application can read data logged by arbitrary applications

Due to all these conditions, logging sensitive data using NSLog should be considered a fairly high-risk issue. If applications are logging sensitive authentication data, a malicious application would be able to actively query for this data and send it off to a remote server.

Developers should get in the habit of using a preprocessor macro for performing any logging used during the development process. The following blog post provides a nice walkthrough on how to utilize NSLog when building in DEBUG mode and how to remove all NSLog statements within production builds.

http://www.cimgf.com/2009/01/24/dropping-nslog-in-release-builds/

SOURCE Barcelona: Rails Slides Posted

My presentation slides (Security Goodness with Ruby on Rails) from last week's SOURCE Barcelona Conference are posted here. During the talk I spoke about strategies for both auditing and writing more secure applications with this popular framework. I covered a number of different topics including: best practices, security tools and APIs, and how to identify and address the most common vulnerabilities.

Thanks to Stacy and the SOURCE Barcelona Advisory Board for putting on such a great conference. As always, I felt very comfortable there and had a great time. I highly recommend attending SOURCE next year and enjoying Barcelona as well.

Ekoparty Presentation: Cloud & Control

I gave my first presentation at a security conference on Friday, presenting at ekoparty on some work I did at the beginning of the year on distributing complex tasks to hundreds or thousands of computers. SETI@Home was the project that pioneered the idea of distributed volunteer computing, and their command & control software evolved into a generic project called BOINC. You can run just about any application in BOINC - whether it's open or closed source, uses GPUs, the network, or even if it's not CPU intensive (like nmapping the internet).

Setting up a server isn't the most exciting topic to talk about, so I used two examples to illustrate BOINC in my presentation: factoring RSA512 to recover the private key to SSL certificates or PGP keys and cracking passwords. Factoring was a huge success, but cracking didn't work out that well. BOINC was able to distribute the work and crack things really quickly - by splitting up wordlists automatically based on hash functions I was able to scale out to more machines than I think most people are able to... but the problem came from never actually looking at the output. The best crackers, especially in cracking contests, find patterns in the cracked passwords to make mangling rules and masks and crack more passwords. You could still use BOINC as a work distributor to scale out, but you need to be behind the wheel making work units - not use it as a fire-and-forget system.

Getting applications running in BOINC is a bit of trial and error. If it's an open source application, you have to patch it a little bit and if it's closed source you have to write a job.xml file defining how to run the application. In either case you have to define input and output templates that let BOINC know what files to send with the workunit and to expect the program to produce. And when I was sending a couple hundred MB wordlists and resource files, I wanted to compress them and decompress them on the client, so that added a little bit of work too. To try and make it easier on you, I've released all the scripts, templates, config files, and patches I created while working with BOINC. I've also not just released my slides, but annotated them with links to the reference material for everything mentioned. Everything is up on github.

I've wanted to factor large numbers for a while, and this was actually what got me into this whole mess. I have some (simple) observations about factoring using the General Number Field Sieve, as well as instructions for how to do it yourself (with or without BOINC).

I have to thank Leonardo and all the ekoparty organizers for putting on a great conference. They went out of the way to make the international arrivees as comfortable as possible, and even had simultaneous translation from english to spanish and from spanish to english. Buenos Aires is a wonderful city, and I really recommend you visit!

.NET Server.Transfer vs Response.Redirect - Reiterating a Security Warning

During several recent .NET (C#) security code review projects, multiple severe authorization bypass vulnerabilities were identified that allowed unprivileged remote users to access any page hosted on the web server, despite not having been provisioned with the appropriate required security access permissions.  (Typically an attacker could leverage this type of vulnerability to access application administration functionality, both to obtain access to application data and to consolidate on-going future privileged access for themselves.)

The primary cause of these vulnerabilities was insecure use of the Server.Transfer method.  As we continue to regularly identify and exploit this issue during our security reviews I thought I would write this quick blog in an effort to further raise awareness around this simple yet often overlooked security item. 

Ultimately, any use of the Server.Transfer method that takes in user controllable input is likely to result in authorization bypass vulnerabilities (amongst other possible security issues).  This is a known issue and is captured in the Microsoft Support KB Article ID: 320976 (http://support.microsoft.com/kb/320976/). 

The underlying security “gotcha” that is not well communicated/publicized to developers is that when using the Server.Transfer method, the new page is being retrieved and presented by a separate handler, during which no authorization checks are performed regarding the actual remote user/callers identity.  This is very different from the Response.Redirect method which instructs the user’s browser to request a different page, and forces a new page request - thus (hopefully) triggering an appropriate authorization check.

Unfortunately, much of the core standard documentation available to developers makes no mention of this important security factor, including those found on the MSDN site (http://msdn.microsoft.com/en-us/library/ms525800%28v=vs.90%29.aspx).  In fact, on first glance the documentation on MSDN states that “Server.Transfer acts as an efficient replacement for the Response.Redirect method” but does not highlight the potential security implications of using this method.

(However, to be fair, the MS Patterns and Practices team do capture this exact issue in Chapter 6 of their “Improving .NET Application Performance and Scalability” publication: http://msdn.microsoft.com/en-us/library/ff647787.aspx)

As an example, the following vulnerable code snip is representative of those we regularly identify and leverage in proof-of-concept authorization bypass attacks:

        protected void btnBack_Click(object sender, System.EventArgs e)
        {

          string returnUrl = Request["ReturnUrl"];
           if (returnUrl == null)
            {
                returnUrl = "Login.aspx";
            }

            Server.Transfer(returnUrl);
            Response.End();
       }

The function above will redirect the browser to the page contained in the ReturnUrl parameter, unless it is null in which case the browser will be redirected to the login page.

A typical application will have authorization checks to confirm if a user is authorized to view a requested page but as discussed previously when the Server.Transfer method is used, this logic will be bypassed (assuming that the page requested is hosted on the server). As the “ReturnUrl” parameter is user controllable, this function makes it possible to load any page on the server, including admin pages that lower privileged users should not be authorized to view. It is also possible to download DLLs from the /bin directory if the name of the dll is known (the dll can then be decompiled for further analysis). However, IIS does prevent the web.config file from being viewed.

If the Response.Redirect method was used in the code sample above, the browser would issue a new request for the page passed in the ReturnUrl parameter; because this would be a new request it would pass through the permissions checks again and the authorization bypass vulnerability would be prevented.

The Server.Transfer method of course can be used in valid circumstances such as to redirect to a page where the destination is not user-controllable (i.e. perhaps using an index of hardcoded ‘safe’, non-privileged destinations). Developers should take into account the differences between the Server.Transfer and Response.Redirect methods and understand that the Server.Transfer method is NOT always a secure replacement for the Response.Redirect method.