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

Web Exploit Detector - Tool To Detect Possible Infections, Malicious Code And Suspicious Files In Web Hosting Environments

The Web Exploit Detector is a Node.js application (and NPM module) used to detect possible infections, malicious code and suspicious files in web hosting environments. This application is intended to be run on web servers hosting one or more websites. Running the application will generate a list of files that are potentially infected together with a description of the infection and references to online resources relating to it.

As of version 1.1.0 the application also includes utilities to generate and compare snapshots of a directory structure, allowing users to see if any files have been modified, added or removed.

The application is hosted here on GitHub so that others can benefit from it, as well as allowing others to contribute their own detection rules.

Installation

Regular users
The simplest way to install Web Exploit Detector is as a global NPM module: -
npm install -g web_exploit_detector
If you are running Linux or another Unix-based OS you might need to run this command as root (e.g. sudo npm install -g web_exploit_detector).

Updating
The module should be updated regularly to make sure that all of the latest detection rules are present. Running the above command will always download the latest stable (tested) version. To update a version that has already been installed, simply run the following: -
npm update -g web_exploit_detector
Again, you may have to use the sudo command as above.

Technical users
You can also clone the Git repository and run the script directly like so: -

1. git clone https://github.com/polaris64/web_exploit_detector
2. cd web_exploit_detector
3. npm install

Running

From NPM module
If you have installed Web Exploit Detector as an NPM module (see above) then running the scanner is as simple as running the following command, passing in the path to your webroot (location of your website files): -
wed-scanner --webroot=/var/www/html
Other command-line options are available, simply run wed-scanner --help to see a help message describing them.
Running the script in this way will produce human-readable output to the console. This is very useful when running the script with cron for example as the output can be sent as an e-mail whenever the script runs.
The script also supports the writing of results to a more computer-friendly JSON format for later processing. To enable this output, see the --output command line argument.

From cloned Git repository
Simply call the script via node and pass the path to your webroot as follows: -
node index.js --webroot=/var/www/html

Recursive directory snapshots
The Web Exploit Detector also comes with two utilities to help to identify files that might have changed unexpectedly. A successful attack on a site usually involves deleting files, adding new files or changing existing files in some way.

Snapshots
A snapshot (as used by these utilities) is a JSON file which lists all files as well as a description of their contents at the point in which the snapshot was created. If a snapshot was generated on Monday, for example, and then the site was attacked on Tuesday, then running a comparison between this snapshot and the current site files afterwards will show that one or more files were added, deleted or changed. The goal of these utilities therefore is to allow these snapshots to be created and for the comparisons to be performed when required.
The snapshot stores each file path together with a SHA-256 hash of the file contents. A hash, or digest, is a small summary of a message, which in this case is the file's contents. If the file contents change, even in a very small way, the hash will become completely different. This provides a good way of detecting any changes to file contents.

Usage
The following two utilities are also installed as part of Web Exploit Detector: -

• wed-generate-snapshot: this utility allows a snapshot to be generated for all files (recursively) in a directory specified by "--webroot". The snapshot will be saved to a file specified in the "--output" option.
• wed-compare-snapshot: once a snapshot has been generated it can be compared against the current contents of the same directory. The snapshot to check is specified using the "--snapshot" option. The base directory to check against is stored within the snapshot, but if the base directory has changed since the snapshot was generated then the --webroot option can be used.

Workflow
Snapshots can be generated as frequently as required, but as a general rule of thumb they should be generated whenever a site is in a clean (non-infected) state and whenever a legitimate change has been made. For CMS-based sites like WordPress, snapshots should be created regularly as new uploads will cause the new state to change from the stored snapshot. For sites whose files should never change, a single snapshot can be generated and then used indefinitely ensure nothing actually does change.

Usage as a module
The src/web-exploit-detector.js script is an ES6 module that exports the set of rules as rules as well as a number of functions: -

• executeTests(settings): runs the exploit checker based on the passed settings object. For usage, please consult the index.js script.
• formatResult(result): takes a single test result from the array returned from executeTests() and generates a string of results ready for output for that test.
• getFileList(path): returns an array of files from the base path using readDirRecursive().
• processRulesOnFile(file, rules): processes all rules from the array rules on a single file (string path).
• readDirRecursive(path): recursive function which returns a Promise which will be resolved with an array of all files in path and sub-directories.

The src/cli.js script is a simple command-line interface (CLI) to this module as used by the wed-scanner script, so reading this script shows one way in which this module can be used.
The project uses Babel to compile the ES6 modules in "src" to plain JavaScript modules in "lib". If you are running an older version of Node.js then modules can be require()'d from the "lib" directory instead.

Building
The package contains Babel as a dev-dependency and the "build" and "watch:build" scripts. When running the "build" script (npm run build), the ES6 modules in "./src" will be compiled and saved to "./lib", where they are included by the CLI scripts.
The "./lib" directory is included in the repository so that any user can clone the repository and run the application directly without having to install dev-dependencies and build the application.

Excluding results per rule
Sometimes rules, especially those tagged with suspicion, will identify a clean file as a potential exploit. Because of this, a system to allow files to be excluded from being checked for a rule is also included.
The wed-results-to-exceptions script takes an output file from the main detector script (see the --output option) and gives you the choice to exclude each file in turn for each specific rule. All excluded files are stored in a file called wed-exceptions.json (in the user's home directory) which is read by the main script before running the scan. If a file is listed in this file then all attached rules (by ID) will be skipped when checking this file.
For usage instructions, simply run wed-results-to-exceptions. You will need to have a valid output JSON from a previous run of the main detector first using the --output option.
For users working directly with the Git repository, run node results_to_exceptions.js in the project root directory.

Rule engine
The application operates using a collection of "rules" which are loaded when the application is run. Each rule consists of an ID, name, description, list of URLs, tags, deprecation flag and most importantly a set of tests.
Each individual test must be one of the following: -

• A regular expression: the simplest type of test, any value matching the regex will pass the test.
• A Boolean callback: the callback function must return a Boolean value indicating if the value passes the test. The callback is free to perform any synchronous operations.
• A Promise callback: the callback function must return a Promise which is resolved with a Boolean value indicating if the value passes the test. This type of callback is free to perform any asynchronous operations.

The following test types are supported: -

• "path": used to check the file path. This test must exist and should evaluate to true if the file path is considered to match the rule.
• "content": used to check the contents of a file. This test is optional and file contents will only be read and sent to rules that implement this test type. When this test is a function, the content (string) will be passed as the first argument and the file path will be passed as the second argument, allowing the test to perform additional file operations.

Expanding on the rules
As web-based exploits are constantly evolving and new exploits are being created, the set of rules need to be updated too. As I host a number of websites I am constantly observing new kinds of exploits, so I will be adding to the set of rules whenever I can. I run this tool on my own servers, so of course I want it to be as functional as possible!
This brings me onto the reasons why I have made this application available as an open-source project: firstly so that you and others can benefit from it and secondly so that we can all collaborate to contribute detection rules so that the application is always up to date.

Contributing rules
If you have discovered an exploit that is not detected by this tool then please either contact me to let me know or even better, write your own rule and add it to the third-party rule-set (rules/third-party/index.js), then send me a pull request.
Don't worry if you don't know how to write your own rules; the most important thing is that the rule gets added, so feel free to send me as much information as you can about the exploit and I will try to create my own rule for it.
Rules are categorised, but the simplest way to add your own rule is to add it to the third-party rule-set mentioned above. Rule IDs are written in the following format: "author:type:sub-type(s):rule-id". For example, one of my own rules is "P64:php:cms:wordpress:wso_webshell". "P64" is me (the author), "php:cms:wordpress" is the grouping (a PHP-specific rule, for the Content Management System (CMS) called WordPress) and "wso_webshell" is the specific rule ID. When writing your own rules, try to follow this format, and replace "P64" with your own GitHub username or other unique ID.

Unit tests and linting
The project contains a set of Jasmine tests which can be run using npm test. It also contains an ESLint configuration, and ESLint can be run using npm run lint.
When developing, tests can also be run whenever a source file changes by running npm run watch:test. To run tests and ESLint, the npm run watch:all script can be used.
Please note that unless you already have Jasmine and/or nodemon installed, you should run npm install in non-production mode to ensure that the dev-dependencies are installed.

Download Web Exploit Detector

Read More

Beeswarm - Active IDS made easy

Beeswarm is an active IDS project that provides easy configuration, deployment and management of honeypots and clients. The system operates by luring the hacker into the honeypots by setting up a deception infrastructure where deployed drones communicate with honeypots and intentionally leak credentials while doing so. The project has been release in a beta version, a stable version is expected within three months.

Installing and starting the server

On the VM to be set up as the server, perform the following steps. Make sure to write down the administrative password.

$ sudo apt-get install libffi-dev build-essential python-dev python-pip libssl-dev libxml2-dev libxslt1-dev
$ pip install pydes --allow-external pydes --allow-unverified pydes
$ pip install beeswarm
Downloading/unpacking beeswarm
...
Successfully installed Beeswarm
Cleaning up...
$ mkdir server_workdir
$ cd server-workdir/
$ beeswarm --server
...
****************************************************************************
Default password for the admin account is: uqbrlsabeqpbwy
****************************************************************************
...

Download Beeswarm

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

[Topera] The IPv6 port scanner invisible to Snort (IDS)

Topera is a brand new TCP port scanner under IPv6, with the particularity that these scans are not detected by Snort.

Snort is the most known IDS/IPS and is widely used in many different critical environments. Some commercial tools (Juniper or Checkpoint ones) use it as detection engine also.

Mocking snort detection capabilities could suppose a high risk in some cases.

All the community is invited to test it in any environment and we would be thankful if you send us any feedback.

We keep researching on the security implications that the "new" IPv6 protocol will have in different environments. 

You can see an example of execution of Topera here: 
Download Topera

Read More