{"id":29272,"date":"2022-09-19T13:47:47","date_gmt":"2022-09-19T11:47:47","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=29272"},"modified":"2022-09-19T13:47:47","modified_gmt":"2022-09-19T11:47:47","slug":"defcon30-zoom-vulnerability","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/defcon30-zoom-vulnerability\/29272\/","title":{"rendered":"Eine Zoom-Schwachstelle und der Kampf zwischen Hackern und Entwicklern"},"content":{"rendered":"

Im M\u00e4rz 2020, als sich die ganze Welt gerade mit der Heimarbeit vertraut machte, wurde im Installationsprogramm von Zoom, einem der weltweit wichtigsten Tools f\u00fcr die Fernkommunikation, eine Sicherheitsl\u00fccke<\/a> entdeckt. Der Bug erm\u00f6glichte die Ausf\u00fchrung von beliebigem Code auf Apple-Computern. Zoom hat die Sicherheitsl\u00fccke inzwischen behoben\u2026 zumindest fast. Denn im August 2022 wurde eine \u00e4hnliche L\u00fccke gefunden (sowohl in Bezug auf den Fundort an sich als auch auf die Folgen des Exploits). In diesem Artikel untersuchen wir diese aktuelle Sicherheitsl\u00fccke und versuchen zu erkl\u00e4ren, warum Schwachstellen h\u00e4ufig an derselben Stelle erneut auftreten.<\/p>\n

Wie sieht diese neueste Schwachstelle aus?<\/h2>\n

Das neue Problem im Zoom-Videokonferenz-Client wurde von Forscher Patrick Wardle auf der DEF CON 30 Anfang August dieses Jahres vorgestellt<\/a>. Kurz gesagt, es wurden einige Bugs im automatischen Update-System f\u00fcr den Apple Zoom-Client gefunden. Durch diese Fehler war es theoretisch m\u00f6glich, so genannte Super-User-Rechte zu erlangen. Um die Schwachstelle auszunutzen, musste der Angreifer jedoch bereits physischen Zugriff auf den Computer haben, wenn auch ohne besondere Privilegien oder Rechte. Ein v\u00f6llig unrealistisches Szenario ist dies nicht: So k\u00f6nnte ein Nutzer seinen Rechner beispielsweise w\u00e4hrend der Mittagspause unbeaufsichtigt lassen. Theoretisch k\u00f6nnte die Schwachstelle auch durch Malware ausgenutzt werden.<\/p>\n

Weitere Details<\/h2>\n

Die rechtzeitige Bereitstellung und einfache Installation von Updates sind wichtige Voraussetzungen f\u00fcr jede moderne Software. Im Idealfall sollten Patches installiert werden, ohne dass der Benutzer dies \u00fcberhaupt bemerkt, aber das ist nicht immer m\u00f6glich. Um eine Aktualisierung abzuschlie\u00dfen, m\u00fcssen Programme oder das ganze System oft neugestartet werden. Und ja, wir alle sind genervt von Pop-up-Benachrichtigungen, die uns daran erinnern, ein Programm, ein Betriebssystem oder die Firmware eines Smartphones oder Tablets zu aktualisieren. Doch leider ist dies unerl\u00e4sslich: Denn Updates schlie\u00dfen Sicherheitsl\u00fccken, die sonst gegen Sie verwendet werden k\u00f6nnten. In einigen besonders schwerwiegenden F\u00e4llen m\u00fcssen Sie anf\u00e4llige Software sogar sofort<\/em> vor aktiven Cyberangriffen sch\u00fctzen.<\/p>\n

Die \u00fcbliche Methode zum Aktualisieren einer macOS-Anwendung gleicht der ihrer Erstinstallation: Sie laden die neue Version herunter, f\u00fchren die Datei aus und geben ein Benutzerkennwort ein. Zoom hat versucht, eben diese Prozedur zu vereinfachen: Der Client verbindet sich mit dem Server, l\u00e4dt die neue Version herunter und installiert sie vollautomatisch, ohne dass der Benutzer ein Passwort eingeben muss. Leider wird dieser Prozess der Kommunikation mit dem Server und das Herunterladen und Installieren des Updates nicht immer korrekt ausgef\u00fchrt. Vor zehn Jahren war der Zugriff auf Server ohne Datenverschl\u00fcsselung g\u00e4ngige Praxis, sodass ein potenzieller Angreifer die Aktualisierungsdatei einfach durch Malware ersetzen konnte. Mit der Einf\u00fchrung der Verschl\u00fcsselung wurde dies immer komplizierter. Trotzdem ist es immer noch m\u00f6glich, die Datei nach dem Herunterladen zu ersetzen, wenn sie bereits auf der Festplatte gespeichert, aber noch nicht installiert wurde.<\/p>\n

In der neuesten Version von Zoom (Stand Ende letzten Jahres, als Patrick mit seinen Ermittlungen begann) schien alles in Ordnung zu sein. Der Client verbindet sich \u00fcber einen sicheren Kanal mit dem Update-Server und l\u00e4dt die Datei herunter. Anschlie\u00dfend \u00fcberpr\u00fcft er die Echtheit der Datei (indem er pr\u00fcft, ob sie mit dem Zertifikat des Herstellers signiert ist) und installiert diese. F\u00fcr die Installation fordert die SW tempor\u00e4re Superuser-Rechte vom System an, jedoch ohne, dass der Nutzer ein Passwort eingeben muss.<\/p>\n

\"\"<\/a>

Zitat aus der Pr\u00e4sentation von Patrick Wardle, die den Nutzen der Signierung von Updates zeigt.<\/p><\/div>\n

\u00a0<\/p>\n

Die digitale Signatur ist wichtig. Schlie\u00dflich wird das Programm aus irgendeiner Ecke des Internets auf den Computer des Benutzers heruntergeladen und mit maximalen Privilegien ausgef\u00fchrt. Es muss also sichergestellt werden, dass es sich um das richtige Programm handelt. Ein einfaches F\u00e4lschen der heruntergeladenen Datei wird hierbei nicht funktionieren: Wie in Patricks Pr\u00e4sentation oben gezeigt, f\u00fchrt das Ersetzen der Datei zu einer Fehlermeldung \u2013 das gef\u00e4lschte Update hat keine digitale Signatur, und es ist \u00e4u\u00dferst schwierig, diese zu f\u00e4lschen.<\/p>\n

Leider war das Verfahren zur \u00dcberpr\u00fcfung der digitalen Signatur selbst fehlerhaft. Es funktionierte, indem ein Systemdienstprogramm ausgef\u00fchrt wurde. Dieses zeigte die Parameter der digitalen Signatur des heruntergeladenen Updates an, einschlie\u00dflich einer Zeile, die angab, welches Unternehmen das Zertifikat erhalten hatte:<\/p>\n

Zoom Video Communications, Inc. Developer ID Certification Authority Apple Root CA<\/em><\/p>\n

War diese Zeile bei der Verarbeitung der Ausgabe des Dienstprogramms vorhanden, begann die Installation. Das Problem war, dass aber auch der Name der Datei in der Ausgabe auftauchte. Ein Angreifer k\u00f6nnte also theoretisch ein sch\u00e4dliches Update namens \u201eZoom Video Communications, Inc. Developer ID Certification Authority Apple Root CA.pkg<\/em>\u201c anstelle der Standarddatei \u201eZoomUpdate.pkg<\/em>\u201c erstellen. Das w\u00fcrde ausreichen, um das \u00dcberpr\u00fcfungsverfahren zu t\u00e4uschen: Die erforderliche Zeile ist vorhanden, also muss<\/em> die Datei legitim sein \u2013 auch wenn es eigentlich die falsche Datei ist und die magischen W\u00f6rter an einer vollkommen falschen Stelle stehen!<\/p>\n

Das hei\u00dft, ein Angriff k\u00f6nnte folgenderma\u00dfen aussehen: Das Update-Validierungsverfahren wird eingeleitet (was nicht schwer ist), dann wird das legitime Update heruntergeladen, durch Malware ersetzt und umbenannt, um den fehlerhaften Zertifikatsvalidierungsprozess zu \u00fcberlisten. Die Schaddatei wird mit Systemprivilegien ausgef\u00fchrt und der Computer gehackt!<\/p>\n

Am 20. Dezember 2021 wurde jedoch ein Zoom-Update ver\u00f6ffentlicht, das diesem Angriffsvektor ein Ende setzte. Die \u00c4nderung war mehr als simpel: Nach dem Download wurde eine Umbenennung der Datei erzwungen. Patrick Wardle war jedoch in der Lage, den Angriff zu modifizieren: Wenn Zoom erst ab Version 5.9.0 sicher ist, was w\u00e4re, wenn der Client auf eine \u00e4ltere Version \u201eaktualisiert\u201c w\u00fcrde? Und genau das funktionierte: Das alte Update verf\u00fcgte \u00fcber ein legitimes digitales Zertifikat, und die Version wurde w\u00e4hrend der Installation nicht \u00fcberpr\u00fcft.<\/p>\n

Wo liegt das Problem?<\/h2>\n

Die Forschungsergebnisse von Patrick Wardle zeigen, wie wichtig es ist, die Bereitstellung und Installation von Updates zu sichern. Dar\u00fcber hinaus zeigt die Geschichte dieses Bugs ganz offensichtlich, wie Softwareentwickler oft versuchen, ein Problem durch eine einfache \u00c4nderung zu l\u00f6sen, ohne einen genaueren Blick auf die Details zu werfen. Zun\u00e4chst (noch bevor Wardle das Problem an Zoom meldete), im Dezember 2021, verteidigten sie die einfachste Version eines Angriffs mit trivialer Dateisubstitution und Umgehung der Zertifikatsvalidierung. Nachdem die Schwachstelle im April 2022 gemeldet wurde, schlossen sie die Downgrade-Option \u2013 die Installation einer \u00e4lteren, anf\u00e4lligeren Version von Zoom \u00fcber den Standard-Mechanismus zur Bereitstellung von Updates. Aber erst im Juli 2022, sechs Monate nach dem Bericht von Wardle, wurde der Mechanismus zur Validierung digitaler Zertifikate repariert.<\/p>\n

Das Problem wurde dadurch trotzdem nicht vollst\u00e4ndig aus der Welt geschafft. Zwar wurden die beiden einfachsten Angriffsmethoden, das Ersetzen der Aktualisierungsdatei durch Malware und das Herabstufen auf eine anf\u00e4lligere Version aus dem Arsenal der M\u00f6chtegern-Cyberkriminellen entfernt, aber es gab noch ein weiteres Problem: Eine mit Superuser-Rechten ausgef\u00fchrte Update-Datei konnte von jedem, der Zugriff auf den Computer hatte, ge\u00e4ndert werden! Ein Angreifer musste nur den richtigen Weg finden, im richtigen Moment eine sch\u00e4dliche Datei in das Zoom-Installationsprogramm zu schleusen: nachdem die digitale Signatur validiert wurde, aber bevor die Installation begann. Und es hat tats\u00e4chlich funktioniert. Als Patrick Wardle seine Ergebnisse auf der DEF CON 30 im August 2022 vorstellte \u2013 acht Monate nachdem Zoom \u00fcber das Problem informiert wurde \u2013 war die Schwachstelle noch immer nicht vollst\u00e4ndig gepatcht! Erst am 17. August, f\u00fcnf Tage nach Patricks Bericht, setzten die Entwickler dem Problem endlich ein Ende.<\/p>\n

\u00dcber Hacker & Entwickler<\/h2>\n

Wenn man den Bericht von Patrick Wardle liest, fragt man sich unweigerlich, wie das sein kann. Wie kann es zu solch kindischen Schwachstellen in kritischen Softwareteilen kommen, und warum werden Sicherheitsl\u00fccken, selbst bei Meldung eines Problems, erst acht Monate sp\u00e4ter und beim dritten Versuch geschlossen? Wir wollen die Entwickler nicht zu Unrecht der Inkompetenz beschuldigen. In allen Programmen tauchen gelegentlich Bugs und Fehler auf. Denn auch im Bereich der Programmierung ist Irren menschlich.<\/p>\n

Vielleicht liegt es daran, dass White-Hat-Hacker (die ihre Ergebnisse an die Hersteller melden) und Cyberkriminelle (die Schwachstellen ausnutzen, um Nutzer anzugreifen und Profit zu machen) andere Priorit\u00e4ten haben als Softwareentwickler. Bei der Entwicklung eines Programms ist es wichtig, dass es zahlreiche verschiedene Aufgaben korrekt ausf\u00fchrt. Dabei ist oberste Priorit\u00e4t, die Nutzer nicht aus ihrer Komfortzone zu locken, was im Falle von Zoom eine gute Kommunikationsqualit\u00e4t und Kompatibilit\u00e4t mit verschiedenen Betriebssystemen und Tausenden von alten und neuen Ger\u00e4ten bedeutet. Ein Krimineller hingegen muss lediglich einen einzigen Bug finden, der f\u00fcr schmutzige Tricks missbraucht werden kann. Stellen Sie sich nun vor, jemand informiert Sie \u00fcber eine Schwachstellen. Ja, sie muss gepatcht werden, aber ohne das empfindliche System der Client-Server-Software zu zerst\u00f6ren. Nat\u00fcrlich m\u00f6chte der Entwickler das Problem mit sehr geringem Aufwand l\u00f6sen. Aber das ist leider oft nicht genug.<\/p>\n

Programme werden mit jedem Patch nach und nach sicherer. Man kann nicht alle Probleme l\u00f6sen und so die perfekte Anwendung erstellen. Oder besser gesagt, man kann es schon, aber nur, wenn man bei Null anf\u00e4ngt. Aber einige kritische Elemente sollten so gut wie m\u00f6glich instandgehalten werden, und das System zur Bereitstellung von Updates ist definitiv eines davon. Wir, die Nutzer, m\u00fcssen den Programmen, die wir auf unseren Computern installieren, vertrauen k\u00f6nnen. Und in diesem Sinne ist die Geschichte der Zoom-Schwachstellen ein positives Beispiel f\u00fcr die Zusammenarbeit eines unabh\u00e4ngigen Forschers und eines Entwicklers bei der L\u00f6sung eines Problems. Sie zeigt deutlich die verantwortungsvolle Haltung des Entwicklers.<\/p>\n

Wir beenden diese Geschichte mit einem wichtigen Reminder: Malware gelangt oft bei der Erstinstallation von Software auf einen Computer. Daher ist es wichtig, darauf zu achten, dass Hilfsprogramme nur aus offiziellen Quellen bezogen werden; d. h. nach M\u00f6glichkeit aus offiziellen App-Stores. Unter keinen Umst\u00e4nden sollten Programme von verd\u00e4chtigen Websites heruntergeladen werden. Andernfalls besteht die Gefahr, dass Ihre Daten durch sehr einfache Hacking-Methoden gestohlen werden \u2013 und dazu ist meist nicht einmal der Exploit ausgekl\u00fcgelter Sicherheitsl\u00fccken in offizieller Software notwendig.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Einblick in die DEF CON 30: Schwachstelle in Zoom f\u00fcr macOS.<\/p>\n","protected":false},"author":665,"featured_media":29275,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1848,3107,3108],"tags":[109,1585,903,1498,3994],"class_list":{"0":"post-29272","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-apple","11":"tag-def-con","12":"tag-macos","13":"tag-schwachstellen","14":"tag-videokonferenz"},"hreflang":[{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/defcon30-zoom-vulnerability\/29272\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/defcon30-zoom-vulnerability\/24561\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/20027\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/27010\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/defcon30-zoom-vulnerability\/24918\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/25259\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/defcon30-zoom-vulnerability\/27616\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/defcon30-zoom-vulnerability\/33925\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/defcon30-zoom-vulnerability\/11012\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/45420\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/defcon30-zoom-vulnerability\/19410\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/defcon30-zoom-vulnerability\/20011\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/defcon30-zoom-vulnerability\/25412\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/defcon30-zoom-vulnerability\/30967\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/defcon30-zoom-vulnerability\/30663\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.de\/blog\/tag\/schwachstellen\/","name":"Schwachstellen"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/29272","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/comments?post=29272"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/29272\/revisions"}],"predecessor-version":[{"id":29274,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/29272\/revisions\/29274"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media\/29275"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media?parent=29272"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/categories?post=29272"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/tags?post=29272"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}