Subscriber Discussion

Security Vulnerability: Camera Reboot Process Visible

UE
Undisclosed End User #1
Aug 09, 2017

We have a significant deployment of cameras from a specific manufacturer, I am not going to blast them... but maybe I should, who allows their cameras to be rebooted in clear text with a web browser without authentication. I approached them to see if they could "fix" the problem, gave them enough time to address and I still have not heard from them yet. Their only solution was to segment my cameras so no one could get to them. That is fine but the risk still exists and they HAVE NOT disclosed this issue to anyone. When I spoke to them, they indicated "they new about it". I was able to keep a camera down by refreshing my clear text... funny how they did not see this as a vulnerability. I asked if they published the problem or communicated the issue to their integrators/partners... no. The cameras also fail when a vulnerability scan is conducted, the image fails, it becomes multi colored and distorted. Their solution to this was to not scan them. The only issue I have with this is I have cameras which do not fail upon scanning and I would rather maintain my relationship with my InfoSec team than get on their bad side. The funny thing is they currently advertise cyber security is important and is found in every camera.

I searched IPVM and did not see any discussion or articles about this issue with this manufacturer. I searched the internet and again could not see any discussions. I have given this manufacturer over 4 months to address this. Questions:

  • Is there a list of cameras with this issue?
  • Do you agree cameras, or any IoT, should be able to reside on a network and behave securely without depending on firewalls, ACLs, etc.
  • At what point do I "alarm" everyone of the issue? How much time is enough time?

first post - thanks

(3)
Avatar
Brian Rhodes
Aug 09, 2017
IPVMU Certified

Hello, Und #1, welcome.

What type/model/brand of cameras are these? Stating that upfront can get you better involvement in addressing this issue.

Also, the 'vulnerability scan' that causes some to fail - what is it?  Do you know what ports/processes are being scanned?

UE
Undisclosed End User #1
Aug 09, 2017

It’s a light Vulnerability scan from Qualys.

 

The light scan hits about 160 ports:

11, 13, 15, 17, 19-23, 25, 37, 42, 53, 66, 69-70, 79-81, 88, 98, 109-111, 113, 118-119, 123, 135, 139, 143, 220, 256-259, 264, 371, 389, 411, 443, 445, 464-465, 512-515, 523-524, 540, 548, 554, 563, 580, 593, 636, 749-751, 873, 900-901, 990, 992-993, 995, 1080, 1114, 1214, 1234, 1352, 1433, 1494, 1508, 1521, 1720, 1723, 1755, 1801, 2000-2001, 2003, 2049, 2301, 2401, 2447, 2690, 2766, 3128, 3268-3269, 3306, 3372, 3389, 4100, 4443-4444, 4661-4662, 5000, 5432, 5555-5556, 5631-5632, 5634, 5800-5802, 5900-5901, 6000, 6112, 6346, 6387, 6666-6667, 6699, 7007, 7100, 7161, 7777-7778, 8000-8001, 8010, 8080-8081, 8100, 8888, 8910, 9100, 10000, 12345-12346, 20034, 21554, 32000, 32768-32790

Avatar
Brian Rhodes
Aug 09, 2017
IPVMU Certified

Thanks, here's a profile on QualysGuard.

Avatar
Brian Karas
Aug 09, 2017
IPVM

Your concerns and assumptions are certainly valid. This is not the kind of behavior you should expect from a security-oriented device, and it represents a significant risk to your organization.

There are several publications online for responsible disclosure. For example, this one from CSO Online requires:

  • The security researcher who found the vulnerability to confidentially report it to the impacted company.
  • The security researcher and company work in good faith to establish an agreed upon period of time for the vulnerability to be patched.
  • Once the agreed upon time period expires and the vulnerability is patched or the patch is available for installation by the users of the software, the security researcher can publicly disclose the vulnerability.

From what you are describing, the company involved is not working with you on step 2, and you seem to have positive confirmation from them on this. In this scenario, you would generally be considered in the right to switch to full disclosure, and publish the vulnerability publicly. This would warn others of the issue, and potentially help convince the company to address it.

In regards to full disclosure, you do not have to publish steps to reproduce it, simply posting what you posted here, that it is a known issue and can be reproduced reliably, etc. would allow you to inform others without giving out a recipe to make it work (and thereby increase risks for them).

 

(1)
U
Undisclosed #2
Aug 09, 2017

Sorry, what does it matter if the camera reboot process is visible? Who can get attack it or take advantage?

UE
Undisclosed End User #1
Aug 09, 2017

Undisclosed #2, why then have passwords for anything on your network? Who would be able to get to your devices? You have passwords to reduce risk. A camera which can be taken down with a remote command, continuously, is a risk. 

(2)
UI
Undisclosed Integrator #4
Aug 09, 2017

I believe EU1 is talking about an API Command like the two examples below. One requires a Username/Password to reboot while the other does not (NOT REAL CODE). 

curl --user {USERNAME}:{PASSWORD} http://{CAMERA_IP}/...=reboot

VS.

curl -- http://{CAMERA_IP}/...=reboot

 

That being said any camera that allows you to take an unauthenticated RTSP Stream could potentially do the same thing. Just automate a scrip to keep opening streams until you crash the camera or kill all usable bandwidth. 

(1)
U
Undisclosed #3
Aug 09, 2017

Given your description of the image becoming multi-colored and distorted under load (under a vulnerability test), I'm going to guess it's Arecont?

(1)
U
Undisclosed #3
Aug 09, 2017

It's not clear from the post, but I suspect the issue is that you can reboot the camera via the network without authentication. Also, it's not good that the camera dies under the stress of a vulnerability test. There are a lot of successive network requests made during a vulnerability test, and it involves a lot of malformed or non-compliant network traffic, but the load is much less than a DDOS attack and should not be expected to disable the device.

Edit: Meant as a response to U2

(1)
U
Undisclosed #5
Aug 10, 2017
IPVMU Certified

The cameras also fail when a vulnerability scan is conducted...

See a guy named Rodney in IT ;)

New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions