Dahua and ONVIF authentication

patters

patters

n3wb
Aug 24, 2016
23
1
I need some help with ONVIF authentication as implemented by Dahua.

I'm trying to configure a SD22204T-GN camera for remote viewing via a smartphone app IP CENTCOM. This is the Windows Phone version of the sister Android app ONVIF IP Camera Monitor by the same developer.

The app works nicely with ONVIF authentication disabled, but it still requires a WebUI account to be able to view the RTSP streams from the camera. I cannot leave the credentials fields blank as I am led to expect by the app developer. I can view the two camera streams, and PTZ control and PTZ presets are working as long as the WebUI credentials are populated in the app's config. With this same camera WebUI configuration I can also view the camera feeds using VLC by opening the network URL:
Code: 
rtsp://onvifadmin:onvifpass@192.168.1.108/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
I can access all three video streams by altering the subtype parameter (0,1,2).

What is not clear at all is that the ONVIF credentials are completely separate from the WebUI ones, and they're not listed in the WebUI at all. The default value is admin:admin, and this can only be changed using an additional software tool - for instance ONVIF Device Manager, which also allows you to add new accounts with varying role-based permissions (administrator, operator, user). I found this information in this conversation thread. What is suspicious is that the video streams are not viewable in ONVIF Device Manager, so this may indicate the Dahua is not entirely compliant with the ONVIF specification. With auth disabled, these streams should be viewable without credentials, and you can see that none are being passed in the RTSP URL that ONVIF Device Manager is using.

But the app works - so far so good. Exposing an unsecured ONVIF device to the Internet is not advisable though, so what happens when we enable ONVIF authentication in the camera WebUI? Well, the IP CENTCOM app can enumerate the device just fine when given ONVIF account credentials, but it cannot view the RTSP streams - I get an auth failure.

Testing with VLC with ONVIF authentication enabled also results in a failure of the RTSP URL quoted above. The only way I could get VLC to show me the stream was to use a WebUI account (not ONVIF) and to remove the "&proto=Onvif" parameter from the URL:
Code: 
rtsp://webuiadmin:webuipass@192.168.1.108/cam/realmonitor?channel=1&subtype=0&unicast=true

So why should enabling ONVIF authentication break the RTSP stream? Is it because ONVIF authentication enabled implies that the credentials should be presented as a one-time digest, rather than plaintext? This seems implied by this stackoverflow post (and its answers).

I see that another ONVIF app developer did apparently implement some specific workaround for an ONVIF authentication issue on DAHUA camerashere.

My camera info below:
Model SD22204T-GN (PAL variant)
Software Version 2.400.0000.16.R.T1.484, build : 2016-05-17
WEB Version 3.2.1.345759
ONVIF Version 2.4.2

I would appreciate if someone with developer knowledge of ONVIF could assist, or perhaps someone who has successfully configured some other ONVIF application to view steams from a Dahua camera with ONVIF authentication enabled. The latter would narrow down whether the problem is with the app, or the camera firmware.

Thanks!
 
Last edited:
  • Like
Reactions: alastairstevenson
An interesting post, for us techies.
Thanks for sharing.
patters said:
What is not clear at all is that the ONVIF credentials are completely separate from the WebUI ones, and they're not listed in the WebUI at all. The default value is admin:admin, and this can only be changed using an additional software tool
Click to expand...
Hmmm... that sounds like a bit of a potential backdoor for the unwary.

As a bit of an aside - have you sen the camera generate any ONVIF event notifications?

Unfortunately I can't contribute technically to your analysis as I don't (yet) have any Dahua products.
 
I haven't experimented with any notification features I'm afraid. I want to get the basics working first.

The main take-away from my experiments is that it is possible to view the RTSP streams using VLC. When I first bought the camera the Mac OS plugin was not available at all (it was being updated for El Capitan I think) and so this was something I had really needed but could not get working. Most other published methods for Dahua cameras simply do not work for newer cameras such as this one. My MacBook will heat up and run its fan loudly when viewing streams using the horribly inefficient camera WebUI, but I can leave VLC open permanently showing the same stream with barely any CPU impact and no fan noise at all.
Another bonus is that the UWP version of VLC for Windows 10 (inc. W10 Mobile) opens these network streams too. So by port forwarding the RTSP port on my camera I do at least have decent remote viewing capability, and I can obfuscate it to some degree by picking a custom port. I'm aware that I could use a custom HTTPS port and select PTZ presets using browser POST requests like so:
Code: 
https://cameraDDNShostname:httpsport/cgi-bin/ptz.cgi?action=start&channel=0&code=GotoPreset&arg1=0&arg2=2&arg3=0
where arg2=PTZ preset number.

Sending credentials in the RTSP URL string is insecure too. Any answers to the questions in my initial post would be greatly appreciated.
 
Last edited:
Have you tried SmartPSS for mac? Im watching 7 substreams on my Sierra MBP and its only using ~80% of a single core.. Controls a PTZ much better than the WebUI ever could
 
My interest is in a viable secure mobile solution for my phone - a Lumia 950 running Windows 10 Mobile - while I'm away from home. The various PSS apps for Windows Phone 8.x all broke with the transition to Windows 10.
 
Last edited:
get a different phone heh.. wha'd you expect buying the least adopted and most hated mobile OS.

I use Domoticz's selector switch to go to presets via a https webpage I host out of the house.. A https get request with the credentials in the URI is not insecure; the credentials are simply communicated to the browser and it includes those in aa http auth header, those wont be transmitted until the encrypted connection is established.. the only issue is locally its readable, but you could just embed those into your request silently by crafting your own auth header if thats a concern.

The problem is the RTSP Stream is auth in plain text.

Then there's always a VPN Server, which would make all your concerns moot: VPN Primer for Noobs
 
Last edited:
Moving the PTZ with an HTTPS request isn't so bad. I get prompted for credentials once, but I can then move the PTZ without credentials prompts for the remainder of that session. The RTSP is still the weak link (credentials on URL string). I have an SSH host with two factor auth which I use for port tunnelling when I need it, so a VPN isn't necessary. However that requires a computer to act as an SSH client with local gateway ports. Mobile OS app sandboxes do not typically allow such things. Often I want to just check the camera without all that.

This is veering off topic, and as you can hopefully judge from the content of my initial post I'm not a tech noob. The thread topic is that ONVIF authentication is designed to provide the secure solution I'm looking for here, and it isn't working. I want to understand why not and try to solve the problem, rather than find a workaround. Ideally there is some working example implementation of this protocol that can securely control Dahua cameras that can be analysed with Wireshark and mitmproxy.
 
Last edited:
shrug, Ive written my own applications against all my Dahuas using the ONVIF specifications.. worked fine and I had absolutely no trouble with a 3rd party ONVIF library that did most of the work.

I dont see how it provides any additional security accessing the video stream; one way or another the credentials are sent in plain text as the cameras dont do encrypted RTSP; whom cares if its hashed if you can intercept the hash and reuse it all you want.. Who wants to bet its just base64 encoding the credentials and any idiot can decode the originals.

I dont use VPN to access my home automation WebUI; it does x509 Auth and if a device has a certificate I signed it can access the interface without even entering a password.. the automation engine will then issue commands to my cameras and subscribe to events coming from them.
 
Did you ever experiment with that ONVIF library with the camera's ONVIF authentication enabled?

If you read the stackoverflow link in my first post it mentions that the password digest has a time component to it (which it syncs from the camera's time source) so it's not reusable. The device's serial number is also used which means you can't simply replay the same thing on all cameras. That would all be great if the initial connection to the ONVIF stack was HTTPS, but it's HTTP so logically it can't be secure. They probably made this design decision due to the need for certificates, and it inherently being vulnerable to MITM attacks since it's unlikely people would use certs from publicly trusted CAs, and they'd be unlikely to verify the trust chain - instead just clicking to ignore the warning. These digest functions add a heavy layer of obscurity, but that's not security.

For now for my remote viewing I'm going with the compromise of issuing PTZ commands using POSTs to the regular HTTPS WebUI on a non-standard port (manually inputting connection credentials in the browser dialog), and stream viewing using RTSP in VLC. For someone to gain my credentials, they would have to sniff my connection request. The security of the actual stream content is not particularly important to me even if can be eavesdropped by an attacker in the network route between my phone and my home. My mitigation is that I'm connecting to RTSP with non-privileged ONVIF 'user' role permissions only, so an attacker who captures the credentials from the connection request cannot modify the camera config. It's the camera getting rooted I'm worried about, which isn't so likely using these measures.

The bonus to using this method is that I can use all three streams rather than being limited to the two that ONVIF exposes. I can continue to use the 4Mbps 1080p main stream for my motion capture recording to SD card, I can use low framerate 320Kbps MJPEG for substream1 for really low bandwidth WAN connections, and I can use substream2 for 2Mpbs 720p for my mobile viewing.
 
Last edited:
yes ONVIF Authentication was always enabled on my cameras, this is what I used: onvif

with no encryption layer all the video your streaming is visible; still not secure.. and then your trusting that these cameras can be exposed to the internet.. and thats another fatal flaw in your logic.. one issue and all authentication can be entirely bypassed
 
The SSH port tunnelling is the hardest security option, since my SSH host has two factor auth. Agreed, despite HTTPS protecting the WebUI, Dahua has got quite a track record for leaving backdoor accounts in their systems. Plus they'll be using outdated versions of Linux crypto libs. I'm beginning to think that writing my own web service using a pre-canned ONVIF library might have to be the way forward, and I'm not even a developer.
 
Last edited:
Interesting information from the ONVIF 2.4.1 specification Security section (5.12):
Both digest authentication and the user name token profile give only a rudimentary level of security. In a system where security is important, it is recommended to always configure the device for TLS-based access (see 10.1). Digest authentication or the user name token message level security combined with TLS, with client and server authentication, protected transport level security give an acceptable level of security in many systems.

An ONVIF compliant device should authenticate an RTSP request at the RTSP level. If HTTP is used to tunnel the RTSP request the device shall not authenticate on the HTTP level.

An ONVIF compliant device shall when authenticating RTSP and HTTP methods use user / credentials from the same set of users / credentials that are used for the WS part. For user defined with the user name token profile, digest authentication [RFC 2617] shall be used for RTSP and HTTP.
Click to expand...

So based on the first paragraph the initial contact with the device should be allowed on the HTTPS port for true ONVIF compliance. That would clear the way for subsequent RTSP auth to use the one-time password digests based on credentials plus serial number plus system time, which can't be guessed without that HTTPS access. Looks like my choice of mobile app is at fault here since it won't allow that - it's HTTP only. It lets you override the port, but not the protocol.

Notice the final paragraph - the RTSP auth should use the same credentials as the ONVIF HTTP/HTTPS auth, but this doesn't seem to be working for me because the app fails to show video when ONVIF authentication is enabled despite allowing ONVIF device enumeration, and I can't get VLC to show a stream using valid ONVIF credentials. Perhaps it's because I'm trying to use the actual credentials and not the digest values, however it does not appear that digest authentication is mandatory. The only way to be sure would be to Wireshark capture traffic from that onvif library you used.
 
Last edited:
it looks like the token profile uses digest auth, but I see no indication that is required... I can play a stream using standard user credentials that have viewing permission in RTSP but its not using digest auth, its basic auth.
 
And that's with ONVIF auth enabled? If so, can you try connecting to the RTSP stream using valid ONVIF credentials using VLC using this URL:
Code: 
rtsp://onvifadmin:onvifpass@192.168.1.108/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
Does that work?
It's possible that I'm seeing behaviour caused by a Dahua bug in my particular camera's firmware version. It might work fine on yours for instance.
 
Last edited:
opens just fine for me on my Dahua NVR and also directly to my Cameras in VLC
 
Hi nayr,

I ended up staying up very late on the night I was responding to this, and ended up having to stop my testing to get some sleep.

Just to be absolutely clear that my camera firmware is the issue, please can you confirm that we understand the same thing by ONVIF authentication enabled (WebUI: SETUP > Network > Connection > ONVIF tab > Authentication : enable).

It seems to me that my camera's firmware may have something the wrong way around - when ONVIF auth is disabled, I'm required to provide the ONVIF credentials to even see the RTSP stream in VLC, which seems counterintuitive.
On your camera, if you disable ONVIF authentication are you able to view the RTSP stream in VLC without credentials? Can you see the video streams without authenticating using ONVIF Device Manager on a Windows PC (if you have one)?

Thanks
 
ONVIF Authentication is enabled, credentials are required for the RTSP regardless of ONVIF Authentication settings, Stream because RTSP !== ONVIF..

RTSP and its credentials have nothing what so ever to do with ONVIF.. thats done over HTTP on another channel and are used to help devices discover the RTSP Stream and do other things.

I have no Windows PC
 
I know ONVIF is essentially the HTTP web service, but your statement that it has nothing whatsoever to do with RTSP is somewhat misleading - because as I stated in my first post, my camera wants the ONVIF credentials to view the RTSP stream. It will not work with WebUI credentials, which is why I had been unable to ever use VLC for viewing until I stumbled across a mention of admin:admin being the ONVIF defaults.
 
Also that RTSP stream auth requirement changes (well, breaks really) when I enable ONVIF auth, so there is a linkage somewhere along the way.

Anyhow, thanks for your tests - what we have been able to establish it seems is that my particular firmware release is borked for ONVIF auth, and is behaving differently from yours when tested with VLC. The earlier version of firmware to the one I use has a fault whereby the PTZ initial position setting is ignored on reboot, so I'm not really interested and reflashing that to further test this issue. The even older versions than that one were horrifically unstable after just a few clicks in the WebUI. I checked the Czech FTP server for newer firmware availability and it seems like I'm running the newest version that exists at present. So this looks like the end of the trail for now.
 
Last edited:
You must log in or register to reply here.
Top Bottom