Hikvision like Dahua? No authentication on snapshot?

[40th Floor 0]

Give this a try on a Hikvision IP camera:

 

h ttp://1.2.3.4/onvif/snapshot

 

from any browser, or http getter, and see if you get a picture without any sort of authentication.

 

Here, I put in http://192.168.0.31/onvif/snapshot. I double-checked in wireshark to make sure no authentication info was being passed. An Axis onvif shapshot requires authentication. Dahua and Hikvision do not. If port 80 is open to the world, anyone who stumbles upon your camera(s) can sneak a peek.

[ak357 0]

Give this a try on a Hikvision IP camera:

 

h ttp://1.2.3.4/onvif/snapshot

 

from any browser, or http getter, and see if you get a picture without any sort of authentication.

 

Here, I put in http://192.168.0.31/onvif/snapshot. I double-checked in wireshark to make sure no authentication info was being passed. An Axis onvif shapshot requires authentication. Dahua and Hikvision do not. If port 80 is open to the world, anyone who stumbles upon your camera(s) can sneak a peek.

Hmm, u right

Very interesting

[RDC 0]

You're right!. I checked this on different firmwares even the newest 5.1.6 and all are the same.

 

Not just port 80 either. If you have multiple cameras, as most people do, adding the correct port also works, i.e.

 

h ttp://1.2.3.4:portno/onvif/snapshot

 

Thats bad.

[venturis 0]

Give this a try on a Hikvision IP camera:

 

h ttp://1.2.3.4/onvif/snapshot

 

from any browser, or http getter, and see if you get a picture without any sort of authentication.

 

Here, I put in http://192.168.0.31/onvif/snapshot. I double-checked in wireshark to make sure no authentication info was being passed. An Axis onvif shapshot requires authentication. Dahua and Hikvision do not. If port 80 is open to the world, anyone who stumbles upon your camera(s) can sneak a peek.

 

I don't have any idea if this is in any way related to your post but the release notes of Ver 5.1.6 firmware contains the following which makes mention of not having to input a username/password to get an MJPEG stream from the camera.

 

"Optimize MJPEG sub stream command, no need inputting username and password after input URL. URL format is “http://ip:port/Streaming/channels/1/preview?auth=xxxxxxx”. Here xxxxxxx is base64 encrypted verification."

 

Can anyone explain what that means and how to I create a base64 encrypted verification?

[buellwinkle 0]

Works remotely too using DDNS and the HTTP port. I guess I'll have to make sure no private area cameras are port forwarded. Didn't Dahua fix this is more current firmware releases?

[ak357 0]

Works remotely too using DDNS and the HTTP port. I guess I'll have to make sure no private area cameras are port forwarded. Didn't Dahua fix this is more current firmware releases?

I think they done it for reason

their camera can connect to Control4

using mjpeg

[40th Floor 0]

Can anyone explain what that means and how to I create a base64 encrypted verification?

Check wikipedia. The form of the basic authentication is:

 

username:password

 

You can probably find that at wikipedia, too. Feed that into a base-64 generator and out comes a base-64 (you can wiki base-64, too) string (wiki string?). So, if your username is joe and your password is blow,

 

c:\>b64 -e < "joe:blow" > thebase64string.txt

 

(Use whatever method the base-64 generator you find needs but that is how I would do it.)

 

This is easily reversible. Anyone that sees that "out there" will (100% positively) know your username and password. But anyway, that is an mjpeg stream, not just a snapshot. The snapshot requires digest authentication, which is not reversible. You should go that way; the idea for using digest authentication is to not expose your username or password.

 

h_ttp://1.2.3.4/streaming/channels/1/picture/

 

should require digest authentication (wiki...). If it is not (and how would you know? you would have to look at the network stream), you could see if adding the query, auth=digest does it (I don't need it here).

 

.../streaming/channels/1/picture/?auth=digest

 

 

Back to what the show-anyone-that-looks-my-password hik way, the output of the base-64 generator is what you give the auth= line, so something like

 

.../streaming/channels/1/picture/?auth=OICU8124AaSDt4349adf==

 

Anyone can take the "OICU8124AaSDt4349adf==" string and reverse the base-64 to get your username and password.

[PluffMud 0]

I noticed there were no options for authentication which is a major problem for remote viewing. I wonder if this is something they plan to add?

 

Just so I understand (please confirm):

1) Snapshots can be pulled without a username/password whatsoever right?

2) Live feeds can be accessed simply by sniffing out the unencrypted username/password.

3) Live feeds can not be accessed without a username/password

 

Granted, sniffing out passwords takes a little work and the right conditions but it's very easy to do.

[TheUberOverLord 0]

These are just a few reasons why if you are using HTTP access methods to access your IP Cameras to not access your IP Cameras directly, over unsecure Internet connections.

 

Here are some methods you can use to use php on a web server or server to ("Act as a proxy") front-end access to your IP Cameras. That can be used from any Internet browser capable devices. Without plugins or any need to install software on any device.

 

While the live examples shown below are using Foscam IP Camera models. It's very easy to implement and apply the same concepts and methods to any IP Camera brands and models that allow pulling snapshots using HTTP or HTTPS access methods.

 

At least this allows you to not expose the DDNS, IP Address, Port and any User credentials for your IP Cameras:

 

http://foscam.us/forum/showing-secure-methods-using-php-to-display-your-ip-cameras-t8721.html

 

Note: The methods shown above are not meant to be your only solution to accessing your IP Cameras. They are simply another tool for the toolbox for your IP Cameras. That can be used when and as needed. After all, do you only have one type and size of screwdriver in your toolbox of tools? Why should tools for IP Cameras be any different? Especially more so, when they are free.

 

Also. I suggest, if your IP Camera supports HTTPS access methods. I would only port forward the HTTPS port for the IP Camera and not the HTTP port for the IP Camera, for remote access.

 

That said. If someone was sniffing packets, they could still see what DDNS/IP Address and port was being accessed, even when using HTTPS access methods. In the cases mentioned here, allowing them to still be able to access your cameras snapshots and/or video feed. So the php proxy solution above, is a much more secure access method, when using unsecure Internet connections.

 

There is also, a free tool at the link above, that will allow you to easily see what information is exposed when communicating with your IP Cameras when using HTTP and HTTPS access methods. You may be or become very surprised what's normally being exposed, that could and can be sniffed by others, as you access your IP Cameras.

 

This is most certainly a case of "What you can't see CAN hurt you!".

 

Don

[Tek420 0]

Hey does anyone know what the URL for the snapshot is on 5.2 on a DS-2CD2132-I? I had this setup in my Vera Lite and using the IP:PORT in the settings and it worked using URL /onvif/snapshot before my upgrade (not sure but think it was 5.1) but now this is not working. I knew it worked when I tested the URL http://IP:PORT/onvif/snapshot in a browser and got a picture.

 

I tried the http://ip:port/Streaming/channels/1/preview?auth=xxxxxxx.http://ip:port/Streaming/channels/1/?auth=xxxxxxx==, http://ip:port/onvif/snapshot/?auth=xxxxxxx==, and http://ip:port/onvif/snapshot/preview?auth=xxxxxxx== in a browser with and without the == at the end and numerous others from here (http://www.ispyconnect.com/man.aspx?n=HIKVISION) and get "This page is unavailable" on all of them. I used an online base 64 encoder in the format username:password and that seems fine as I tried it on several sites and got the same string.

 

I am out of town a lot and kind of desperate to get this working again as I have Vera Alerts (a Vera app) send me an alert when the doorbell is rung with a picture. When I get a package delivered I can see it and have my neighbor grab it for me if I am out of town because packages have been stolen in my neighborhood.

 

If anybody can help or has any ideas I would GREATLY appreciate it!!

 

Dave

[khx73 0]

http://ip:port/Streaming/channels/1/picture

 

works for me... prompts for user/pass

[Tek420 0]

http://ip:port/Streaming/channels/1/picture

 

works for me... prompts for user/pass

 

Thank khx but that path stopped working for me the last time I updated firmware and broke this same process until I found the /onvif/snapshot path. I'm still digging though.

 

Dave

[Dirk_D 0]

oops - wrong thread.

 

[khx73 0]

http://ip:port/Streaming/channels/1/picture

 

works for me... prompts for user/pass

 

Thank khx but that path stopped working for me the last time I updated firmware and broke this same process until I found the /onvif/snapshot path. I'm still digging though.

 

Dave

 

Ok, none of your example URLs ended in /picture . That's why I suggested it.

Also, I should have added that this example works on my 2032, after the firmware update broke the onvif one. So of course no guarantees it'll work on your 2132.

[40th Floor 0]

H* fixed the no-creds snapshot peek but it still advertises the same URI for getting a snaphot. Software expecting an onvif camera to supply a working snapshot URI will come up empty as far as getting anything out of that URI (there's no response so eventually it'll time out; I tried it in a browser and it's still spinning a minute later). Some fix.

 

:
XmlIn::GetNextPrefixAndLocalName mode= 1.2 'trt:GetSnapshotUriResponse'
XmlIn::GetNextPrefixAndLocalName mode= 1.3 'trt:MediaUri'
XmlIn::GetNextPrefixAndLocalName mode= 1.4 'tt:Uri'
XmlIn::GetNextValue              mode= 3.0 'http://192.168.0.31/onvif/snapshot'
XmlIn::GetNextPrefixAndLocalName mode= 1.4 'tt:InvalidAfterConnect'
XmlIn::GetNextValue              mode= 3.0 'false'
XmlIn::GetNextPrefixAndLocalName mode= 1.4 'tt:InvalidAfterReboot'
XmlIn::GetNextValue              mode= 3.0 'false'
XmlIn::GetNextPrefixAndLocalName mode= 1.4 'tt:Timeout'
XmlIn::GetNextValue              mode= 3.0 'PT0S'
:

In 5.1.8.