Visavid — Datensicherheit im Warteraum
Ich habe eine Sicherheitslücke in der primär in bayerischen Schulen und von Steuerberater*innen eingesetzten Videokonferenz Software Visavid gefunden, die es ermöglicht, geschützte Videokonferenzen nur mithilfe der Raumnummer unbemerkt aufzurufen und mitzuschneiden.
Am 1. Juli bin ich über diese Pressemitteilung des bayerischen Kultusministeriums gestolpert. Dort wird angekündigt, dass sie eine Videokonferenzensoftware namens “Visavid” beschafft haben. Die dort an Schulen Microsoft Teams aufgrund der bestehenden Datenschutzproblematik ersetzen soll.
Ich wurde dabei etwas hellhörig, weil ich von dieser Software noch nie gehört habe und auch nicht verstehe, warum man in der aktuellen Situation nicht einfach auf verfügbare Open Source Software wie Jitsi oder Big Blue Button gesetzt hat.
Also fing ich an, ein bisschen zum Visavid-Hersteller Auctores zu recherchieren. Dabei ist mir einerseits aufgefallen, das es natürlich — was soll man in Bayern auch anderes erwarten — Verstrickungen zwischen Auctores und der CSU gibt und sich auch die Freien Wähler sehr über die Vergabe freuten. Andrerseits fand ich heraus, dass sie nicht wirklich eine eigene Videokonferenz Software entwickelt, sondern nutznießerisch und ohne darauf hinzuweisen auf die Open Source Software Janus aufsetzen.
Dabei wirkte das, was ich sehen konnte, etwas verbastelt und eben genau so, wie ich mir ein Videokonferenzsystem, das mal schnell von einer kleinen Agentur gehackt wurde, vorstellen würde. Also evaluierte ich die Lösung genauer und wie zu erwarten war, ließ der erste Fund einer Sicherheitslücke nicht lange auf sich warten.
Es gibt in Visavid die Möglichkeit, einen Link zu teilen, bei dem Teilnehmer*innen bei der Moderator*in der Videokonferenz anfragen können, ob sie dieser beitreten dürfen. Bis die Moderator*in eine Person als Teilnehmer*in akzeptiert, befindet sich diese in einem Warteraum. Ein sehr unspektakuläres Feature, welches auch bei vielen anderen Lösungen wie z.B. Zoom oder Jitsi existiert.
Das Spannende ist allerdings, wie diese Funktion implementiert wurde. Der User erhält dabei als erstes über einer Programmierschnittstelle einen sogenannten JWT-Token. Das ist ein digitaler Schlüssel, der eine Person gegenüber dem Videokonferenzserver als Teilnehmer*in ausweist.
Mit diesem Token kann er dann ein Verbindung zum Videokonferenzserver herstellen und eine Anfrage zum Betreten des Raumes stellen und wird dann ggf. vom Moderator zugelassen — soweit die Theorie. In der Praxis kann dieses Token allerdings auch ohne die Zustimmung des Moderators auch für allerlei andere Dinge benutzt werden, da der Token den User ja bereits als Teilnehmer*in der Videokonferenz ausweist.
Darüber kann man z.B. die Liste der Teilnehmenden abrufen, die Videostreams der anderen Teilnehmenden mitschneiden, ihnen Chatnachrichten schicken oder alle geteilten Dateien und Boards ansehen.
Ohne das die Teilnehmenden davon etwas mitbekommen.
Hier findet ihr ein PoC-Script, für die Attacke.
Das ganze funktioniert mit Kenntnis der Raumnummer, bei Räumen die über einen Warteraum betreten werden und bei Räumen mit Pin, wenn man Kenntnis über diese erlangt. Diese sind aber entweder eine Google-Suche oder 9999 Kombinationen durchprobieren weit entfernt.
Wie schon zoombombing gezeigt hat, ist das Verbreiten von Zugangsdaten von Videokonferenzen über das Internet einfach nicht sinnvoll zu verhindern. Deshalb wurden ja Konzepte wie Warteräume, … entwickelt. Nur leider im Falle von Visavid so schlecht umgesetzt, dass sie den Teilnehmenden keinerlei Sicherheit bieten.
Meldung der Sicherheitslücke
- 4. Juli — 13:20 ich informiere das Cert Bund, das Cert Bayern sowie den Hersteller über die Sicherheitslücke
- 5. Juli — 9:17 ich habe eine Eingangsbestätigung vom CERT Bayern erhalten
- 5. Juli —11:22 ich habe dem Hersteller und dem CERT eine aktualisierte Version des PoC Scriptes übermittelt und mich nach einer Timeline erkundigt.
- 5. Juli — 18:32 der Hersteller hat mich darüber informiert, das an einem Fix gearbeitet wird und dieser vermutlich am Mittwoch auf die Produktivsysteme ausgerollt wird
- 7. Juli — 09:45 die Lücke wurde geschlossen. Es wurde ein neue Token-Rolle “PARTICIPANT_PENDING” eingeführt
- 8. Juli — 10:00 das Kultusministerium bezeichnet meine Arbeit als einen “Hackerangriff”,
- 8. Juli — 12:43 der Hersteller Informiert via Twitter über die Lücke
- 9. Juli 07:00 BR berichtet über die Sicherheitslücke
- 9. Juli 11:00 der Hersteller veröffentlicht eine Pressemitteilung in der er die Sicherheitslücke weitestgehend eingesteht.
Außerdem Berichten:
Das alles ist jetzt nicht super unerwartet. Also in einem Stück proprietärer Software eines kleinen Herstellers eine solche Sicherheitslücke zu finden. Eine Lücke, die davon zeugt, das sie anscheinend nicht mal über Basiswissen im Bereich IT-Security verfügen.
Das Problem ist, das sie vom Land Bayern eingekauft, eingesetzt und sogar von Datenschützer*innen befürwortet wird. Und dabei anscheinend nichtmal auf die Idee kam, die Software vor Abschluss eines 3-Jahresvertrags aus einer Security Perspektive zu evaluieren.
Das sie laut Website des Betreibers angeblich sogar erfolgreich gepentestet wurde (was da getestet wurde, schreiben sie natürlich nicht). Und dass alles, obwohl eigentlich offensichtlich ist, das so eine Lösung nicht sicher sein kann, wenn selbst bei den größten Anbietern der Welt öfters mal krasse Sicherheitslücken gefunden werden.
Und nein diese Software wird nicht sicher, weil diese eine Sicherheitslücke behoben wurde. Das gesamte System ist nämlich eine einzige Sicherheitslücke und z.B. max. 4-Stellige Pins für Räume ist nur eines von vielen weiteren Problemen.
Das grundlegende Problem hier ist die Logik, nach der der Staat heute Softwareprodukte aussucht und einkauft. Es geht in dem Prozess primär darum, nach häufig von Juristen erstellten Compliancekriterien ein Produkt auszuwählen. Ob das dann tatsächlich sicher ist, ist erstmal zweitrangig. Gerade in diesem Fall wäre es einfach gewesen, auf eine Open Source Lösung zu setzen, diese selbst zu betreiben und Maintainer bei der Implementierung von neuen Features zu unterstützen. Stattdessen hat man sich eine Ausschreibung zugeschnitten auf kleine Anbieter entschieden, die sich schon gut mit der öffentlichen Vergabe/Förderung auskennen.
Ich weiß nicht, was ich an diese Situation nun schlimmer finden: Die bayerische Arroganz, in der das Kultusministerium davon ausgeht, das ein kleine Agentur eine sinnvolle Alternative zu den großen Anbietern und Open Source Projekten bieten kann. Oder die Leichtfertigkeit, in der hier mit der Datensicherheit der Schülerschaft eines ganzen Bundeslandes umgegangen wird und das alles nur für ein bisschen antiamerikanischen Populismus.
Die Antwort auf große Monopolisten, die sich nicht an deutsches Datenschutzrecht halten, darf nicht sein, auf noch schlechtere Lösungen von Anbietern zu setzen, die höchstens auf dem Papier die datenschutzrechtlichen Anforderungen erfüllen. Stattdessen kann eine Unabhängigkeit von Monopolisten nur langfristig sinnvoll funktionieren, wenn man auf offene Produkte setzt und diese gemeinsam mit den Communities, die an diesen oft schon über ein Jahrzehnt arbeiten, weiterentwickelt.
Mit der heute vorherrschenden immer umfassenderen Externalisierung der digitalen Basisinfrastruktur der Verwaltung und der konsequenten Weigerung zum behördeninternen Wissensaufbau werden diese Art von Probleme in der Zukunft immer größer werden. Eigentlich ist es mittlerweile schon egal, ob die Daten der Schüler*innen bei Microsoft oder einem DSGVO konformen Anbieter liegen. Die Verwaltung hat einfach nicht die Kompetenz sie zu schützen.
PS. Liebes Kultusministerium, wäre das ein Hackerangriff gewesen, hättet ihr jetzt ein richtig großes Problem (also noch größer als jetzt). Wie wäre es denn mal mit ein Dankeschön für die ehrenamtliche Arbeit anstatt der Diskreditierung von Sicherheitsforschung?
Wenn ihr meine zivilgesellschaftliche Arbeit zu Themen wie z.B. Verwaltungsdigitalisierung, Sicherheitsforschung und Open Data unterstützen wollt, dann könnt ihr das via Patreon tun. Außerdem könnt ihr mir auf Twitter folgen.
