The backbone of Interoperable Surveillance Solutions

Deploying effective surveillance systems is a common challenge, especially in a world that is becoming more security conscious. To guarantee that various devices can be used together without any problems, there is an emphasis placed on the interoperability of the associated application protocol standards. That is where the need for Open Network Video Interface Forum (ONVIF) protocol is, in being the major step towards achieving interoperability goals.

What is ONVIF?

ONVIF is an open industry forum aimed at standardizing IP-based security devices, governed by a consortium of manufacturers and industry leaders in the security technology sector. It enables devices from different manufacturers to communicate seamlessly, facilitating integration in surveillance systems. As of now ONVIF has more than 1000 member companies that produce various ranges of products such as cameras, recorders and access control systems. This protocol is quite commendably well accepted at the security arena which allows the end user to implement versatile and extensible surveillance architecture. An example of this is the use of ONVIF by CP PLUS smart cameras, as shown below:

Figure 1: CP Plus smart camera phone app utilizing ONVIF

Network Traffic Analysis

The ATI team in Keysight has analysed the network traffic of ONVIF Protocol and observed seven types of packets, which are:

1. Pull Sub Manager (Pull Subscription Manager) Request: Manages and retrieves event notifications using a pull-based approach, where clients request events from the server at regular intervals.
2. Device Service Request: Manages and configures IP-based security devices, providing functionalities for device discovery, configuration, and status monitoring.
3. Login Request: Access login page.
4. Media Request: Provides access to media profiles and streaming configurations for ONVIF-compliant IP cameras.
5. Imaging Request: Provides standardized control and adjustment of video camera settings, such as brightness, contrast, and focus, ensuring consistent image quality across different devices.
6. Analytics Request: Enables standardized integration and management of video analytics functions, such as motion detection and object recognition, across various networked surveillance devices.
7. Snapshot Request: Allows the retrieval of a still image from a networked video device at a specific moment in time.

Let’s take a detailed look at the decrypted traffic for all the above mentioned packets:

Figure 2: Sample Pull Sub Manager Request from ONVIF Client

The HTTP request packets used for ONVIF-compatible devices share a similar structure, consisting of:

1. Request Line (URI):

The URIs for different request packets are shown in the table below, typically beginning with either POST or GET requests to specific endpoints:

Table 1: ONVIF Request Packets – HTTP Methods and URIs

2. Headers:

• Content-Type: application/soap+xml, indicates the format for SOAP XML communication.
• Host: the target server’s IP address.
• Accept-Encoding: gzip, deflate i.e. lists supported compression methods, allowing for efficient data transmission
• Connection: Usually set to Close or keep-alive.
• Cookie: <cookie_name> for session management, optional if behind a proxy.
• Content-Length: length of message body i.e. the XML file, which ensures proper reading of the message body.

3. Request Body:

The payload contains a SOAP envelope, and the XML body is divided into two sections:

Header: Contains security credentials like username, password digest (Base64 encoded), nonce, timestamp.

Figure 3: HTTP POST request payload from ONVIF Client

Body: Varies by request type, specifying the action and required details.

Table 2: ONVIF Packet Name and Request Body

For all the seven types of request packet, we have observed three types of HTTP Response packets, with a similar type of header and payload structure as discussed below:

1. Response Type:

• 200 OK Response: Indicates that the request was successful and the ONVIF server has returned the requested data.
• 304 Not Modified Response: Signifies that the requested resource has not changed since the last request, so the client can use its cached version.
• 500 Internal Server Error Response: Indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.

2. Headers:

• Content-Type: application/soap+xml, indicates the format for SOAP XML communication.
• Content-Length: length of message body i.e. the XML file, which ensures proper reading of the message body.

Figure 4: Sample HTTP 200 OK response header from ONVIF server

3. Body: The payload contains a SOAP envelope, and the XML body. Which looks like:

Figure 5: Sample HTTP 200 OK response body from ONVIF server

ONVIF Traffic Simulation in Keysight ATI

At Keysight Technologies, our Application and Threat Intelligence (ATI) team, researchers have examined the traffic pattern of ONVIF protocol and added its support in ATI-2024-19 StrikePack release on September 30, 2024.

We have added a new Application named ONVIF and its 7 new Superflows as shown below:

Figure 6: ONVIF App and its Superflows in BPS

These SuperFlows cannot only simulate the various devices and scenarios but are functionally identical and can interact with any ONVIF-compliant device.

Leverage Subscription Service to Stay Ahead of Attacks

Keysight’s Application and Threat Intelligence subscription provides daily malware and bi-weekly updates of the latest application protocols and vulnerabilities for use with Keysight test platforms. The ATI Research Centre continuously monitors threats as they appear in the wild. Customers of BreakingPoint now have access to attack campaigns for different advanced persistent threats, allowing BreakingPoint Customers to test their currently deployed security control’s ability to detect or block such attacks.

Related Content

Related Posts