How To Write An RTSP URL Honeypot...

Here's a few lines of code you can use to capture the URL's that various discovery tools use when trying to figure out what camera(s) are on the network. This can be helpful when troubleshooting, or when trying to figure out a cameras RTSP URL.

Also, if one is writing client software, this can give you a headstart on URLS that other programs are already using.

This assumes you have a linux box or virtual machine, but there are versions of netcat available for windows, so its easily adapted.

create a file called url.sh:

#!/bin/sh
read url
echo $url >> urls
echo RTSP/1.0 404 Not Found

Then run netcat like so:

nc -ll -p 554 -e url.sh

Then just tell your discovery tool that a camera exists at that IP and let it go to work. After a few minutes, kill it and get the honey in the urls file.

Here's what I got using AnyCam's discovery process:

OPTIONS rtsp://192.168.200.1:554 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554//Streaming/Channels/1 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554//Streaming/Channels/2 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/live RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/cam/realmonitor?channel=1&subtype=1 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/h264 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/cam1/h264 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/video.h264 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/live.sdp RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/mpeg4 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/play1.sdp RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/HighResolutionVideo RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/image.mpg RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/rtsph2641080p RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/h264/ch1/sub/ RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/mpeg4unicast RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/onvif/profile1/media.smp RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/MediaInput/h264 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/profile1/media.smp RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/h264unicast RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/H264/media.smp RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/mpeg4/media.amp RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/axis-media/media.amp RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/onvif-media/media.amp RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/axis-media/media.amp RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/mpeg4 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/mpeg4/media.amp RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/axis-media/media.amp RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/live1.sdp RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/PSIA/Streaming/channels/1 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/ch01.264 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/1/stream1 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/ucast/11 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/stream.sdp1 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/1 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/live1.264 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/live0.264 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/?channel=1&stream=0.sdp RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/av0_0 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/av0_1 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/live/h264 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/live/ch00_0 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/video RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/rtsp_tunnel RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/cgi-bin/rtspStream/1 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/live3.sdp RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/11 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/12 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/VideoInput/1/h264/1 RTSP/1.0
OPTIONS rtsp://192.168.200.1:554/live.sdp RTSP/1.0

Next up, Milestone?


Nice work!

btw, why did you choose AnyCam? Anything particularly good or different about them?

I saw Anycam when looking up Angelcam. It seemed pretty confident that it could detect Any cam, but when it couldn't, I did the usual tedious Wireshark capture and filter thing.

Then I realized that you could trick these discovers into giving you their entire URL database just by acting dumb.

Cool, although not a "Honeypot" in the true IT Security sense of the word.

Not til you open up your firewall on 554, and wait...

This looks very interesting, but not understanding the nuts and bolts of it. Can you break this down in more simple laymen's terms?

First the script/Anycam combo would help you do what exactly? In a real world environment, when would this come in handy?

Second, there's about 50 or so replies from the same IP address, what are they all? Are they all separate streams over port 554?

"Second, there's about 50 or so replies from the same IP address, what are they all?"

I am guessing those are different attempts sent to the IP address, trying to see if any responds. Brute force connectivity approach. 1, what do you say?

I am guessing those are different attempts sent to the IP address, trying to see if any responds. Brute force connectivity approach.

That's correct. Though of course AnyCam is the Brute here, as it tries to live up to its name.

btw, I also did this to angelcam, (sorry Peter), by opening up my firewall first. Their results were 2 or 3 times longer. Interestingly, with angelcam since you choose a manufacturer first you might think the results would be different depending on whether you choose Dahua or Hik, but they are not. They are just in different orders, presumably they are in the order of most likely to least.

First the script/Anycam combo would help you do what exactly? In a real world environment, when would this come in handy?

For most people, it wouldn't come in handy. For someone developing client connectivity software though it could really give you a jumpstart. Consider the alternative of looking thru manuals and various online databases, for urls and default creds each model.

Wouldnt it be great just to start with what Milestone has already honed for years? And then continually update your database with the newest additions to theirs?

Second, there's about 50 or so replies from the same IP address, what are they all?

The IP is the one from our imposter camera, which is just the script running on our PC listening on port 554.

Are they all separate streams over port 554?

The are all seperate stream requests from Anycam. They never become actual streams because the device we have setup to act like a camera is just a PC. Instead it rebuffs every request by saying "I don't have a stream named X.", which causes Anycam to exhaust all of its known urls in an attempt to find one that works.

as a part dev for surveillance software its a nifty little trick, but that is all it is. nothing wireshark or a sqldump of a rtsp database from ispyconnect cant give you. Not to mention most of those stream locations are ancient ( especially the onvif ones). if the rtsp streams are in a SQL database along with a model/brand then is makes it that much easier as a dev to do what you need.

also you called this a "database" but it just a list of streams that you printed to a file. you would have to guess what each stream goes with what camera. and then import that data into a database structure of some kind for it to be even usable.

nothing wireshark ... can't give you.

Disagree.

Wireshark alone gives nothing.

You would need to at least setup a 'camera', to listen on 554.

And make sure the camera will attentively listen on port 554, yet will always respond with a 404, lest your discoverer program thinks it has figured out the model and stop inqueries.

Then figure out the right Wireshark filters to pull out only the relevant RTSP tags and write a nice db-loadable report of just the parts you want.

Tell me how long that takes.

nothing ispyconnect ... can't give you.

Disagree.

i love ispyconnect, don't get me wrong. But it is an absolute mess of duplication and riddled with user tagging errors. But, the real thing missing in ispyconnect is the ordering of most likely to least likely, as I'm sure your familiar with. A well written discoverer plays the odds, and will go for the URL's most likely at first. Which if you are trying to save time discovering 50 unknown cameras is important.

In addition, don't you think that Milestone likely has better URL info than ispyconnect, after all the integrations?

Why wouldn't you want a simple, non-duplicative list of URLS, by manufacturer that Milestone uses?

I used Anycam because it is a simple example to demonstrate the general idea.

But the real value of the script is that apparently some of the better discovers adjust the URLS that they try based on the OUI of the device.

So get 50 cameras of every different brand and get out your Wireshark. Or just input a list of OUI's to a script.

"some of the better discovers adjust the URLS that they try based on the OUI of the device."

Or refuse to connect to some OUIs....

For most people, it wouldn't come in handy. For someone developing client connectivity software though it could really give you a jumpstart. Consider the alternative of looking thru manuals and various online databases, for urls and default creds each model.

Then figure out the right Wireshark filters to pull out only the relevant RTSP tags and write a nice db-loadable report of just the parts you want.

Tell me how long that takes.

As a dev in this field not knowing how to use wireshark would just make you a contracted code monkey in a 3rd world country that gets told to code a specific peice a code for a specific function in a specific language after all the hard work(planning and thinking) has been done. also what you have done is a low grade Wireshark on a specific port which you would have had to have known what and how rtsp is and how it works to know what you are looking for. I am afraid it would only take about 10 mins on google to find that looking to listen for a port and filter those results as that filter method is wireshark 101. But hey everyone has a "tool" they prefer so if you find what you did is easiesr than wireshark thats fine.

nothing ispyconnect ... can't give you.

Disagree.

i love ispyconnect, don't get me wrong. But it is an absolute mess of duplication and riddled with user tagging errors. But, the real thing missing in ispyconnect is the ordering of most likely to least likely, as I'm sure your familiar with. A well written discoverer plays the odds, and will go for the URL's most likely at first. Which if you are trying to save time discovering 50 unknown cameras is important.

I am going to assume you didnt understand or I didnt explain well enough what I meant by a SQLdump instead of taking what I said out of context. A SQLdump is a copy of the SQL database on a machine. Milestone, ispyconnect, ONSSI, Exacq,etc all use a SQL databse to store their data including what they pull for RTSP URL's. If you were to copy those and import those into another database you would have far more data and be able to easily, from a Dev's position, use that data for developing an app quicker and more reliable than anything a few printed urls in a file that you would have spend time importing into another database. not to mention that none of the URL's have stream/channel identfiers which would be in the database under a differnent database name within SQL after it did a discovery search.

most discovery tools that I have dealt with that are proprietary to their respective brands actually use SNMP. so for example Panasonic has a IP utility to search just for Panasonic cameras with a private MIB to find the model, IP, etc and so on. then after it finds its cameras it uses that infomation to go further such as rtsp streams locations, resoultions, SD card locations, etc, etc. all of the other major brands have something simliar and the major VMS companys would use that beofore trying to find rtsp stream locations as that would be faster and more reliable than "guessing" what rtsp streams are out there on the network broad casting.

As I said before its a neat trick (not being sarcastic) but there are far better ways for Dev to get and use data than the way you are using. most of us just borrow form the dev pages or other programs as its easier that way.

Milestone ... use a SQL databse to store their data including what they pull for RTSP URL's.

Show me the query for Milestone.

Great post! At my ( low :) skill level, I totally got your idea and thought, "What a cool technique that even I could implement!" Unfortunately, I'm not a dev in the field, and I imagined that SQLdump might be something that happens in a water closet, so, absent a more descriptive approach, all that went over my head. For example, even after I thought I knew quite a bit about maintaing a local network, I discovered arp right here on IPVM.

I'd imagine that IPVM members represent a wide range of skill levels and experience (for example, see "can-you-code"). Although there might be some who don't see a benefit, please keep the ideas and approaches coming, because they stimulate good discussions and are sure to be of interest to at least a subset of IPVM members.