Dipl.-Inform. Carsten Eilers

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