Has always been in place,
The webserver is nixed - stupid design. The "Do you want to open in a different app" isn't a bad user experience, it's a good warning that you are leaving the browser...
Zoom Video Communications, whose web conferencing service is used by millions, is under fire for installing a hidden web server on Macs in order to bypass user consent when joining a meeting. Researcher Jonathan Leitschuh, a member of the security team at Gradle Inc, investigated how the Zoom client opens automatically when …
This. Two of my requirements when I'm buying a computer are: that it doesn't have a built-in camera, and that it doesn't have a built-in microphone. I have occasionally had to purchase machines that had one or the other -- but in that case, a little work with a sidecutter solves the problem.
If that's an option, yes, but the last time I did this, there weren't any cables to unplug.
"went you let the machine go to some other home"
I don't really do that. The only time I've let working machines go was donating antique computers to a museum. Otherwise, if they're working, then I can find a use for them. If they're not, then I cannibalize them for parts and give the parts I don't want my local electronics recycler.
Would be nice if the manufacturers could be convinced to employ some basic precautions such as:
A shutter that covers the camera and possibly disconnects the microphone with a switch.
Alternatively, allow the camera (assuming it's installed in a tablet or the top of a laptop screen) to pivot downwards by 90 degrees, effecting the same.
Power light should be directly linked to camera sensor power, with no chance of being disabled via software.
A shutter that covers the camera and possibly disconnects the microphone with a switch.The weird thing is, this is how laptops used to work.
In 2004, or maybe 2003, I bought a Dell laptop. On the chassis it had three physical slider switches to enable/disable:
1) WiFi (yay 802.11a/b/g)
If you enable the switch, then software can enable/disable that service, but only if the switch was set to 'on' for that function. If set to 'off' then the software setting was irrelevant, it was off.
I'm not sure why these hardware switches were removed - actually, I lie, I do know, cost, money, profit. But they never should have removed them.
I never got the point of taping over or installing a shutter on your webcam. If my laptop was compromised to that degree I have far greater concerns than hackers watching me masturbate. Besides, the microphones will always be more incriminating and you can't exactly tape over those.
1) This article shows that it is extremely likely that there are other bugs lurking which make taking control of the webcam easier than many other compromises.
2) I spend much of my day on conference calls, many of them external and so using random conferencing apps chosen by other people. I don't want my camera enabled if their chosen app does not have a safe default (as, it appears, Zoom does not).
The point is, getting your laptop rooted is painful, and for some of us, embarrassing. Having the experience recorded raises the stakes to humiliating, and potentially dangerous. You seem to be in one of the parts of the world where being caught whacking is your main concern.
Not everyone is so lucky, and getting trolled is just the tip of the iceberg. People can face blackmail, stalking, assault, kidnapping, and arrest by less than merciful governments. Real consequences that a piece of an old post-it note can provide real protection from.
That said I agree that the alert lite should be hardwired to the camera leads, not switched on by software(looking at you Apple, never had to tape a webcam till I worked at an Apple shop, and my ipad dosen't even have a light)
Two clicks are easy for you, (being presumably someone who's relatively computer savvy), but if you've ever tried setting up a video conference with a non-technical user you'll start to understand why they tried to make the whole process as automatic as possible.
With some people, if there's any way they can possibly screw something up, they will, and there's been times when I'd commit physical violence to remove the need for a user to have to click on something.
If I understand correctly what you mean, then no.
In the scenario described, the malicious traffic on tcp port 19421 isn't going through your site perimeter (by which I assume you mean a router at the edge of your network). It's going over the loopback device on the individual Mac being attacked. You're not going to block this in a router.
The attack goes roughly like this:
- I, a person who has once used Zoom, visit an ordinary website like https://www.evilbadguys.com/evil.html
- that website has a bit of HTML (or a bit of JS that generates HTML) in it like `<img src="http://localhost:19421/evil_bad_url">`
- now my browser generates a HTTP request to localhost:19421
- some badly written software running on my Mac is listening on :19421 for incoming connections, and does something unwise in response to that HTTP request, causing me to get spied on
- so the HTTP request which causes the bad thing to happen is going from my machine to my machine, just over the loopback device, without going through the perimeter at any point
- the only traffic that went through the perimeter was on tcp ports 80 or 443, because this was triggered by an ordinary website
Blocking connections to tcp 19421 at your perimeter isn't going to hurt anything but it also isn't going to fix anything. A firewall on the Mac itself which blocks traffic to port on the loopback device could block it. I think the firewall that comes with Mac OS can do that (but I can't offhand remember if loopback traffic skips it. I would expect not.).
"Would blocking :19421 at the perimeter be enough? Or would this app shift ports if it couldn't find the mothership?"
It's a bit confusing at first but if you read carefully you'll see that this has nothing to do with the perimeter. The web server is on the same machine as the browser and client, and the traffic never hits the network at all. This is not a web server that can be contacted from anywhere else, and is not about reaching any mothership, so blocking access to this (or another) port won't have any effect. In any case the appropriate mitigation is described in the article.
All that said, my advice would be to remove Zoom, apply the fix described to also remove the web server, and place Zoom and the people behind it on the list of people whose products you'll never use because they've shown reckless disregard for your safety. As a general best practice unrelated to Zoom, you should keep an opaque lens cap/slider/etc, if equipped, or black tape over any camera when not in use.
I've used it twice, and I removed its client immediately afterwards.
Personally, I found getting WebRTC to work to take a bit of effort the first time (mainly to do with figuring out where the permission settings were in Chromium), but the solutions I use now were worth the trouble - nothing I like better than services that are as close to natively supported as possible.
I am wary of extra software and plugins etc etc - you never know who they're from and where they've been - plus Zoom is a US outfit, and we know just how keen that nation's intelligence services are on "assistance" from its locals to, er, "widen their view".
I use Zoom, Skype for Business, and WebEx regularly at work. They are all frustrating and problematic, each in their own special way. Between the three, though, my experience is that Zoom brings the least pain with it.
The problems with these applications are such that I really try to avoid using any of them whenever I can get away with it. Unless screen-sharing is required, none of them are better than the old-fashioned POTS conference call.
I signed up with Zoom when I clicked to be reminded of a webinar. It never reminded me. Some service. I don't seem to have it installed and did not give permission to install anything (I'm not that incautious). If it had started automatically and joined me in I would have been annoyed and sought the cause as I have autoplay disabled.
Honestly makes me wonder how zoom can know enough to get WebRTC to work, but dont understand how websockets work??
Maybe its some mac specific security (blanket) feature im unaware of, but i would have thought a more graceful and less problematic way of acheiving this would be to have the zoom link hit zooms servers, read the client ip of the incoming request, look up the client id against registered agents possibly with an additional unique id to handle nat behind routers, and fire start meeting request at the agent.... ya know like how RPC has worked for over 20+ years just with a new fangled transport
This post has been deleted by its author