WebSocketServer.exe?

wittaj

IPCT Contributor
Joined
Apr 28, 2019
Messages
24,451
Reaction score
47,588
Location
USA
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

Known around here
Joined
Sep 5, 2016
Messages
17,029
Reaction score
47,512
Location
Floriduh
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

IPCT Vendor
Joined
Nov 8, 2016
Messages
8,262
Reaction score
23,727
Location
HONGKONG
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.
 
Last edited:

bigredfish

Known around here
Joined
Sep 5, 2016
Messages
17,029
Reaction score
47,512
Location
Floriduh
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.
 

Wildcat_1

Known around here
Joined
Dec 9, 2018
Messages
2,047
Reaction score
5,869
Location
US
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
 
Last edited:

Mike A.

Known around here
Joined
May 6, 2017
Messages
3,825
Reaction score
6,377
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

Known around here
Joined
Dec 9, 2018
Messages
2,047
Reaction score
5,869
Location
US
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

Known around here
Joined
Sep 5, 2016
Messages
17,029
Reaction score
47,512
Location
Floriduh
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

Known around here
Joined
Dec 9, 2018
Messages
2,047
Reaction score
5,869
Location
US
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 :)
 
Last edited:

Mike A.

Known around here
Joined
May 6, 2017
Messages
3,825
Reaction score
6,377
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.
 
Last edited:

Wildcat_1

Known around here
Joined
Dec 9, 2018
Messages
2,047
Reaction score
5,869
Location
US
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.

Known around here
Joined
May 6, 2017
Messages
3,825
Reaction score
6,377
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

Known around here
Joined
Dec 9, 2018
Messages
2,047
Reaction score
5,869
Location
US
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

Getting the hang of it
Joined
Nov 3, 2023
Messages
117
Reaction score
86
Location
Tennessee
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

IPCT Contributor
Joined
Apr 28, 2019
Messages
24,451
Reaction score
47,588
Location
USA
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

Getting the hang of it
Joined
Nov 3, 2023
Messages
117
Reaction score
86
Location
Tennessee
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?
 
Last edited:

wittaj

IPCT Contributor
Joined
Apr 28, 2019
Messages
24,451
Reaction score
47,588
Location
USA
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.
 
Top