Kiteworks forderte seine Kunden auf, ihre Produktionssysteme am Wochenende offline zu nehmen. Während dieser Abschaltung entdeckte und behob das Unternehmen eine kritische Schwachstelle.
Das Unternehmen erklärte am 28. September , dass seine Untersuchung während der Abschaltung eine bislang unbekannte kritische Schwachstelle aufgedeckt habe. Nach Angaben des Unternehmens ist die betroffene Funktion bei weniger als 1 % der Kunden aktiviert. Es gebe keine Hinweise darauf, dass die Schwachstelle ausgenutzt wurde, und die Kunden könnten den normalen Betrieb wieder aufnehmen.
Für Sicherheitsteams wirft der Vorfall eine praktische Frage auf: Wie schnell können sie auf eine glaubwürdige Warnung reagieren, wenn die Abschaltung einer Plattform für sensible Daten die Geschäftsabläufe beeinträchtigt?
Was geschah während der Abschaltung?
Am 25. September riet Kiteworks seinen Kunden dazu, ihre Systeme für einen Zeitraum von neun Stunden herunterzufahren, nachdem das Unternehmen Informationen erhalten hatte, dass ein Angreifer einige Installationen ins Visier nehmen könnte. Kunden, die Systeme vor Ort oder in AWS beziehungsweise Azure verwalten, sollten die Abschaltung selbst durchführen; Kiteworks fuhr die von ihm gehosteten Umgebungen herunter. Die Empfehlung war eine Vorsichtsmaßnahme, und das Unternehmen erklärte damals, es gebe keine Hinweise auf eine Kompromittierung.
Während der Abschaltung identifizierte Kiteworks die kritische Schwachstelle, entwickelte und implementierte eine Behebung und brachte in allen Umgebungen eine zusätzliche Schutzschicht zum Einsatz. In seiner Stellungnahme vom 28. September hat das Unternehmen die Funktionsweise der Schwachstelle nicht öffentlich beschrieben. Separat weist die aktualisierte Anleitung von Kiteworks zum Neustart Kunden mit selbst gehosteten Advanced Forms an, den Support um Unterstützung zu bitten.
Kiteworks hob die Empfehlung zur Abschaltung am 27. September auf. Das Unternehmen erklärte, die kontinuierliche Überwachung habe während des Bedrohungszeitraums keine ungewöhnlichen Aktivitäten gezeigt und es gebe keine Hinweise auf eine Ausnutzung oder Kompromittierung. Nach Angaben des Unternehmens sind alle von Kiteworks gehosteten Kundensysteme wieder online.
Warum die Warnung für Verteidiger wichtig ist
Dateifreigabe- und Dateiübertragungssysteme können sich in unmittelbarer Nähe zu sensiblen Geschäftsdaten befinden. Eine frühere Berichterstattung über eine Schwachstelle in MOVEit Transfer zeigt, warum Schwachstellen in diesen Plattformen schnelles Handeln erfordern. Im Fall von Kiteworks führte eine glaubwürdige Warnung zu einer Abschaltung, und die Untersuchung deckte eine kritische Schwachstelle auf, während die Systeme offline waren.
„Dieser Vorfall zeigt auch, warum Threat Intelligence in konkrete Maßnahmen umgesetzt werden muss. Informationen, die in einem Bericht oder Dashboard liegen, schützen nichts“, sagte Phil Wylie, Senior Consultant und Evangelist bei Suzu Labs.
Diese Informationen in konkrete Maßnahmen umzusetzen, erfordert einen Reaktionsplan: Wer kann eine Notabschaltung genehmigen, welche Systeme hängen von dem Dienst ab, wie werden Kunden und Mitarbeiter benachrichtigt und welche Nachweise benötigen die Teams, bevor sie den Zugriff wiederherstellen? Ähnliche Fragen zur Reaktion stellen sich, wenn Teams einen aktiv ausgenutzten GitLab-Fehler priorisieren oder die Ausnutzung einer Schwachstelle bei der Dateiübertragung untersuchen müssen.
Was Kiteworks-Kunden jetzt tun sollten
Administratoren können die Systeme gemäß der aktualisierten Anleitung von Kiteworks wieder online bringen. Teams mit selbst gehosteten Advanced Forms sollten den Kiteworks-Support um Unterstützung bitten, wie vom Unternehmen ausdrücklich empfohlen. Sie sollten bei Kiteworks bestätigen, dass ihre Bereitstellung die erforderliche Behebung enthält, ihre eigene Überwachung auf ungewöhnliche Aktivitäten überprüfen und dokumentieren, wie sich die Abschaltung auf kritische Übertragungen ausgewirkt hat.
Kiteworks zufolge gibt es keine Hinweise auf eine Ausnutzung oder Kompromittierung. Kunden müssen ihre eigenen Konfigurationen und den Wiederherstellungsstatus dennoch überprüfen, insbesondere wenn sie Advanced Forms einsetzen.
Mehr dazu: Die Warnung zum ShareFile Storage Zone Controller ist ein weiteres Beispiel für die Entscheidungen, vor denen Sicherheitsteams stehen, wenn ein Anbieter von Dateifreigaben angesichts einer glaubwürdigen Bedrohung empfiehlt, Systeme offline zu nehmen.