Coder Social home page Coder Social logo

ullaakut / cameradar Goto Github PK

View Code? Open in Web Editor NEW
3.9K 141.0 501.0 36.35 MB

Cameradar hacks its way into RTSP videosurveillance cameras

License: MIT License

Go 98.67% Dockerfile 1.33%
penetration-testing security hacking infosec rtsp cctv cameras hacking-tool pentesting security-tools

cameradar's Introduction

Cameradar

Coverage Status

An RTSP stream access tool that comes with its library

Cameradar allows you to

  • Detect open RTSP hosts on any accessible target host
  • Detect which device model is streaming
  • Launch automated dictionary attacks to get their stream route (e.g.: /live.sdp)
  • Launch automated dictionary attacks to get the username and password of the cameras
  • Retrieve a complete and user-friendly report of the results

Table of content

Docker Image for Cameradar

Install docker on your machine, and run the following command:

docker run -t ullaakut/cameradar -t <target> <other command-line options>

See command-line options.

e.g.: docker run -t ullaakut/cameradar -t 192.168.100.0/24 will scan the ports 554, 5554 and 8554 of hosts on the 192.168.100.0/24 subnetwork and attack the discovered RTSP streams and will output debug logs.

  • YOUR_TARGET can be a subnet (e.g.: 172.16.100.0/24), an IP (e.g.: 172.16.100.10), or a range of IPs (e.g.: 172.16.100.10-20).
  • If you want to get the precise results of the nmap scan in the form of an XML file, you can add -v /your/path:/tmp/cameradar_scan.xml to the docker run command, before ullaakut/cameradar.
  • If you use the -r and -c options to specify your custom dictionaries, make sure to also use a volume to add them to the docker container. Example: docker run -t -v /path/to/dictionaries/:/tmp/ ullaakut/cameradar -r /tmp/myroutes -c /tmp/mycredentials.json -t mytarget

Installing the binary on your machine

Only use this solution if for some reason using docker is not an option for you or if you want to locally build Cameradar on your machine.

WARNING: Manually building the binary will NOT WORK for any camera that uses DIGEST AUTHENTICATION if your version of curl is over 7.64.0, which is most likely the case. For more information, see this response on the subject from the author of curl.

Dependencies

Steps to install

  1. go install github.com/Ullaakut/cameradar/v5/cmd/cameradar@latest

The cameradar binary is now in your $GOPATH/bin ready to be used. See command line options here.

Configuration

The RTSP port used for most cameras is 554, so you should probably specify 554 as one of the ports you scan. Not specifying any ports to the cameradar application will scan the 554, 5554 and 8554 ports.

docker run -t --net=host ullaakut/cameradar -p "18554,19000-19010" -t localhost will scan the ports 18554, and the range of ports between 19000 and 19010 on localhost.

You can use your own files for the credentials and routes dictionaries used to attack the cameras, but the Cameradar repository already gives you a good base that works with most cameras, in the /dictionaries folder.

docker run -t -v /my/folder/with/dictionaries:/tmp/dictionaries \
           ullaakut/cameradar \
           -r "/tmp/dictionaries/my_routes" \
           -c "/tmp/dictionaries/my_credentials.json" \
           -t 172.19.124.0/24

This will put the contents of your folder containing dictionaries in the docker image and will use it for the dictionary attack instead of the default dictionaries provided in the cameradar repo.

Check camera access

If you have VLC Media Player, you should be able to use the GUI or the command-line to connect to the RTSP stream using this format: rtsp://username:password@address:port/route

Command-line options

  • "-t, --targets": Set target. Required. Target can be a file (see instructions on how to format the file), an IP, an IP range, a subnetwork, or a combination of those. Example: --targets="192.168.1.72,192.168.1.74"
  • "-p, --ports": (Default: 554,5554,8554) Set custom ports.
  • "-s, --scan-speed": (Default: 4) Set custom nmap discovery presets to improve speed or accuracy. It's recommended to lower it if you are attempting to scan an unstable and slow network, or to increase it if on a very performant and reliable network. You might also want to keep it low to keep your discovery stealthy. See this for more info on the nmap timing templates.
  • "-I, --attack-interval": (Default: 0ms) Set custom interval after which an attack attempt without an answer should give up. It's recommended to increase it when attempting to scan unstable and slow networks or to decrease it on fast and reliable networks.
  • "-T, --timeout": (Default: 2000ms) Set custom timeout value after which an attack attempt without an answer should give up. It's recommended to increase it when attempting to scan unstable and slow networks or to decrease it on fast and reliable networks.
  • "-r, --custom-routes": (Default: <CAMERADAR_GOPATH>/dictionaries/routes) Set custom dictionary path for routes
  • "-c, --custom-credentials": (Default: <CAMERADAR_GOPATH>/dictionaries/credentials.json) Set custom dictionary path for credentials
  • "-o, --nmap-output": (Default: /tmp/cameradar_scan.xml) Set custom nmap output path
  • "-d, --debug": Enable debug logs
  • "-v, --verbose": Enable verbose curl logs (not recommended for most use)
  • "-h": Display the usage information

Format input file

The file can contain IPs, hostnames, IP ranges and subnetwork, separated by newlines. Example:

0.0.0.0
localhost
192.17.0.0/16
192.168.1.140-255
192.168.2-3.0-255

Environment Variables

CAMERADAR_TARGET

This variable is mandatory and specifies the target that cameradar should scan and attempt to access RTSP streams on.

Examples:

  • 172.16.100.0/24
  • 192.168.1.1
  • localhost
  • 192.168.1.140-255
  • 192.168.2-3.0-255

CAMERADAR_PORTS

This variable is optional and allows you to specify the ports on which to run the scans.

Default value: 554,5554,8554

It is recommended not to change these except if you are certain that cameras have been configured to stream RTSP over a different port. 99.9% of cameras are streaming on these ports.

CAMERADAR_NMAP_OUTPUT_FILE

This variable is optional and allows you to specify on which file nmap will write its output.

Default value: /tmp/cameradar_scan.xml

This can be useful only if you want to read the files yourself, if you don't want it to write in your /tmp folder, or if you want to use only the RunNmap function in cameradar, and do its parsing manually.

CAMERADAR_CUSTOM_ROUTES, CAMERADAR_CUSTOM_CREDENTIALS

These variables are optional, allowing to replace the default dictionaries with custom ones, for the dictionary attack.

Default values: <CAMERADAR_GOPATH>/dictionaries/routes and <CAMERADAR_GOPATH>/dictionaries/credentials.json

CAMERADAR_SCAN_SPEED

This optional variable allows you to set custom nmap discovery presets to improve speed or accuracy. It's recommended to lower it if you are attempting to scan an unstable and slow network, or to increase it if on a fast and reliable network. See this for more info on the nmap timing templates.

Default value: 4

CAMERADAR_ATTACK_INTERVAL

This optional variable allows you to set custom interval to wait between each attack in order to stay stealthy. It's recommended to increase it when attempting to scan a network that might be protected against bruteforce attacks. By default, there is no interval, in order to make attacks as fast as possible

Default value: 0ms

CAMERADAR_TIMEOUT

This optional variable allows you to set custom timeout value after which an attack attempt without an answer should give up. It's recommended to increase it when attempting to scan unstable and slow networks or to decrease it on fast and reliable networks.

Default value: 2000ms

CAMERADAR_LOGGING

This optional variable allows you to enable a more verbose output to have more information about what is going on.

It will output nmap results, cURL requests, etc.

Default: false

Contribution

Build

Docker build

To build the docker image, simply run docker build . -t cameradar in the root of the project.

Your image will be called cameradar and NOT ullaakut/cameradar.

Go build

  1. go get github.com/Ullaakut/cameradar
  2. cd $GOPATH/src/github.com/Ullaakut/cameradar
  3. cd cmd/cameradar
  4. go install

The cameradar binary is now in $GOPATH/bin/cameradar.

Frequently Asked Questions

Cameradar does not detect any camera!

That means that either your cameras are not streaming in RTSP or that they are not on the target you are scanning. In most cases, CCTV cameras will be on a private subnetwork, isolated from the internet. Use the -t option to specify your target. If you are sure you did everything right but it still does not work, please open an issue with details on the device you are trying to access ๐Ÿ™

Cameradar detects my cameras, but does not manage to access them at all!

Maybe your cameras have been configured, and the credentials / URL have been changed. Cameradar only guesses using default constructor values if a custom dictionary is not provided. You can use your own dictionaries in which you just have to add your credentials and RTSP routes. To do that, see how the configuration works. Also, maybe your camera's credentials are not yet known, in which case if you find them it would be very nice to add them to the Cameradar dictionaries to help other people in the future.

What happened to the C++ version?

You can still find it under the 1.1.4 tag on this repo, however it was slower and less stable than the current version written in Golang. It is not recommended using it.

How to use the Cameradar library for my own project?

See the example in /cmd/cameradar. You just need to run go get github.com/Ullaakut/cameradar and to use the cameradar package in your code. You can find the documentation on godoc.

I want to scan my own localhost for some reason, and it does not work! What's going on?

Use the --net=host flag when launching the cameradar image, or use the binary by running go run cameradar/cameradar.go or installing it.

I don't see a colored output:(

You forgot the -t flag before ullaakut/cameradar in your command-line. This tells docker to allocate a pseudo-tty for cameradar, which makes it able to use colors.

I don't have a camera, but I'd like to try Cameradar!

Simply run docker run -p 8554:8554 -e RTSP_USERNAME=admin -e RTSP_PASSWORD=12345 -e RTSP_PORT=8554 ullaakut/rtspatt and then run cameradar, and it should guess that the username is admin and that the password is 12345. You can try this with any default constructor credentials (they can be found here).

What authentication types does Cameradar support?

Cameradar supports both basic and digest authentication.

Examples

Running cameradar on your own machine to scan for default ports

docker run --net=host -t ullaakut/cameradar -t localhost

Running cameradar with an input file, logs enabled on port 8554

docker run -v /tmp:/tmp --net=host -t ullaakut/cameradar -t /tmp/test.txt -p 8554

Running cameradar on a subnetwork with custom dictionaries, on ports 554, 5554 and 8554

docker run -v /tmp:/tmp --net=host -t ullaakut/cameradar -t 192.168.0.0/24 --custom-credentials="/tmp/dictionaries/credentials.json" --custom-routes="/tmp/dictionaries/routes" -p 554,5554,8554

License

Copyright 2023 Ullaakut

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

cameradar's People

Contributors

arturformella avatar gaelollivier avatar ishanjain28 avatar jeremyletang avatar jirfag avatar justbuchanan avatar randomrobbiebf avatar sliicy avatar supremepot avatar testwill avatar ullaakut avatar voroninmichael avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cameradar's Issues

Update functional tests

The tests are not working anymore because the architecture of the project changed and they have not been updated since.

Refacto the tester's code

The go code in it was a quick copy paste of another tool that was not very clean in the first place, and it was my first use of Golang ever, which is one of the reasons why it's so unclean at the moment. It would very much need to be done in a more elegant way.

I will do a few changes right now but I don't have the time to change all of it for now.

  • Total refacto
  • Separate service and service config
  • Remove duplicate database configuration
  • Add newlines in some part of the code to make it clearer
  • Remove error checks on the same lines as error definitions
  • Fix comments
  • Add comments to struct variables where it's needed

Make output file more human-readable

Right now the format outputed looks like :

[
{
   "address" : "172.17.0.4",
   "ids_found" : true,
   "password" : "root",
   "path_found" : true,
   "port" : 8554,
   "product" : "GStreamer rtspd",
   "protocol" : "tcp",
   "route" : "/live.sdp",
   "service_name" : "rtsp",
   "state" : "open",
   "thumbnail_path" : "/tmp/172.17.0.4/1479896397.jpg",
   "username" : "root"
}
,{
   "address" : "172.17.0.5",
   "ids_found" : true,
   "password" : "ubnt",
   "path_found" : true,
   "port" : 8554,
   "product" : "GStreamer rtspd",
   "protocol" : "tcp",
   "route" : "/cam",
   "service_name" : "rtsp",
   "state" : "open",
   "thumbnail_path" : "/tmp/172.17.0.5/1479896397.jpg",
   "username" : "Admin"
}
,{
   "address" : "172.17.0.6",
   "ids_found" : true,
   "password" : "",
   "path_found" : true,
   "port" : 8554,
   "product" : "GStreamer rtspd",
   "protocol" : "tcp",
   "route" : "/live_mpeg4.sdp",
   "service_name" : "rtsp",
   "state" : "open",
   "thumbnail_path" : "/tmp/172.17.0.6/1479896397.jpg",
   "username" : ""
}
,{
   "address" : "172.17.0.7",
   "ids_found" : true,
   "password" : "ubnt",
   "path_found" : true,
   "port" : 8554,
   "product" : "GStreamer rtspd",
   "protocol" : "tcp",
   "route" : "/cam",
   "service_name" : "rtsp",
   "state" : "open",
   "thumbnail_path" : "/tmp/172.17.0.7/1479896397.jpg",
   "username" : "Admin"
}

]

And it would be better to make it be

[
{
   "address" : "172.17.0.4",
   "ids_found" : true,
   "password" : "root",
   "path_found" : true,
   "port" : 8554,
   "product" : "GStreamer rtspd",
   "protocol" : "tcp",
   "route" : "/live.sdp",
   "service_name" : "rtsp",
   "state" : "open",
   "thumbnail_path" : "/tmp/172.17.0.4/1479896397.jpg",
   "username" : "root"
},
{
   "address" : "172.17.0.5",
   "ids_found" : true,
   "password" : "ubnt",
   "path_found" : true,
   "port" : 8554,
   "product" : "GStreamer rtspd",
   "protocol" : "tcp",
   "route" : "/cam",
   "service_name" : "rtsp",
   "state" : "open",
   "thumbnail_path" : "/tmp/172.17.0.5/1479896397.jpg",
   "username" : "Admin"
},
{
   "address" : "172.17.0.6",
   "ids_found" : true,
   "password" : "",
   "path_found" : true,
   "port" : 8554,
   "product" : "GStreamer rtspd",
   "protocol" : "tcp",
   "route" : "/live_mpeg4.sdp",
   "service_name" : "rtsp",
   "state" : "open",
   "thumbnail_path" : "/tmp/172.17.0.6/1479896397.jpg",
   "username" : ""
},
{
   "address" : "172.17.0.7",
   "ids_found" : true,
   "password" : "ubnt",
   "path_found" : true,
   "port" : 8554,
   "product" : "GStreamer rtspd",
   "protocol" : "tcp",
   "route" : "/cam",
   "service_name" : "rtsp",
   "state" : "open",
   "thumbnail_path" : "/tmp/172.17.0.7/1479896397.jpg",
   "username" : "Admin"
}
]
  • Remove useless space at the end
  • Change position of the commas

Add new RTSP URLs and add contribution doc

Three new URLs will be added to the base dictionary

  • /rtsp_live0
  • /rtsp_live1
  • /rtsp_live2

And I need to add some contribution documentation to list contributors and give guidelines for those who want to help.

Cameraccess prototype

When the Cameradar library is ready, in order to keep a simple standalone application, it is important to maintain the functions of Cameradar 1.1.4 through the Cameraccess binary.

The first step will be to have a prototype, able to use the Cameradar library to discover cameras and dictionary attack them. No need to generate thumbnails or check if they are valid for GStreamer, except if it's requested by our users.

The call to the binary should be identical to the way Cameradar 1.1.4 was called :

$> cameraccess [-c /path/to/conf] [-l log_level] [-s subnets] [-p ports] [-m max_threads] [-v] [-h]

Upon success, the Cameraccess prototype should output its results in a JSON file (See #54 for the output file name).

  • Command line parsing
  • Discovery
  • Dictionary attack
  • Output
  • Documentation

Bruteforce Comelit Cameras

Comelit cameras don't seem to respect the RTSP RFC.

Developing a different algorithm and adding a long option like --comelit could be a nice improvement.

Legends say that they answer with 451 Parameter Not Understood instead of 200 OK when the ids and url are the good ones, but that they also can have some random behaviour sometimes.

Rename contribution file

It's currently called CONTRIBUTION.md, and I just learned that calling it CONTRIBUTNG.md integrates it in GitHub issue / PR interface.

Functional testing is not 100% functional

Unable to deserialize result file: invalid character '{' after array element
Test OK in 185.780285s
All tests completed
--- Writing results... ---
Unable to deserialize test-results.xml file: EOF
--- Test summary ---
Results: 5/5 (100%)
Time: 185.780285s
-> JUnit XML report written: test-results.xml
--- Writing results done ---
Tests exited with code 0
<testsuites>
	<testsuite tests="5" failures="5" time="185.780285">
		<testcase message="" time="185.780285"></testcase>
		<testcase message="" time="185.780285"></testcase>
		<testcase message="" time="185.780285"></testcase>
		<testcase message="" time="185.780285"></testcase>
		<testcase message="" time="185.780285"></testcase>
	</testsuite>
</testsuites>stopping all cameras tests
stopping and removing 5 containers
Tests returned 0

There are several problems here :

  • Deserialization failure should terminate the test
  • If no tests were found, the results should not have been 5/5 (100%)
  • The testcases do not have failures as they should
  • The tester should not return success after all those problems

IP List Functionality

Being able to feed in a list of IP addresses would be potentially a useful feature, for example, for where one does a "pre-scan" of a range for the open RSTP ports using something like zmap or masscan, prior to passing to this tool.

Error installing cameradar in Kali

Hello folks,

After following the steps, and installing all the dependencies I stayed in step 6

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

root@kali:~/Programas/cameradar/build# cmake ..
-- retrieve current git revision SHA1 of cameradar
-- current cameradar git revision SHA1 is b61fe521615d64e234e892b6e739ca965b470500
-- current cameradar build version will be 20170512004743
-- Configuring deps.jsoncpp
-- Configuring deps.mysqlconnector
-- Configuring done
-- Generating done
-- Build files have been written to: /root/Programas/cameradar/build

root@kali:~/Programas/cameradar/build# make
[ 18%] Built target deps.jsoncpp
[ 20%] Performing configure step for 'deps.mysql_connector'
CMake Error at /root/Programas/cameradar/deps/mysql-connector/src/deps.mysql_connector-stamp/deps.mysql_connector-configure-.cmake:16 (message):
  Command failed: 1

   '/usr/bin/cmake' '-DBOOST_ROOT=/root/Programas/cameradar/deps/boost/src/deps.boost' '-DCMAKE_INSTALL_PREFIX=/root/Programas/cameradar/deps/mysql-connector' '-DBUILD_TYPE=Release' '-DMYSQL_CXXFLAGS=-fexceptions' '/root/Programas/cameradar/deps/mysql-connector/src/deps.mysql_connector'

  See also

    /root/Programas/cameradar/deps/mysql-connector/src/deps.mysql_connector-stamp/deps.mysql_connector-configure-*.log


deps/CMakeFiles/deps.mysql_connector.dir/build.make:106: recipe for target '../deps/mysql-connector/src/deps.mysql_connector-stamp/deps.mysql_connector-configure' failed
make[2]: *** [../deps/mysql-connector/src/deps.mysql_connector-stamp/deps.mysql_connector-configure] Error 1
CMakeFiles/Makefile2:124: recipe for target 'deps/CMakeFiles/deps.mysql_connector.dir/all' failed
make[1]: *** [deps/CMakeFiles/deps.mysql_connector.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

See the error:

root@kali:~/Programas/cameradar/deps/mysql-connector/src/deps.mysql_connector-stamp# cat deps.mysql_connector-configure-err.log 
CMake Error at FindMySQL.cmake:556 (message):
  Could not find "mysql.h" from searching "/usr/include/mysql
  /usr/local/include/mysql /opt/mysql/mysql/include
  /opt/mysql/mysql/include/mysql /usr/local/mysql/include
  /usr/local/mysql/include/mysql /MySQL/*/include /MySQL/*/include"
Call Stack (most recent call first):
  CMakeLists.txt:217 (INCLUDE)

Any ideia to fix the error?

Thanks in advance.

Add unit testing

Right now the code is not unit tested at all, and it could be very good to have more than just functional end-to-end testing.

Add progress indicator

Currently if the program takes a long time to scan / attack cameras, the user has no clue that it's not stuck somewhere. It might be good to show a kind of spinner and a temporary log explaining what the program is currently doing.

(Maybe also a time estimation)

Improve run speed

Maybe the mapping can be improved with a different nmap command, or by changing dynamically the order of the dictionary using the bruteforcing results, or maybe you even have other ideas to improve the speed!

Any improvement would be very appreciated!

Fix temporary Travis dirty patch

Here is the full story about this quick&dirty fix that I used to get Travis to test Cameradar.

First, I use cmake3.5.1 on my system and it works flawlessly. Travis uses the 2.8 by default but I managed to find a PPA giving me the 3.2.3 version. However, even though the 3.5 and the 3.2 do not have relevant differences concerning the install method, it seems that on my system CPack manages to find the external shared libraries after their installation, while Travis does not.

I really tried lots of different manipulations, I've read all the documentation concerning file and install in CMake, and I still have no clue to why they're not found. When looking for them in the system, they are properly generated and in the right place, but they are simply not added to the tarball at the end.

It results in Docker failing to create the image.

To fix this temporarily, I manually unzip the tarball, copy the shared libraries using a global expression, and zip the tarball again with the added libs. It does the trick, but the paths to the libraries is written directly in the .travis.yml file, which is disgusting.

I will keep looking for the reason of this problem later!

If you have an idea of where it could come from, you're free to look at the logs of the 30 first builds of Cameradar on Travis, here : https://travis-ci.org/EtixLabs/cameradar/builds and to answer to this issue.

Find a way to automatically bypass RTSP Proxies

Either register to the proxy's registry if it uses one (would need to have a mac address and an IP address matching the pattern set in the proxy configuration) or find exploits that could be used.

`result.json` file regression

The tester did not catch it, but here is the problematic line : Unable to deserialize result file: invalid character '{' after array element

MultiOS Compatibility

The main purpose of making Cameradar a library is to make it usable by as many people as possible. Releasing a binary under Linux is not a problem since we can use Docker, but for a library, it's very important to ensure MultiOS compatibility and to maintain it at all times.

Rename MySQL table

A result table could be confusing in a bigger database. Renaming it to cameradar_results will be more appropriate and avoid eventual confusion.

Add new RTSP routes

So far I found a few I can add :

  • /video.h264
  • /11
  • /12
  • /ch1-s1
  • /live3.sdp
  • /onvif-media/media.amp
  • /axis-media/media.amp
  • /axis-media/media.amp?videocodec=h264
  • /mpeg4/media.amp
  • /stream
  • /cam/realmonitor
  • /live
  • /video.pro2
  • /videoMain
  • /VideoInput/1/mpeg4/1
  • /VideoInput/1/h264/1
  • /video.pro3
  • /video.pro1
  • /video.mjpg
  • /h264_vga.sdp
  • /media.amp
  • /media
  • /ONVIF/MediaInput
  • /nphMpeg4/g726-640x48
  • /MediaInput/mpeg4
  • /MediaInput/h264
  • /Streaming/Channels/1
  • /ch0_0.h264
  • /rtsph2641080p
  • /live/av0
  • /cam1/onvif-h264
  • /ucast/11
  • /LowResolutionVideo
  • /1
  • /live/ch00_0
  • /medias2

I will add more to this list as I find more of them and when I think it is complete enough, I will create a PR for it.

Subnet and port CLI options

Hello,

Setting the tested subnets and ports in the configuration file might be nice when you want to repeat the same process several time, but is not ideal when you are trying around to find something incrementally.
It might be nice to have some options that would override the config file.

New static analysis warnings from Codacy

  • Useless warnings that say functions declared in .h files are never used even if they are
  • Style warnings saying that in Golang, error strings should not begin with an uppercase and not end with a dot

The C++ warnings are weird and I don't really get why they happen. I decided to ignore them, because the functions are obviously used. The Golang warnings however will be fixed in a PR very soon.

Option to specify output file

Add a -o option such as ./cameraccess -o test outputs the results in the test file instead of the standard result.json. The default value of the output should be cameradar_results.json instead of the current result.json.

CMake Error at mysql-connector

CMake Error at /home/lionsec/cameradar/deps/mysql-connector/src/deps.mysql_connector-stamp/deps.mysql_connector-configure.cmake:16 (message):
Command failed: 1

'/usr/bin/cmake' '-DBOOST_ROOT=/home/lionsec/cameradar/deps/boost/src/deps.boost' '-DCMAKE_INSTALL_PREFIX=/home/lionsec/cameradar/deps/mysql-connector' '-DBUILD_TYPE=Release' '-DMYSQL_CXXFLAGS=-fexceptions' '/home/lionsec/cameradar/deps/mysql-connector/src/deps.mysql_connector'

See also

/home/lionsec/cameradar/deps/mysql-connector/src/deps.mysql_connector-stamp/deps.mysql_connector-configure-*.log

deps/CMakeFiles/deps.mysql_connector.dir/build.make:103: recipe for target '../deps/mysql-connector/src/deps.mysql_connector-stamp/deps.mysql_connector-configure' failed
make[2]: *** [../deps/mysql-connector/src/deps.mysql_connector-stamp/deps.mysql_connector-configure] Error 1
CMakeFiles/Makefile2:112: recipe for target 'deps/CMakeFiles/deps.mysql_connector.dir/all' failed
make[1]: *** [deps/CMakeFiles/deps.mysql_connector.dir/all] Error 2
Makefile:136: recipe for target 'all' failed
make: *** [all] Error 2
KO!

any idea how to fix this

Update to use RTSPATT for testing

CES became RTSPATT. The new version is way cooler and can be used with a docker image, which would avoid the ugly binary in the repo.

Refactor Cameradar into a static library

I never did this before so the first step will be to answer those questions :

How to handle scanning in the library?

System call of nmap with the required arguments followed by the use of the https://github.com/lair-framework/go-nmap library to parse the XML result.

How to use dictionaries with the library ?

Are default dictionnaries a good idea?
We need a loadCustomDictionnary() function.

Should the thumbnail generation, the stream checking and the output file generation be part of the library ?

For now my opinion is that it should not. The library should just be in charge of discovering and accessing the streams. A simplified use I imagine would be :

import cameradar "github.com/EtixLabs/cameradar"

func main() {
  c := new(cameradar);

  c.loadCustomURLDictionary("/path/to/url/dict");
  c.loadCustomIDDictionary("/path/to/ids/dict");
  err := c.scan("192.168.100.0/24", "554")
  if err != nil {
      os.exit(1);
  }
  err = c.access()
  if err != nil {
      os.exit(1);
  }
  for stream := range c.getValidStreams() {
       fmt.Println(stream.getIP(), " accessible at URL ", stream.getURL())
  }
}

Which would ideally produce the following output :

192.168.100.10 accessible at URL rtsp://root:[email protected]/live.sdp:554
192.168.100.11 accessible at URL rtsp://root:[email protected]/live.sdp:554
192.168.100.12 accessible at URL rtsp://root:[email protected]/live.sdp:554
192.168.100.13 accessible at URL rtsp://root:[email protected]/live.sdp:554
192.168.100.14 accessible at URL rtsp://root:[email protected]/live.sdp:554
192.168.100.15 accessible at URL rtsp://root:[email protected]/live.sdp:554

If we need more functionalities, we would then simply use the getter methods to retrieve the URL and open it with FFMPEG to generate a thumbnail. The same goes for the stream checking and the generation of output files.

For now I think we would only need libcurl, and even better is that it can be configured to be built stripped of useless parts of the library, which would make it less than 300ko.


Here is what I consider mandatory for the 2.0.0 :

  • Configuration
  • Dictionary loading
  • Network scanning
  • RTSP discovery
  • RTSP dictionary attack
  • Multithreading

SQLite cache manager

For someone who wants a database to keep and access the data, MySQL can be overkill, which is why SQLite seems like a neat easy solution for a simple persistent cache-manager.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.