Slack hat etliche Nutzer aufgefordert, ihr Passwort zu ändern. Über eine Sicherheitslücke wurden über Jahre Hashes der Passwörter versendet.

Die Kollaborationssoftware Slack hat in bestimmten Fällen die gehashten Passwörter an andere Nutzer übermittelt. Man habe rund 0,5 Prozent der Nutzer aufgefordert, ihr Passwort zu ändern, teilte Slack mit. Was nach wenig klingt, sind bei vom Onlinemagazin The Register geschätzten 10 Millionen täglich aktiven Nutzern eine ganze Menge.

Laut Slack wurden die gehashten Passwörter übermittelt, wenn Nutzer einen gemeinsamen Einladungslink für einen Arbeitsbereich erstellten oder widerriefen. Die Daten seien dann an alle Mitglieder des Arbeitsbereichs gesendet worden, erklärte Slack. In der Software sei der Passworthash allerdings nicht angezeigt worden, vielmehr habe der am Gerät ankommende Netzwerkverkehr untersucht werden müssen, um an den Passworthash zu gelangen.

Entdeckt hatte das Problem ein Sicherheitsforscher, der es am 17. Juli 2022 an Slack meldete. Dort wurde das schon seit längerer Zeit bestehende Problem umgehend behoben. Betroffen sind demnach Nutzer, die im Zeitraum zwischen dem 17. April 2017 und dem 17. Juli 2022 entsprechende Einladungslinks erstellten oder widerriefen. Weitere Details zu dem Problem nannte Slack nicht.

Auch das eingesetzte Hashingverfahren nannte das Unternehmen nicht, auf Nachfrage haben wir bisher noch keine Antwort erhalten. Die Passwörter seien vor dem Hashen mit einem sogenannten Salt (engl. Salz) verlängert worden, teilte Slack mit. “Es ist praktisch nicht möglich, ein Kennwort aus dem Hash abzuleiten, und niemand kann den Hash direkt zur Authentifizierung verwenden”, betonte der Anbieter. Je nach eingesetztem Hashingverfahren, Passwortlänge und vorhandener Rechenpower können Passwörter jedoch durchaus geknackt werden.

Bei den betroffenen Nutzern wurde das Passwort zurückgesetzt, sie müssen ein neues Kennwort wählen. Slack empfiehlt zudem, die Zwei-Faktor-Authentifizierung (2FA) zu aktivieren.

Der Beitrag Slack schließt jahrelanges Datenleck erschien zuerst auf Linux-Magazin.

Ein Ausfall von Slack im Februar resultierte aus einem kaskadierenden Fehler, den das Team aufgrund der Komplexität nur schwer beheben konnte.

In seinem Engineering-Blog beschreibt ein Technikteam des Messengerdienstes Slack Ursachen und Fehlerbehebung eines Ausfalls im vergangenen Februar. Dabei hält das Team schon zu Beginn eine wohl eher unbequeme Erkenntnis fest: “Dieser Vorfall war ein Paradebeispiel für ein komplexes Systemversagen: Es gab eine Reihe von Faktoren, die dazu beitrugen, und ein Teil des Vorfalls bestand aus einem kaskadenartigen Fehlerszenario.”

Der Ausfall des Systems machte sich dem Beitrag zufolge dadurch bemerkbar, dass Nutzer Probleme damit hatten, sich am Morgen (US-Zeitzonen) mit dem Messenger zu verbinden. Unabhängig davon erhielt das Team automatische Fehlermeldungen des Alarmsystems.

Die Probleme zeigten sich laut dem Blogpost an der Technik durch einen deutlichen Anstieg der Last der Datenbanksystemen. Das Team schreibt: “Was anfangs nicht klar war, war die Frage, warum die Datenbank so stark belastet wurde (..) und wie wir zu einem normalen Betriebszustand gelangen konnten.” Lösen konnte das Slack demnach nur durch eine größere interne Kooperation unter Beteiligung mehrerer Teams.

Die zunächst naheliegende Lösung, zur Lastvermeidung die Anzahl neuer Clients zu reduzieren, die sich mit neu mit dem System verbanden, und anschließend diese Zahl wieder langsam zu erhöhen, hatte aber nicht den erhofften Erfolg. Das Team war offenbar schlicht zu ungeduldig und erzeugte zu schnell wieder zu viel Last, ohne den zugrunde liegenden Fehler zu beheben.

Zur Ursachensuche schreibt das Team: “Wie kam es dazu, dass wir von einem stabilen Auslieferungszustand in einen Zustand der Überlastung gerieten? Die Antwort lag in den komplexen Interaktionen zwischen unserer Anwendung, den Vitess-Datenspeichern, dem Caching-System und unserem Service Discovery System.” Bei Vitess handelt es sich um ein Datenbank-Cluster-System für MySQL, das gestartet wurde, um die Skalierungsprobleme von Youtube zu lösen.

Ausgangspunkt war den Angaben zufolge ein Upgrade von Consul, das für Service Discovery genutzt wird. Wie schon mehrfach zuvor sollten dabei nur 25 Prozent der Server aktualisiert werden. Das hatte zwar zuvor geklappt, zusammen mit einer gestiegenen Last durch die Clients führte es aber letztlich am Tag des Ausfalls von Slack zu bisher unbekannten Problemen.

Mit den Upgrades von Consul wurden nach und nach die davon überwachten Cache-Knoten offline genommen. Die Automatisierung von Slack startete dann zwar ersatzweise neue Knoten mit Memcached, letztlich führte der Updateprozess aber dazu, dass sich die Cache Hit Rate immer stärker verringerte.

Da die Abfragen im Cache nicht erfolgreich waren, wurden die eigentlichen Datenbanken verstärkt angefragt, die aufgrund einer spezifischen Anfrage und der Verteilung der angefragten Daten im System immer mehr unter Last gerieten. Dazu schreibt das Team: “Die Datenbank war überfordert, da die Leselast im Verhältnis zum Prozentsatz der Cache Misses superlinear anstieg.” Die Systeme erreichten laut Slack schließlich einen Kipppunkt, ab dem sich der Fehler selbst weiter verstärkte.

Das Team reduzierte zum Beheben der Probleme zunächst die Anzahl sich verbindender Clients, verbesserte die ineffiziente Datenbankabfrage, um nur noch jene Daten zu lesen, die tatsächlich im Cache fehlten, und die Datenbank-Replicas wurden als Systeme zum Lesezugriff bereitgestellt. Letztlich konnte der Cache so wieder aufgefüllt werden, bis alle Clients ihre Daten wieder daraus erhalten konnten.

Der Beitrag Slack erklärt “Paradebeispiel für komplexes Systemversagen” erschien zuerst auf Linux-Magazin.