Last year, Nozomi Networks Labs conducted extensive security research on multiple IP cameras and video surveillance systems. This research led to the discovery of vulnerabilities in Axis and ThroughTek devices. We’re publishing the details of a new vulnerability (tracked under CVE-2022-30563) affecting the implementation of the Open Network Video Interface Forum (ONVIF) WS-UsernameToken authentication mechanism in some IP cameras developed by Dahua, a very popular manufacturer of IP-based surveillance solutions. This vulnerability could be abused by attackers to compromise network cameras by sniffing a previous unencrypted ONVIF interaction and replaying the credentials in a new request towards the camera.
In this blog we introduce the ONVIF standard, outline the WS-UsernameToken authentication mechanism, provide details on the observed vulnerability, and share specific remediations that can be applied by end users.
Open Network Video Interface Forum (ONVIF)
According to the official website, ONVIF is an open industry forum that provides and promotes standardized interfaces for effective interoperability of IP-based physical security products. ONVIF-conformant products can be seamlessly accessed via vendor-agnostic software through a set of standardized Application Programming Interfaces (APIs). The APIs allow a user to perform a variety of actions on the remote device. Examples of such actions include watching camera footage, locking or unlocking a smart door, performing maintenance operations, etc.
Under the hood, ONVIF requests are mostly transmitted through XML SOAP messages via HTTP. Figure 1 is an example of an ONVIF request to trigger the reboot of an IP camera.
WS-UsernameToken Authentication
Besides other authentication mechanisms, the ONVIF specification still accepts WS-UsernameToken, which is described in the OASIS specification document. WS-UsernameToken relies on the transmission of the following data to authenticate a request:
- Username – The username for a certified user
- Nonce – A random, unique number generated by a client
- Created – The UtcTime when the request is made
- Password – The password for a certified user
According to the specification, “Password” should not be set in plain text. Setting a password generates a “PasswordDigest,” a digest that is calculated according to the following algorithm:
Digest = B64ENCODE( SHA1( B64DECODE( Nonce ) + Created + Password ) )
For instance, given these arguments:
Nonce – LKqI6G/AikKCQrN0zqZFlg==
Created – 2010-09-16T07:50:45Z
Password – userpassword
This is the resulting digest to be included in the request to authenticate it:
tuOSpGlFlIXsozq4HFNeeGeFLEI=
This helps obscure the password and offers a basis for preventing replay attacks. According to the ONVIF standard, for web service producers to effectively thwart replay attacks, three counter measures are also recommended (where “recommended” is to be interpreted according to RFC 2119 parameters):
1. It is recommended that web service producers reject any UsernameToken not using both nonce and creation timestamps.
2. It is recommended that web service producers provide a timestamp “freshness” limitation, and that any UsernameToken with “stale” timestamps be rejected. As a guideline, a value of five minutes can be used as a minimum to detect, and thus reject, replays.
3. It is recommended that used nonces be cached for a period of time; at least as long as the timestamp freshness limitation period, above, and the UsernameToken with nonces that have already been used (and are thus in the cache) being rejected.
The specification steps can be considered optional to relieve the device from the burden of performing the verifications for non-sensitive, non-state changing requests. Although only “recommended” by the specification, it is crucial that the device correctly validates all these counter measures for security-critical requests. As a matter of fact, in the absence of these checks, an attacker that can sniff an unencrypted ONVIF interaction would also be able to indefinitely replay the credentials in new requests towards the camera, which would be accepted as valid authenticated requests by the device.
Dahua ONVIF Vulnerability Details
During one of our research projects, we purchased an IPC-HDBW2231E-S-S2, which is a dome network camera manufactured by Dahua. While investigating ways to extract device fingerprinting information, we sent the following non-state changing GetScope ONVIF request from the authenticated demo_admin administrator account (Figure 2). It returns the public scope parameters of the device used in the discovery phase to match a probe message.
Figure 2: ONVIF GetScopes request from the demo_admin user.
When trying to send this exact request a second time, the device accepted the request and replied again with the same response. This is a reasonably safe behavior, given the non-sensitive nature of the information required.
However, we decided to further investigate this condition, to verify that it indeed applies only for minor requests. So, we tried forging a CreateUsers request that surreptitiously adds an attacker-controlled administrator. We used the same authentication data as the previous request, from a different IP address, and approximately 30 hours after the transmission of the GetScopes request. The result follows:
As seen in Figure 3, the device accepted the request and created the attacker-controlled administrator. We were then able to use this newly created account to access the device with full privileges, to include watching live footage from the camera as shown below.
.webp)
To mount this attack, an adversary must be able to sniff one unencrypted ONVIF request authenticated with the WS-UsernameToken schema. This is not an uncommon condition, for the following reasons:
- WS-UsernameToken is still used by default by many popular ONVIF clients, such as ONVIF Device Manager, or DSE VMS.
- By default the IPC-HDBW2231E-S-S2 (like other Dahua devices) does not expose an HTTPS service, and all ONVIF interactions occur through unencrypted HTTP. We are hoping that in the real world, asset owners are not using the default WS credentials and are using HTTPS for secure connections, in order to prevent such an attack from occurring.
Summary
In addition to building security, surveillance cameras are used throughout many critical infrastructure sectors such as oil & gas, power grids, telecommunications, etc. These cameras are used to oversee many production processes, providing remote visibility to process engineers. Threat actors, nation-state threat groups in particular, could be interested in hacking IP cameras to help gather intel on the equipment or production processes of the target company. This information could aid in reconnaissance conducted prior to launching a cyberattack. With more knowledge of the target environment, threat actors could craft custom attacks that can physically disrupt production processes in critical infrastructure.
Upon notification from Nozomi Networks Labs, the vendor released a patch to solve the vulnerability. Users are urged to update vulnerable devices to the latest available firmware version. As for defense in depth approaches, we also strongly recommend reducing the exposure of devices on the public internet to the bare minimum, and always accessing them through secured protocols (e.g., HTTPS), which would have impeded any exploitation of this issue.
