In addition to other authentication mechanisms, the ONVIF Specification always accept
WS-UsernameTokenwhich is described in the OASIS Specification Document.
WS-UsernameToken relies on the transmission of the following data to authenticate a request:
- Username – The username of a certified user
- Nonce – A random, unique number generated by a customer
- Created the
UtcTimewhen the request is made
- Password – The password of a certified user
According to the specification, “Password” must not be defined in plain text. Defining a password generates a “PasswordDigest”, a digest calculated according to the following algorithm:
Digest = B64ENCODE( SHA1( B64DECODE( Nonce ) + Created + Password ) )
For example, given these arguments:
Nonce – LKqI6G/AikKCQrN0zqZFlg==
Created – 2010-09-16T07:50:45Z
Password – userpassword
Here is the resulting summary to include in the request to authenticate it:
This helps hide the password and provides a base to prevent replay attacks. According to the ONVIF standard, for web service producers to effectively thwart replay attacks, three countermeasures are also recommended (where “recommended” should be interpreted according to RFC 2119 parameters):
1. It is recommended that producers of web services reject any
UsernameToken do not use both nonce and creation timestamps.
2. Web service producers are recommended to provide a timestamp”
freshness” limitation, and that all
UsernameToken with “
stale” timestamps are discarded. As a guide, a value of five minutes can be used as a minimum to detect, and therefore reject, replays.
3. It is recommended to cache used nonces for some time; at least as long as the timestamp freshness limitation period, above, and the
UsernameToken nonces that have already been used (and are therefore in the cache) being discarded.
The specification steps can be considered optional to relieve the device of the burden of performing checks for non-sensitive state change requests. Although only “recommended” by the specification, it is crucial that the device properly validates all of these countermeasures for security-critical requests. In fact, absent these checks, an attacker able to sniff an unencrypted ONVIF interaction would also be able to endlessly replay credentials in new requests to 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 made by Dahua. While researching ways to extract the fingerprint information from the device, we sent the following non-state change
GetScope ONVIF request from authenticated server
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.