RSA Security hat von dem erfolgreichen Hackerangriff ihre Kunden und die Börsenaufsicht informiert. Feststeht, soviel geht aus der kryptischen Unternehmensmitteilung hervor, dass die Schlüssel-Token-SecurID von der Attacke betroffen sind. Sie gehören zum wohl bekanntesten Zwei-Faktor-Authentifizierungssystem. Laura Didio, die Chefin des Analystenhauses ITIC ist erschüttert:
"Sowas ist peinlich. Wer setzt denn RSA Secure-ID ein? Viele staatliche Stellen, Hochtechnologie-Unternehmen, Finanzdienstleister und so weiter. Das sind doch alles keine kleinen Klitschen. Diese Dinge sind schließlich teuer."
Bislang galt SecurID als sicher. Der Benutzer kann sich mit dem System beispielsweise auf einem Server einloggen, indem er ein herkömmliches Passwort verwendet und zusätzlich eine vom Token errechnete Zahl eingibt, erläutert Helmut Reiser, Abteilungsleiter Netzwerke beim Leibniz-Rechenzentrum in München:
"Dieses Token benutzt zur Berechnung dieser Zahl die aktuelle Zeit, also alle 60 oder 30 Sekunden, und verschlüsselt diese Zeit mit dem token-spezifischen Schlüssel. Das heißt, das Token und der Server auf Unternehmensseite müssen diesen Schlüssel kennen und können dann das selbe Verfahren anwenden und können serverseitig prüfen: Hat jetzt der Benutzer sein richtiges Passwort und den aktuell gültigen Token-Wert eingegeben? Wenn beides passt, bekommt er entsprechend Zugang auf die Ressourcen, die geschützt werden sollen."
Für die im Token und auf dem Unternehmens-Server gespeicherten Schlüssel nun gibt es einen Fachbegriff, weil sie auf eine besonders sichere Art und Weise entstehen. Ihr Zustandekommen kann nicht logisch nachvollzogen werden, weil dahinter gar keine Logik steckt, sondern weil ein Zufallsgenerator sie erzeugt.
"Diese Zufallszahlen werden im Englischen einfach als 'Seed' häufig bezeichnet. Man kann es eigentlich in dem Fall auch als kryptographischen Schlüssel bezeichnen oder übersetzen."
Aber dass die Schlüssel durch einen Zufallsgenerator erzeugt werden, nützt nichts, wenn sie nicht nur im Token und auf dem Server gespeichert sind, sondern wenn noch weitere Kopien davon existieren. Und dass dem so ist, davon ist Andrew Kemshall überzeugt. Er hat früher für RSA gearbeitet und hat dann ein eigenes Unternehmen gegründet, SecurEnvoy, das gegen RSA konkurriert. Sonderlich traurig ist Kemshall deshalb wegen der Probleme seines ehemaligen Arbeitgebers nicht.
"RSA programmiert die Token und liefert diese dann zusammen mit dem entsprechenden Seed-Record aus. Es ist also klar, dass für alle produzierten Token Kopien dieser Seed-Records existieren, die von RSA gespeichert werden für den Fall, dass ein Kunde eine solche Kopie verlangt."
Andrew Kemshall vermutet, dass die Hacker, die in die RSA-Rechner eingedrungen sind, Seed-Records entwendet haben. Sie wären dadurch wahrscheinlich in der Lage, SecurID-Token nachzuprogrammieren und sich so Zugang zu Hochsicherheitsbereichen in aller Welt zu verschaffen. Vieles deutet darauf hin, dass dem so ist. Natürlich könnten die Hacker sich auch andere Informationen verschafft haben, sagt Helmut Reiser. Beruhigend allerdings wäre das auch nicht.
"Vielleicht gibt es bei RSA intern Dokumentationen über Schwachstellen, die RSA bekannt sind, die bisher aber nicht veröffentlicht wurden. Das wäre natürlich aus meiner Sicht der Worst Case, wenn der Angreifer quasi schon die Beschreibung kriegt, wie er dieses Verfahren client- oder serverseitig angreifen kann."
Was immer auch bei RSA weggekommen ist, das bislang renommierte Unternehmen muss jetzt seiner Kundschaft erklären, wie es deren Server schützen will, wo es doch nicht einmal in der Lage ist, seine eigenen zu schützen. Gezeigt hat der Vorfall aber auch, zu welchen technischen Höchstleistungen Hacker mittlerweile in der Lage sind. Vergleichbar ist der RSA-Hack durchaus mit der Programmierung von Stuxnet.
"Sowas ist peinlich. Wer setzt denn RSA Secure-ID ein? Viele staatliche Stellen, Hochtechnologie-Unternehmen, Finanzdienstleister und so weiter. Das sind doch alles keine kleinen Klitschen. Diese Dinge sind schließlich teuer."
Bislang galt SecurID als sicher. Der Benutzer kann sich mit dem System beispielsweise auf einem Server einloggen, indem er ein herkömmliches Passwort verwendet und zusätzlich eine vom Token errechnete Zahl eingibt, erläutert Helmut Reiser, Abteilungsleiter Netzwerke beim Leibniz-Rechenzentrum in München:
"Dieses Token benutzt zur Berechnung dieser Zahl die aktuelle Zeit, also alle 60 oder 30 Sekunden, und verschlüsselt diese Zeit mit dem token-spezifischen Schlüssel. Das heißt, das Token und der Server auf Unternehmensseite müssen diesen Schlüssel kennen und können dann das selbe Verfahren anwenden und können serverseitig prüfen: Hat jetzt der Benutzer sein richtiges Passwort und den aktuell gültigen Token-Wert eingegeben? Wenn beides passt, bekommt er entsprechend Zugang auf die Ressourcen, die geschützt werden sollen."
Für die im Token und auf dem Unternehmens-Server gespeicherten Schlüssel nun gibt es einen Fachbegriff, weil sie auf eine besonders sichere Art und Weise entstehen. Ihr Zustandekommen kann nicht logisch nachvollzogen werden, weil dahinter gar keine Logik steckt, sondern weil ein Zufallsgenerator sie erzeugt.
"Diese Zufallszahlen werden im Englischen einfach als 'Seed' häufig bezeichnet. Man kann es eigentlich in dem Fall auch als kryptographischen Schlüssel bezeichnen oder übersetzen."
Aber dass die Schlüssel durch einen Zufallsgenerator erzeugt werden, nützt nichts, wenn sie nicht nur im Token und auf dem Server gespeichert sind, sondern wenn noch weitere Kopien davon existieren. Und dass dem so ist, davon ist Andrew Kemshall überzeugt. Er hat früher für RSA gearbeitet und hat dann ein eigenes Unternehmen gegründet, SecurEnvoy, das gegen RSA konkurriert. Sonderlich traurig ist Kemshall deshalb wegen der Probleme seines ehemaligen Arbeitgebers nicht.
"RSA programmiert die Token und liefert diese dann zusammen mit dem entsprechenden Seed-Record aus. Es ist also klar, dass für alle produzierten Token Kopien dieser Seed-Records existieren, die von RSA gespeichert werden für den Fall, dass ein Kunde eine solche Kopie verlangt."
Andrew Kemshall vermutet, dass die Hacker, die in die RSA-Rechner eingedrungen sind, Seed-Records entwendet haben. Sie wären dadurch wahrscheinlich in der Lage, SecurID-Token nachzuprogrammieren und sich so Zugang zu Hochsicherheitsbereichen in aller Welt zu verschaffen. Vieles deutet darauf hin, dass dem so ist. Natürlich könnten die Hacker sich auch andere Informationen verschafft haben, sagt Helmut Reiser. Beruhigend allerdings wäre das auch nicht.
"Vielleicht gibt es bei RSA intern Dokumentationen über Schwachstellen, die RSA bekannt sind, die bisher aber nicht veröffentlicht wurden. Das wäre natürlich aus meiner Sicht der Worst Case, wenn der Angreifer quasi schon die Beschreibung kriegt, wie er dieses Verfahren client- oder serverseitig angreifen kann."
Was immer auch bei RSA weggekommen ist, das bislang renommierte Unternehmen muss jetzt seiner Kundschaft erklären, wie es deren Server schützen will, wo es doch nicht einmal in der Lage ist, seine eigenen zu schützen. Gezeigt hat der Vorfall aber auch, zu welchen technischen Höchstleistungen Hacker mittlerweile in der Lage sind. Vergleichbar ist der RSA-Hack durchaus mit der Programmierung von Stuxnet.