Zoom für Mac patcht heimtückischen „spy-on-me“-Bug – jetzt aktualisieren!

Das beliebte und allgegenwärtige (Software ist nicht immer beides!) Cloud-Meeting-Unternehmen Zoom hat kürzlich einen Hoppla-das-sollte-nicht-passieren-Bug in der Mac-Version seiner Software angekündigt.

Das Sicherheitsbulletin ist verzeihlicherweise im typischen Stakkato- und Jargon-getränkten Stil von Bug-Hunter geschrieben, aber die Bedeutung ist ziemlich klar.

Der Fehler ist gekennzeichnet CVE-2022-28762, und ist detailliert in Zoom-Bulletin ZB-22023:

Wenn der Rendering-Kontext des Kameramodus als Teil der Zoom App Layers-API aktiviert wird, indem bestimmte Zoom-Apps ausgeführt werden, wird vom Zoom-Client ein lokaler Debugging-Port geöffnet.

Wohin möchten Sie heute gehen?

Ein „Debugport“ bezieht sich normalerweise auf eine lauschende Netzwerkverbindung, normalerweise ein TCP-Socket, der Debugging-Anforderungen verarbeitet.

Auf die gleiche Weise, wie ein E-Mail-Server normalerweise TCP-Port 25 abhört und darauf wartet, dass entfernte E-Mail-Clients sich über das Netzwerk „einwählen“ und die Erlaubnis anfordern, eingehende Nachrichten zuzustellen, lauschen Debugging-Ports auf einem Port ihrer eigenen Wahl (oft konfigurierbar, obwohl manchmal nur auf undokumentierte Weise) für eingehende Verbindungen, die Debug-Befehle ausgeben möchten.

Im Gegensatz zu einem E-Mail-Server, der Anfragen bezüglich der Nachrichtenzustellung (z MAIL FROM und RCPT TO) bieten Debugging-Verbindungen normalerweise eine viel intimere Art der Interaktion mit der App, mit der Sie sich verbinden.

Debugging-Ports ermöglichen es Ihnen im Allgemeinen nicht nur, sich über die Konfiguration und den internen Zustand der App selbst zu informieren, sondern auch Befehle direkt an die App zu erteilen, einschließlich der Art von sicherheitsverringernden Befehlen, die normalen Benutzern nicht zur Verfügung stehen über die normale Benutzeroberfläche.

Ein E-Mail-Server zum Beispiel lässt Sie normalerweise eine Nachricht an seinen TCP-Port für einen Benutzernamen Ihrer Wahl senden, aber er lässt Sie keine Befehle senden, die den Server selbst neu konfigurieren, und Sie können keine geheimen Informationen extrahieren B. Serverstatistiken oder Nachrichten anderer Personen.

Im Gegensatz dazu sind das genau die Art von „Features“, die Debugging-Ports normalerweise zulassen, sodass Entwickler das Verhalten ihrer App optimieren und überwachen können, während sie versuchen, Probleme zu beheben, ohne durch die normale Benutzeroberfläche gehen zu müssen.

(Sie können sehen, wie diese Art von „Seitenkanal“ in den Kern einer Anwendung besonders praktisch wäre, wenn Sie versuchen, die Benutzeroberfläche selbst zu debuggen, da die Verwendung der Benutzeroberfläche zum Debuggen der Benutzeroberfläche mit ziemlicher Sicherheit stören würde mit genau den Messungen, die Sie machen wollten.)

Insbesondere ermöglichen Debugging-Ports normalerweise, dass Sie eine Art „interne Ansicht“ der App selbst erhalten, wie z. das Erfassen von Datenschnappschüssen, die vertrauliche Daten wie Passwörter und Zugriffstoken enthalten könnten; und Auslösen von Audio- oder Videoaufnahmen, ohne den Benutzer zu warnen…

…alles ohne sich überhaupt in die App oder den Dienst einzuloggen.

Mit anderen Worten, Debugging-Ports sind ein notwendiges Übel für die Verwendung während der Entwicklung und des Testens, sollten jedoch aufgrund der offensichtlichen Sicherheitslücken, die sie einführen, während der normalen Nutzung der App nicht aktiviert werden oder idealerweise sogar aktivierbar sein.

Kein Passwort erforderlich

Grob gesagt, wenn Sie Zugriff auf den TCP-Port haben, auf dem der Debugger lauscht, und Sie eine TCP-Verbindung zu ihm herstellen können, ist dies die gesamte Authentifizierung, die Sie benötigen, um die App zu übernehmen.

Aus diesem Grund werden Debugging-Ports normalerweise nur unter sorgfältig kontrollierten Umständen aktiviert, wenn Sie wissen, dass Sie es einem Entwickler tatsächlich ermöglichen möchten, direkt in der Anwendung herumzuwandern und sich an einem praktisch unregulierten und potenziell gefährlichen Supermachtzugriff zu erfreuen .

Tatsächlich werden viele Softwareprodukte absichtlich in zwei verschiedenen Varianten erstellt: ein Debug-Build, bei dem das Debuggen auf Wunsch eingeschaltet werden kann, und ein Release-Build, bei dem die Debugging-Funktionen vollständig weggelassen werden, sodass sie überhaupt nicht aktiviert werden können, sei es durch Unfall oder Absicht.

Die Android-Telefone von Google verfügen über einen Debug-Modus, in dem Sie ein USB-Kabel anschließen und von Ihrem Laptop aus über die sogenannte ADB (kurz für) in das Telefon eingreifen können (wenn auch nicht mit voller Root-Leistung). Android-Debug-Bridge. Um das Debuggen überhaupt zu aktivieren, müssen Sie zunächst auf klicken Einstellungen > Über Telefon > Buildnummer siebenmal (wirklich!) hintereinander. Nur dann erscheint die Option zum Einschalten des Debugging überhaupt in den Menüs, wo Sie es aktivieren können Einstellungen > System > Fortgeschrittener > Entwickleroptionen > USB-Debugging. Wenn Sie dann eine Verbindung herstellen und versuchen, von Ihrem Laptop aus eine Verbindung herzustellen, müssen Sie die Verbindung über ein Warn-Popup auf dem Telefon selbst autorisieren. Sie können dies sicherlich absichtlich tun, wenn Sie physischen Zugriff auf ein entsperrtes Telefon haben, aber es ist unwahrscheinlich, dass dies versehentlich geschieht.

Für zusätzliche Sicherheit werden Debugging-Ports oft so eingerichtet, dass sie keine Verbindungen akzeptieren, die von anderen Computern kommen (technisch gesehen lauschen sie nur auf der „localhost“-Schnittstelle).

Dies bedeutet, dass ein Angreifer, der versucht, eine fälschlicherweise aktivierte Debugging-Schnittstelle zu missbrauchen, zuerst auf Ihrem Computer Fuß fassen muss, z. B. eine Art Proxy-Malware, die selbst Verbindungen über das Internet akzeptiert und dann ihre Netzwerkpakete an die „localhost“-Netzwerkschnittstelle weiterleitet.

Trotz der Notwendigkeit eines lokalen Zugriffs im Fall von CVE-2022-28762 gab Zoom diesem Fehler jedoch einen CVSS-„Schweregrad“ von 7.3/10 (73 %) und eine Dringlichkeitsbewertung von High.

Lokale TCP-Netzwerkverbindungen sind normalerweise so konzipiert, dass sie über Benutzer- und Prozessgrenzen hinweg funktionieren, sodass ein Angreifer nicht als Sie (oder als Administrator) angemeldet sein muss, um diesen Fehler zu missbrauchen – jeder Prozess, sogar ein Programm, das unter einer sehr eingeschränkten Gastkonto, kann Sie möglicherweise nach Belieben ausspionieren.

Da Softwarebefehle, die über einen Debugging-Port ausgegeben werden, normalerweise unabhängig von der regulären Benutzeroberfläche einer App funktionieren, würden Sie außerdem wahrscheinlich keine Anzeichen dafür sehen, dass Ihre Zoom-Sitzung auf diese Weise gekapert wurde.

Wenn ein Angreifer die App über konventionellere Mac-Fernsteuerungskanäle wie Screen Sharing (VNC) aktiviert, hätten Sie zumindest eine Chance, den Angreifer zu entdecken, der Ihren Mauszeiger bewegt, auf Menüschaltflächen klickt oder Text eingibt …

…aber über eine Debugging-Schnittstelle, die im Wesentlichen eine absichtliche Hintertür ist, können Sie sich glücklicherweise nicht bewusst sein (und vielleicht sogar nicht erkennen), dass ein Angreifer Sie sehr persönlich mit Ihrer Webcam und Ihrem Mikrofon ausspioniert hat.

Was ist zu tun?

Glücklicherweise hat das eigene Sicherheitsteam von Zoom entdeckt, was wir für einen Build-Time-Fehler halten (eine Funktion, die aktiviert blieb, die hätte unterdrückt werden sollen) und die fehlerhafte Mac-Software umgehend aktualisiert.

Aktualisieren Sie auf Ihren macOS Zoom Client Version 5.12.0 oder höher und der Debugging-Port bleibt geschlossen, wenn Sie Zoom verwenden.

Gehen Sie auf einem Mac zum Hauptbildschirm zoom.us Menü und wählen Sie Check for Updates... um zu sehen, ob Sie die neueste Version haben.

---