WebSocketServer.exe?

[wittaj]

I am using Internet Explorer. But I did open this in Edge early on because supposedly that camera could work in other browsers, so I was testing it.

 

[bigredfish]

Well it asked for it but its not there so I said no and all is working fine....seems odd. Obviously wants to communicate with the mother ship for something, glad it works without it.

 

[EMPIRETECANDY]

I just checked with dahua,
it's a reminder for those who haven't install the plugin, the web5.0 still reminder to install the plugin, but can ignore it, it's mainly for AI settings, so when the IVS triggered it will require to set up the plugin. So that is why you get such reminder.
For normal liveview, IR settings, camera normal settings can use without it.

 

[bigredfish]

Thanks Andy
Yeah it complains on the AI tab but was able to setup without it. Again maybe browser dependent, but so far all AI and other functions seem fine without it.

 

[EMPIRETECANDY]

Yes, maybe for some special browser they still need it.

 

[Wildcat_1]

Not seeing it on my setups but I do keep a watch on what’s being installed along with file calls etc. Assuming you’re locking the cams down locally directly with firewall on your router or better yet segregating the cams with VLANs then locking, nothing to worry about even if you come across something like this. If you want an even more hardened approach you can also host your own local DNS and blocking service (something like pi-hole or Ad Guard home and setup client queries and restrictions). Then build your firewall rules to ONLY allow your DNS server and no others. You’d be surprised how certain companies like Lorex are very determined to try and get access Taking the steps I mentioned (if not already using them) keeps things nice and tight.

If you want another layer on top of VLAN or physical segmentation + FW rules + DNS filtering, you could always add an additional layer of content blocking at your browser using UBlock etc for script level alert/block.

For blocking access via process etc on a Mac you can also use Little Snitch as an extra layer.

HTH

 

[Mike A.]

Not saying that there's any malicious intent in this case but the problem with plug-ins is that it's not running on the cams. It's running on the machine that you're using to access the cam. So all of your network restrictions for the cams themselves are kind of moot. Good to do otherwise but they're not in play as this goes other than as the source for the code. That's why I never liked the ActiveX plug-ins for much of anything. You put all of that time effort into securing your cams and network and then run some sketchy plug-in directly on one of your main computers. ; ) Things are a little better now without but I'm surprised that they can launch a service like that. That's kind of big and, at least potentially, could do a lot. But I guess if you grant it permissions then it can. Just as a matter of general good practice I'd avoid doing that.

 

[Wildcat_1]

Not saying that there's any malicious intent in this case but the problem with plug-ins is that it's not running on the cams. It's running on the machine that you're using to access the cam. So all of your network restrictions for the cams themselves are kind of moot. Good to do otherwise but they're not in play as this goes other than as the source for the code. That's why I never liked the ActiveX plug-ins for much of anything. You put all of that time effort into securing your cams and network and then run some sketchy plug-in directly on one of your main computers. ; ) Things are a little better now without but I'm surprised that they can launch a service like that. That's kind of big and, at least potentially, could do a lot. But I guess if you grant it permissions then it can. Just as a matter of general good practice I'd avoid doing that.

That depends on where the machine accessing the cam is of course. If it is also VLAN’d and firewall controlled (since it’s a known device being used to access your cams, so realistically should be) then your network security would still be solid. Also use of things like dual homed NICs would assist. The DNS filtering is also useful though as you can then lock down any rogue dns requests being made through your own DNS server and as mentioned restrict any other DNS server attempting to be used. Apps like Little Snitch can monitor and then block process based access BUT to your point IF you decide to bypass all of this OR just bypass in terms of stating ‘allow xyz process to run’ then Yes, you are creating a potential hole out and that is NOT good

 

[bigredfish]

I like the Delete method as a starting point

 

[Wildcat_1]

I like the Delete method as a starting point

Yep I’m with you there. iF you have a browser and platform dependent on a process such as this and have concerns, block, delete and DO NOT ALLOW

 

[bigredfish]

Pretty common setup= 2 month old Win 11 HP, Bitdefender, Edge and Pale Moon 32 both get prompted for it.
Im guessing it was installed along with the plugin and most would never notice it being there if they didnt monitor running processes. (Thought the new GUI didnt need a plugin?)
My home network is not accessible from outside without OpenVPN.

 

[Wildcat_1]

Pretty common setup= 2 month old Win 11 HP, Bitdefender, Edge and Pale Moon 32 both get prompted for it.
Im guessing it was installed along with the plugin and most would never notice it being there if they didnt monitor running processes. (Thought the new GUI didnt need a plugin?)
My home network is not accessible from outside without OpenVPN.

Good to hear you have precautions in place (knew you would), always best to secure cam networks in this way, VLAN, isolated segments or combination of both. As you know, I'm a Mac guy first, Windows guy second, hence the Little Snitch recommendation for Mac, great for alerting of processes looking to find a way out even though it wouldn't get out On Mac of course and other browser / platforms you won't necessarily need a plugin, again though this is dependent. For example Firefox on Mac, states the need for plugin download for E-PTZ functionality , which of course plugin won't work as its a windows executable ! (part of my feedback to Dahua on the NO PLUGIN NEEDED piece). Everything else on Firefox works without the plugin. On Safari however, everything works (except updating E-PTZ zones) without additional plugin needs at all and no prompt etc.

Going back to the personal DNS server piece, if you guys aren't running one, I definitely recommend it. I have a number of deployments configured that way (obviously in those cases on dedicated high end equipment) and currently just spun up a separate Ad Guard Home on a Raspberry PI (for testing outside of my main config) with custom config, blocklists and client settings. Then I restrict ANY DNS server except this one through strict FW rules (this is on top of the hardened VLAN + HW isolated segmentation and associated FW rules there). You may be surprised at not only what tries to get out (but can't) but how persistent it is. If you're running something like pfsense etc you can also add in ntopng which is a great way of getting a visual on who is doing what and where. As I mentioned I was doing a security demo on a deployment (part of most project rollouts, configurations and overall deployment scenarios) and thought it would be fun to throw in a number of manufacturers in the biz + associated SW middleware platforms. It showed people the importance of hardening your NW and paying attention to not only HW security devices (cams, NVRs etc) but SW both in terms of middleware + end user app. Always have to keep an eye on your privacy and even more so when it comes to security cams whether residential or global deployment. Something I'm glad most people here are aware of and if they're not, we're all here to help with

 

[Mike A.]

That depends on where the machine accessing the cam is of course. If it is also VLAN’d and firewall controlled (since it’s a known device being used to access your cams, so realistically should be) then your network security would still be solid. Also use of things like dual homed NICs would assist. The DNS filtering is also useful though as you can then lock down any rogue dns requests being made through your own DNS server and as mentioned restrict any other DNS server attempting to be used. Apps like Little Snitch can monitor and then block process based access BUT to your point IF you decide to bypass all of this OR just bypass in terms of stating ‘allow xyz process to run’ then Yes, you are creating a potential hole out and that is NOT good

In most cases the machine used to view/control cams won't be on a more restricted portion of the network. It will be a general-use computer and have much greater access to your network and to the outside. Though it usually won't be, a dual-homed machine in that role can hurt more than it helps. While traffic from one side to the other won't hop through on its own (unless set up to do so), something running on that machine does at least potentially have access to both sides. That's a prime target and how things can easily jump from general to secure sides and/or from administrative to process control networks and really shouldn't be permitted in such cases.

DNS restrictions only work where a DNS request is made. Lots of ways that traffic can bypass DNS-based limitations.

There are various process monitoring systems that can be run but most won't won't be or they'll be intrusive or unclear, typically to the point that if broad enough to catch such things they effectively get turned off or ignored. The permission request when the plug-in is installed here is one such system-level restriction and we can see how that works out at a practical level.

What happens as a result doesn't even need an outside connection, If I can install a service to act as a websocket server, then I can install a service to do pretty much anything else. Just as an example, ransomware. Don't need for something like that to establish an outside connection from the compromised machine, That host willl be done and contact will be made in another way. If the compromised machine happens to be dual-homed between open/secure sides, then potentially it jumps that gap.

And again I'm not implying anything about this case in particular or any ill intent on the part of Dahua. Rather, just as a matter of general practice.

 

[Wildcat_1]

In most cases the machine used to view/control cams won't be on a more restricted portion of the network. It will be a general-use computer and have much greater access to your network and to the outside. Though it usually won't be, a dual-homed machine in that role can hurt more than it helps. While traffic from one side to the other won't hop through on its own (unless set up to do so), something running on that machine does at least potentially have access to both sides. That's a prime target and how things can easily jump from general to secure sides and/or from administrative to process control networks and really shouldn't be permitted in such cases.

DNS restrictions only work where a DNS request is made. Lots of ways that traffic can bypass DNS-based limitations.

There are various process monitoring systems that can be run but most won't won't be or they'll be intrusive or unclear, typically to the point that if broad enough to catch such things they effectively get turned off or ignored. The permission request when the plug-in is installed here is one such system-level restriction and we can see how that works out at a practical level.

What happens as a result doesn't even need an outside connection, If I can install a service to act as a websocket server, then I can install a service to do pretty much anything else. Just as an example, ransomware. Don't need for something like that to establish an outside connection from the compromised machine, That host willl be done and contact will be made in another way. If the compromised machine happens to be dual-homed between open/secure sides, then potentially it jumps that gap.

And again I'm not implying anything about this case in particular or any ill intent on the part of Dahua. Rather, just as a matter of general practice.

This of course depends on your deployment. In truly secure deployments you DO identify the machine(s) / devices that are restricted for / to accessing live feed + historic / retained data with associated access controls for those individuals using them. This is expected and required in many global deployments and for me is something I get asked about and work on a lot. However, your point is very valid, this depends on your deployment, threat model, access requirements, use case and associated 'risks' you are then willing / need to take. While residential deployments do not carry the absolute requirements of commercial, government etc, there is a positive rising trend in end users taking more of a proactive approach to their own privacy and security, thats a good thing.

Dual homed machines can cause issues IF not configured correctly and are a ripe target to hackers BUT does give you options for those wanting to go down that path IF you have no other alternatives. They key as I think you and I would agree, is not assuming that this one approach will solve everything. Similarly with DNS restrictions, these are 1 part of an overall plan, never to be seen as all inclusive. They do however form an effective layer (when running your own server as well) that most people do miss or gloss over. Yes they are focused on a key area, targets on a DNS request starting the process but are still effective. Look at Lorex and many other manufacturers that while again not necessarily doing anything nefarious are continually looking to poll out and do this utilizing a DNS request to start. This plus reducing your surface area from a DNS perspective is also a plus. Added bonus is reducing / removing ads, encrypting your requests, potential performance bump etc all of course dependent on how you are configured for DNS already vs taking this approach Like I said, not an all inclusive solution but a key as part of an overall one.

As you said with process control, Yes spoofing a process or another man in the middle type of attack can absolutely be a problem. As we know, a number of security penetrations do come within the local systems and generally are most impactful when a) there are not precautions being taken at all and / or b) when human intervention plays a role (making incorrect decisions to open/access/grant control etc or general lack of awareness). As we know, you'll never protect against everything BUT you can certainly take effective measures to detect, block, alert and ultimately be more aware. Taking decisive action to lockdown completely or just harden an infrastructure (regardless to which level and depth you go) and its associated devices is a choice, one that I'm happy most here do take step towards in order to protect themselves.

As you said, @Mike A. no one is implying that the Dahua plugin is malicious or nefarious in any way, just highlights the potential risks that always exist and reminds us all to pay attention, as @bigredfish did when he saw this. Good conversation on this thread for sure and also highlights the attention of any forum user to the fact that when it comes to your privacy, your security and that of your home and business, be your own advocate for ensuring you take the security of it seriously. That starts with being aware, leads to a block first, allow later mentality and ultimately forms the path to how and where you implement your chosen security design in relation to overall desired goals, needs and associated threat model.

 

[Mike A.]

Yes, it all comes together as part of an overall approach and all of the various pieces are good and play a role. The problem with the plug-ins as I said is that you're letting them circumvent some of that. I was happy to see that we'd gotten away from the damn things with the newer cams that worked (mostly, or should at least) without plug-ins but now looks like we're back to that and they're apparently installing Windows services in the background in a nontransparent way. lol I have pretty much a zero-trust relationship with everything no matter who its from and as much as I like Dahua they don't get a pass to do such things. Not a great approach imo.

Can we get some more detailed response from Dahua as far as why this is required and exactly what it's doing? As @bigredfish posted above, doesn't seem to be required to access and manage the cams in the typical way. I can pretty much guarantee that they're going to need to come up with something that explains it when they start rolling out this new interface to larger customers and they see the same behavior. Might need to rethink how that's done.

 

[Wildcat_1]

Yes, it all comes together as part of an overall approach and all of the various pieces are good and play a role. The problem with the plug-ins as I said is that you're letting them circumvent some of that. I was happy to see that we'd gotten away from the damn things with the newer cams that worked (mostly, or should at least) without plug-ins but now looks like we're back to that and they're apparently installing Windows services in the background in a nontransparent way. lol I have pretty much a zero-trust relationship with everything no matter who its from and as much as I like Dahua they don't get a pass to do such things. Not a great approach imo.

Can we get some more detailed response from Dahua as far as why this is required and exactly what it's doing? As @bigredfish posted above, doesn't seem to be required to access and manage the cams in the typical way. I can pretty much guarantee that they're going to need to come up with something that explains it when they start rolling out this new interface to larger customers and they see the same behavior. Might need to rethink how that's done.

Yes that’s what I’m pushing for with them, supposedly no need for plug-in, yet based on platform, requires plug-in that is not universal and while it appears limited to onscreen activities such as E-PTZ & AI Live events, needs further answers and development towards true plug-in free, browser agnostic GUI

 

[H. Swanson]

Resurrecting this thread. Is the consensus that we should delete the Torch folder? Wouldn't that nullify the use of the plug-in to perform certain functions? I saw the websocketserver messages when logging into my cameras and of course hit Cancel, but I hate having some unpublished app doing god knows what on my main PC.

 

[wittaj]

It seems to be hit or miss on whether any features are reduced.

I'd say get the camera going and dial it in and then delete it and hope you don't have to get into the camera again.

Or if you have an old unused laptop sitting around or buy a used one cheap just use it for the cameras. I had an old Win7 computer collecting dust that I hadn't got rid of and I wiped it clean and use it for only my cameras.

 

[H. Swanson]

It seems to be hit or miss on whether any features are reduced.

I'd say get the camera going and dial it in and then delete it and hope you don't have to get into the camera again.

Or if you have an old unused laptop sitting around or buy a used one cheap just use it for the cameras. I had an old Win7 computer collecting dust that I hadn't got rid of and I wiped it clean and use it for only my cameras.

Is the only way to uninstall the plugin by deleting the folders? I tried finding it through the settings of my browser but to no avail

The other issue is that the plugin is needed to make the NVR UI work more seamlessly, so it's not just about the cameras. Or perhaps the plugin for the NVR is different than the one for the cameras?

 

[wittaj]

You can delete the extensions in the browser, but the files remain on the computer. So if you want them gone, you should do in both places.

The plug-ins are all called the same thing, so when you have all the same camera, you don't have an issue. You might just be "lucky" in that the same plug-in for the NVR is also what works for the cameras you have.

I have so many different models of cams that I constantly have to delete the plugin from the browser if I open up another model. Especially between the 4MP and the 8MP cams, or the old versus new GUI.