Dieser Artikel wurde das letzte Mal aktualisiert am 11. Oktober 2011 19:45 Uhr

Das Unternehmen RSA Security – es ist seit 2006 Teil der EMC Corp. – ist in erster Linie durch ihre Lösung SecurID bekannt geworden. Diese gilt als das wohl populärste Produkt zur Umsetzung strenger Authentisierung. Ein Benutzer muss dabei neben Benutzername und Passwort ebenfalls einen dritten Faktor mitgeben. Dieser wird durch einen SecurID-Token erzeugt. Dabei handelt es sich um einen sechs- bis achtstelligen Zahlencode, der alle 60 Sekunden aktualisiert wird. Durch eine vorgängige Synchronisation mit dem RSA-Server wird es durch eben diesen möglich, die Legitimität der Authentisierung zu erkennen. Sieht sich ein Angreifer in der Lage Benutzername, Passwort und Token abzufangen, kann er diese Daten maximal 60 Sekunden für eine erfolgreiche Authentisierung nutzen. Danach ist der dritte Faktor, der Zufallscode des Token, nutzlos.

Zwischenfall und Veröffentlichung

Am 17. März 2011 veröffentlicht Art Coviello, CEO von RSA, auf der Unternehmenswebseite einen offenen Brief. In diesem weist er mit Bedauern darauf hin, dass eine Kompromittierung der RSA-Systeme stattgefunden hat und eine nicht näher definierte Gefahr für die SecurID-Lösungen besteht:

Recently, our security systems identified an extremely sophisticated cyber attack in progress being mounted against RSA. (…) Our investigation also revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is specifically related to RSA’s SecurID two-factor authentication products.

In diesem Zusammenhang wird der umstrittene Begriff APT (Advanced Persistant Threat) genutzt, um auf die technische Überlegenheit der Angreifer hinzuweisen. Technische Details zur Attacke oder den betroffenen Komponenten werden nicht genannt.

Tage nach der Veröffentlichung dieses Schreibens wurde durch Uri Rivner, Head of New Technologies, ein eher technischer Blog-Post herausgegeben. In diesem wird das grundlegende Vorgehen der Angreifer skizziert (Zusammenfassung):

The attacker in this case sent two different phishing emails over a two-day period. The two emails were sent to two small groups of employees; you wouldn’t consider these users particularly high profile or high value targets. The email subject line read “2011 Recruitment Plan.” (…) The spreadsheet contained a zero-day exploit that installs a backdoor through an Adobe Flash vulnerability (CVE-2011-0609). (…) As you know, the next step in a typical APT is to install some sort of a remote administration tool that allows the attacker to control the machine. In our case the weapon of choice was a Poison Ivy variant set in a reverse-connect mode that makes it more difficult to detect, as the PC reaches out to the command and control rather than the other way around.

So schien es, als würde wirklich jemand eine zielgerichtete Attacke gegen RSA umsetzen wollen. Die technische Umsetzung dieser war jedoch nicht besonders ausgeklügelt, da sie sich vorwiegend auf altbekannte Mechanismen und Schwachstellen verliess. Ob die Angreifer wirklich von Anfang an darum bemüht waren, technische Details zur SecurID-Lösung zu erlangen, lässt sich zur Zeit nicht sagen.

Mutmassungen und Gerüchte

Nach Veröffentlichung dieser Mitteilung wurde auf Twitter, in Blogs und den Medien sehr viel über den Fall berichtet. Aufgrund der sehr dünnen Faktenlage wurden Mutmassungen in alle Richtungen angestossen. Zuerst ging man davon aus, dass technische Details zur Umsetzung der RSA-Lösung – vielleicht sogar der Programmcode der eingesetzten Komponenten – gestohlen wurde.

Dies wäre vor allem für Mitbewerber von Interesse, die um den Nachbau oder die Herstellung von kompatiblen Komponenten bemüht sind. Für die Sicherheit der Lösung hätte dies eigentlich, wäre sie denn designtechnisch intelligent umgesetzt, keinen weitreichenden Einfluss. Denkbar wäre das Finden und Ausnutzen einer bis dato unbekannten technischen Schwachstelle.

Viel eher ist jedoch anzunehmen, dass das Root Seed File gestohlen wurde. Hierbei handelt es sich um einen 16-stelligen Code, der für die Individualisierung aller Token eingesetzt wird. Der Seed hat direkten Einfluss auf die Generierung der Codes durch das Token. RSA speichert die Zuweisung der Seeds zu Token, um eine entsprechende Authentisierung beglaubigen zu können.

Befindet sich jemand im nur Besitz dieser Seed-Daten, kann er theoretisch keinen Rückschlüss der Zuweisung zu einem Token umsetzen. Es bleibt zu hoffen, dass RSA die Seets getrennt von der Zuweisung aufbewahrt hat und sie nicht zusammen im Rahmen des Angriffs entwendet wurden.

Doch auch mit einem Seed alleine können für einen Angreifer Vorteile entstehen. Durch das Mitlesen eines legitimen Token-Codes und das Wissen dessen zugrundeliegenden Seeds kann er ein Reverse Engineering anstreben und dadurch zukünftigen Token-Codes errechnen. Damit wäre der Zeitfaktor, der als entscheidender Vorteil von SecurID-Lösungen gilt, nichtig. Befindet sich ein Angreifer einmal im Besitz eines legitimen Codes, kann er nach Belieben das Token auf mathematischer Ebene emulieren.

Ein davon betroffenes Token gilt als in der Praxis gebrochen und muss zurückgesetzt werden. Dies ist mit erheblichem Aufwand für die Nutzer und Betreiber einer SecurID-Lösung verbunden. Die Anwender müssen die Token zurückschicken, die Betreiber diese zurücksetzen und wieder ausliefern.

Weiteres Vorgehen und Empfehlungen

Es ist fragwürdig, warum sich RSA in Bezug auf technische Details und Konsequenzen des Problems sehr bedeckt hält. Das Hinauszögern der durch die Kunden erwarteten Transparenz scheint lediglich den Angreifern in die Hände zu spielen. Der grosse Nachteil wird hierbei auf die Kunden abgewälzt.

Angeblich hat RSA vorgängig grössere Regierungsbehörden über den Zwischenfall informiert, damit diese grundlegende Massnahmen ergreifen können. Mittlerweile mehren sich auch die Berichte unserer Kunden, dass diese zwischenzeitlich auf die Nutzung von SecurID verzichten und stattdessen andere Mechanismen zur strengen Authentisierung einsetzen werden (z.B. Konkurrenzprodukte, SMS, TAN, etc.). EMC führt unabhängig davon einige generische Massnahmen in einem publizierten PDF-Dokument auf.

Wir raten unseren Kunden in Hochsicherheitsumgebungen ebenfalls zu diesem Schritt. SecurID-Lösungen in weniger kritischen Umgebungen sollten unter Beobachtung gestellt und bei verdächtigen Aktivitäten sofort reagiert werden. Bisher sind keine Angriffsversuche, die in verlässlicher Weise auf den genannten Datendiebstahl zurückzuführen sind, bekannt. Werden solche publik, sollte aber unbedingt sofort reagiert werden.

Update 23. März 2011 09:30 Uhr

Erweiterung der Mutmassungen bezüglich Zuweisung Seed/Token und 0-Day Schwachstellen.

Update 27. März 2011 17:15 Uhr

In der vergangenen Woche wurde unser Stefan Friedli von der Gratiszeitung 20 Minuten zum Fall interviewt. Sein Expertenkommentar ist ebenfalls online verfügbar. Ebenso wurde die Mutmassung der schon umgesetzten erfolgreichen Angriffe hinzugefügt.

Update 02. April 2011 17:15 Uhr

RSA hat einige grundlegende technische Details zur Umsetzung des Angriffs publik gemacht. Die darin enthaltenen Aussagen wurden in die Auflistung der Fakten übernommen.

Update 05. April 2011 11:30 Uhr

Der Hinweis auf das RAT-Tool Poison Ivy wurde den Fakten hinzugefügt. Zudem wurde das ursprüngliche Statement bezüglich APT (Advanced Persistant Threat) relativiert.

Update 30. Mai 2011 08:45 Uhr

Hinweis auf den vermeintlich erfolgreichen Angriff auf Lockheed Martin Corp als Mutmassung hinzugefügt.

Update 01. Juni 2011 13:50 Uhr

Hinweis auf den vermeintlich erfolgreichen Angriff auf L-3 Communications sowie die Mutmassung der Möglichkeit des Klonen von SecurID-Token hinzugefügt.

Update 06. Juni 2011 08:30 Uhr

Anpassung des Hinweis von Lockheed Martin, dass der identifizierte Angriff auf ihre Infrastruktur tatsächlich auf den Einbruch bei RSA zurückzuführen ist.

Update 07. Juni 2011 12:45 Uhr

Art Coviello erklärt in einem offenen Brief, dass die kompromittierten SecurID-Token ersetzt werden sollen.

Update 11. Oktober 2011 19:45 Uhr

Art Coviello und Tom Heiser nutzten ihre Eröffnungsansprachen zur RSA Conference in London, um Einzelheiten der Angriffe im März zu erläutern. Dabei äusserten sie die Vermutung, dass voraussichtlich staatliche Stellen hinter dem erfolgreichen Angriff stecken. Hierbei konnten zwei unabhängig voneinander agierende Gruppen als potentielle Täterschaft ausgemacht werden. Ziel des Angriffs war angeblich nicht RSA selber, sondern mittelfristig die Kunden des Unternehmens.

Update 13. Februar 2012 10:15 Uhr

Das Paper Command and Control in the Fifth Domain diskutiert die technischen Hintergründe des Angriffs. Dabei werden die Infektions- und Kommunikationswege im Detail besprochen.

Über den Autor

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

• http://bit.ly/f43iHn
• http://blogs.rsa.com/rivner/anatomy-of-an-attack/
• http://de.wikipedia.org/wiki/SecurID
• http://heise.de/-1210245
• http://it.slashdot.org/comments.pl?sid=2042624&cid=35524592
• http://it.slashdot.org/comments.pl?sid=2042624&cid=35526850
• http://it.slashdot.org/story/11/03/17/2321226/RSAs-Servers-Hacked
• http://nakedsecurity.sophos.com/2011/04/04/rsa-release-details-on-security-breach/
• http://securosis.com/blog/rsa-breached-secureid-affected
• http://taosecurity.blogspot.com/2011/03/initial-thoughts-on-rsa-apt.html
• http://threatpost.com/en_us/blogs/paul-kocher-rsa-attack-032211
• http://twitter.com/#!/indi303/status/50333176823951360
• http://twitter.com/#!/mruef/status/48692062056497152
• http://www.20min.ch/finance/news/story/30231747
• http://www.commandfive.com/papers/C5_APT_C2InTheFifthDomain.pdf
• http://www.heise.de/security/meldung/RSA-Wir-wurden-von-einem-Staat-gehackt-1359373.html
• http://www.nsslabs.com/research/analytical-brief-rsa-breach.html
• http://www.nytimes.com/2011/03/19/technology/19secure.html
• http://www.nytimes.com/2011/06/04/technology/04security.html
• http://www.reuters.com/article/2011/05/27/us-usa-defense-hackers-idUSTRE74Q6VY20110527
• http://www.rsa.com
• http://www.rsa.com/node.aspx?id=3872
• http://www.rsa.com/node.aspx?id=3891
• http://www.wired.com/threatlevel/2011/05/l-3/