Serious security vulnerability with Tenvis JPT3815W (foscam clone)

Hey, I'd like to report a serious security vulnerability with a rather popular network camera by Tenvis, model "JPT3815W". I haven't tested if other models or firmware is affected as of now. My firmware is "version 1.1.0.5" and it's a 2014 model.

Long story short, it's very easy to access the live video feed from the camera without supplying any credentials. However, that's not the worst of it.

The problem, is that it's equally easy to get the wifi password of the network that the camera is installed in, along with its SSID! All the attacker needs is the camera's IP address (or the unique URL from Tenvis' DDNS).

For more details on how to reproduce that please check my article. I'm very interested in learning if this is a vulnerability shared among other models, firmware versions or even brands. Since we are talking about clones, their software is pretty much the same.
The chinese weren't so particularly impressed when i contacted them about this and simply replied "I’m afraid at present, we have no better way to protect customer’s privacy. Hope you can understand our difficulty." 

Anyway, if you find the same vulnerability elsewhere, please report it here!

Take care!

First it's important to verify that the browser you are using is not caching the User credentials making you ("Think") there is no requirement to use a User Id and Password for CGI commands like get_params.cgi. You can test this theory by purging your browser cache and trying the CGI command again to verify that in fact your current firmware has a security vulnerability.

Additionally. It would be a good idea to make sure that your browser is NOT using stored user credentials for your IP Cameras. By both its local IP Address and DDNS/WAN IP Address.

This is why. If you are going to personally use an unsecure Internet connection to access your MJPEG based IP Camera or you are going to allow someone else to access your MJPEG based IP Cameras remotely using HTTP access methods. It's best to use additional security methods, to protect yourself.

You can for example. Take your most trustworthy friends or family members whom you allow to access your IP Camera over an unsecure Internet connection and because the MJPEG based IP Camera in most cases only support unsecure HTTP access. You become "Screwed".

Not really because this trustworthy friend or family member was trying to hurt you in any way. But because they don't realize that the HTTP protocol is not secure.

Because of this. I suggest using additional security methods like this for remote access to MJPEG based IP Cameras or any IP Camera which only supports HTTP access methods or is using HTTP Access methods for remote access.

While it does require access to a web server. It's worth it IMHO. In todays time you can run/operate your own ("Not shared") web server with a unique IP Address. Without any requirement to create a domain name, for as little as $5.00 U.S. a month example. Which most likely you could use at minimum for FTP alarm notification snapshots and/or video recordings for your IP Camera:

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

At least you know that whatever firmware vulnerability may "Crop Up" with your IP Camera won't ever expose your IP Camera or data in your IP Cameras configuration to be abused by others.

Sadly. I know of many IP Camera owners that own IP Cameras that support HTTPS access methods. Yet they or their friends and family members always only use unsecure HTTP access methods to access their IP Cameras remotely. True insanity. IMHO. If your IP Camera supports HTTPS access methods you should disable remote HTTP access methods to your IP Camera and exclusively use HTTPS access to access your IP Camera remotely. Even that won't stop a man-in-the-middle attack. But it's much more safe and secure then remote HTTP access to your IP Camera.

Usually. It's someone like you who finds a flaw in a specific IP Camera firmware version and then everyone worldwide is on a hunt for IP Cameras like yours to abuse them ASAP.

As you stated. What's worse is that people can in cases like yours also DUMP any Email and FTP User credentials anonymously ("See below"). Allowing them to take over and/or destroy those accounts, as well. So, this is not simply about someone being able to move your IP Camera around or view your IP Camera.

It's also about someone/others potentially taking over your Email and FTP/Website accounts as well! What they could do after doing so. I will leave to your imagination of what a worse case scenario afterwards, would be.

One last and final point about this is. Because the get_params.cgi request is a short term connection request to your IP Camera. As are virtually all/most other CGI requests to the IP Camera. It's NOT LOGGED in your IP Cameras access log information. Meaning that you can't even tell if someone/others has/have used it.

Try it again. Then check your IP Cameras access log. You will see there is no IP Camera access log entry that someone/others DUMPED the complete configuration data of your IP Camera. Including any Email and FTP User Credentials.

So. If you ever wanted to be a twin brother or sister. This is one way to "instantly" create your twin(s) with potentially some severe financial ramifications, while doing so!

While it might be possible that someone can/could stumble on the open port on your local network for your IP Camera and gain access to your IP Camera that way. Assuming that the port you picked for your IP Camera is not a standard port. It's much more probable that others will learn the DDNS/IP Address, Port and User credentials for your IP Camera while you or someone you allow is using an unsecure Internet connection using HTTP access methods to access your IP Camera remotely. This is why the additional security methods can be and are very helpful in cases like yours.

While these additional security measures don't currently support the full blown camera interface. They are better then remote HTTP access and they can be modified and customized by you as well.

Don

Hey Don, nice answer!

It's very true that plain http is a larger and more general problem here. Using an external server to broadcast the feed through a safe connection is a smart idea (i might try to implement it, if my cam supports upload via sftp) and inexpensive, however would require some "hassle" and time (not necessarily technical skill) something which wouldn't be so popular among the users.

By the way, I also have an AXIS network camera which does support safe connections and can actually enforce secure connections if the administrator chooses so. However that one costs around 10 times more than the Tenvis and is mostly oriented towards professional and industrial solutions. Do you have any models/brands in mind that are both inexpensive and provide such connectivity (ssl) options?

Finally, getting back on topic now, the same model with different firmware wasn't prone to these particular vulnerabilities, but considering the fact that i just bought it and that there are no firmware updates for my firmware version, means that there are many more people out there who are in danger.

Thanks.

Well. This is easy to implement for ANY IP Camera owner of ANY IP Camera. It's heavily commented:

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

It has all the files included. Even if one does not know php it's not that complicated. It really does not require SFTP or FTP to pull the images from the IP Camera. It simply pulls snapshots/images from the camera using HTTP access on the back end. Using it as a proxy on the web server side for the client side. It can also be used to pull snapshots/images using HTTPS on the backend from your IP Camera. If your IP Camera supports HTTPS access.

The issue is more about how long will there NOT be a firmware update for cameras that have this firmware version, with this issue? It could be a very long time before a firmware upgrade becomes available for this issue. Especially more so if this issue is across multiple IP Camera brands and models.

IMHO. You are very lucky you caught this. There are currently thousands of IP Cameras potentially exposed to this issue ("See below") and their IP Camera owners don't know it. The issue is when something like this happens again in the future. Will you be lucky enough to catch it always in the future? Most likely not.

Even if you can and do. That won't protect you from using unsecure Internet connections using HTTP access to remotely access your IP Camera. So there would be no need to have any current firmware security vulnerability with your IP Camera. Because others can capture the DDNS/IP Address, Port and User credentials 24/7/365 when you use unsecure HTTP access methods over unsecure Internet connections for remote access to your IP Camera.

First it's important to verify that the browser you are using is not caching the User credentials making you ("Think") there is no requirement to use a User Id and Password for CGI commands like get_params.cgi. You can test this theory by purging your browser cache and trying the CGI command again to verify that in fact your current firmware has a security vulnerability allowing some or all CGI commands to be executed without any User credentials.

Additionally. It would be a good idea to make sure that your browser is NOT using stored user credentials for your IP Cameras. By both its local IP Address and DDNS/WAN IP Address.

I say this because. It's odd that there are no other security vulnerability reports yet posted for this issue. Minus yourself and your IP Camera:

http://cdrussell.blogspot.com/2014_06_01_archive.html

So implementing this extra HTTP remote access security really is not meant as a defensive move. But should be thought more of as an offensive move for your IP Camera. For now and the future. To be used as needed when needed. Such as checking your IP Cameras health while using a free WiFi connection or displaying your IP Camera in webpages and websites.

Don

First it's important to verify that the browser you are using is not caching the User credentials making you ("Think") there is no requirement to use a User Id and Password for CGI commands like get_params.cgi. You can test this theory by purging your browser cache and trying the CGI command again to verify that in fact your current firmware has a security vulnerability allowing some or all CGI commands to be executed without any User credentials.

Additionally. It would be a good idea to make sure that your browser is NOT using stored user credentials for your IP Cameras. By both its local IP Address and DDNS/WAN IP Address.

sorry, i forgot to answer this in the previous post. The findings were verified with other browsers that i don't frequently use (opera, firefox) and also by using a TOR browser (proxy, no cookies, no cache). The screenshots in my blog post are made from a TOR browser for example. Last but not least, other users who never had any access to the camera, like Craig Russell who was kind enough to write an article about this, were called to verify the situation. Their findings were exactly the same.

I'll look into the https solutions you guys made in that other posts and comment there if i have any questions. Thanks for your time!