Skip to content

RSA und die unsicheren SecurID Token

RSA tauscht SecurID-Token aus, da deren Startwerte Dritten bekannt sind. Das sind die nun bekannt gewordenen Folgen des im März bekannt gewordenen, gezielten Angriffs auf RSA, über den ich bereits im Standpunkt vom 11. April kommentiert habe.

RSA-Daten für Angriffe ausgenutzt

Arthur W. Coviello, "Executive Chairman" von RSA, hat in einem offenen Brief an die Kunden bestätigt, dass die bei RSA ausgespähten Informationen im Rahmen eines im Mai durchgeführten Angriffs auf Lockheed Martin eingesetzt wurden. Entsprechende Vermutungen gab es bereits sofort nach dem Angriff, siehe auch die Diskussion in Bruce Schneiers Blog. Da Lockheed Martin nach dem Angriff alle verwendeten SecurID Tokens austauschte, war eine Verbindung nahliegend. Eine Warnung oder auch nur Information seitens RSA blieb damals aber aus. Zu den weiteren, parallel zum Angriff auf Lockheed Martin durchgeführten Angriffe auf "several other U.S. military contractors", darunter angeblich bzw. eventuell L-3 Communications und Northrop Grumman, äußerte sich Arthur Coviello nicht. Dafür erklärt er im offenen Brief gleich nach der Einleitung, in der er die herkömmlichen Schutzmaßnahmen für ausreichend hält:

"Certain characteristics of the attack on RSA indicated that the perpetrator's most likely motive was to obtain an element of security information that could be used to target defense secrets and related IP, rather than financial gain, PII, or public embarrassment. For this reason, we worked with government agencies and companies in the defense sector to replace their tokens on an accelerated timetable as an additional precautionary measure. We will continue these efforts."

Wieso muss ich da nur gerade an gleiche TiereKunden denken?

Aber zurück zu Lockheed Martin. Dazu erklärt Arthur Coviello:

"It is important for customers to understand that the attack on Lockheed Martin does not reflect a new threat or vulnerability in RSA SecurID technology. Indeed, the fact that the only confirmed use to date of the extracted RSA product information involved a major U.S. defense contractor only reinforces our view on the motive of this attacker."
[Hervorhebung aus dem Original]

Kein Wunder, dass man da keine neue Bedrohung oder Schwachstelle sieht, denn das Kind liegt bereits seit langem unten im Brunnen. Aber dazu komme ich gleich.

RSA tauscht SecurID Token aus - aber nicht alle!

Obwohl man völlig von der Sicherheit der SecurID Token überzeugt ist (was man ja auch an den bisherigen Aktionen sieht, oder?), tauscht man einen Teil der Token aus:

"An offer to replace SecurID tokens for customers with concentrated user bases typically focused on protecting intellectual property and corporate networks."

Alle anderen Kunden haben eben Pech gehabt. Ach, halt, einen Zuckerbrocken gibt es noch:

"An offer to implement risk-based authentication strategies for consumer-focused customers with a large, dispersed user base, typically focused on protecting web-based financial transactions."

Aha. Mehr oder weniger gute Ratschläge gibt es für die, aber keine neuen Token? Laut Threat Post betrifft das zwei Drittel der SecurID Token:

"fully two thirds of SecurID tokens in circulation are used by consumer-focused banks and brokerages, not firms with intellectual property or trade secrets to protect."

Aber das ist vielleicht auch besser so, dann können die Betroffenen sich gleich nach einem neuen Lieferanten umsehen und werden von RSA nicht in Versuchung geführt. Wie gut, dass es noch mehr Token-Hersteller gibt. Ob die die Sicherheit ihrer Kunden ernster nehmen, erfährt man erst im Ernstfall. Aber nachdem RSA vorgemacht hat, wie man es nicht machen sollte, hoffe ich doch, dass sowas nicht noch mal passiert.

RSA tauscht doch alle SecurID Token aus?

Laut Wall Street Journal hat Arthur Coviello den Austausch aller Token angekündigt: "for virtually every customer we have". Also den offenen Brief verstehe ich da aber anders. Und auch laut Threat Post gilt der Austausch nicht für alle Kunden:

"Customers who wish to get their SecurID tokens replaced are still bound by the terms of their licensing agreement, according to one customer who contacted Threatpost. EMC/RSA said through its spokesman that it didn't have any information on deals or other discounts offered to customers on replacement tokens or the risk based authentication technology."

Nun, wir werden sehen, was passiert.

RSA, Sie sind raus!

Andererseits: Wer will schon ein neues Token von RSA haben, dessen Seed dann beim nächsten Mal ausgespäht wird? Denn laut Ars Technica wurden in der Tat die Seeds ausgespäht: "Sources close to RSA tell Ars that the March breach did indeed result in seeds being compromised."

Man kann darüber streiten, ob RSA die Seeds aufbewahren muss/soll/darf. Eigentlich braucht RSA sie nicht, es reicht, wenn sie den jeweiligen Kunden bekannt sind. Immerhin stellen die Seeds eine Art "privater Schlüssel" der Kunden dar und erleichtern dem, der sie besitzt, den Zugang zu den Systemen des Kunden. Mir persönlich gefällt die Idee gar nicht, dass da jemand quasi einen Zweitschlüssel besitzt. Das einzige mögliche Argument für die Speicherung der Seeds: Verliert der Kunde sie, kann RSA sie ihm erneut mitteilen. Schließlich kann man ja i.A. auch für seine eigenen Sicherheitsschlösser beim Hersteller Nachschlüssel anfordern. Man könnte aber auch argumentieren, dass der Kunde gefälligst auf seine Seeds aufpassen soll. Verliert er sie, hat er dann eben Pech gehabt. Ggf. könnte man die Speicherung ja als zusätzliche und optionale Backuplösung anbieten. Für die Kunden, die selbst nicht in der Lage sind, ein Backup anzulegen. Was nicht besonders viele sein dürften - wer ein SecurID Token braucht, sollte erst recht anständige Backup-Lösungen brauchen, und dann kann er auch seine Seeds selbst speichern.

Aber egal wie man argumentiert: Die Seeds aufzubewahren und dann kopieren zu lassen - damit ist das Unternehmen RSA aus Sicherheitssicht in meinen Augen erledigt. Die Daten hätten niemals auf einem mit dem Netzwerk verbundenen Rechner gespeichert sein dürfen. Wozu? So oft, dass man da ständig drauf zugreifen muss, werden die Kunden ihre Seeds ja wohl nicht verlieren. Oder braucht RSA einen ständigen Zugriff auf die Zweitschlüssel zu den Systemen ihrer Kunden? Wieso, weshalb, warum?

Kurzsichtiges Sicherheitsunternehmen?

Laut Wall Street Journal hat RSA die Kunden nicht ausführlicher informiert, um den Angreifern(!) keine weiteren Informationen zu liefern:

"Mr. Coviello said his company has provided the right amount of information to its customers. Providing any further information, he said, would give the hackers a blueprint for how to mount further attacks."

Nur zur Erinnerung: Das war ein gezielter Angriff, die Angreifer wussten ganz genau, was sie ausspähen wollten. Und dann hat RSA Angst, man könnte denen verraten, was sie mit den ausgespähten Daten machen können? Gleichzeitig wurden der Regierung und der Verteidigungsindustrie ein Austausch der Token angeboten, da man mit Angriffen auf deren Systeme rechnet. Ja, was denn nun - zielgerichtete, schlaue Angreifer, oder Angreifer, die so dumm sind, dass sie gar nicht wissen, was sie ausgespäht haben?

Trau, schau wem

Noch einmal Arthur Coviello, zitiert aus dem Wall Street Journal:

"The whole thing has reached a crescendo where customers don't want to tolerate any level of risk, whether it's real or perceived."

Stimmt genau. Die Frage ist nur, ob diese Kunden es nun riskieren, erneut ein RSA-Token einzusetzen. Ich jedenfalls vertraue niemanden, der immer nur soviel zugibt, wie bereits bekannt ist, und erst reagiert, wenn das erste Kind im Brunnen liegt. Und selbst dann noch Ausflüchte sucht und viele Fragen offen lässt. Von der völlig unnötigen Speicherung der Seeds ganz zu schweigen.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Passwort, P4ssw0rt, k1Gv3rJ8 - oder ist alles Käse?

Vorschau anzeigen
Wie ein gutes Passwort gebildet wird, weiß wohl jeder: Mindestens 8 Zeichen, Groß- und Kleinbuchstaben und Zahlen gemischt, gerne auch ein Sonderzeichen, ... Regeln gibt es viele, wie man so ein "zufälliges" aber doch gut merkbare

Dipl.-Inform. Carsten Eilers am : Vertrauensfragen

Vorschau anzeigen
Der aktuelle Angriff auf bzw. die Reaktion darauf durch DigiNotar macht ein grundlegendes Problem der IT-Sicherheit, nicht nur im Umgang mit SSL-Zertifikaten, sichtbar: Vertrauen, das missbraucht werden oder ungerechtfertigt sein kann. Oder beid

Dipl.-Inform. Carsten Eilers am : Adobes 0-Day-Schwachstellen des Monats

Vorschau anzeigen
0-Day-Schwachstellen in Adobe Reader, Acrobat und dem Flash Player - die muss ich einfach kommentieren, so eine Vorlage lasse ich mir natürlich nicht entgehen. Werfen wir also einen Blick auf die (mageren) Fakten. Eine 0-Day-Schwachstelle

Dipl.-Inform. Carsten Eilers am : Noch ein bekannter Advanced Persistent Threat: Der Angriff auf RSA

Vorschau anzeigen
Der Angriff auf RSA zum Ausspähen der Seeds der SecurID-Token ist ein weiterer bekannter Advanced Persistent Threat (APT), der noch dazu relativ gut dokumentiert ist. Zumindest wissen wir, wie der Angreifer "den Fuss in die Tür bekommen

Dipl.-Inform. Carsten Eilers am : Authentifizierung: Passwortregeln, Teil 2

Vorschau anzeigen
Im ersten Teil dieses zweiteiligen Artikels über Sinn und Zweck von Passwortregeln ging es um das Aufschreiben von Passwörtern. Als nächstes geht es um das Wechseln der Passwörter: Passwörter regelmäßig we

Dipl.-Inform. Carsten Eilers am : Zwei-Faktor-Authentifizierung mit spezieller Hardware, Teil 2

Vorschau anzeigen
Security-Token sind ebenso wie die ChipTAN eine weitere Möglichkeit, der Authentifizierung einen zweiten Faktor hinzuzufügen. Insbesondere Security-Token, die Einmalpasswörter erzeugen, sind theoretisch sehr sicher. Praktisch kann d

entwickler.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

jaxenter.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

Dipl.-Inform. Carsten Eilers am : Drucksache: Windows Developer 11.16 - Zwei-Faktor-Authentifizierung

Vorschau anzeigen
Im windows.developer 11.16 ist ein Artikel über die Zwei-Faktor-Authentifizierung erschienen. Lange Zeit reichte die Kombination aus Benutzername und Passwort aus, um einen Benutzer sicher zu identifizieren. Inzwischen gelangen diese Zu