Skip to content

Gezielter Angriff auf RSA mit unabsehbaren Folgen

Mitte März meldete RSA einen gezielten Angriff, bei dem nicht näher beschriebene Daten ausgespäht wurden. Darunter befanden sich auch Informationen über die SecurID-Token zur Zwei-Faktor-Authentifizierung. Ebenfalls Mitte März meldete Adobe eine 0-Day-Schwachstelle im Flash Player, die über präparierte Excel-Dateien im Rahmen gezielter Angriffe ausgenutzt wurde. Ein Zusammenhang zwischen beiden Vorfällen war damals nicht erkennbar. Ein Angriff über die Flash-Schwachstelle wurde im Blog contagio analysiert, als "Köder" diente der GAU in Japan.

RSA ein Opfer der gezielten Angriffe

Inzwischen hat RSA einige Details über den Angriff veröffentlicht. Auch wenn der Artikel am 1. April veröffentlicht wurde, handelt es sich leider um keinen Aprilscherz.

Der Angriff bestand aus zwei verschiedenen E-Mails mit dem Subject "2011 Recruitment Plan.", die innerhalb von zwei Tagen an zwei relativ kleine Gruppen von RSA-Mitarbeitern geschickt wurden (die Angreifer scheinen eine Vorliebe für die Zahl 2 zu haben). Die E-Mails wurden als Spam eingestuft, aber einer der Mitarbeiter holte die Mail aus seinem Spam-Ordner heraus und öffnete die angehängte Datei "2011 Recruitment plan.xls".

Das ist dem Mitarbeiter aber kaum vorzuwerfen, denn er hat genau dass getan, was er und sicher auch jeder andere, der in einem Büro und mit Computern arbeitet, immer wieder mal machen muss: Eine anscheinend fälschlich als Spam eingestufte wichtige Mail aus dem Spam-Ordner gerettet und die angehängte Excel-Datei geöffnet. Dass diese Mail zu Recht im Müll gelandet war, kann er ja nicht wissen. Der Angreifer hat sicher durch einen passenden Absender dafür gesorgt, dass die Mail wichtig erscheint, und der Inhalt der Mail war laut RSA-Bericht auf jeden Fall überzeugend. Und wenn dann der Virenscanner nicht über die angehängte Datei meckert, besteht ja wohl kein Grund, die nicht zu öffnen. Dass man sowas nicht macht, weiß jeder, der sich mit IT-Sicherheit oder auch nur IT auskennt. Aber das wissen auch die Angreifer, die sich deshalb gezielt ganz normale Mitarbeiter als Ziel aussuchen. Wer als normaler Benutzer noch nie eine wichtige Mail aus dem Spam-Ordner gefischt und noch nie eine nicht angekündigte Datei ohne Rückfrage geöffnet hat, darf den ersten virtuellen Stein werfen...

Dass diese Excel-Datei präpariert war und über die 0-Day-Schwachstelle im Flash Player eine Hintertür in Form eines Fernwartungs-Tools installierte, dürfte nach den Vorbemerkungen wohl zu erwarten gewesen sein. Vom kompromittierten Rechner und Benutzerkonto aus arbeitete der Angreifer sich dann weiter in das RSA-Netz vor. Nachdem er Zugriff auf für ihn interessante Server erhalten hatte, kopierte er von dort Daten auf einen anderen lokalen Server, wo er sie zusammenfasste, komprimierte und verschlüsselte. Danach wurden die Daten über FTP auf einen externen Server übertragen. Dabei wurde der Angriff von RSA entdeckt. Welche Daten ausgespäht wurden, verrät RSA immer noch nicht. Vermutlich weiß man es selbst nicht so genau, schließlich sieht man es den kopierten Daten ja nicht an, dass sie kopiert wurden.

Auswirkungen auf SecurID

Da RSA nicht verrät, was der Angreifer ausspähen konnte, lassen sich die Auswirkungen auf die Sicherheit der SecurID-Authentifizierung nicht abschätzen. In der ersten Bekanntmachung heißt es dazu nur

"Some of that information is specifically related to RSA's SecurID two-factor authentication products. While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations."

Die SecurID-Token erzeugen alle 60 Sekunden ein neues Einmalpasswort, dass mit dem AES-Algorithmus aus einem zufälligen Schlüssel und einem Zeitindex berechnet wird. Der Benutzer gibt beim Einloggen dann seinen Benutzernamen, eine nur ihm bekannte PIN und das erzeugte Einmalpasswort ein, die Authentifizierung erfolgt also anhand zweier Faktoren: Wissen (der PIN) und Besitz (des Tokens). Die Sicherheit der SecurID-Token basiert darauf, dass der Schlüssel für die Erzeugung der Einmalpasswörter, der sog. Seed, nicht bekannt ist. Konnte der Angreifer Seeds ausspähen, kann er für jedes zugehörige Token die Einmalpasswörter berechnen. Um sich als ein bestimmter Benutzer ausgeben zu können, muss der Angreifer also "nur noch" den Benutzername und die PIN abphishen und heraus bekommen, welches Token der Benutzer verwendet (d.h. z.B. welche Seriennummer es hat).

Inzwischen gibt es von RSA einen Anweisung "Required Actions for SecurID Installations", die in einem Bericht ("Form 8-K") an die US-amerikanische Börsenaufsicht (U.S. Securities and Exchange Commission) enthalten ist (PDF). Diese enthält eine Reihe vom Empfehlungen, die eigentlich nur einen Schluss zulassen: RSA rechnet damit, dass die SecurID-Token nutzlos sind. Warum sonst sollten die RSA-Kunden alles tun, um ihre Systeme bestmöglich abzusichern und auf mögliche Angriffe zu überwachen? Demnach hätte der Angreifer Seeds ausgespäht.

Abwehr von Advanced Persistent Threat (APT)

Der Angriff auf RSA wird, ebenso wie die Angriffe auf Google und andere Unternehmen im Rahmen der "Operation Aurora" als sog. "Advanced Persistent Threat" (APT) eingestuft. Wie man diesen Angriffe, die oft mit einem "Spear Phishing", also einem gezielten Angriff auf Mitarbeiter, beginnen, begegnen kann, wurde von RSA am 18. Februrar in einem Blogartikel angesprochen. Evtl. während der Angriff gerade lief, gegen den Anti-Phishing-Maßnahmen sowieso nutzlos gewesen wären.

Denn in der Hinsicht greift auch der im Beitrag verlinkte RSA Security Brief (PDF) zu kurz: Es handelt sich in der Tat um gezielte Angriffe auf Mitarbeiter, aber bei weitem nicht nur um Phishing. Die Verwendung des Begriffs "Spear Phishing" halte ich in diesem Zusammenhang für gefährlich verharmlosend. Beim Angriff auf Google wurden die Mitarbeiter auf eine präparierte Webseite gelockt, auf der ihnen im Rahmen einer Drive-by-Infektion über eine 0-Day-Schwachstelle im Internet Explorer der Schadcode untergeschoben wurde, beim Angriff auf Google reicht das Öffnen der angehängten präparierten Excel-Datei. Bei beiden Angriffen gab es mit Sicherheit keine typischen Hinweise auf Phishing. Denn am abphishen von Zugangsdaten hatten die Angreifer gar kein Interesse.

Es ist also nicht ausreichend, die Benutzer vor gezielten Phishing-Angriffen zu warnen, sie müssen darüber aufgeklärt werden, dass alles, was Sie zugeschickt bekommen, egal ob über E-Mail, Instant Messaging, Social Networks, Datenträger, ... schädlich sein kann. Das Problem dabei: Entweder, sie werden so paranoid, dass sie nichts mehr öffnen und damit auch nicht mehr arbeiten können, oder sie arbeiten weiter und fallen u.U. irgend wann doch mal einem Angriff zum Opfer.

Schutz vor dem Benutzer

Angriffe der APT-Kategorie zeigen ein grundsätzliches Problem der IT-Sicherheit auf: Es ist kein Problem, ein besonders schutzbedürftiges System vor Millionen unerwünschter Angreifer abzuschotten. Es ist aber sehr wohl ein Problem, bösartige Zugriffe des u.U. einzigen zulässigen Benutzers zu erkennen.

Wie unterscheidet man erwünschte Zugriffe des authentifizierten Benutzers von solchen, die eingeschleuste Schadsoftware in seinem Namen durchführen? Wenn der Benutzer mehrmals am Tag ganz regulär Daten abfragt, und ein eingeschleuster Trojaner dass dann zusätzlich ein weiteres Mal macht, dann sehen diese Zugriffe für das angegriffene System völlig identisch aus: Sie kommen alle vom richtigen Rechner, sie weisen alle die korrekten Zugangsdaten des Benutzers auf, es gibt nichts, dass auf einen Missbrauch hindeutet. Man könnte natürlich für jeden Zugriff die Eingabe eines Einmal-Passworts verlangen (wobei man dann sicherheitshalber wohl kein SecurID-Token verwenden sollte) - aber wie praktikabel ist das? In den meisten Fällen würde der Benutzer damit so sehr behindert, dass er seine eigentlichen Aufgaben nicht mehr erfüllen kann.

Es gibt zwar Ansätze, abnormales Verhalten zu erkennen - aber die funktionieren nur, wenn die Angreifer so dumm sind, sich verdächtig zu verhalten. Und wer er schafft, sich in einem lokalen Netz heimlich bis zum ihn interessierenden Server vorzuarbeiten, wird bestimmt alles daran setzen, dann nicht durch abnormales Verhalten aufzufallen.

Fazit

Es gibt viel zu tun - fangen wir an. Aber immer schön ruhig und vorsichtig. Denn die typischen Opfer solcher gezielten Angriffe sind die ganz normalen Mitarbeiter. Und die sollen ja arbeiten und nicht aus Sicherheitsgründen an der Arbeit gehindert werden.

Am besten wäre es, die gezielten Angriffe würden ihre Empfänger gar nicht erst erreichen. Was nicht im Spam-Ordner auf dem Benutzerrechner liegt, kann vom Benutzer auch nicht heraus geholt werden. Wenn eine evtl. falsch aussortierte E-Mail erst über die IT-Abteilung angefordert werden muss, wird sie dort hoffentlich als Angriff erkannt und dann gelöscht. Wie sich das mit geltenden Datenschutzbestimmungen vereinbaren lässt, ist dann wieder ein anderes Problem...

Ach so: Brian Krebs berichtet über ein paar Hintergründe des Angriffs, der evtl. ebenso wie die Angriffe der Operation Aurora von China ausgegangen sein könnten. Oder von jemanden, der möchte, dass China verdächtigt wird. Entzückend!

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Flash Player und 0-Day-Exploit - eine unendliche Geschichte

Vorschau anzeigen
Es gibt (bzw. gab) schon wieder eine 0-Day-Schwachstelle im Flash Player. Im Unterschied zur vorigen 0-Day-Schwachstelle wurde diese schon innerhalb von 5 Tagen geschlossen. Aber immer der Reihe nach... 11.4. - 0-Day-Schwachstelle ver&oum

Dipl.-Inform. Carsten Eilers am : Remote Administration Toolkits - Fernwartung in der Grauzone

Vorschau anzeigen
Ein Remote Administration Toolkit, teilweise auch als Remote Administration Trojan oder Tool bezeichnet, aber in allen Fällen mit RAT abgekürzt, erlaubt die Fernwartung eines Rechners. Die kann sowohl von Administratoren z.B. zur Beseitigu

Dipl.-Inform. Carsten Eilers am : RSA und die unsicheren SecurID Token

Vorschau anzeigen
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 ha

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 : Digitale Schutzimpfung

Vorschau anzeigen
Heise Security hat festgestellt, dass einige Virenscanner bei der Erkennung eines minimal manipulierten Staatstrojaners versagen und die Erkennungsleistung auch sonst zu wünschen übrig lässt. Wundert das irgend jemanden? Virensc

Dipl.-Inform. Carsten Eilers am : Das RAT, das aus dem Stuxnet kam

Vorschau anzeigen
Mehrere Antiviren-Hersteller haben einen neuen Schädling entdeckt, der teilweise als Stuxnet-Ableger bezeichnet wird. Da ist aber zumindest etwas irreführend. Der Duqu genannte neue Schädling weist einige Parallelen zu Stuxnet auf,

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 : Neues zur Sicherheit von Clients, nicht nur im Web

Vorschau anzeigen
Auch in dieser Folge gibt es einen Überblick über die 2011 auf Sicherheitskonferenzen vorgestellten neuen Angriffe und mögliche Schutzmaßnahmen. Den Anfang macht noch einmal der Web-Client, bevor wir dann zu vom Web unabhän

Dipl.-Inform. Carsten Eilers am : Kann man Advanced Persistent Threats erkennen?

Vorschau anzeigen
Die "Operation Aurora", Stuxnet und der Angriff auf RSA - drei bekannte Advanced Persistent Threats und zwei entscheidende Fragen: Kann man solche Angriffe erkennen, und wenn ja: Wie? Der eigentliche Angriff Fangen wir mit dem eigentlic

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.

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!