Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[BryanGriffith]

I just plugged in a DCS-920 and opened a route to port 80. I am running the latest firmware 1.03.

I then pasted the APPLET code into an HTML file, and the camera is now visible to the world without any security.

<APPLET name="cvcs" CODEBASE="http://127.0.0.1:81/" CODE="xplug.class" WIDTH=640 HEIGHT=480>
              <param name="RemotePort" value=81>
              <param name="Timeout" value=5000>
              <param name="RotateAngle" value=0>
              <param name="PreviewFrameRate" value=2>
              <param name="DeviceSerialNo" value="***************=">
              </APPLET>

Anyone who can access the applet class, or the ActiveX class can view the live video and bypass the security. Only the still image is password protected by the user access control.

This is completely unacceptable as anyone with my IP and DeviceSerialNo can now view my camera.

Every file on the camera, including the java .class and ActiveX class, should be protected by the user access controls.

Is there a fix for this problem or should I return the camera?

[Mickey]

Did you enable user access control?

[BryanGriffith]

Yes. I have enabled User Access Control, but that only prevents access to the JPG image and the control panel, but not the JAVA Class or the ActiveX Control which provide streaming video.

I have not called to complain yet, but I think this is a major problem.

[BryanGriffith]

Why hasn't this received any attention? I tried to report this problem over the phone, but they were not helpful.

[ECF]

What where you told over the phone by technical support? Did they replicate your issue and provide any feedback?

[BryanGriffith]

Tech support did not seem interested in hearing my concerns, and refused to escalate the call to anyone responsible. I guess I should keep calling back, but it just takes an incredible amount of time to do so.

Can anyone else replicate the problem?

[BryanGriffith]

Skitsnack,

I am not going to post my camera information, but you can test on your own camera by pointing your browser to:

http://MYCAMERA/xplug.class

or if you are running Chrome Developer (maybe BETA too) version, you can point your browser to http://MYCAMERA/mjpeg.cgi

or, you can paste the JAVA or ActiveX code into an html page to embed your camera into the page, and you will not get a password request to view any of these files. All of this provides direct unprotected access to the live stream.

[trevwgtn]

I concur with BryanGriffith's observations – actually, it is worse than he states here, as I’ve observed in my case where I own four DCS920 cameras all purchased at different times spread over 12 months, and the ALL have the same DeviceSerialNo.

So, if you have more than one camera, and say for example you want to share one of them publically (e.g. out-door facing weathercam), and keep the others private (e.g. indoor baby-cam), with this bug, all of them could become find-able by someone with this knowledge (or presumably just the knowledge that it’s a DCS920). In my case they could just try all my other ports on my home IP and it wouldn’t take long to find the other cameras.

I find the bug unacceptable on several levels – (1) all files should be user-access protected as BryanGriffith mentions; but also (2) the DeviceSerialNumber should at least be hashed from the actual serial device (not jus hard-coded in firmware), or even better (3) hashed from a user-defined security string, so security can be enhanced by changing it periodically or as required (e.g. security breach)

My installation is a home cable modem, and wireless router. I want to write my own web code software to share cameras publically but without creating (and running, all the time) an intermediate server to decouple the camera’s video from the stream available publically, I can’t see a way of doing it securely while the current fault exists.

[ionizer]

has this issue been resolved in newer firmware v1.03 or some other manner?

i tried to replicate, via direct html of the xplug.class or the mjpeg.cgi direction
i also tried to replicate by using the <applet> code mentioned

i tried this in firefox, IE and Chrome and I was never able to access my cameras, but have no problem accessing them via the normal web page.

ideally, i'd like to be able to setup my own html page that shows two streams and of course be prompted for a password, but if that is not possible, i definitely want to make sure no one can just simply access each one individually.

[ionizer]

nevermind, i see that the device serial # doesn't necessarily correspond to the serial # on the back of the device....i viewed the source from the html page and then copied that and i see that this is indeed a bypass available.

anyone can simply acquire that information and have access!!!

[Mackerel]

The only part visible/accessible is the video. Any other access (setup, etc) goes via user/password. If you want to close off access to your webcam you can use a forwarded port via the router into your website. This will not stop people from viewing the image, but the rest is obfuscated.

The only part I do not understand is what the problem is with it being publicly viewable... If you keep it behind the router, it stays inside your LAN. So please explain where the problem lies.

[ionizer]

here's the problem:

I want to view my home remotely from work to see a 3 week old baby.  thus i need the ports forwarded to access from work.  in addition, i may want to share an additional username/password with family and friends so that they can view her remotely.

however, i do not want anyone else in the world who knows about this workaround to be able to have the chance of remotely viewing my home. 

i thought that was kinda obvious, no?

[Mackerel]

i thought that was kinda obvious, no?

Not really, but now it is... If you have a website with added options (scripting/cgi/php/etc) you could force usage of a login through that, but going to the webcam directly... That will not work (at this moment). If you forego on the DDNS and just use the hard IP-address, it will be (a little bit) harder to 'find' your camera.

So, again, not possible on 920. Sorry.

[ionizer]

Not really, but now it is... If you have a website with added options (scripting/cgi/php/etc) you could force usage of a login through that, but going to the webcam directly... That will not work (at this moment). If you forego on the DDNS and just use the hard IP-address, it will be (a little bit) harder to 'find' your camera.

So, again, not possible on 920. Sorry.

yeah, i mean the url itself is not going to be something obvious to find and it just goes hard direct to the ip address and port anyway.  so yeah, it's harder to find, but it's the mere fact that it could be only a matter of time if someone wanted to scan for this type of feed, find it, then view into ur home.

there's absolutely no reason that the feed shouldn't have some authentication on it.  it seems like a basic security principle to me.  did d-link think everyone is stupid and wouldn't figure it out?

[ECF]

Do you have these same results if you do not port forward port 80 to the camera but utilize the secondary http port?