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.

Accepting Un-Trusted Certificates using the iOS Simulator

There are scenarios where an iOS developer might want to accept an un-trusted SSL certificate, such as when they are testing their application using the iOS simulator. By default applications using the NSUrlConnection API for performing remote connections contains built-in certificate validation. Therefore, developers or testers may encounter issues when testing HTTPS traffic using the iOS simulator. Some example scenarios may include applications communicating with remote services hosted on a non-production environment using self-signed certificates or the testers who need to debug SSL communication between the application and service using a local proxy tool, such as Burp Proxy or Fiddler. From a developer’s perspective, what is the best way to accept SSL certificates? While performing a Google search, I encountered the following thread on Stack Overflow discussing ways to accept self-signed certificates when using NSUrlConnection to connect to a website. In general, the responses all recommended performing code level changes in order to disable the built in certificate validation performed by iOS. Although, some answers recommend disabling certificate validation against certain hosts, there are also recommendations for disabling validation against all hosts. Given the temptation to copy and paste, this guidance is likely to result in insecure iOS application releases to the Apple App Store as the applications will be susceptible to man in the middle attacks.

Is there a better way to temporarily trust un-trusted certificates within the Simulator? In my opinion, the more secure way is to add the Certificate Authority(CA) certificate which signed the website’s certificate as a Trusted CA on the simulator. On an iOS device, this can be performed easily by opening the CA certificate on the device by emailing the certificate; however this is not possible with the simulator. Behind the scenes, when a CA certificate is added as a Trusted CA on the device, the certificate is inserted into the tsettings table of the TrustStore.sqlite3 database. This database is also used by the Simulator and can be found in the ~/Library/Application Support/iPhone Simulator/<SDK version>/Library/Keychains/ directory on your Mac workstation.

The tsettings table stores the contents of the CA certificate (Fingerprint, Subject, etc) but the only field needed by iOS during validation is the sha1 column which refers to the certificate's SHA1 fingerprint. The table can be manually modified by using one of the many available SQLite clients. In order to simplify this process, I wrote a simple python script which can be used to import CA certificates into each TrustStore database  used by the Simulator. The following example will walkthrough the steps for importing the Portswigger CA certificate. Importing this certificate will provide testers with the ability to intercept application HTTPS traffic using Burp Proxy. Although we can view and intercept SSL HTTP traffic while testing applications, the insecurity of accepting un-trusted certificates is no longer built into the application logic

Step 1: Modify the System Preferences/Network Proxy settings on your Mac in order to have all HTTP/HTTPS traffic be sent to your Burp Proxy.

Step 2: Visit an HTTPS website using Firefox. You will be shown a “This Connection is Untrusted” error page. Choose the Add Exception option and then click the View button. Enter the Details tab and you will be shown information about the certificate chain. Select the PortSwigger CA within the “Certificate Hierarchy” listing. Export the Certificate to the directory of your choice.

Step 3: Run the add_ca_to_iossim script and pass in the exported certificate as an argument. 

Sample Usage: 

python add_ca_to_iossim.py PortSwiggerCA.cer

Successfully added CA to /User/GDS/Library/Application Support/iPhone Simulator/4.3/Library/Keychains/TrustStore.sqlite3

Successfully added CA to /User/GDS/Library/Application Support/iPhone Simulator/4.3.2/Library/Keychains/TrustStore.sqlite3

Run the simulator while proxying through Burp Proxy and you should be able to intercept HTTPS application sent by your application.

The add_ca_to_iossim python script can be download within the GDS Github page.

Beyond Padding Oracle - Manger's Oracle and RSA OAEP Padding

Several months ago I was looking at the proceedings from #days 2010 and read Pascal Junod's slides Open-Source Cryptographic Libraries and Embedded Platforms. In them, he mentioned James Manger's attack on RSA OAEP, a padding scheme first defined in PKCS #1 v2.0. I hadn't heard of it before, and it interested me enough to investigate. (The paper is available via Google or ACM if you're a member.)

The basics of the attack are similar to the Padding Oracle attack in that a small piece of information is exposed via error messages and doing some clever math you can use that to retrieve the plaintext from the ciphertext. After the ciphertext is decrypted, the OAEP decoding process begins. The decrypted plaintext is supposed to fit in one less byte than the maximum size of the ciphertext. If the plaintext does not have a 00 in the highest byte, the ciphertext is considered to have been tampered with and an error is returned. Because of the properties of RSA, you can directly influence the plaintext p by multiplying the ciphertext c by x^e mod n - where e is the exponent from the public key, n the modulus, and x the arbitrary number you want to multiply the plaintext by. This will produce a plaintext p*x mod n after decryption.

Manger's Oracle relies on manipulating the plaintext and detecting when it has overflowed into the highest byte. Using a method reminiscent of binary search, the possible values of the plaintext are narrowed down until only one remains - allowing recovery of the plaintext from the ciphertext. The number of oracle queries needed depends on keysize; for 1024, it's around 1200.

I checked the popular implementations of RSA-OAEP and found none of them vulnerable to Manger's Oracle. OpenSSL specifically protects against it, calling Manger out by name in the comments. BouncyCastle and the .NET implementation were secure because they didn't throw an error if the first byte was non-zero (probably on the assumption that another part of OAEP, the hash, wouldn't match). Libgcrypt didn't implement RSA-OAEP - a patch had been provided a few years ago, but it was never merged... until a few weeks ago when it was committed to trunk.

The new code wasn't actually directly vulnerable - the same error code was returned no matter the type of error that occurred. Regardless, I decided this would be a fun exercise and set about implementing the attack. I got it working; but only after editing the source of libgcrypt to 'cheat', providing my own oracle. I managed to find a mistake in the original paper too, a floor() that should have been a ceil() - detailed in the code linked later.

Since I modified the libgcrypt code to provide an oracle, it was an overly contrived example, but it seemed like it might be possible to exploit it using a timing attack. After measuring and graphing the differences between the two cases, I saw you could determine the error from timing information - so long as you looked at the percentiles over a sufficient number of trials, as shown below. It isn't 100% reliable, but I was able to get a working proof of concept going with just timing information.


Left two box plots show the longer execution time, right two show the shorter.

I've published the code to exploit the oracle in a contrived case, and included the code and steps to demonstrate the timing differential. The code is on github, and as far as I know, this is the only public implementation of Manger's Oracle. (Although apparently it is assigned as homework somewhere...)

"OAEP Padding" is indeed an example of RAS Syndrome

Regional Broadcast Using an Atmospheric Link Layer

I'm happy to announce my latest endeavor, published today by the IETF: RFC 6217: Regional Broadcast Using an Atmospheric Link Layer. It provides recommendations for broadcasting text or binary data to a geographic region, in an efficient manner that does not impede existing network infrastructure. It also defines a new protocol, Asynchronous Dumb Visual Exchange of Raw Transmissions, for the Network Layer, designed to be both extremely compact but also flexible enough for use in different communities and for different uses.

The RFC does raise, and attempt to address, certain security concerns. If organizations feel this protocol may be beneficial to them but are concerned about testing their infrastructures prior to deployment, Gotham Digital Science is poised to offer the best advice and services relating to this cutting-edge technology.

Hackers Puzzle Challenge in the CSAW 2010 CTF Final Round

A few weeks ago NYU Polytechnic held the final round of their Capture the Flag. Marcin previously wrote about his challenge for the qualification round. We both wrote challenges for the final round, and my challenge was primarily based around steganographic tricks with file formats, surrounded by some simple cryptography.

Introduction

The first things you received were a bat script and a multi-part file, without an extension. The bat file copied the second file twice and appended .jpg and .zip extensions as hints. It's a fairly well known secret that you can combine jpg and zip files into a single file, and it's 'valid' as both - but 'valid' is in quotes for a reason. You actually need to do a bunch of byte manipulation to get this into a legal format - you can read about how it works over in my stackoverflow answer here.

The jpg-part of the multi-part file was a reference to the movie Hackers, after which the challenge was themed. Within the zipfile-part was an executable which when run would look for the multi-part file and then display a prompt:

Entering Hackers-themed words would get you images, an mp3 snippet, hints, and even the hacker's manifesto:

Exploring the Code

But none of these were the key of course. .Net is trivial to disassemble, and I was counting on that. The code in the program seeks past the jpg-part of the multi-part file, and then reads blocks of data from the middle - stopping when it reaches the zip-part of the file. (So the file had three parts: jpg, zip, and in-between: an arbitrary binary format). The password entered is hashed, and used to key a dictionary. The value of the dictionary is used to attempt decryption of each block of data read from the middle of the file. When it succeeds it will - depending on a sentinel byte - show an image, text, play a song, or write out a file. Now because you can disassemble the program - you can see all the dictionary values, and therefore you can decrypt the blocks of data without ever needing to know the password.

But that would be too easy - so not all the encryption keys are in the dictionary. If your hashed password is not found in the dictionary, it is used itself. The encryption algorithm chosen was XTEA, and the key itself was neutered down to 27 bits. The encrypted blocks were easily brute-forced. (And XTEA is a very simple algorithm to implement).

After you brute-forced all the blocks and matched up their corresponding filetypes from the code, you were left with a slew of images, an mp3, several textfiles, and two very promising files with the extensions .key.gpg and .txt.gpg. Upon examining these files with gnupg, you found that .txt.gpg was an asymmetrically encrypted file with a key you did not possess; and .key.gpg was symmetrically encrypted with a passphrase you did not know.

You discovered that in the .key.gpg file - either through verbose gnupg output, looking at it in a hex-editor, or by running strings - there were a number of userid and marker packets at the end of the file. (The OpenPGP file format is a collection of different types of packets.) These extra packets contained the string "dot", "dash", or "PGP". Dot and dash were morse code, and PGP was the letter-delimiter, and it decoded to the word 'morse' - which was the passphrase to the file.

Upon decryption, you had a .key file, which was the public and private key used to encrypt the second .txt.gpg file - but without any indicator of what the passphrase was. Again, either through gnupg options, a hex-editor, or the 'strings' utility - you found that the preferred keyserver for the key was set to a particular URL. When you visited it, you were given the passphrase, and the file decrypted to a text file containing the key for the CTF.

Aftermath

When the files were given to the teams, they also received a hint that the challenge would require brute forcing - Julian Cohen (one of the CTF organizers) and I argued back and force for a while about whether it was acceptable, and how much time it should take. I wanted the teams to only have enough time to run their program twice - while Julian felt it should be instant. He argued they didn't have much time (the competition was 5 hours for a half-dozen challenges) while I argued they should understand the code and write it correctly the first time - I didn't want the challenge to become trial and error. In the end, not only did they get a neutered keyspace (27 bits took me 5 minutes to run) but they received the challenge the night before. However, the hint given threw off at least one team - they spent a long time finding hash collisions in the first 27 bits of the MD5 output.

In the end, this was the challenge solved by the most teams. I don't know if it was because they spent more time on it than other challenges by receiving it early, because they could easily retrieve the code so the challenge was more accessible to them, or if it was just too darn easy. I'll have to start brainstorming next year's challenge... If you'd like to attempt the challenge yourself, you can download the multi-part file.

Bonus Trivia

This challenge is extremely small - the multi-part file weighs in at only 220KB, despite containing many photos and a small snippet of an mp3. While I had parts of the code from a project a year ago, the bulk of the challenge was actually written for a Hackers-Themed party in Brooklyn where I intended to distribute the challenge on 5 1/4" disks:

Unfortunately, both of my 5 1/4" drives not only didn't work, but blew out one of my motherboards. I had to resort to 3 1/2" disks. However, since only one of my friends I gave it to was even able to find a 3 1/2" drive, I decided to repurpose the challenge (adding the gpg elements, neutering the key) for the CTF. Apparently I could have handed out blank 5 1/4" disks and no one would have known the difference. As a final aside, in a fresh box of multi-colored 3 1/2" disks sitting on my shelf since the '90s, the green disks exihibited a much higher failure rate than the others: 7 dead green disks, 2 dead orange, 1 dead yellow, and 0 dead red or blue.