Which Idiot Invented That? Some thoughts on ONVIF

When I look at ONVIF my first thought is that we need two abbreviations.
  • Internet Of Things
  • I Do Internet Of Things
ONVIF is a 100% match for the second abbreviation. Let's have a closer look why.

A Soapy Lunacy Through and Through

ONVIF is a SOAP based specification where the actual meaning of the SOAP conversation is defined using WSDL.

That is an excellent way of making two large and complex systems talk to each other somewhere in the depth of an enterprise network behind 7 firewalls while supported by a dedicated software development and network security teams. When used in its "native environment", which is protected networks in a large enterprise, SOAP shines. It allows you to describe nearly anything and everything as well as nail down the parameters to a set of acceptable values (as well as relevant dependencies between them).

Putting SOAP out there, into the Internet Wild West is like walking about in a rough neighborhood carrying a gigantic poster saying "I am a SUCKER, I have a grand in cash, come and take it. Take my phone and credit cards too and have some kinky fun to top it up, I do not mind". This is even if it is implemented correctly as long as it is open for anyone to connect and the sole security is username + password (there is a reason why SOAP+WSDL nearly always go hand in hand with x509 in enterprise environments you know...).

Now add to that the fact that it was implemented by a person who has no clue whatsoever in Internet security, has barely read the the documentation of an off-the shelf toolkit and has cobbled it together in an afternoon from off-the-shelf parts while forgetting to turn telnet off and leaving a default password of 1234. The person after that went to spend 99% of his paid time to work on the project doing an ugly web interface hacked together from flash, long abandoned insecure bugware like the quicktime plugin for Windows and made it barely work only in IE. After that, as an icing on the cake, the "developer" (quotes intended and needed) added a ready baked recipe that forwards ALL open ports (and not just what is needed) via UPnP across the user firewall. After all, what can go wrong if you put a device with a set of wide open protocols onto the Internet...

The Mirai (and other similar botnets) are not incidents, they are natural consequences of an I Do Internet Of Things specification. ONVIF as a specification puts 100% emphasis on adapting an inappropriate enterprise protocol to talk to the device, 0% on the device actual security, 0% on the device manageability, 0% on the device service provider integration and 0% on local network integration and what the device should be allowed to request in terms of NAT traversals (or IPv6 firewall holes).

So what can we do about this mess. Well, for the time being, until the perpetrators of the ONVIF lunacy have been made responsible for their creation we have to paraphrase Arnaud Amalric: "Firewall eos. Novit enim Dominus qui sunt eius"

Corralling IoT Typhoid Mary

I have a special Isolation Ward where each and every new IoT device goes before it is signed off for use. It is a subnet for which the forwarding is turned off completely. It is using a local DHCP server, local DNS server and local NTP server in addition to the other tools that may be needed to analyze the new (presumed) hostile device. Do I sound paranoid?

Well, let's take a random device off Amazon and see if my paranoia is justified. For this particular exercise we will take the ONVIF supporting Revotech® - I6032B-P POE.

Let's hook it up and boot it up and see what it does:

  • Device boots
  • Device asks a Chinese educational network server for time sync. Facepalm
  • Device tries to use some rather interesting DNS queries to do what looks like register its location with a Chinese cloud DVR service. Double Facepalm. That was definitely not on the menu. Nice idea - having your pics shipped to a country where you have no legal recourse and no data protection whatsoever.
  • Device is continuing to try to get out of the cage we have put it in - UPnP, weird DNS requests, you name it. That just broke the Facepalm Barrier
  • Device runs ONVIF so after we have gathered our thoughts we can give it a go and see if we can reconfigure some of that.
  • It is now up and has open plenty of ports including telnet. While the Mirai password list does not provide a positive, it most likely has a default password, I just cannot be bothered to try to brute force it.

First of all, it looks like our paranoia was justified. Putting this device without precautions onto an average user network opens the network to an attacker AND registers with a DVR service in a country with no data protection for Eu subjects so the DVR service owner can sell your live camera feed anyway they like whenever they like.

Second, we are writing about ONVIF, right? So let's see what happens when you give a paid-peanuts-by-the hour developer in the Wild East a SOAP/WSDL spec...

It is not a pretty sight. Half of the operations return with an error. Ask it for its video stream params ? Error (despite it being present and available at a harcoded location). Ask for video encoding parameters? Try to change a parameter. Error. Error. Error.

I can (and I have done so) repeat the same exercise with a different IoT device. The reality is that unless it is something Enterprise grade in the 100£+ bracket range it will have a broken ONVIF implementation. Reality - meet SOAP and WSDL. Reality - 1. SOAP and WSDL - 0. This, by the way is by no means a SOAP/WSDL problem. We would have had a similar result if we tried to build our Not standard on top of YANG, the TR69 family or any other flexible modelling approach out there.

This is the key issue with SOAP and other model driven interfaces - they are complex. Sure, you can make anything interoperate with anything. This, however, comes at a fairly high cost in terms of minimum developer qualification and a HUGE integration and testing cost. All the Chinese vendors shipping semi (or often outright) illegal 35£ a pop IoT devices have neither the resources, nor the intention to spend that cost. The spec is simply not fit for purpose for the market it is intended to serve day one. This is even if it was fit for purpose if it was implemented correctly.

The Spec is Broken Too

When I read ONVIF it reminds me of TR69 - they are both examples of specifications where very few engineers were anywhere near the spec when it was written. And it shows.

Let's take the video camera device spec and have a look at it in more detail. This is the so called ONVIF Profile S. It makes an for an entertaining read:

So let's read the spec. The first thing we find is that it makes no sense. It is sparse, does not cover everything, obvious things are missing and it is does not match what we see in the clients. Frankly, you can get significantly more information by reading the WSDL files. As an example - the S profile lists only two (rather primitive) authentication methods. Compared to that the WSDLs list the whole (as expected) SOAP authentication suite including the use of X509 certificate paths and cryptography. Similarly, there are bits on video encoding, stream specs, etc in the WSDL which are not in the spec. This situation is worst in the parts that matter most - the video analytics. There is NOTHING on that in the standard. You have to read the WSDL, try to figure out what is the meaning of the parameters and prey that the particular piece of cheap Chinese tat you are testing against supports it (usually it does not).

The real surprise comes when you are finished reading it. There is NOTHING in it describing any parameters. At all. There is a number of key parameters which a video analytics system must support in order to be able to detect motion. We are going to steal some examples out of the motion wiki page. These include (but are not limited to):

  1. Percentage of pixels changed in order for motion to be detected
  2. Masks to exclude, include or adjust sensitivity prior analytics analysis.
  3. Standard filters to decrease noise and thus minimize false positives such as de-speckle
  4. Are the parameters constants or they are adjusted over time
  5. Special processing to take into account lights on/off and switching to/from IR mode

The list can be continued for a while. None of this is present. The situation is similar in other parts of the spec. You have a look at the ONVIF profiles - there is little or nothing there. You double check vs the WSDL files in existing toolkits and you find that they specify operations, but do not specify the payloads and their meanings for any of the stuff that one will need to program an actual analytics job into the camera.

It is not only the user which is "surprised" by this part of the spec. Every time one tries to poke any of these functions via ONVIF the result is an "Operation not supported" or various weird and wonderful errors. That leaves the user with only two options

  • Trust the camera web/configuration interface to program the analytics engine correctly. As most of the parameters are hidden from the user we have no clue what is the actual analytics methodology.
  • To forget ONVIF altogether and use server side video stream analytics like motion to detect events.

For the time being I am sticking with the latter. I may one day enable some of the events on my cameras, but it is definitely not worth it doing it today.

-- AntonIvanov - 05 Mar 2017
Topic revision: r3 - 11 Mar 2017, AntonIvanov

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback