5. Mai 2011 | No Comments »
Update 06.06. zu Tausch der Tokens am Ende
Update 28.05. zu Angriff auf Lockheed Martin am Ende
Einleitung
Mitte März 2011 schrieb Art Coviello, CEO bei RSA, einen offenen Brief an die Kunden. In einem „ausgeklügelten Angriff“ wurden „bestimmte Informationen“, davon „einige, die in direktem Zusammenhang mit der RSA Zwei-Faktor-Authentisierung stehen“ entwendet. Obwohl mit diesen Informationen nach Coviello kein direkter Angriff auf die Endkunden möglich wird, könnte die der Angriff die „Wirksamkeit der Implementierung der Zwei-Faktor-Authorisierung reduzieren“. Also die Kombination aus Besitz (Token) und Wissen (PIN).
Was genau passiert ist, ob etwa wie gemutmaßt der SecurID-Quellcode oder die Seeds, die für die Berechnung der von den Tokens generierten Einmalpasswörter (One-Time-Passwords, OTP) benötigt werden entwendet wurden, weiß man leider dank der Informationspolitik von RSA bis heute nicht.
Die Empfehlungen, die von RSA bzw. dem mittlerweile Mutterkonzern EMC herausgegeben wurden, helfen leider ebenso nur bedingt weiter. Weitere Informationen sind auch der Channel Communication Guideline, die an die Kunden direkt versendet wurde nicht zu entnehmen.
Man möge:
- Vermehrt den Fokus der Sicherheitsanstrengungen für Soziale Netze und die Nutzung durch Anwender, die Zugriff auf kritische Infrastrukturen haben, legen
- Starke Passwort- und PIN-Richtlinien durchsetzen
- Nur die Rechte vergeben, die ein Benutzer wirklich benötigt (Principle of least privilege)
- Den Authentication-Manager im Auge behalten
- Fernzugriff auf den Authentication-Manager einschränken
- Die Benutzer und das Help-Desk sensibilisieren
Auf die Frage, ob SecurID-Token-Records gestohlen worden sind, wird mit folgender lapidaren Begründung nicht geantwortet: “Im Interesse der Sicherheit unserer Kunden erteilen wir keine nähere Auskunft zu den ausgespähten Daten.”.
Welche Auswirkungen hat dies für die Praxis?
Leider kann man nur Annahmen treffen. Aufgrund der Aussagen vom EMC/RSA muss davon ausgegangen werden, dass die Generierung der OTPs vorhersagbar geworden ist. Dafür spricht auch, dass die „einige Abläufe“ seitens RSA unterbrochen worden sind, darunter die Vertriebstätigkeit (!). Insofern scheint das Problem nicht nur eine Datenbank mit Seeds zu betreffen, sondern man kann davon ausgehen, dass auch neu produzierte Tokens, die nicht in einer solchen Datenbank beinhaltet sind betroffen wären. Also scheinen die Informationen entwendet worden zu sein, die man braucht, um aus der Seriennummer des Tokens den jeweils gültigen OTP zu berechnen.
Wann kommt also nun ein Angriff in der Praxis mit dieser Annahme zum Tragen? Sobald ein Angreifer weiß, welche Tokennummer einem Benutzer zugeordnet ist und im Besitz der bei RSA gestohlenen Informationen ist, kann er mutmaßlich den OTP-Wert berechnen. Hierfür benötigt er wie bisher zumindest kurzzeitig den Token selbst oder muss (z. B. über Inventarlisten bei der Firma, die die Token einsetzt oder Bestellinformationen bei Distributoren) anderweitig an die Tokennummer gelangen. Damit kann man die Kenntnis der Tokennummer mit der Nutzung bzw. dem Diebstahl des Tokens gleichsetzen. Kann sich der Angreifer nun anmelden? Ab diesem Zeitpunkt ist der Angriff der exakt gleiche, der er immer schon war. Der Angreifer benötigt weiterhin die Adressen der Zugangsportale, an denen der Token verlangt wird, ebenso wie den Benutzernamen und die Zugangs-PIN.
Bisher benötigte ein Angreifer also:
- Token
- Passenden Zugangspunkt
- Zum Token passenden Benutzername
- Zum Token passenden PIN
Jetzt benötigt er (weiterhin eine Annahme)
- Token ODER Tokennummer
- Zum Token/Tokennummer passenden Zugangspunkt
- Zum Token/Tokennummer passenden Benutzername
- Zum Token/Tokennummer passenden PIN
Welche Handlungsempfehlungen lassen sich für IT-Sicherheitsbeauftrage, IT-Sicherheitsverantwortliche, CISOs in dieser solchen Situation ableiten?
Es wird davon ausgegangen, dass folgende Maßnahmen bereits in der Vergangenheit ergriffen worden sind. Falls nicht, ist dies in jedem Falle sofort nachzuholen. Die angegeben Beispielwerte stellen aus unserer Sicht für einen durchschnittlichen Sicherheitsanspruch belastbare Empfehlungen dar. Diese sind jedoch stets individuell zu bewerten.
- Regelmäßiges Ändern der PIN (z. B. 90 Tage, variiert je nach Sicherheitsanspruch)
- Definierte Komplexitätsanforderungen die PIN (z. B. 6 Zeichen alphanumerisch, variiert je nach Sicherheitsanspruche)
- Generierung der PINs durch das System, nicht Vergabe durch den Nutzer
- Sperren des Zugangs nach definierter Anzahl Fehlversuche (z. B .3 Versuche, variiert je nach Sicherheitsanspruch)
- Entsperren nur manuell
- Regelmäßige Prüfung der Authentication Manager-Protokolle auf fehlgeschlagene Logins und „Next Tokencode Required“ Meldungen (z. B. alle zwei Wochen, variiert je nach Sicherheitsanspruch)
- Regelmäßige Nutzersensibilisierung
- Help-Desk-Sensibilisierung
- Authentication-Manager wird Out-Of-Band und auf keinen Fall remote gemanaged
- Datenbank des Authentication-Managers ist geschützt
- Die Seriennummern der Tokens werden nirgends (z. B. in Inventarlisten) gespeichert
Es empfiehlt sich, die Maßnahmen zu überprüfen und darüber hinaus folgende Maßnahmen ad hoc zu ergreifen:
- Nutzerinformation über den Vorfall, Sensibilisierung
- PINs und Passwörter dürfen an niemanden, weder extern noch intern weitergeben werden
- Tokennummern und –Codes dürfen nur im Supportfall dem Helpdesk genannt werden. Beim Anruf des Helpdesks stets die Rufnummer prüfen oder das Helpdesk aktiv zurückrufen
- Eingabe des Token-Codes nur auf durch das Helpdesk benannte Adressen. Hierbei niemals einen Link anklicken, sondern die Adresse selbst ins Adressfeld eintragen
- Sensibilisierung des Help-Desks
- Prüfen der Authentisierungsmethoden gegenüber dem Helpdesk. Wie wird die Identität eines Anrufers verifiziert? Ist es einem Angreifer möglich, die Informationen die abgefragt werden auf anderem Weg zu erlangen? Wie werden neue PINs im Falle des Zurücksetzens übermittelt?
Stellen Sie einen schriftlichen Plan der zu ergreifenden Maßnahmen auf und besprechen Sie diese in Ihrem Sicherheitsteam bzw. mit den Administratoren. Dokumentieren Sie die ergriffenen Maßnahmen und begründen sie diese.
Gibt es mögliche weitere Probleme
Möglicherweise wurde auch Quelltext entwendet, so dass es Angreifern möglich sein könnte Schwachstellen in den Authentisierungsservern zu finden. Ist dies der Fall, kann dies theoretisch auch dazu führen, dass die Sicherheit der Gesamtlösung vollständig nicht mehr gegeben ist. Hält man dies für realistisch kommt man nicht umhin, die RSA-Lösung sofort außer Betrieb zu setzen und für eine äquivalente Lösung ohne Sicherheitsmängel zu sorgen. Dies scheint unserer Einschätzung nach jedoch für die meisten Einsatzbereiche derzeit nicht notwendig.
Nachsatz
Es ist für den Einsatz einer Sicherheitslösung wie RSA Secure-ID Tokens im Falle eines Einbruchs unerlässlich um die Gesamtsicherheit der Lösung zu wissen. Es ist in keinem Fall zuträglich, dass EMC/RSA die Sicherheit der Kunden vorschiebt, um nicht Stellung zu den entwendeten Daten beziehen zu müssen. Damit wird der Kunde letztlich allein gelassen und kann nicht mit ausreichender Sicherheit adäquat auf das durch EMC/RSA verursachte Problem reagieren.
Update 28.05.: Angriff auf Lockheed Martin Ende Mai
Am 28.05. veröffentlichte das Rüstungsunternehmen Lockheed Martin eine Mitteilung, dass Angriffe auf Ihre Infrastruktur erfolgten, aber dank der sofortigen Intervention nichts passiert ist. Dem Vernehmen nach steht der Angriff im Zusammenhang mit den Vorfällen bei RSA. So wurden die Remote-Zugänge zunächst gesperrt, neue Tokens verteilt und bei der Anmeldung ein zweites Passwort nach der eigentlichen Anmeldung verlangt.
Es ist fraglich, ob diese Sicherheitsmaßnahmen greifen, insbesondere was den Tausch der Tokens betrifft. Offensichtlich wird jedoch das Problem: Bei großen Unternehmen sind die Zugangsportale meist leicht zu finden und an eine gültige Tokennummer zu kommen, ist bei 100.000 (!!) Nutzern ebenfalls deutlich leichter, als bei vergleichsweise kleinen Nutzerkreisen.
Ändert sich durch den Vorfall die eingangs beschriebene Einschätzung und die abgeleiteten Empfehlungen? Nein. Der Fall bringt nichts Neues ans Tageslicht, auch wenn es natürlich beunruhigend ist, wenn ein Angriff gegen einen RSA-Kunden nun erfolgreich wird. Derzeit ist ein realer Angriff dennoch vergleichsweise unwahrscheinlich und die benannten Gegenmaßnahmen sinnvoll. Es könnte jedoch jeden Tag passieren, dass die Seeds für die Token-Berechnung im Internet veröffentlicht werden. Damit steigt die Gefahr von Angriffen massiv. Es ist daher sicherlich empfehlenswert, sich bereits heute für ein entsprechendes Szenario zu wappnen.
Update 06.06. Tokens werden getauscht
Also doch: RSA hat sich binnen kürzester Zeit *hust* dazu entschlossen, die Tokens zu tauschen. Alle. Auf Wunsch der Kunden. Der “offene Brief an die Kunden” ist wiedermal sehr lesenswert: Natürlich besteht weiterhin keinerlei Gefahr, wenn man die Best-Practice-Ansagen umsetzt. Diese ganzen Hacks der letzten Zeit gegen “Epsilon, Sony, Google, PBS, and Nintendo” stehen in keinem Zusammenhang mit dem RSA Problem – hatte das wer behauptet? Der Angriff gegen Lockheed Martin (siehe Update 28.05.) irgendwie schon, aber hey, Lockheed hat ihn ja vereitelt. Und der Angriffsvektor, der bei Lockheed Martin zum Tragen kam, ist kein neuer Angriffsvektor (der letzte Teil ist im Original unterstrichen). In anderen Worten: Das, was Lockheed Martin passiert ist, kann allen anderen auch passieren die SecurID einsetzen.
Wer übrigens nach einer Alternative sucht, bekommt eine Liste von Marktbegleitern direkt bei RSA..
Dieser Token-Tausch kann im Übrigen nur eines bedeuten: Die Seeds sind – wie bereits zu Beginn vermutet – entwendet worden. Das ist schlimm genug. Viel schlimmer aus unserer Sicht ist, dass die Seeds überhaupt bei RSA gespeichert wurden. Das ist das Secret des Kunden, der den Token einsetzt! Das hat bei RSA nichts, aber auch nichts mehr verloren, nachdem der Token produziert wurde. Insofern lohnt sich der Blick auf den Markt durchaus..
Weitere Hilfe
Wie immer hoffen wir, dass Ihnen die Informationen in unserem Blog möglichst konkret weiterhelfen. Sollten Sie darüber hinaus gehenden Beratungsbedarf haben, z. B. um die Sicherheitsmaßnahmen für Ihr Unternehmen gemeinsam zu untersuchen und zu verbessern, so nehmen Sie bitte unverbindlich Kontakt mit uns auf.
/GT
Schlagwörter: Hack, RSA, SecurID, Token ,
)
