Subscriber Discussion

Remove Web Browser - Make IP Camera 100x More Secure

Avatar
Michael Archer
Nov 21, 2017

Remove the web browser from IP cameras and make them 100x more secure.

Reasons to Keep Browser:

  1. No need to install applications to access device.*
  2. Remote (WAN) configuration.
  3. Advanced device configuration beyond IP address etc.

*However ActiveX is quite a big install, and can also cause version problems with devices.

Reasons to remove

  1. Mostly* just IE browser support requires an ActiveX plugin
  2. Security on device for easy to find exploits will be removed.
    1. Plain text passwords, or simple encoded passwords
    2. Web forms showing data parameters usernames.
    3. Weak session IDs, local cookies in plain text.
  3. Performance of device without a web service running has to be positive.

*To date who can stream H.265 plugin free on any browser from any known IPC or NVR?

Expand the almost always supplied scan tool could be expanded to cater for all devices. And also can be simpler to bulk setup multiple devices in a mouse click. This has to be a better viable option.

There is consideration Onvif uses some web services, however this is mostly done via a separate application on device as it's own service. (Hikvision last update tells you this much)

U
Undisclosed #1
Nov 21, 2017
IPVMU Certified

What makes you think that the client application access is any more secure than a browser?

The only way that it’s more secure is because of obscurity, and that only buys time.

And it’s likely to be fundamentally less secure, once studied in detail, since programmers may write more of their own home-grown auth code.  

IMHO.

 

JH
John Honovich
Nov 21, 2017
IPVM

The only way that it’s more secure is because of obscurity, and that only buys time.

Disagree. Removing the web browser/access is a form of reducing the attack surface.

U
Undisclosed #1
Nov 21, 2017
IPVMU Certified

Ok, I’ll agree with that.

What about eliminating the client app (if functionally possible), would that be more secure then?

JH
John Honovich
Nov 21, 2017
IPVM

What do you mean by client app? I ask because usually the client app is some form of CMS or VMS like iVMS-4200 or ACS, etc.

U
Undisclosed #1
Nov 21, 2017
IPVMU Certified

Yes, like take iVMS-4200 as an example.

It needs a way to communicate to the VMS/camera/recorder, just like a browser based app.

But because the client and the server are written entirely by one entity, there is a great deal of flexibility in how to do it. 

Since it takes more time and effort to figure out what’s going on, you might think it more secure. 

But the obscurity can lead to sloppiness if you rely on it to keep it secure.

Take this latest hack with Dahua.  This isn’t (as far as i can tell a browser based hack).  Rather it’s a socket listening on an unknown purpose port that if communicated with properly will accept a firmware update.  Which could be a comprised firmware, leading to exploitation.

Fairly obscure though, and even though it had a hard coded “dahua/dahua” cred, it was safe for a long time.

In a similar way, client apps can be written using various, concocted protocols, based on expediency, footprint, library availability or just because somebody thought of a cool way to do something.  

I’m guilty myself.

 

JH
John Honovich
Nov 21, 2017
IPVM

Since it takes more time and effort to figure out what’s going on, you might think it more secure.

But the obscurity can lead to sloppiness if you rely on it to keep it secure.

Certainly, but that's not a required outcome of the move. It's like saying if I have 2 doors and I board one up, I'll get lazy and leave the other door open.

So I definitely agree that the remaining 'door'/'opening'/interface still needs to be appropriately secured, simply that by reducing the attack surface, you can better concentrate your resources in defending the opening remaining.

To me, the bigger issue would be whether how many people would object to buying a camera with no web interface. 

U
Undisclosed #1
Nov 21, 2017
IPVMU Certified

To me, the bigger issue would be whether how many people would object to buying a camera with no web interface.

Yes, but what about the alternative of only web, do you think that is more secure than only client?

JH
John Honovich
Nov 21, 2017
IPVM

There is no practical alternative of 'only web', given the fundamental need for professional cameras to be integrated into recorders. 

U
Undisclosed #1
Nov 21, 2017
IPVMU Certified

Why couldn’t that need be met by http interfaces?

bm
bashis mcw
Nov 22, 2017

Disagree. Several vendors actually trying to do so as of today, but the vulnerabilities are not there because HTTP/HTTPS access, that's only one of the interfaces of many others, however the most standard one.

For example, both Dahua and Hikvision has their own "binary" interface agains the provided services, and the services it self are the vulnerable ones.

In short, you don't necessarily hit Dahua's HTTP/HTTPS interface to reach same functionality, it's just fine to reach TCP/37777 or TCP/5000, you ending up into same functionality anyway (more or less).

The difference between these interfaces are the protocol how to login and request things.

And that's not a big deal to reverse.

 

(1)
Avatar
Michael Archer
Nov 21, 2017

By nature client apps are going to be harder to decode compared to just reading simple source HTML or JS scripts which any person can do in just seconds.

Most venerabilities of late seems to reside around CGI HTTP web code, with buffer overflows and injection methods, and poorly encoded plain text information.

The discovery of device on Sodan will stop as it does not scan all ports for private protocols. There would end all the on mass attacks which no doubt used this data in one form or other.

It's going to be a significantly tougher job to from binary data, but not impossible indeed. The point is not able hacking it's about security and how better make these devices more secure.

 

 

U
Undisclosed #1
Nov 21, 2017
IPVMU Certified

It's going to be a significantly tougher job to from binary data, but not impossible indeed.

Why do you think it’s necessarily binary data?  Client apps can transmit clear text just as easily as browser based apps.

U
Undisclosed #2
Nov 21, 2017

The "web browser" irks me a bit, but I guess you refer to the "web interface" or "web server" on the devices. Anyway, instead of removing this functionality, perhaps it should be implemented properly. Mobile banking, Facebooks etc. seem to work fine on the same set of core technologies, but the resources available to implement the services on an IP camera are obviously more limited. They should still be sufficient if anyone cared enough.

If there was only a "secret" tool to configure the camera via a proprietary binary protocol, judging from past experiences the software would not only be reverse engineered quickly (by hackers or manufacturers), but there's also a 99% probability that it's extremely poorly made, corners have been cut, outdated software and design principles have been used to implement it, and the camera will, at the very least, succumb to any fuzzer feeding it random data, potentially bricking it or worse.

Also, the people who make VMS software need to know how to talk to the camera and obscuring the protocol is a good way to ensure no one will ever support it.

ActiveX should be banished from the universe though.

Some simple things that wouldn't be tough to do but would increase security to some extent:

- at first boot of the camera, require the password to be changed (refusing poor ones) and/or some form of credentials to be generated that would allow to disable passwords altogether

- at first boot of the camera, require a whitelist of management addresses to be specified

- disable all legacy services, such as FTP, telnet etc. and remove those from the firmware completely

- making firmware updates easier to manage and reliable, bulk upgrade feature is a very good thing to have, but in big environments where there might be dozens of different manufacturers and models within the same system, it is tricky for now

- manufacturers announcing security problems in a timely manner, not after they're being exploited all over the world

(2)
Avatar
Michael Archer
Nov 21, 2017

Good points here of course, and we should take it no nobody has ftp or telnet open unless they are kind of demented.

I have to chuckle at "implemented properly." Part of the problem is that it does not get done properly, history has told us this already from the existing exploits.

Bugs on a web front end is the same for what a configuration tool would have. But you find many apps are there these days on Apple and Google stores, and none of these will use a device with a web service. So in fact we have home products in ways more secure. At least those without the web service running on them.

Hacking a device reverse engineer a App is no different for the competent person. But doing from web and html code as I've mention is a 1,000times easier. When you get labels and data clearly stating details of what is being sent. Injections for buffer overflows are often cited as exploits.

You will be less likely to find an exploit on a embedded device by the methods from an SDK, and I say binary, because your only means to capture the data is from a network sniffer application, a browser sends everything as plain text, in tables, XMLs nice simple dumps are really easy to see what a device is doing. Built in debugging tools from all web browser make this simple quick and easy to see in a matter of seconds.

Here is an interesting video of no doubt skilled security people (geeks)  and a few exploits here show how weakness in web coding is often the root of attack. 

https://www.youtube.com/watch?v=h5PRvBpLuJs&t=10s

I wonder why now Onvif if we take at least a standard, does not cater for a expansion configuration dataset for a device. A list of additional features of a device would be read by the application an presented in a format so the information can be set in one way or other, data types, IP addresses time date emails any data is just a type. Not that must effort.

Each device can just represent itself with an xml (for sake of just easier handling) data file, and then we could get common configuration possibility.

I'm not sure why the Onvif steering committee does, can they come up with something new and more secure for the world.

U
Undisclosed #2
Nov 21, 2017

... we should take it no nobody has ftp or telnet open unless they are kind of demented

Sadly, on some (especially older) cameras there are such ports open and can't even be easily disabled from their configuration interface.

I agree that having some unified and secure way to manage the devices would sure be nice instead of a mess of incompatible protocols and poorly written software. I think it's going to get "better" as more and more IoT devices and people trying to handle them demand those things.

I remember watching that video, and surely there are many ways around security of any device, sometimes the lowest hanging fruit is a dodgy web interface and other times it's a simple serial terminal (which was prominently featured in the video too), whichever is more convenient. If only one interface was available to communicate with the device and someone wants to get around it, soon there would be two.

But you find many apps are there these days on Apple and Google stores, and none of these will use a device with a web service.

What do you mean by this?

Avatar
Brian Karas
Nov 21, 2017
IPVM

The web interface is not the real root cause of the vulnerabilities. Manufacturers are creating cameras with lots of features and configurable things. They could strip the cameras down to bare minimums, just a box that streams pictures, that would be relatively easy to secure, and uninteresting to exploit. Unfortunately, buyers want (or at least think they want), cameras with lots of features like edge storage or analytics, on-camera applications, etc.

If we are going to agree that cameras should have robust features and things that need complex APIs, then you have to look at creating a secure platform and API structure. If you are capable of doing that properly, wrapping a web interface around it so that you can access the device with a commonly available client (a browser) should not be that difficult.

We have the vulnerabilities we have because manufacturers are not looking at cyber security from the ground up, and are shipping devices with poorly implemented code. Removing the web interface will not suddenly make their engineers write secure code, it will just trade one attack surface for another.

I agree that one possible benefit could be fewer devices showing up on Shodan, however Mirai spread not with Shodan, but with its own IP scanner and pure brute force. 

Also, while removing the browser interface from a camera is an almost possible consideration, I think it is far less practical when we talk about recorders. This again brings us around to manufacturers needing to figure out how to create truly securable devices, and not rely on a security-through-obscurity approach.

 

(5)
(1)
UD
Undisclosed Distributor #3
Nov 21, 2017

I think Brian has the right idea, it's not just one component that is the problem, it's the overall lack of consideration for security at all.  When will these manufacturers wake up and stop working on 10 year old platforms?  Why are they still working on the same BusyBox Linux OS and using telnet and FTP?  Why, dear god why, are they still requiring that web access is only available to IE, a browser that is on its' way out?  The answer is that they are either unwilling, or unable to create a properly secured IoT device.  The investment to change and acquire the intellectual capacity to create these updates too much for them to consider, especially if they just ignore these things and they keep going away after the next 2-for-1 sale.

(2)
Avatar
Michael Archer
Nov 22, 2017

The reason they use the same busybox is because at least in the case of HiSilicon, this is what's provided in their SDK. The less work and consideration at start makes a less secure device. One thing is HiSilicon do run everything on device as root, so that's not very good idea from a security perspective, so breaking into any service running gives you root access.

Ambarella do it a lot better, then have multiple access accounts for different parts. From what I recall the password hash had many accounts there.

If indeed people want to start doing something good is at first try to encode their firmware files! Take a look at Samsung their binary files, it's not possible to extract anything with binwalk or anything. Seems this lacks a lot of attention.

A lot of firmware updates also do not include the Linux Kernal, (not all) so this itself does indeed give an issue. Making a platform a nice host for anything and nothing can or will update it to fix the issue.

If I was to make an update, then 1st I would not let a downgrade be possible.

I would encode each firmware revision, and each update I would change the key, thus if someone decoded a version, it would be more difficult to generate a patched version.

Radio communication devices from long ago would use a digital key that after each message it would hop frequency to another, and only a matched pair would enable communication for a duration. Military level devices do or at least did this. It's not impossible this could be done to secure a device. But gives food for thought! 

 

(1)
(3)
UM
Undisclosed Manufacturer #4
Nov 22, 2017

I think that having an HTTP web server interface is what separates professional devices from consumer devices.  There are tons of IP cameras that only work with the provided (crappy) app.

When you move to professional IoT, whether it is some monitoring device for a control system or an IP camera, IT professionals want to be able to monitor them via SNMP v3, have HTTP access, etc.  

Providing security to use HTTPS, removing unused protocols such as FTP, telnet, etc. is mandatory.  

Think about how many laptops used to have issues getting ActiveX installed due to corporate policies, lack of admin permissions, etc.  Now if you require some large toolkit or client to make simple changes to the camera, you are asking for trouble.  Sure, a simple utility to scan for a camera is OK, but if you start cramming more functionality into it, I be the manufacturers will then make them more complex.

As for running a camera or NVR without activeX, YES it is being done.  Some manufacturers do have HTML5 or other cross-browser interfaces and can allow you to access the web UI on any browser on any OS or device.  This makes it super easy to change a quick setting, focus the camera, change IP, etc.

I have worked with IT professionals who can't use windows utilities. They HAVE to use linux.  Providing cross-browser solutions is the way to go.  Requiring them to use a manufacturer specific tool would restrict them, because we all know they would not be available for every platform.

Avatar
Michael Archer
Nov 22, 2017

A simple scan utility already has ability to communicate with the device.

Expanding this make no difference to include more settings. I fail to see why one is good but yet you still think professional devices have web browser which I think will be reversed as a trend in future. I bet you all manufacturers would love to do this. But who is brave enough to start the trend!

Takes a large pair to remove something people have gotten use too. Like say removing a headphone jack.

If everyone and I don't make assumptions I guess, needs to use a factory tool just to find a device in the first place, would it not save considerable time just to do more than currently is on offer.

We are talking from a security perspective, and aside from nightmares of plugins and configurations associated with IE like stupid security in-certificated setups, just to get to configure this dumb device. A PC App or even on a smart device can be easier to use.

For instance the Onvif device manager, this is a interesting tool which can not only allow many device settings to be made, it's also super simple just to prove a device is running, streaming. and good enough for a focus test from a laptop whilst hanging off a ladder adjusting a device position! I use it just to get the RTSP stream.

UM
Undisclosed Manufacturer #4
Nov 22, 2017

Re: Samsung encrypting firmware:

Discussion about Firmware encryption/signing.

(1)
Avatar
Vincent Tong
Nov 22, 2017

Routers have been doing that for years.  For example the apple, ubiquiti, and google routers do not have a web interface.  They either require downloading a program or just mobile apps to configure.

(1)
U
Undisclosed #1
Nov 22, 2017
IPVMU Certified

ubiquiti routers don’t have a web interface?

Mine do, for sure.

Avatar
Vincent Tong
Nov 22, 2017

maybe i was thinking of the amplifi

Avatar
Sean Nelson
Nov 22, 2017
Nelly's Security

Good idea.

Security aside, The web interfaces have always been a nightmare to begin with. Most manufacturers still cant figure out how to implement a web interface without having a darn nightmarish plugin. 

(1)
New discussion

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

Newest discussions