Proceedings - IT-Sicherheitsinfrastrukturen

Transcrição

Proceedings of the
st
1 Conference Seminar
on IT Security
ITSEC@i1 ’11
Erlangen, January 24th, 2011
Chair for IT Security Infrastructures
University of Erlangen-Nuremberg
ITSEC@i1 2011
Programme committee
• Zinaida Benenson (Universität Mannheim)
• Hans-Georg Eßer (Universität Erlangen-Nürnberg)
• Felix Freiling (Universität Erlangen-Nürnberg, Vorsitz)
• Christian Moch (Universität Erlangen-Nürnberg)
• Tilo Müller (Universität Erlangen-Nürnberg)
• Michael Spreitzenbarth (Universität Erlangen-Nürnberg)
• Stefan Vömel (Universität Erlangen-Nürnberg)
Additional reviewers
• Julian Hammer (Universität Erlangen-Nürnberg)
• André Hanak (Universität Erlangen-Nürnberg)
• Mykola Protsenko (Universität Erlangen-Nürnberg)
• Sergiy Protsenko (Universität Erlangen-Nürnberg)
• Kilian Redel (Universität Erlangen-Nürnberg)
• Arne Hendricks (Universität Erlangen-Nürnberg)
2
ITSEC@i1 2011
Inhaltsverzeichnis
• Ein Überblick über verschiedene Schwachstellen des Privaten Modus bei aktuellen
Browsern
André Hanak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
• Verified by Visa und MasterCard SecureCode, oder: Wie man die Authentifizierung
nicht
entwerfen sollte
Sergiy Protsenko . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
• (Un-)sicherheit in komplexen Systemen
Kilian Redel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
• Practical capabilities for UNIX
Mykola Protsenko . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
• An MD5 collision based attack on the SSL key infrastructure
Julian Hammer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3
Ein Überblick über verschiedene Schwachstellen des Privaten Modus bei . . .
ITSEC@i1 2011
2-1
Ein Überblick über verschiedene Schwachstellen
des Privaten Modus bei aktuellen Browsern
André Hanak Universität Erlangen
Zusammenfassung—Der Beitrag beschreibt, wie es möglich ist
das Surfverhalten eines Nutzers zu analysieren, obwohl dieser
den Privaten Modus seines Browsers verwendet. Besonderer Wert
wird dabei auf zwei Angriffsszenarien gelegt: Auf der einen Seite
wird erläutert, wie die Analyse des Nutzerverhaltens auf der
Seite eines Webseitenbetreibers aussehen kann. Dies betrifft vor
allem, inwiefern man Benutzer während ihrer Aktivitäten im
Internet verfolgen kann. Auf der anderen Seite wird untersucht,
ob eine Person, die lokal vollen Zugriff auf den Computer hat,
an Daten gelangen kann, die eigentlich durch den Privaten
Modus geschützt werden sollen. Dabei werden verschiedene
Szenarien erläutert und beispielhaft bekannte Schwachstellen
genauer untersucht.
Browser wird anschließend untersucht wie die Browserhersteller den Privaten Modus ankündigen und danach eine Studie zu
dessen Verwendung vorgestellt. Im Kapitel III geht es weiter
ins Detail, dort werden Sicherheitsziele definiert, die Browser
einhalten sollen. Etwas praktischer werden dann die Einzelheiten der Implementierungen in Kapitel IV analysiert und Abweichungen vom definierten Sicherheitsmodell deutlich herausgearbeitet. Nach einer Aufzählung der Sicherheitslücken in
den Browsern selbst, werden anschließend Probleme erläutert,
die bei Verwendung von Erweiterungen auftreten. Dabei wird
auch auf einen Lösungsvorschlag näher eingegangen und dieser hinsichtlich der Praxistauglichkeit bewertet.
I. E INF ÜHRUNG
II. G RUNDLAGEN
Um die Sicherheit des Privaten Modus zu untersuchen ist
es zunächst einmal nötig Grundlagen zu erläutern. Es folgt
eine Übersicht über die verschiedenen Browser und ihre Art
Private Browsing umzusetzen.
Der Private Modus ist in den letzten Jahren zu einem
beliebten Feature in Browsern geworden. Die vier am weitesten verbreiteten Browser [10] (stand Oktober 2010) Firefox,
Internet Explorer, Chrome und Safari unterstützen diesen in
ihren aktuellen Versionen. Durch die Verwendung soll im
Allgemeinen verhindert werden, dass andere Personen herausfinden können welche Internetseiten besucht wurden, während
der Private Modus aktiviert war.
In einem Konferenzbeitrag von Aggarwal, Bursztein, Jackson und Boneh mit dem englischen Titel An Analysis of
”
Private Browsing Modes in Modern Browsers“ [1] analysieren
die Autoren die Sicherheit dieser Modi exakt. Sie zeigen in
diesem Artikel wie man automatisiert nach Sicherheitslücken
suchen kann und stellen die Ergebnisse vor. Dieser Beitrag
steht inhaltlich in engem Zusammenhang mit meiner Arbeit.
Der oben genannt Beitrag nennt zwei im Grundsatz verschiedene Sicherheitsziele. Auf der einen Seite steht der
Schutz vor Personen, die vollen Zugriff auf den verwendeten
Computer haben. Sie werden als lokaler Angreifer bezeichnet.
Es könnten beispielsweise Familienmitglieder sein, die sich
einen Rechner teilen. Auf der anderen Seite steht der Schutz
vor Personen, die über diesen direkten Zugang nicht verfügen,
dem entfernten Angreifer. Beispielsweise soll der Betreiber
einer Internetseite keinen Zusammenhang zwischen dem Besuch seines Angebots mit und ohne Privaten Modus herstellen
können. Letzteres wird von den aktuellen Browsern oft nur
teilweise oder überhaupt nicht umgesetzt.
Dieser Beitrag ist nach dem Top-Down Ansatz gestaltet.
Am Anfang steht eine Einführung in den Privaten Modus.
Beginnend mit einem kurzen Überblick über die verschiedenen
Dieser Beitrag entstand im Rahmen des Konferenzseminars IT”
Sicherheit“, das im Wintersemester 2010/11 an der Universität ErlangenNürnberg durchgeführt wurde. Es wurde organisiert vom Lehrstuhl für ITSicherheitsinfrastrukturen (Prof. Dr. F. Freiling).
André Hanak
A. Überblick über die vier Browser
Der Firefox Browser von Mozilla unterstützt den Privaten
Modus ab Version 3.5 vom 30.06.2009 [7]. Er lässt sich
über das Extras“ Menü starten. Dabei werden alle aktuell
”
geöffneten Fenster und Tabs geschlossen. Abgesehen von
einem Vermerk in der Titelleiste des Fensters weist während
der Verwendung nichts auf die private Sitzung hin. Beendigt
wird sie wieder über das Menü Extras“. Vorher geöffnete Tabs
”
und Fenster werden wieder hergestellt.
Der Internet Explorer von Microsoft unterstützt die Funktion
ab Version 8 [6]. Die Funktion heißt hier InPrivate-Browsen“.
”
Startet man den Modus, so wird ein neues Fenster geöffnet.
Der Benutzer bekommt durch eine Schaltfläche auf der Adressleiste mit der Aufschrift InPrivate“ angezeigt, dass er diese
”
Funktion gerade verwendet.
Google Chrome nennt das Feature Inkognito Modus“.
”
Dieser lässt sich öffnen, indem man auf die EinstellungsSchaltfläche klickt und dann ein neues Inkognito Fenster über
das Menü öffnet. Der Benutzer wird auf den Privaten Modus
mit Hilfe eines Icons hingewiesen.
In Safari heißt der Modus Privates Surfen“ er lässt sich
”
über das Optionsmenü starten. Es erscheint eine Dialogbox,
die bestätigt werden muss. Anschließend befinden sich alle
geöffneten Fenster im Privaten Modus. Im Safari 4 ist der
einzige Hinweis auf die Verwendung ein Haken vor dem
entsprechenden Menüeintrag. Seit Safari 5 befindet sich auch
noch ein entsprechender Hinweis in der Adressleiste.
Details zu den Implementierungen werden in Kapitel IV-A
genauer untersucht.
4
ITSEC@i1 2011
2-2
Abbildung 1: Verwendung des Privaten Modus [1]
B. Vermarktung des Privaten Modus
Es gibt unterschiedliche Gründe den Privaten Modus zu
verwenden. Alle vier Browserhersteller präsentieren das Feature auf ihren Internetseiten. Im Folgenden möchte ich kurz
zusammenfassen welche Gründe für die Benutzung genannt
werden und wovor der Private Modus exakt schützt.
Firefox beschreibt auf der Internetseite [8] sehr exakt was
den Privaten Modus von einer einer normalen Sitzung unterscheidet. Interessant ist dabei vor allem ein Absatz, in
dem klargestellt wird, dass kein Schutz vor einem entfernten
Angreifer besteht, obwohl man beim Firefox sehr wohl bemüht
ist davor Schutz zu bieten. Ein Grund zur Verwendung des
Privaten Modus wird nur sehr allgemein formuliert: Teilt man
sich mit anderen Personen einen Rechner, dann möchte man
vermeiden, dass diese Personen herausfinden können welche
Internetseiten man besucht hat.
Auf der Seite des Internet Explorer [6] heißt es: Endlich
”
können Sie ein besonderes Geschenk bestellen, ohne dass die
Familie versehentlich darüber stolpert, oder einen freigegebenen Computer verwenden, ohne Spuren zu hinterlassen.“. Vor
was der Modus genau schützt ist nicht beschrieben.
Das Planen von Überraschungen oder Geburtstagen nennt
Google auf der Internetseite zu Chrome [5]. Dabei wird
zusätzlich noch einmal darauf hingewiesen, dass heruntergeladene Dateien auf dem Computer vorhanden bleiben und dass
Internetseiten das Ziel des Inkognito Modus unter Umständen
untergraben können.
C. Studie über die Benutzung des Privaten Modus
Aggarwal, Bursztein, Jackson und Boneh [1, S. 8] führten
eine Studie durch, in der sie die Verwendung des Privaten
Modus verschiedener Browser bei verschiedenen Kategorien
von Internetseiten untersuchen. Zur Ermittlung dieser Daten
wurden Werbeanzeigen geschaltet. Diese enthielten JavaScript
Code, der erkennen kann ob der Private Modus gerade aktiviert ist. Um dies festzustellen nutzen die Entwickler aus,
dass alle gängigen Browser noch nicht besuchte Links in
blau darstellen, während Seiten, die in der Browserchronik
bereits vorhanden sind lila eingefärbt werden. Ein Link zu
einer bereits in einem Frame angezeigten Seite wird also
normalerweise immer lila dargestellt. Eine Ausnahme stellt
das Verhalten im Privaten Modus dar: Hier sind alle Links in
blauer Schriftfarbe, da keine Chronik existiert.
Die Ergebnisse sind in Abbildung 1 dargestellt. Aus der
Grafik kann man zwei Aussagen direkt ableiten. Zum einen
André Hanak
fällt auf, dass auf Erotikseiten der Private Modus verstärkt eingesetzt wird, andererseits hängt die Verwendung auch deutlich
vom Typ des Browsers ab.
Während auf Erotikseiten im Durchschnitt etwa 8% den
Privaten Modus verwenden sind es bei Seiten auf denen
man Geschenke kaufen kann oder auf Nachrichtenseiten etwa
6%. Man kann also davon ausgehen, dass der Private Modus
nicht überwiegend dazu verwendet wird, um den Kauf von
Geschenken über das Internet zu verstecken.
Ein anderer interessanter Aspekt ist, dass die Häufigkeit
der Nutzung offensichtlich stark vom verwendeten Browser
abhängt. Benutzer von Safari und Firefox aktivieren den Privaten Modus offenbar wesentlich häufiger, als beispielsweise
diejenigen, die den Internet Explorer verwenden. Auf der
Grafik erkennt man, dass die Verwendung des Modus auf
Nachrichtenseiten zwischen 1% (Internet Explorer 8) und
knapp 10% (Mozilla Firefox) schwankt. Eine mögliche Erklärung für diese Statistik ist die Art und Weise, wie die
verschiedenen Browser auf den aktivierten Modus hinweisen.
Firefox und Safari weisen eher unauffällig darauf hin, während
der Indikator bei Google Chrome oder dem Internet Explorer
sehr viel auffälliger ist. Der Internet Explorer verwendet einen
Hinweis in der Adressleiste (Abbildung 2), hingegen zeigt
Abbildung 3 das deutlich sichtbare Icon von Google Chrome.
Im Gegensatz dazu ist im Firefox der Hinweis in der Titelleiste
(Abbildung 4) leicht zu übersehen. Bei Safari (Abbildung 5)
ist in der Version, die während der Studie aktuell war, auf
der normalen Oberfläche kein Hinweis zu sehen. Man kann
nur über das Einstellungsmenü herausfinden, dass der Private
Modus gerade verwendet wird. Es liegt also der Verdacht nahe,
dass ein leicht zu übersehender Indikator dazu führt, dass die
Benutzer vergessen den Privaten Modus wieder auszuschalten.
Eine weitere Ursache für die so unterschiedliche Nutzung
ist die unterschiedliche Implementierung in den Browsern.
Während Internet Explorer und Chrome das gleichzeitige
Surfen mit und ohne Privaten Modus durch das Öffnen eines
zusätzlichen privaten Fensters erlauben ist es bei Firefox und
Safari nicht möglich gleichzeitig privat und normal zu surfen.
III. S ICHERHEITSMODELL UND S ICHERHEITSZIELE
Um die Sicherheit des Privaten Modus zu untersuchen ist
es zunächst einmal nötig formal zu spezifizieren was dieser
genau leisten soll und vor welchen Angriffszenarien man sich
dabei schützen muss. Wie in dem Konferenzbeitrag [1, S. 2]
werden zwei Angriffszenarien definiert: Der lokale Angreifer
5
ITSEC@i1 2011
2-3
Abbildung 2: Bildschirmfoto Internet Explorer
Abbildung 4: Bildschirmfoto Firefox
Abbildung 3: Bildschirmfoto Chrome
Abbildung 5: Bildschirmfoto Safari
ist eine Person, die direkten Zugriff auf den Computer hat.
Das zweite Szenario sieht einen entfernten Angreifer vor.
Dieser kontrolliert die Internetseite, die im Privaten Modus
besucht wird. Ein weiterer Begriff ist der Benutzer, hiermit
wird im folgenden die Person bezeichnet, die den Privaten
Modus verwendet.
auf den Rechner, so ist es ein leichtes für den Angreifer
an diese Informationen zu kommen, ganz egal wie gut oder
schlecht der Private Modus im Browser implementiert ist. Beispielsweise könnte ein Keylogger installiert werden oder der
Netzwerkverkehr mitgehört werden. Der Angriff wird alleine
auf die anschließende Analyse beschränkt. Daher kann die
Sicherheit theoretisch dadurch gewährleistet werden, dass nach
Beendigung des Privaten Modus alle hinterlassenen Spuren
zuverlässig gelöscht werden.
Ganz so einfach stellt sich das dann aber doch nicht dar.
Da die verschiedenen Browser auch im Privaten Modus eine
möglichst hohe Benutzerfreundlichkeit erreichen sollen, ist es
nicht von Vorteil alle Veränderungen wieder zu löschen. So
soll es beispielsweise auch möglich sein im Privaten Modus
Lesezeichen anzulegen, die erhalten bleiben. Es ist also nötig
Änderungen zu klassifizieren:
1) Änderungen, die von der Internetseite angestoßen werden und keinerlei Interaktion des Benutzers benötigen,
beispielsweise Einträge im Cache, gespeicherte Cookies
oder Einträge in der Browserchronik.
A. Lokaler Angreifer
Vermieden werden soll im Falle des lokalen Angreifers, dass
auf dem Rechner nach Beendigung des Privaten Modus Spuren
zurückgelassen werden, die dem Angreifer Rückschlüsse auf
die besuchten Seiten zulässt. Konkret heißt das, dass ein
Angreifer, der die Kontrolle über den Rechner des Benutzers
übernommen hat, nachdem der Benutzer den Privaten Modus
beendet hat, keinerlei Informationen über das Verhalten des
Benutzers während des privaten Surfens erhalten darf. Dies
wird weiter unten genauer beschrieben.
Besonders wichtig ist dabei, dass der Angreifer erst Zugriff
erlangt, nachdem der Private Modus beendet wurde. Erlangt
er vorher oder auch während des privaten Surfens Zugriff
André Hanak
6
ITSEC@i1 2011
2-4
2) Änderungen, die von der Internetseite angestoßen werden, aber zusätzlich Interaktion des Benutzers benötigen.
Beispiele dafür sind das generieren eines Client Zertifikats oder das Speichern von Passwörtern.
3) Änderungen, die vom Benutzer angestoßen werden. Zum
Beispiel das Hinzufügen eines Lesezeichens oder das
Herunterladen einer Datei.
4) Änderungen, die nicht anwenderspezifisch sind. Hierunter fällt zum Beispiel das Installieren einer Browser
Aktualisierung oder das Aktualisieren der Liste zum
Schutz vor Phishing.
Alle Browser haben als Ziel Änderungen zu verwerfen, wie sie
im Punkt (1) beschrieben sind. Erfüllen sie dieses Ziel nicht,
so kann dies als Verstoß gegen das Sicherheitsmodell, also
als Sicherheitslücke, aufgefasst werden. Die restlichen Punkte
stellen eine Grauzone dar. Welche Arten von Änderungen
verworfen werden sollen unterscheidet sich stark, je nach
Browser. Aber auch das Verhalten eines Browsers ist oft inkonsistent. Diese Fälle werden im nächsten Kapitel ausführlich
beschrieben.
Um das Sicherheitsmodell exakter zu beschreiben werden
im folgenden die Fähigkeiten des Angreifers definiert:
• Der Angreifer tritt nicht in Aktion, bis zu dem Zeitpunkt,
an dem der Benutzer den Privaten Modus verlässt. Ab
diesem Zeitpunkt bekommt der Angreifer vollen Zugriff
auf die Maschine. Dies limitiert den Angreifer auf die
anschließende Analyse forensischer Art.
Dabei werden in dieser Arbeit Spuren ignoriert, die nur
im flüchtigen Speicher vorhanden sind. Diese Spuren
zu verwischen kann sehr kompliziert werden und kein
Browser besitzt momentan diese Fähigkeit.
• Eine weitere Voraussetzung ist, dass der Angreifer keinen
Zugriff auf Informationen im Netzwerk hat, während der
Benutzer in einer privaten Sitzung ist. Dies ist einfach
damit erklärbar, dass in der Arbeit die Sicherheit der
Browser untersucht werden soll. Ein Browser kann aber
beispielsweise nicht verhindern, dass der Netzwerkverkehr mitgeschnitten wird.
Ein Problem für die Einhaltung der Ziele von privatem
Browsern stellen die Internetseiten dar. Als Beispiel sei folgendes Szenario gegeben: Ein Benutzer loggt sich innerhalb
des Privaten Modus auf einem Forum ein. Dieses hat auf der
Hauptseite für alle Besucher sichtbar einen Abschnitt ”Benutzer, die heute Online waren”. In diesem Fall wird das Sicherheitsziel verletzt. Allerdings ist ein hundertprozentiger Schutz
technisch kaum realisierbar. Denkbare Lösungsmöglichkeiten
sind:
• Einführen einer Liste mit Internetseiten, ähnlich wie bei
Phishing, die im Privaten Modus nicht angezeigt werden
sollte.
• Einführung einer elektronischen Kennzeichnung auf Internetseiten, die angibt, dass diese Seite nicht gegen
Sicherheitsziele des Privaten Modus verstößt.
• Einführung eines Logos, welches nach Prüfung durch
eine offizielle Stelle auf einer Internetseite angezeigt
werden kann. Ist dieses Logo vorhanden weiß der Benutzer, dass die Seite im Privaten Modus gefahrlos besucht
André Hanak
werden kann.
Es gibt auch sonst verschiedene Schwierigkeiten beim Einhalten der Sicherheitsziele gegenüber einem lokalen Angreifer.
Eine davon ist das verwendete Betriebssystem. Dabei gibt es
zwei Probleme.
Ein Problem sind DNS1 Anfragen. Diese müssen für jede
besuchte Domain ausgeführt werden, dabei speichern viele
Betriebssysteme die Anfragen in einem lokalen Zwischenspeicher. Anhand der eingetragenen Domains und der zugehörigen
TTL2 lässt sich dann herausfinden welche Seite wann besucht
wurde. Eine korrekte Implementierung des Privaten Modus
darf also bei Durchführung der DNS Abfragen keine Einträge
im Zwischenspeicher des Systems hinzufügen oder entfernen. Eine andere, wesentlich aggressivere, Möglichkeit besteht
darin den kompletten DNS Zwischenspeicher zu leeren. Die
DNS Problematik wird jedoch momentan von keinem großen
Browser aufgegriffen.
Das andere Problem ist das Auslagern von Hauptspeicherseiten auf der Festplatte. Ist im Hauptspeicher zu wenig Platz,
dann kann das Betriebssystem Teile davon auf der Festplatte
auslagern. Dies erfolgt unter Windows in einer Auslagerungsdatei auf der Festplatte und unter Linux meist in einer extra
Partition auf der Festplatte. In dieser Datei oder Partition
könnten sich nur Informationen über das Nutzungsverhalten
befinden.
Aggarwal, Bursztein, Jackson und Boneh [1, S. 3] haben
ein Experiment durchgeführt, welches diese Theorie eindeutig
belegt: Unter Ubuntu 9.10 Linux und Firefox 3.5.9 surften
sie im Privaten Modus. Nach Beendigung starteten sie ein
Programm mit einem Speicherleck, so dass das Betriebssystem
gezwungen wurde Teile des Hauptspeichers auszulagern. In
diesem Fall wurde eine Auslagerungsdatei verwendet. Diese
Auslagerungsdatei wurde untersucht und es wurden darin
sowohl Internet Adressen, als auch Links und auch Text der
Internetseiten gefunden.
Zuletzt möchte ich ein paar Implementierungsmöglichkeiten
gemäß ihrer Realisierbarkeit erläutern. Eine auf den ersten
Blick sinnvoll erscheinende Variante ist die Verwendung von
Schnappschüssen (engl. snapshot) einer virtuellen Maschine.
Vor dem Surfen im Privaten Modus wird dann ein Schnappschuss angelegt. Wird der Modus beendet, so wird der Rechner
wieder auf den Stand vor dem Starten des Privaten Modus
zurückgesetzt. Dieses Verfahren hat aber sehr viele Nachteile,
so dass die Verwendung keinen Sinn macht: Änderungen, die
der Benutzer explizit selber veranlasst (siehe Punkte (3) und
(4) in obiger Aufzählung) werden danach wieder verworfen.
Dies betrifft Sicherheitsupdates, heruntergeladene Dateien und
Einstellungen wie die Startseite oder verwendete Symbolleisten. Dies führt zu schlechter Benutzerfreundlichkeit und
damit zu frustrierten Benutzern.
Eine sehr einfache Möglichkeit obige Lösung zu implementieren bieten Benutzerprofile wie sie beispielsweise Mozilla
1 DNS: Domain Name System, dient u.A. der Zuordnung von menschenlesbaren Namen zu IP Adressen
2 TTL: Time to live. Jeder Eintrag im Zwischenspeicher erhält ein Ablaufdatum. Kennt der Angreifer dieses und ist beispielsweise bekannt, dass dieses
beim Eintragen in den Speicher gewöhnlich eine Stunde in die Zukunft gesetzt
wird, so lässt sich der Zeitpunkt des Eintragens berechnen.
7
ITSEC@i1 2011
2-5
Firefox bereits verwendet. Man könnte beim Start des Privaten
Modus eine Sicherungskopie des Profils anlegen und diese
nach Beendigung wieder herstellen. Dieses Verfahren hat
aber im Wesentlichen dieselben Nachteile wie oben bereits
beschrieben.
Alle vier großen Browser verwenden die gleiche
Möglichkeit. Einerseits versuchen sie möglichst wenig
Daten zu speichern, so wird beispielsweise die Chronik erst
gar nicht mitgeschnitten. Andererseits werden Daten, die
gespeichert werden müssen, nach der Beendigung wieder
gelöscht. Cookies sind ein gutes Beispiel dafür. Soweit die
Theorie, tatsächlich werden jedoch nicht alle Daten korrekt
gelöscht, wie in Kapitel IV gezeigt wird.
Tabelle I: Welche Daten aus dem normalen Modus sind
während einer privaten Sitzung verfügbar? [1, S. 7]
B. Entfernter Angreifer
Tabelle II: Welche Daten aus dem Privaten Modus sind nach
Ende der Sitzung noch verfügbar? [1, S. 7]
Im Gegensatz zum lokalen Angreifer hat der entfernte
Angreifer keinen Zugriff auf den Computer des Benutzers.
Dafür kontrolliert er eine oder mehrere Internetseiten, die
der Benutzer mit Hilfe des Privaten Modus besucht hat. Die
meisten Browser versuchen auch vor diesem Angriffszenario
in einem gewissen Grad zu schützen. Eine Ausnahme stellt
Safari dar – der Browser ignoriert das Modell des entfernten
Angreifers komplett.
Ziele:
1) Besucht ein Benutzer dieselbe Internetseite sowohl mit
als auch ohne Privaten Modus, so darf der Webseitenbetreiber keine Verbindung zwischen diesen beiden
Seitenaufrufen herstellen können. Dieses Ziel wird bei
Chrome, Firefox und Internet Explorer zumindest teilweise implementiert indem Cookies im Privaten Modus
nicht verfügbar sind, die ohne Privaten Modus gesetzt
wurden.
2) Besucht der Benutzer eine Internetseite in zwei verschiedenen privaten Sitzungen, so darf es nicht möglich
sein den Zusammenhang zu einem Benutzer herzustellen Als Beispiel sei folgendes Szenario gegeben: Ein
Benutzer besucht eine Internetseite das erste mal ohne
Privaten Modus, danach ein zweites mal im Privaten
Modus. Anschließend nochmal ohne und beim vierten
und letzten mal wieder unter Schutz der Privatsphäre.
Anschließend soll der entfernte Angreifer nicht erkennen
können, dass es sich bei dem zweiten und vierten mal
um denselben Benutzer handelte. Dieses Ziel ist in
den Browsern zumindest teilweise dadurch umgesetzt,
dass Cookies wieder gelöscht werden, die während der
privaten Sitzung gespeichert wurden.
3) Eine Internetseite soll nicht in der Lage sein zu erkennen, ob der Private Modus gerade aktiviert ist oder nicht.
Wie in Kapitel II-C bereits erwähnt wurde, hat zur Zeit
der Studie von Aggarwal, Bursztein, Jackson und Boneh
[1] kein Browser dieses Ziel umsetzen können.
Die Ziele (1) und (2) sind für Browser sehr schwer einzuhalten. Es gibt zahlreiche Möglichkeiten Benutzer zu verfolgen
(engl. tracking), die – wenn überhaupt – nur mit enormen
Aufwand unterbunden werden können. Erkennungsmerkmale,
die dazu verwendet werden können sind beispielsweise die IP
André Hanak
Chronik
Cookies
Lokaler Speicher HTML5
Lesezeichen
Passwort Datenbank
Formular Autovervollständigung
Selbst signierte SSL Zertifikate
Einträge in der Download Liste
Heruntergeladene Dateien
Suchausdrücke und Suchfeld
Cache
Client Zertifikate
Anwender-spezifische Protokolle
Seiten-spezifische Zoomstufe
Chronik
Cookies
Lesezeichen
Passwort Datenbank
Cache
Client Zertifikate
FF
ja
nein
nein
ja
ja
ja
ja
nein
ja
ja
nein
ja
ja
nein
FF
nein
nein
nein
ja
nein
nein
nein
nein
ja
nein
nein
ja
ja
nein
Safari
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
nein
ja
n/a
n/a
Safari
nein
nein
nein
ja
nein
nein
ja
nein
ja
nein
nein
n/a
n/a
n/a
Chrome
nein
nein
nein
ja
ja
ja
ja
ja
ja
ja
nein
ja
n/a
ja
Chrome
nein
nein
nein
ja
nein
nein
ja
nein
ja
nein
nein
n/a
n/a
nein
IE
nein
nein
nein
ja
ja
nein
ja
n/a
ja
ja
nein
ja
n/a
n/a
IE
nein
nein
nein
ja
nein
nein
ja
n/a
ja
nein
nein
ja
n/a
n/a
Adresse, die Bildschirmauflösung, installierte Plugins, installierte Schriftarten oder die Zeitzone. Abgesehen von der IP
sind alle Eigenschaften über Javascript auslesbar. Die Electronic Frontier Foundation zeigte im Projekt Panopticlick [2, 3],
dass für nahezu alle Browser ein einzigartiger Fingerabdruck
(engl. Fingerprint) erstellbar ist, der dazu verwendet werden
kann Benutzer zu verfolgen und damit die Ziele (1) und (2)
komplett zu umgehen.
Torbutton [9] ist ein Browserplugin, welches mit Hilfe des
Tor3 Dienstes die IP Adresse verschleiert und gleichzeitig
Maßnahmen ergreift um das Erstellen eines Fingerabdrucks
zu erschweren. Die Verwendung des Plugins hat jedoch einen
erheblichen Verlust in Geschwindigkeit und Komfort zur Folge.
IV. A BWEICHUNGEN VON DEN S ICHERHEITSZIELEN
A. Unterschiede in den Implementierungen der verschiedenen
Browser
In Kapitel II-A wurde bereits ein Überblick über die verschiedenen Browser und deren Benutzeroberfläche gegeben.
Es werden unterschiedliche Indikatoren zur Kennzeichnung
des aktivierten Privaten Modus verwendet. Neben der Benutzerfreundlichkeit spielt bei der Wahl des Indikators auch
3 Tor ist ein Netzwerk zur Anonymisierung. Es verhindert die Identifikation
eines Benutzers anhand seiner IP Adresse, indem der Netzwerkverkehr über
zahlreiche Computer geleitet wird.
8
ITSEC@i1 2011
2-6
Tabelle III: Welche Daten sind während des Privaten Modus
verfügbar? [1, S. 7]
Chronik
Cookies
Lesezeichen
Passwort Datenbank
Cache
Client Zertifikate
FF
nein
ja
ja
ja
nein
nein
ja
ja
ja
nein
ja
ja
ja
nein
Safari
nein
ja
ja
ja
nein
nein
ja
nein
ja
nein
ja
n/a
n/a
n/a
Chrome
nein
ja
ja
ja
nein
nein
ja
nein
ja
nein
ja
n/a
n/a
ja
IE
nein
ja
ja
ja
nein
nein
ja
n/a
ja
nein
ja
ja
n/a
n/a
die Privatsphäre eine Rolle. Einer Person, die dem Benutzer
über die Schulter schaut, fällt es bei deutlich erkennbaren
Indikatoren leichter herauszufinden, ob der Modus aktiv ist.
Im Safari 4 wurde das Problem ernst genommen, im Firefox
fällt der Hinweis in der Titelleiste zumindest nicht sofort auf.
In allen anderen Browsern ist der Hinweis in oder neben der
Adressleiste deutlich erkennbar.
Im Folgenden soll das interne Verhalten genauer untersucht
werden. Aggarwal, Bursztein, Jackson und Boneh [1, S. 4]
haben untersucht, wie sich verschiedene Browserfunktionen im
Privaten Modus verhalten. Die Tests wurden unter Windows 7
mit den Standardeinstellungen der Browser durchgeführt. Die
Ergebnisse sind in den Tabellen I, II und III zusammengefasst.
Tabelle I beschreibt inwiefern im normalen Modus gespeicherte Daten im Privaten Modus zugreifbar sind. Das Erschweren des Zugriffs auf solche Daten dient im Wesentlichen
dem Schutz vor dem entfernten Angreifer aus III-B. Dass
Safari dieses Modell vollständig ignoriert sieht man in der
zweiten Spalte. Alle Daten, mit Ausnahme des Caches, sind
beim privaten Surfen zugänglich. Bei allen Browsern sind die
Chronik, Lesezeichen und gespeicherte Passwörter im Privaten
Modus verfügbar. Firefox, Chrome und der Internet Explorer
blockieren hingegen öffentlich gesetzte Cookies oder Inhalte
des HTML5 Speichers. In anderen Dingen verhalten sich die
Browser oft inkonsistent. So verwendet Firefox ohne Privaten
Modus generierte Client Zertifikate auch in diesem Modus.
Dies ist widersprüchlich zum Sperren von Cookies, denn mit
Client Zertifikaten lässt sich genauso wie bei Cookies eine
Verbindung zwischen dem Besuchen einer Seite mit und ohne
Privaten Modus herstellen.
Tabelle II zeigt, ob Daten, die während des Surfens im
Privaten Modus anfallen, auch nach Beendigung dieses Modus
noch verfügbar sind. Dies stellt den Kern des Privaten Modus
dar. Die Sicherheit vor einem lokalen Angreifer soll damit
gewährleistet werden. Alle Browser versuchen dieses Ziel umzusetzen. Allen Browsern ist gemeinsam, dass sie die Chronik,
Cookies und den HTML5 Speicher löschen. Alle übernehmen
Lesezeichen und heruntergeladene Dateien. Akzeptiert und
speichert ein Benutzer ein selbst signiertes SSL Zertifikat, so
wird dieses nur im Firefox wieder verworfen.
Tabelle III ist eine Übersicht darüber, welche Informationen während ein und derselben privaten Sitzung temporär
André Hanak
verfügbar sind. Firefox schreibt nichts in die Chronik, merkt
sich keine Passwörter oder Suchausdrücke. Im Gegensatz dazu
werden Cookies zunächst gespeichert und erst am Ende der
Sitzung gelöscht. Die Cookies und auch der Cache werden
aber nur im Arbeitsspeicher abgelegt, so dass nach einem
möglichen Absturz keine Spuren hinterlassen werden. Firefox
ist der einzige Browser, der im Privaten Modus Einträge in
die Download Liste schreibt. Auch diese werden allerdings
am Ende der Sitzung wieder gelöscht.
B. Schwachstellen aufgrund der Implementierungen und Inkonsistenzen
Aufgrund der oben genannten unterschiedlichen Implementierungen und Inkonsistenzen in den verschiedenen Browsern
entstehen bereits zahlreiche Probleme, die mit der Einhaltung
der Sicherheitsziele bezüglich der Privatsphäre im Widerspruch stehen. Ich möchte hier vier dieser Probleme beschreiben.
•
•
•
•
Ein Problem ist eine Funktion in HTML5, die sich
custom protocol handlers“ (CPH) nennt. Diese Funktion
”
erlaubt es Internetseiten eigene Protokolle zu definieren.
Das eigene Protokoll xyz“ kann in einer URL der
”
Form xyz://Adresse/Pfad“ verwendet werden. Firefox
”
speichert diese Daten jedoch auch nach Ende der privaten Sitzung. Verwendet eine vom Benutzer im Privaten
Modus besuchte Internetseite so ein CPH, so kann der
Angreifer im Nachhinein nachvollziehen, dass diese bestimmte Seite schon einmal besucht wurde.
Client Zertifikate sind ein weiteres Problem. Sie können
zur Autorisierung dienen und beispielsweise die Anmeldung über eine Session Cookie ersetzen. Auch diese
Funktion implementiert nur Firefox und behält das Zertifikat auch nach Ende der privaten Sitzung. Wurde im
Privaten Modus also eine Seite aufgerufen, die diese
Technik verwendet, so weiß der Angreifer zumindest,
dass die Seite schon einmal besucht wurde.
Ein weiteres Problem bei dem Zertifikate eine Rolle spielen stellen selbst signierte Serverzertifikate dar. Da von
einer vertrauten Authentifizierungsstelle unterschriebene
Zertifikate in der Regel kostenpflichtig sind, verwenden
viele Internetseiten selbst signierte Zertifikate oder lassen
sie von Zertifizierungsstellen signieren, die dem Browser
nicht bekannt sind. Diese Zertifikate müssen dann vom
Benutzer extra bestätigt werden und werden als Ausnahme gespeichert. Chrome, Internet Explorer und Safari
löschen diese Ausnahmen nicht nach Ende der Sitzung.
Ein Angreifer kann also wiederum herausfinden, welche
Internetseiten besucht wurden, für den Fall dass diese
solch ein Zertifikat verwenden.
Problematisch sind weiterhin SMB4 Anfragen beim Internet Explorer. Der Internet Explorer ermöglicht es beispielsweise Bilder von einem Rechner innerhalb des Windows Netzwerks einzubinden. Adressen haben dabei die
Form \\Rechnername\Pfad\Dateiname“. Ein entfernter
”
4 SMB: Protokoll, dass verwendet wird, um auf Windows Netzwerkfreigaben zuzugreifen
9
ITSEC@i1 2011
2-7
Angreifer kann also beispielsweise mit folgendem Code
aber eventuell überhaupt nicht bewusst. Die Ausnahmen
ein Bild auf der Internetseite einfügen:
werden in der Datei permissions.sqlite“ gespeichert.
”
•
Ein weiteres Problem sind Aktionen, die mit herunter<img src="\\1.2.3.4\bild.jpg" alt="" />
geladenen Dateien durchgeführt werden. Wenn Firefox
Dadurch versucht der Internet Explorer eine SMB Verauf einen unbekannten Dateityp trifft, dann fragt er
bindung mit dem Server des Angreifers mit der beispielden Benutzer wie damit verfahren werden soll. Genauso
haften Adresse 1.2.3.4 aufzubauen. Schlägt dann eine
verhält es sich mit unbekannten Protokollen. Klickt der
anonyme Verbindung fehl, so sendet der Internet Explorer
Benutzer auf einen Link mit einem Protokoll, das Firefox
im Rahmen der Autorisierung zahlreiche Daten wie den
nicht bekannt ist, so wird der Benutzer gefragt wie damit
Benutzernamen, den Namen der Windows Domäne und
verfahren werden soll. Diese Antworten werden auch im
den Computernamen. Diese sensiblen Informationen werPrivaten Modus dauerhaft gespeichert. Verwendet eine
den auch im Privaten Modus gesendet. Weder ein Proxy
Internetseite ein einzigartiges Protokoll, so kann dies ein
Server, noch das Zurücksetzen der Browser Einstellungen
Angreifer im Nachhinein herausfinden.
schafft hierbei Abhilfe. Der entfernte Angreifer ist also in
In der automatisierten Studie mit Hilfe der Modultests sind
der Lage, den Benutzer zu identifizieren, zumindest kann
es beim Fingerprint Verfahren helfen. In der Praxis wird weitere Schwachstellen gefunden worden:
der Angriff jedoch dadurch erschwert, dass Provider den
• Gespeicherte Zertifikate von Certificate Authorities (CA)
SMB Port 445 sperren. Ist dies der Fall, so ist der Angriff
werden bei Firefox in der Datei cert8.db“ dauerhaft ge”
über das Internet nicht möglich.
speichert. Dies geschieht immer dann, wenn der Benutzer
eine Internetseite besucht, deren CA Firefox bisher nicht
bekannt ist. Firefox geht die Kette von Zertifikaten durch
C. Andere gefundene Schwachstellen
und speichert die bisher unbekannten Zertifikate in der
Auf der Suche nach Schwachstellen führten Aggarwal,
Datei. Anhand dieser Daten kann ein lokaler Angreifer
Bursztein, Jackson und Boneh [1] zwei systematische Studien
Informationen über die besuchten Seiten ableiten.
beim Firefox Webbrowser durch.
• Das Änderungsdatum der SQLite Datenbanken wird ak• Die erste Sudie wurde mit Hilfe eines manuellen Code
tualisiert. Die Dateigröße der Datenbank ändert sich
Reviews durchgeführt. Dabei suchten sie im Quellcode
jedoch nicht und es wurden auch keine Einträge gelöscht,
gezielt nach Stellen, in denen auf persistenten Speimodifiziert oder hinzugefügt. Trotzdem kann der lokale
cher geschrieben wird. Danach wurde geprüft, ob diese
Angreifer damit feststellen, dass der Private Modus verSchreibvorgänge im Privaten Modus unterbunden werden.
wendet wurde. Es genügt nachzusehen, ob die Dateigröße
Dabei wurde im speziellen untersucht, welche Methoden
gleich geblieben ist, sich aber das Änderungsdatum
Dateien im Profilverzeichnis manipulieren und deren Ververändert hat.
wendung untersucht.
• Eine weitere Methode nimmt den Modultest zur Hilfe.
Ein automatisiertes Werkzeug führt die Firefox ModulV. B ROWSER E RWEITERUNGEN
tests im Privaten Modus des Browsers durch und sucht
Erweiterungen (engl. addons) von Browsern stellen eine
anschließend, ob Änderungen im Profilordner auf der
Festplatte durchgeführt wurden. Dabei wurden einerseits weitere Gefahr dar. Sie können prinzipiell sämtliche SiSystem Calls5 überwacht, die das Dateisystem betreffen, cherheitsziele des Privaten Modus verletzen. Beispielsweise
andererseits wurde das letzte Änderungsdatum der Datei- können Erweiterungen binären Programmcode ausführen und
haben dabei dieselben Rechte wie der Benutzer. Eine Restriken verwendet.
tion auf bestimmte Aktionen wie das Schreiben einer Datei ist
Als Ergebnisse des manuellen Code Reviews wurden
in keinem Browser enthalten. Somit liegt es alleine am Autor
zusätzlich zu den oben bereits beschriebenen Problemen noch
einer Erweiterung, ob diese die Sicherheitsziele des Privaten
folgende gefunden:
Modus einhält oder nicht. Oft macht sich der Entwickler über
• Seiten-spezifische Einstellungen: Diese Einstellungen
diese Problematik aber keine Gedanken und seine Erweitewerden in einer SQLite Datenbank gespeichert und bein- rung unterliegt keiner so exakten Prüfung wie der Browser
halten Rechte, die für jede Internetseite getrennt ange- selbst. Die Browser unterscheiden außerdem meist zwischen
wendet werden. Dabei wird beispielsweise festgehalten Erweiterungen und Plugins. Plugins sind beispielsweise Java,
welche Seiten Cookies speichern, Erweiterungen instal- Flash oder Quicktime. Alle untersuchten Browser behandeln
lieren, Bilder anzeigen, oder Popups anzeigen dürfen. außerdem Erweiterungen im Zusammenhang mit dem Privaten
Teilweise befinden sich Prüfungen bezüglich des Privaten Modus unterschiedlich. Daher ein kurzer Überblick:
Modus im Code, allerdings nicht immer. So wird das
• Der Internet Explorer hat eine Option Symbolleisten und
Hinzufügen von Ausnahmeregeln für den Popup Blocker
”
Erweiterungen beim Start des InPrivate-Browsens deaktinicht unterbunden. Besucht der Benutzer eine Internetseivieren“, die in den Standardeinstellungen ausgewählt ist.
te, die das Erlauben von Popups dringend benötigt und
Erweiterungen sind dann im Privaten Modus deaktiviert.
richtet deshalb eine Ausnahme ein, so hinterlässt er
Trotzdem bleiben ActiveX Plugins weiterhin aktiviert,
dem lokalen Angreifer Spuren. Dies ist dem Benutzer
obwohl diese aus Sicherheitsgründen sowieso sehr be5 System Call: Anfrage an das Betriebssystem
denklich sind.
André Hanak
10
ITSEC@i1 2011
2-8
•
•
•
Bei Firefox funktionieren alle Erweiterungen und Plugins
auch im Privaten Modus.
Google Chrome deaktiviert im Inkognito Modus standardmäßig Erweiterungen. Allerdings bleiben Plugins
und Plugins, die mit Erweiterungen kombiniert sind aktiv.
Außerdem bietet Chrome dem Benutzer die Möglichkeit
einzelne Erweiterungen in der privaten Sitzung über eine
selbst erstellte Ausnahmeregel zu aktivieren.
Safari unterstützt offiziell keine Erweiterungen. Bei der
Verwendung von inoffiziellen APIs können Erweiterungen auch im Privaten Modus verwendet werden.
A. Erweiterungen, die die Privatsphäre verletzen
Um die Gefahr durch Erweiterungen besser beurteilen zu
können wird im Folgenden erläutert, inwiefern bei den bekanntesten Erweiterungen Sicherheitsprobleme auftreten. Aggarwal, Bursztein, Jackson und Boneh [1, S. 11] haben dazu die
Sicherheit der 40 populärsten Firefox Erweiterungen genauer
untersucht. Acht davon enthielten nativen binären Code und
wurden als generell unsicher eingestuft, da die Untersuchung
von solchem Code sehr schwierig ist. Die übrigen 32 Erweiterungen basieren auf JavaScript und sind leicht zu untersuchen,
da es nur zwei Methoden gibt auf das Dateisystem zuzugreifen. Verwendet wurde dabei eine modifizierte Firefox Version,
die diese Dateisystemzugriffe heraus loggt.
Als Ergebnis stellten die Autoren fest, dass 16 der 32
Javascript Erweiterungen unproblematisch sind. Einige davon
schreiben nichts auf die Festplatte, andere nur Einstellungen.
Wieder andere, wie zum Beispiel 1-Click YouTube Video
”
Download“ schreiben nur Dateien auf die Festplatte, die der
Benutzer herunterladen möchte. Nur eine Erweiterung ( Tab
”
Mix Plus“) prüft, ob der Private Modus gerade verwendet
wird und deaktiviert daraufhin eine Option zum Speichern der
aktuellen Sitzung.
Bei 16 Erweiterungen wurden Probleme festgestellt, die es
einem Angreifer möglich machen können an Informationen
aus der Privaten Sitzung zu gelangen. Dabei lassen sich die
meisten Verstöße in drei Kategorien einteilen:
• URL
Whitelists (deutsch: Positivliste), Blacklists
(deutsch: Negativliste) oder Warteschlangen: Viele
Erweiterungen führen Listen mit URLs, für die
Ausnahmen bei der Verarbeitung gemacht werden. Ein
gutes Beispiel ist NoScript“, eine Erweiterung die
”
das Ausführen von Scripts auf Internetseiten verbietet.
Für Internetseiten, die aber beispielsweise JavaScript
benötigen, können Ausnahmen hinzugefügt werden.
Dabei werden URLs gespeichert auch wenn man sich
gerade in einer privaten Sitzung befindet. Ein anderes
Beispiel ist die Erweiterung DownThemAll“, sie
”
ermöglicht es mehrere Dateien auf einmal von einer
Internetseite herunterzuladen. Dabei wird die Liste der
Dateien, die noch heruntergeladen werden müssen auf
der Festplatte gespeichert, auch im Privaten Modus.
• URL Zuordnungen: Einige Erweiterungen erlauben es
auf bestimmten, vom Benutzer festgelegten Internetseiten, eine Sonderbehandlung durchzuführen. So ist es
mit der Erweiterung Stylish“ beispielsweise möglich für
”
André Hanak
•
jede Internetseite eine eigene Stylesheet (CSS) Datei zu
verwenden. Diese Zuordnungen werden mit der URL
zusammen auf der Festplatte gespeichert.
Zeitstempel: Andere Erweiterungen speichern Datum und
Uhrzeit von bestimmten Ereignissen ab. Beispielsweise
wann eine bestimmte Funktion zuletzt verwendet wurde.
Ein Angreifer kann so herausfinden, dass der Private
Modus verwendet wurde, indem er den Zeitpunkt des
letzten Eintrags in der Chronik des Browsers mit so
einem Zeitstempel vergleicht. Ist der Zeitstempel neuer,
so wurde der Private Modus offensichtlich verwendet.
B. Lösungsmöglichkeiten
Mit Ausnahme von Chrome bietet kein Browser die
Möglichkeit, für jede Erweiterung einzeln festzulegen, ob
diese im Privaten Modus verwendet werden soll. Dies ist
jedoch die beste Lösung. Beim Blockieren aller Erweiterungen
während der Privaten Sitzung werden viele Erweiterungen
blockiert, die überhaupt kein Risiko darstellen. Außerdem
werden unter Umständen auch Erweiterungen blockiert die die
Privatsphäre des Benutzers erhöhen sollen. Damit verliert der
Private Modus an Benutzerfreundlichkeit und eventuell sogar
an Sicherheit. Werden alle Erweiterungen generell zugelassen,
ergeben sich die oben beschriebenen Probleme. Folglich sollte
zur Lösung des Problems eine Variante verwendet werden,
die spezifisch für jedes Plugin funktioniert. Dabei gibt es drei
vernünftige Lösungsansätze:
•
•
•
Manuelle Prüfung: Autoren von Erweiterungen können
selbst entscheiden, ob ihre Erweiterung im Privaten Modus verwendet werden soll.
Veränderungen verbieten: Erweiterungen werden
grundsätzlich daran gehindert im Privaten Modus
persistente Daten zu schreiben.
Löschen der Änderungen: Alle bleibenden Änderungen
werden nach Beendigung der privaten Sitzung wieder
verworfen. Ausnahmen können gemacht werden, wenn
die Erweiterung explizit anzeigt, dass die Änderung trotz
des Privaten Modus erhalten bleiben soll.
Aggarwal, Bursztein, Jackson und Boneh [1] haben eine
Firefox Erweiterung namens ExtensionBlocker“ geschrieben.
”
Diese Blockiert alle Erweiterungen in Firefox, die nicht ein
bestimmtes Flag in ihrer Beschreibungsdatei ( install.rdf“)
”
stehen haben. Das Flag ist einfach ein XML Tag, welches
in der Datei hinzugefügt wird. Es sieht folgendermaßen aus:
<privateModeCompatible/>
Dies stellt eine praktische Lösung nach dem oben erst
genannten Punkt dar. Diese Lösung macht aber erst dann
Sinn, wenn entsprechende Erweiterungen dieses Flag auch
setzen, da sonst alle Erweiterungen blockiert werden. Aus
diesem Grund habe ich die 40 meist heruntergeladenen Firefox
Erweiterungen untersucht. Dabei habe ich jeweils die Datei
install.rdf“ aus den Dateien mit der Endung .xpi“ ausgepackt
”
”
und danach nach der Zeichenfolge privateModeCompatible“
”
gesucht. Dabei bin ich zu dem Ergebnis gekommen, dass keine
der untersuchten Erweiterungen dieses Flag verwendet. Die
11
ITSEC@i1 2011
2-9
Gründe liegen vermutlich darin, dass die ExtensionBlock Erweiterung wenig bekannt ist. Eine Lösung des Problems wäre
sicherlich, wenn das Firefox Entwicklerteam diese Funktionalität in den Firefox mit aufnehmen und für die Verwendung
des Flags in Erweiterungen werben würden.
VI. Z USAMMENFASSUNG
Dieser Beitrag befasst sich mit der Frage, wie sicher der
Private Modus in aktuellen Browsern tatsächlich ist. Dabei
wurde zunächst einmal erläutert wie die vier bekanntesten
Browser den privaten Modus implementieren, wie er beworben wird und es wurde eine Studie wurde vorgestellt, die
zeigt, dass die Programmfunktion auf Erotikseiten vermehrt
zum Einsatz kommt. Außerdem wird der Private Modus bei
Firefox und Safari öfters verwendet als bei den anderen beiden
Browsern. Anschließend wurde ein Sicherheitsmodell und
Sicherheitsziele vorgestellt, dabei wurden zwei unterschiedliche Ziele definiert: Der Schutz vor einem lokalen Angreifer
und der vor einem entfernten Angreifer. Es wurden manche
Angriffsmethoden generell nicht betrachtet. Dies Betrifft die
Analyse des Arbeitsspeichers oder Angriffe auf die Netzwerkinfrastruktur. Vor allem das Suchen von Spuren im Arbeitsspeicher könnte ein Thema späterer Forschungsarbeit sein. Es
wurden zahlreiche Probleme festgestellt, die beispielsweise
eng mit der Funktionsweise des Betriebssystems zu tun haben.
Im Falle des entfernten Angreifers ist es kaum möglich die
Sicherheitsziele vollständig umzusetzen. Allerdings gibt es
für den Firefox Erweiterungen die mit dem Tor Netzwerk
zusammenarbeiten und versuchen diese Ziele zu erreichen.
Im Kapitel IV wurde dann untersucht inwiefern sich die Implementierungen der Browser im Detail unterscheiden. Dabei
wurden Inkonsistenzen festgehalten, die das Ausspähen von
Informationen ermöglichen. Außerdem wurden andere Sicherheitsprobleme vorgestellt, die bei Firefox gefunden wurden.
Die Auswirkungen von Erweiterungen auf die Sicherheit wurde in Kapitel V vorgestellt. Eine Lösungsmöglichkeit, die Aggarwal, Bursztein, Jackson und Boneh [1] in Form der Browser
Erweiterung ExtensionBlocker“ entwickelt haben, wurde auf
”
Nutzen in der Praxis getestet. Dabei wurde festgestellt, dass
heute kein Plugin mit der Lösung zusammenarbeitet. Die
Idee ist sicherlich sehr gut, allerdings müsste die Funktion in
Firefox selbst integriert werden, damit mehr Erweiterungen die
Möglichkeit auch tatsächlich nutzen und entsprechende Flags
verwenden.
In diesem Themengebiet steckt noch viel Potenzial für
zukünftige Untersuchungen. So wurde bereits erwähnt, dass
hier viele Angriffsmethoden nicht weiter beschrieben wurden.
Browser werden immer weiter entwickelt, manche Probleme
werden behoben und wiederum neue entstehen. Des Weiteren
wurde aufgrund der Quelloffenheit und seiner weiten Verbreitung vieles nur am Firefox untersucht. Nicht beachtet wurden
weitere Browser wie beispielsweise Opera, die den Privaten
Modus auch unterstützen. Zudem werden viele Browser für
Mobile Endgeräte immer komplexer, für Android gibt es
bereits Lösungen zum anonymen und privaten Surfen, wie
Gauld [4] mit seiner Tor Anwendung zeigt. Zuletzt ist die
Problematik mit Erweiterungen und Plugins noch immer nicht
zufriedenstellend gelöst.
André Hanak
L ITERATUR
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
Gaurav Aggrawal, Elie Bursztein, Collin Jackson und
Dan Boneh. “An analysis of private browsing modes
in modern browsers”. In: Proc. of 19th Usenix Security
Symposium. 2010.
Peter Eckersley. “How Unique Is Your Web Browser?”
In: Privacy Enhancing Technologies. 2010.
Electronic Frontier Foundation. Panopticlick. [Online; aufgerufen am 28-November-2010]. URL: https://
panopticlick.eff.org.
Connell Gauld. TorProxy and Shadow. [Online; aufgerufen am 28-November-2010]. 2009. URL: http://www.
cl.cam.ac.uk/research/dtg/android/tor/.
Google. Incognito mode (private browsing). [Online;
aufgerufen am 28-November-2010]. URL: http://www.
google . com / support / chrome / bin / answer. py ? hl = en &
answer=95464.
Microsoft. Internet Explorer 8: Funktionen. [Online;
microsoft . com / germany / windows / internet - explorer /
features/overview.aspx.
Mozilla. Mozilla Firefox 3.5 Release Notes. [Online;
mozilla.com/en-US/firefox/3.5/releasenotes/.
Mozilla. Private Browsing. [Online; aufgerufen am 28November-2010]. URL: http://support.mozilla.com/enUS/kb/Private+Browsing.
Mike Perry. Torbutton. [Online; aufgerufen am 28November-2010]. URL: https : / / www. torproject . org /
torbutton/.
Wikipedia. Usage share of web browsers — Wikipedia,
The Free Encyclopedia. [Online; aufgerufen am 28November-2010]. 2010. URL: http://en.wikipedia.org/
w / index . php ? title = Usage share of web browsers &
oldid=399157597.
12
Verified by Visa und MasterCard SecureCode, oder: Wie man die . . .
ITSEC@i1 2011
Verified by Visa und MasterCard SecureCode, oder: Wie man die Authentifizierung nicht entwerfen sollte
1
Verified by Visa und MasterCard SecureCode,
oder: Wie man die
Authentifizierung nicht entwerfen sollte
Sergiy Protsenko
Universität Erlangen-Nürnberg
Abstract. Immer mehr Banken führen weltweit das neue System für die Authentifizierung von Online-Transaktionen ein, das
auf dem „3-D Secure - Protokoll“ basiert und unter den Namen
„Verified by Visa“ und „MasterCard SecureCode“ präsentiert
wird. Ein Grund dafür war der rasche Anstieg der Zahl von Online-Betrugsfällen, der mit der Einführung von „Chip&PIN“Authentifizierung für Offline-Transaktionen verbunden war. Das
„3-D Secure - Protokoll“ wurde keiner wissenschaftlichen Überprüfung unterzogen und kann ein Musterbeispiel dafür sein, wie
man die Authentifizierung nicht entwerfen sollte. Es hat erhebliche Schwachstellen, einige davon werden schon ausgenutzt. Es
wird eine Verbesserung des Protokolls angeboten, die technologisch einwandfrei ist und sich nicht nur für Banken, sondern auch
für Händler und Kunden lohnt.
1. EINFÜHRUNG
D
IE sogenannten CNP - Transaktionen („card not present“)
erfolgen über das Internet, Telefon oder Post, wo der
Standort des Händlers (Verkaufsort) und der Standort des Karteninhabers und der Karte nicht übereinstimmen. Der Käufer
wird weder durch die Eingabe einer PIN noch durch eine Unterschrift authentifiziert. Betrügerische Transaktionen dieser
Art machen derzeit einen großen Teil von Betrugsschäden der
Banken aus.
Dieser schnelle Anstieg wurde durch die Einführung von
EMV-Kreditkarten mit Chip herbeigeführt. EMV steht für
Europay, MasterCard und Visa, der Standard wird in englischsprachigen Ländern auch als „Chip & Pin“ bezeichnet. Im
Vereinigten Königreich von Großbritannien und Nordirland
wurde die Einführung dieses Standards gegen Ende 2005 abgeschlossen. Viele europäische Länder haben schon sowohl
die Zahlungskarten als auch die Terminals auf die neue Technologie umgerüstet. In Deutschland haben über 60% aller Zahlungskarten einen EMV-Chip, bis Ende 2010 sollen alle vorhandenen Kreditkarten ohne Chip umgetauscht werden. Die
Zahl von Betrügen mit verlorengegangenen und gestohlenen
Kreditkarten ging eine Zeit lang zurück. Auch die Fälschung
Dieser Beitrag entstand im Rahmen des Konferenzseminars "ITSicherheit", das im Wintersemester 2010/11 an der Universität ErlangenNürnberg durchgeführt wurde. Es wurde organisiert vom Lehrstuhl für ITSicherheitsinfrastrukturen (Prof. Dr. F. Freiling).
Sergiy Protsenko
der Karten mit Chip ist erheblich schwerer. Immerhin können
die Betrüger die mit dem Chip ausgestatteten Karten im Ausland weiterhin benutzen, wo die Chips noch nicht unterstützt
werden (durch Abwärtskompatibilität mit Magnetstreifen).
Gleichzeitig stieg die Zahl von betrügerischen Card Not
Present - Transaktionen drastisch.
Um den akuten Anstieg der Betrugsfälle zu bewältigen,
wurde das Protokoll 3-D Secure (3DS) entwickelt. Es wird
unter den Namen „Verified by Visa“ und „MasterCard SecureCode“ vermarktet. In der Urform des Protokolls sah der
Autorisierungsablauf folgendermaßen aus: bei einem Kauf im
Internet sollte ein Pop-up-Fenster mit dem Formular zur
Kennworteingabe erscheinen (Abb. 2). Wenn der Käufer das
richtige Kennwort eingeben würde, würde er zur Händlerseite
zurückgeführt, um den Kauf abzuschließen. Es gab jedoch
Schwierigkeiten mit Pop-up-Blockern, daher wurde empfohlen, statt Pop-up-Fenstern Inline-Frames zu benutzen. Der
Händler schickt die Kartennummer an Visa oder MasterCard
und bekommt eine URL für Inline-Frame, welches dann in die
Seite, die den Kunden angezeigt wird, eingebettet wird. Wenn
das Protokoll erfolgreich abläuft, bekommt der Händler einen
Autorisierungscode, den er an die Bank weiterleitet.
2. 3-DOMAIN SECURE (3-D SECURE™): BESCHREIBUNG DER
FUNKTIONSWEISE
2.1. GRUNDLEGENDE BEGRIFFE
Das 3DS-Protokoll wird für die Zahlungsservices „Verified
by Visa“ und „MasterCard SecureCode“ eingesetzt, mit dem
Ziel, die Sicherheit beim Online-Einkauf durch zusätzliche
Autorisierung der Transaktionen zu erhöhen.
Es basiert auf dem Modell der drei Domänen (Abb. 1):
- „Issuer Domain“ (die kartenausgebende Bank). Der
Issuer ist für die Anmeldung und Authentifizierung seiner
Kunden (Karteninhaber) verantwortlich. Die Karteninhaber werden auch der Issuer-Domäne zugeordnet.
- „Acquirer Domain“. Unter Acquirer versteht man das
Kreditinstitut, das die Kreditkartenzahlungen für den
Händler abwickelt (die Händler sind Kunden des
Acquirers). Zu dieser Domäne gehören auch die Händler
selbst.
13
ITSEC@i1 2011
-
„Interoperability Domain“ (vertreten durch Visa oder
MasterCard). Sie ermöglicht den Nachrichtenaustausch
zwischen zwei anderen Domänen mit einem gemeinsamen Protokoll.
Issuer Domain
Interoperability Domain
Acquirer Domain
CARDHOLDER
MERCHANT
Shopping and
authentication
messages
Issuer
authenticates
Cardholder
using Issuer
specified method
ISSUER
Authorization
and payment
processing
Authorization
and payment
messages
ACQUIRER
2
sern. Dies hat aber keinen Sicherheitsvorteil und verhindert einen Man-in-the-middle-Angriff nicht, wenn die
Malware sich bereits auf dem Computer des Benutzers
befindet.
4) Die Kundendaten werden für die spätere Benutzung beim
Zugriffskontrollserver des Issuers (ACS – Access Control
Server) gespeichert. Der Karteninhaber wird über das Ergebnis seiner Anmeldung informiert und kann einkaufen,
sobald die Anmeldung erfolgreich abgeschlossen ist.
Damit die Kunden, die sich vorher nicht für 3DS angemeldet haben, trotzdem sofort bei teilnehmenden Händlern einkaufen können, ist bei einigen Banken auch eine Aktivierung
während des Einkaufs („activation during shopping“) erlaubt.
Die Nachteile dieser Lösung werden im Abschnitt 3.2 beschrieben.
Abbildung 1. Die drei Domänen [5]:
• Authentifizierungsanfrage und ihr Ergebnis: Nachrichtenaustausch
zwischen der Acquirer- und der Issuer-Domäne innerhalb der
Interoperability-Domäne über das Internet.
• Authentifizierung des Benutzers: Nachrichtenaustausch zwischen
dem Karteninhaber und dem Issuer innerhalb der Issuer-Domäne.
• Autorisierungsanfrage und Zahlungsabwicklung: Nachrichtenaustausch zwischen dem Händler und dem Acquirer innerhalb der
Acquirer-Domäne.
• Autorisierung und Zahlungsabwicklung: Nachrichtenaustausch zwischen dem Accquirer und dem Issuer innerhalb der InteroperabilityDomäne über VisaNet.
2.2. ANMELDUNG
Der Kunde, der bei teilnehmenden Händlern mit seiner Kreditkarte einkaufen möchte, muss sich vorher für 3DS bei seiner
Bank anmelden. Dabei ist anzumerken, dass es bei einigen
Banken möglich ist, die Anmeldung (und somit die Benutzung
von 3DS) z. B. für die ersten drei Einkäufe zu überspringen.
Der Anmeldeprozess sieht folgendermaßen aus:
1) Der Karteninhaber besucht die Anmeldeseite des Issuers.
2) Der Karteninhaber gibt seine Daten ein: die Kartennummer, das Ablaufdatum und möglicherweise andere Daten,
die vom Issuer angefordert werden (Abb. 2). Danach
werden ein Passwort und eine persönliche Begrüßung
vereinbart. Die persönliche Begrüßung ermöglicht die
beidseitige Authentifizierung. Wenn die Begrüßung richtig angezeigt wird, soll der Käufer annehmen, dass die
Passwortabfrage wirklich von seiner Bank kommt. Natürlich muss die persönliche Begrüßung so gewählt werden,
dass sie von einem möglichen Angreifer nicht leicht erraten werden kann.
3) Der Issuer überprüft die eingegebenen Daten um festzustellen, dass es sich wirklich um den rechtmäßigen Karteninhaber handelt. Die Art der Verifizierung des Karteninhabers ist aber nicht auf die Abfrage von irgendwelchen
Merkmalen begrenzt, sondern kann von jeder Bank frei
gewählt werden. So sind z. B. Einmalpasswörter denkbar,
die per Post oder SMS verschickt werden, oder auch
Hardwarelösungen wie die Verwendung von Kartenle-
Sergiy Protsenko
Abbildung 2. Anmeldung für MasterCard SecureCode.
2.3. AUTHENTIFIZIERUNG: ABLAUF DER
ZAHLUNGSABWICKLUNG
Um an 3D-Secure teilzunehmen, muss der Händler ein so
genanntes Merchant Server Plug-in (MPI) installieren. Alternativ kann die Zahlungsabwicklung durch den Acquirer oder
einen Drittdienstleister erfolgen, der sich dann um den Einsatz
von 3D-Secure kümmert.
Der Ablauf des Einkaufs bei einem teilnehmenden Händler
kann grob in vier Schritte unterteilt werden (hier wird als Beispiel „Verified by Visa“ betrachtet [5]):
1) Abschluss des Einkaufs. Nachdem der Kunde mit dem
Einkauf fertig ist, gibt er seine Kreditkartendaten ein.
Dann wird die MPI-Software aktiviert.
14
ITSEC@i1 2011
2) Anfrage an den Visa Directory Server. Das MPI schickt
eine Anfrage an den Visa Directory Server, um zu ermitteln, ob die kartenausgebende Bank 3DS unterstützt und
ob der Karteninhaber sich bereits für 3DS angemeldet
hat. Wenn das der Fall ist, erhält das MPI eine URL von
dem entsprechenden Zugriffskontrollserver der kartenausgebenden Bank. Die Passwortabfrage wird dann als
Pop-up-Fenster angezeigt oder als Inline-Frame eingebettet. Wenn 3DS für die angegebene Kartennummer nicht
verfügbar ist, erfolgt die herkömmliche Abwicklung
durch den Händler oder seinen Dienstleister.
3) Authentifizierung des Karteninhabers. Das MPI schickt
über den Browser des Karteninhabers eine Authentifizierungsanfrage (PAReq – Payers Authentication Request)
an den Zugriffskontrollserver. Diese Anfrage erhält auch
Informationen bezüglich der konkreten Transaktion
(Händler, Betrag, Datum). Die Authentifizierung erfolgt
meistens durch eine Passwortabfrage (Abb. 3), es können
aber auch andere Methoden (z. B. Chipkarten) verwendet
werden. Der Zugriffskontrollserver überprüft die Richtigkeit des Passworts und schickt das Ergebnis (PARes –
Payers Authentication Response) wieder über den Browser des Käufers an das MPI.
4) Zahlungsabwicklung. Wenn die Authentifizierung erfolgreich war, erhält der Händler die PARes-Nachricht als eine digital signierte Genehmigung der Transaktion. Diese
wird an den Acquirer weitergeleitet.
Zusammenfassend kann man sagen, dass die 3DS-Abfrage
eine Art von Transaktionsauthentifizierung ist.
3
Diese Ausführungen treffen aber nicht zu. Das Ziel des Protokolls ist nicht die Authentifizierung des Benutzers gegenüber
dem Händler mit Hilfe des Zugriffskontrollservers der Bank,
sondern die Autorisierung der konkreten Transaktion. Steven
J. Murdoch nimmt auch irrtümlich an [11], dass der Käufer
keine Beschreibung der Transaktion bei der Passwortabfrage
erhält, somit sei das Protokoll gegen Man-in-the-middleAngriffe ungeschützt. Genau das Gegenteil ist aber der Fall,
wie die Bespiele von Visa und MasterCard zeigen (Abb. 3)
[12,13].
Abbildung 3. Verified by Visa Passwortabfrage.
3. SICHERHEITSSCHWACHSTELLEN
2.4. IST 3DS EIN SINGLE SIGN-ON SYSTEM?
Die unpassende Verwendung des Begriffs „Single Sign-on“
war einer der wichtigsten Kritikpunkte zum Artikel von Steven
J. Murdoch und Ross Anderson [10,11].
Single Sign-on („Einmalanmeldung“) bedeutet, dass der
Benutzer seine Zugangsdaten nur einmal eingeben muss, um
auf verschiedene (aber verwandte) Dienste zugreifen zu können. Es ist wichtig, dass der Benutzer sich wirklich nur ein
einziges Mal authentifiziert, Systeme, die wiederholte Authentifizierungen mit gleichen Zugangsdaten erfordern, zählen
nicht zu Single Sign-on. Das kann man sich auch so vorstellen,
dass der Authentifizierungsserver sich im Namen des Benutzers bei weiteren teilnehmenden Diensten anmeldet.
Steven J. Murdoch bezeichnet 3D-Secure trotz mehrerer
Hinweise weiterhin als Single Sign-on System [11]. Er begründet diese Aussage mit folgenden Ausführungen: Obwohl
3DS nicht als Single Sign-on entworfen wurde, erfülle es die
entscheidende Voraussetzung, dass ein Beteiligter einen anderen authentifizieren kann, ohne dass dieser vorher Zugangsdaten vereinbaren oder Schlüssel austauschen muss. Wie bei
anderen Single Sign-on Systemen, gebe es einen Vermittler,
der die Authentifizierung durchführt und das Vertrauen der
Kommunikationspartner genießt. Die Kartennummer sei ein
Pseudonym, das Protokoll soll dem Händler zusichern, dass
der Kunde der berechtigte Inhaber der Karte ist.
Sergiy Protsenko
Das Protokoll spezifiziert die sichere (verschlüsselte und
signierte)
Nachrichtenübertragung
zwischen
Händler,
Acquirer, Issuer und der Kreditkartenorganisation (VISA oder
MasterCard). Die Art der Authentifizierung der Karteninhaber
(sowohl bei der Anmeldung als auch bei der Zahlungsabwicklung) gehört jedoch nicht zum Protokoll und wird von den
kartenausgebenden Banken selbst gewählt. Die Benutzung von
3DS wird durch Vertragsbedingungen bezüglich Haftung gefördert, da die Händler, die 3DS einsetzen, reduzierte oder gar
keine Haftung bei umstrittenen Transaktionen haben.
Kurzfristig kann das Verfahren die Betrugsquoten beim Online-Handel reduzieren. Allerdings verletzen viele 3DSImplementierungen bestehende Sicherheitsregeln.
3.1. VERWIRRUNG DES BENUTZERS – VERBERGUNG VON
SICHERHEITSHINWEISEN
Den Verbrauchern wird immer wieder geraten, zur Vermeidung von Phishing-Angriffen ihre Bankpasswörter nur auf
TLS-geschützten Webseiten einzugeben. Darüber hinaus sollten sie auch die Richtigkeit der Domain-Namen der Seite
überprüfen. Moderne Browser unterstützen den Benutzer
durch Anwendung von so genannten Extended- ValidationZertifikaten. Dabei wird z. B. die Farbe der Adressleiste bei
aktiver TLS-Verbindung geändert sowie der Besitzer des Domain-Namens angezeigt. Die Eingabemaske von 3DS ist ein
15
ITSEC@i1 2011
Inline-Frame oder ein Pop-up-Fenster ohne Adressleiste, daher
ist es für Benutzer unter Umständen schwierig zu überprüfen,
wer nach dem Passwort fragt (es hängt unter anderem davon
ab, welcher Browser verwendet wird). Da viele Banken die
Umsetzung von 3DS an Drittdienstleister übergeben, kann man
auch bei sichtbarer URL nicht auf Anhieb erkennen, woher die
Seite stammt, da die URL weder der Bank noch dem Händler
gehört. Dies macht die Angriffe gegen 3DS einfacher, außerdem ruiniert es Anti-Phishing-Maßnahmen, indem es gängigen
Sicherheitshinweisen widerspricht.
3.2. AKTIVIERUNG WÄHREND DES EINKAUFS
Bevor 3DS zur Authentifizierung von Transaktionen benutzt
werden kann, soll der Karteninhaber ein Passwort mit seiner
Bank vereinbaren. Eine einigermaßen sichere Methode dafür
wäre, das Passwort per Post an die angemeldete Adresse zu
schicken. Um die Kosten zu sparen, bieten viele Banken die
Möglichkeit, die Anmeldung beim ersten Einkauf mit der 3DSfähigen Karte durchzuführen. Dieses Verfahren wird als „activation during shopping“ (ADS) bezeichnet. Um sicherzustellen, dass der Kunde der berechtigte Kartenbesitzer ist, können
einige schwache Authentifizierungsmerkmale abgefragt werden (z. B. das Geburtsdatum). Einige Banken verzichten sogar
darauf, andere verlangen eine Authentifizierung per Telefon
(z. B. Advanzia Bank S.A.) oder verschicken ein Startpasswort
für 3DS zusammen mit der Geheimzahl für die Kreditkarte
(Commerzbank AG). Aus der Sicht des Käufers fragt ein Online-Geschäft nach persönlichen Daten. Diese Vorgehensweise
wird oft durch Betrüger missbraucht, die Phishing-Seiten machen das ADS-Formular nach. Es steht aber jedem Kunden
frei, sich im Voraus auf der Webseite seiner Bank für 3DS
anzumelden.
3.3. EINVERSTÄNDNISERKLÄRUNG UND WAHL DES
PASSWORTS
Wenn der Kunde sich für 3DS anmeldet (d. h. ein 3DSPasswort festlegt), gilt es als Einverständnis mit den neuen
AGB. Es ist aber naheliegend, dass ADS keine gute Weise ist,
eine Einverständniserklärung des Kunden zu erhalten. Denn
wenn die AGB angezeigt werden, möchte der Käufer in erster
Linie seinen Einkauf tätigen, er wird daher die Vertragsklauseln nicht besonders aufmerksam durchlesen, wenn überhaupt.
Auch die Wahl des Passworts ist eine nebensächliche Aufgabe.
Es wird daher wahrscheinlich ein schwaches Passwort gewählt,
oder ein Passwort, das noch woanders genutzt wird. Nach Anforderungen von Visa können die Käufer bis zu drei Mal ohne
3DS bezahlen. Die Banken können aber den Benutzer zur
Anmeldung zwingen, indem sie den Kauf ohne 3DS sperren.
So hat z. B. die Advanzia Bank S.A. einen Kauf mit der MasterCard ohne 3DS-Anmeldung zugelassen, die NatWest Bank
in Großbritannien ließ keinen einzigen Einkauf ohne das Aktivieren von 3DS zu [1].
Sergiy Protsenko
4
3.4. HAFTUNGSUMKEHR
Da nur wenige Kunden den allgemeinen Geschäftsbedingungen (AGBs) widersprechen, bleibt es den Banken überlassen, die Haftung auf Kunden zu übertragen. Z. B. besagen die
Nutzungsbedingungen der Royal Bank of Scotland besagen
[2]: „You understand that you are financially responsible for
all uses of RBS Secure.“ In den AGB für MasterCard SecureCode der Advanzia Bank S.A. steht [4]: „Sie tragen die alleinige Verantwortung für die Wahrung der Vertraulichkeit Ihres
SecureCodes, Ihrer Registrierungsdaten oder anderer Überprüfungsinformationen, die von Ihnen in Verbindung mit MasterCard SecureCode erstellt wurden. Zudem tragen Sie die alleinige Verantwortung für alle Aktivitäten, im Rahmen derer Sie
Ihr Kennwort, Ihre Registrierungsdaten oder andere Überprüfungsdaten nutzen, die Ihnen in Verbindung mit MasterCard
SecureCode zur Verfügung gestellt oder von Ihnen erstellt
wurden.“ Obwohl die Bank für die ungünstige Wahl der
Sicherheitsmaßnahmen verantwortlich ist, können einige Banken versuchen, die Verluste auf den Kunden zu abzuwälzen.
Die genaue Gesetzlage ist allerdings noch unklar. So heißt
es z. B. im Infoblatt zu 3DS von PayOne [7], das Kennwort sei
nur dem Kunden bekannt, dadurch würde über 3DS gewährleistet, dass es sich bei dem Bezahlenden tatsächlich um den
rechtmäßigen Karteninhaber handelt. Die Haftung für Rückbelastungen, bei denen der Karteninhaber die Nutzung der Karte
bestreitet, liege aber bei der kartenausgebenden Bank.
Obwohl 3D-Secure schon seit einigen Jahren verfügbar ist,
wird es in Deutschland noch nicht flächendeckend eingesetzt.
Es gibt aktuell leider keine Gerichtsurteile, die sich mit der
Haftung bei bestrittenen Kreditkartenzahlungen mittels 3DSecure befassen.
Wenn die Zahlung im Internet nur mit der Kartennummer
und Kartenprüfnummer (auf der Rückseite der Karte) erfolgte,
liege die Beweislast bei der Bank, besagt ein Urteil des Amtsgerichts München [14]. Im beschriebenen Fall hat die Bank
zweimal den Schaden übernommen, wollte aber den dritten zu
Unrecht abgebuchten Betrag nicht komplett erstatten. Es ist
auch offensichtlich, dass es praktisch unmöglich ist, das Verschulden des Kunden für einen sorglosen Umgang mit der
Kreditkarte zu beweisen.
Ganz anders sieht es aus, wenn die Abbuchungen von einer
gestohlenen oder verloren gegangenen EC-Karte am Geldautomat mit der richtigen Geheimzahl erfolgten. Dann kann sich
die Bank auf einen so genannten Anscheinsbeweis berufen.
Das bedeutet, dass die allgemeine Lebenserfahrung für einen
bestimmten Ablauf von Ereignissen spricht. Wenn zum Beispiel das Geld kurze Zeit nach dem Diebstahl mit der Karte
und der richtigen Geheimzahl abgebucht wird, kann der Anscheinsbeweis dafür sprechen, dass die Geheimzahl auf der
Karte notiert war oder mit ihr zusammen aufbewahrt wurde, so
hat der Bundesgerichtshof am 05.10.2004 entschieden [15].
Die Sicherheitsexperten, deren Gutachten von dem Gericht
eingeholt wurde, waren der Meinung, dass es praktisch unmöglich ist, die Geheimzahl aus den auf der EC-Karte vorhandenen Daten zu errechnen. Der Kunde kann aber einen An-
16
ITSEC@i1 2011
scheinsbeweis für grobe Fahrlässigkeit entkräften, wenn ein
Ausspähen der Geheimzahl durch einen Dritten bei der Geldabhebung kurz vor dem Diebstahl möglich erscheint.
Es ist schwer zu beurteilen, ob 3D-Secure vor dem Gericht
als sicher betrachtet wird und ob dieses Verfahren den Anforderungen an einen Anscheinsbeweis genügen kann.
3.5. BEIDSEITIGE AUTHENTIFIZIERUNG
Durch Anzeige einer persönlichen Begrüßung, die bei
der Anmeldung zu 3DS festgelegt wird, kann der Kunde überprüfen, ob er tatsächlich mit seiner Bank kommuniziert. Murdoch und Anderson [1] sind überzeugt, dass die persönliche
Begrüßung nicht sicher genug ist. Erstens, wenn es um ADS
geht, würden die Kunden eher eine schlechte Begrüßung wählen, da ihr Ziel der Einkauf und nicht Sicherheit ist. Außerdem
sei die persönliche Begrüßung für Man-in-the-middle-Angriffe
anfällig. So ein Angriff kann auf von Malware befallenen
Computer des Käufers stattfinden [9].
5
liche Anmeldung und möglicherweise fehlerhafte Darstellung
von Inline-Frames und Pop-up-Fenstern schreckt potenzielle
Käufer ab.
Aus meiner Sicht sind die Grundidee und die Sicherheit bei
dem 3DS durchaus akzeptabel. Es ist auf jeden Fall sicherer
als eine Übermittlung von Kreditkartendaten ohne Authentifizierung. Das Problem liegt darin, dass das Protokoll viele
wichtige Abläufe nicht spezifiziert. Die Banken wählen dann
unpassende Varianten, die den Mindestanforderungen nicht
gerecht werden. Somit diskreditieren fehlerhafte Implementierungen das ganze System.
Die Authentifizierung von Benutzern, die eigentlich nicht
zum 3DS-Standard gehört und vom Issuer gewählt wird, ist
auch eine wesentliche Schwachstelle. Hier wäre eine Verbesserung durch Versand von Einmalpasswörtern per SMS denkbar. Steven J. Murdoch und Ross Anderson [1] glauben, dass
auf lange Sicht ein vertrauenswürdiges kostengünstiges Gerät
mit USB-Schnittstelle die beste Lösung ist. Auf jeden Fall soll
das System ein sicheres Protokoll und eine entsprechende
Rechtsgrundlage für die Haftung so vereinigen, dass vor allem
die Kunden davon profitieren können.
3.6. UNEINHEITLICHE AUTHENTIFIZIERUNGSMETHODEN
Die Spezifikation von 3DS definiert, wie die Kommunikation zwischen Händler, Issuer und Acquirer ablaufen soll, sowie
das Zahlungsschema. Dazu gibt es drei Parameter, die die
Banken selbst festlegen.
Erstens, wie erfolgt die Identifikation des Kunden? Einige
Banken haben eine sehr ungünstige Wahl getroffen, wie z. B.
durch eine Geheimzahl für den Geldautomaten.
Zweitens, wie wird das Passwort neu gesetzt, wenn der
Kunde es vergisst? Hier wird auch am falschen Ende gespart.
Einige Banken bieten nach zwei falschen Eingaben an, das
Passwort in gleicher Weise wie bei ADS neu zu setzen. In
mehreren Fällen fragen die Banken nur das Geburtsdatum ab,
wobei solche Informationen durchaus aus öffentlich zugänglichen Quellen gewonnen werden können.
Drittens, wird das ganze Passwort oder eine Teilmenge der
Zeichen abgefragt? Es kann sinnvoll sein, nur bestimmte Zeichen abzufragen, um ein Abhören des Passworts durch Tastatur-Logger zu erschweren. Allerdings kann dies den Benutzer
dazu zwingen, ein einfaches Passwort zu wählen oder es aufzuschreiben, was gegen die AGB verstößt.
LITERATURVERZEICHNIS
[1]
[2]
https://www.rbssecure.co.uk/rbs/tdsecure/terms_of_use.j
sp, abgerufen am 08.11.2010.
[3]
3DS ist vorteilhaft für Händler, da sie durch die Haftungsumkehr Verluste reduzieren, sowie für Banken, die die Haftung für Kartenmissbrauch auf den Kunden abwälzen.
Im Gegenzug bekommen die Kunden nur eine geringfügige
Verbesserung der Sicherheit und haften möglicherweise für
Missbrauchsschaden. Denn im Schadensfall müssen sie eventuell nachweisen, dass sie das Passwort z. B. nicht grob fahrlässig aufbewahrt haben. Außerdem werden sie für unsicheres
Verhalten im Internet „geschult“. Aber auch Händler profitieren von der Einführung von 3DS nicht immer, denn die zusätz-
Sergiy Protsenko
Advanzia Bank S.A. MasterCard SecureCode: Häufig gestellte Fragen.
https://enrollment.securecode.com/vpas/advanzia/enroll/
faq.jsp?locale=de_DE&bankid=121, abgerufen am 08.11.2010.
[4]
Advanzia Bank S.A. MasterCard Secure Code AGB.
https://enrollment.securecode.com/vpas/advanzia/enroll/
tandc.jsp?locale=de_DE&bankid=121, abgerufen am 08.11.2010.
[5]
VISA International Service Association. 3-D Secure system overview.
https://partnernetwork.visa.com/vpn/global/retrieve_doc
ument.do?documentRetriedalId=119, abgerufen am 08.11.2010.
[6]
[7]
Internet Retailer. Verified by Visa security program used as bait in
phishing scams, 06.01.2005. http://www.internetretailer.com/
dailyNews.asp?id=13764, abgerufen am 23.11.2010.
Payone Payment Services. Infoblatt 3D-Secure.
http://www.payone.de/data/download/download.html?filena
me=Infoblatt_3D-Secure.pdf, abgerufen am 23.11.2010.
[8]
Kartensicherheit.de. Authentifizierung 3D Secure.
http://www.kartensicherheit.de/ww/de/pub/oeffentlich/in
fos_fuer_haendler/3d_secure.php, abgerufen am 23.11.2010.
[9]
4. WIE KANN MAN DAS SYSTEM VERBESSERN?
Steven J. Murdoch, Ross Anderson. Verified by Visa and MasterCard
SecureCode: or, How Not to Design Authentication. Financial Cryptography and Data Security ’10, 25-28 January 2010, Tenerife.
Royal Bank of Scotland. RBS Secure Terms of Use,
Financial hackers attacking Visa/MasterCard users with fake 3-D Secure logins. Infosecurity Magazine, 15.07.2010.
http://www.infosecurity-magazine.com/view/10992/ financial-hackers-attacking-visamastercard-users-with-fake3d-secure-logins, abgerufen am 26.11.2010.
[10] Ross Anderson. How online card security fails. Blogeintrag vom
26.01.2010. http://www.lightbluetouchpaper.org/2010/01/
26/how-online-card-security-fails/, abgerufen am 26.11.2010.
[11] Steven J. Murdoch. Why is 3-D Secure a single sign-on system? Blogeintrag vom 29.01.2010. http://www.lightbluetouchpaper.org/
2010/01/29/why-is-3-d-secure-a-single-sign-on-system/,
abgerufen am 26.11.2010.
[12] Visa Europe Services Inc. Online Einkaufen mit Verified by Visa (Demo).
http://www.visa.de/de/sicher_mit_visa/sicher_online_mit
_verified_by/so_funktioniert_es/demo3.aspx?popup=true,
abgerufen am 06.01.2011.
17
ITSEC@i1 2011
6
[13] MasterCard Europe. So funktioniert MasterCard SecureCode (Demo).
http://www.mastercard.com/de/personal/de/privatkunden/
wissenswertes/securecode_anim/show.html, abgerufen am
06.01.2011.
[14] Amtsgericht München. Urteil vom 16.02.2009, AZ. 242 C 28708/08.
http://www.money-advice.net/view.php?id=43781, abgerufen
am 06.01.2011.
[15] Bundesgerichtshof, Urteil vom 05.10.2004, AZ. XI ZR 210/03.
www.eurolawyer.at/pdf/BGH_XI_ZR_210-03.pdf, abgerufen am
07.01.2011.
Sergiy Protsenko
18
(Un-)sicherheit in komplexen Systemen
ITSEC@i1 2011
X-1
Kilian Redel
Friedrich-Alexander-Universität Erlangen-Nürnberg
Zusammenfassung—Heute vertraut der Mensch sein Leben
einer Vielzahl komplexer technischer Systeme an, deren Komplexität nicht mehr erfasst werden kann. Zwar gibt es Redundanzen
und andere Maßnahmen mit denen eine sehr hohe Ausfallsicherheit des Systems ermöglicht wird, jedoch ist es niemals
möglich alle Wechselwirkungen aller Teilsysteme zu erkennen
und zu beherrschen. So passieren immer wieder Unfälle bzw.
Katastrophen, die eigentlich nicht passieren können, weil mehrere
scheinbar voneinander unabhängige Teilsysteme ausfallen, von
denen jedes einzelne für sich genommen keinerlei Risiko darstellt.
Im Paper sollen anhand vergangener Unfälle das oben genannte
veranschaulicht werden. Außerdem soll auf die Möglichkeiten
zur Steigerung der Sicherheit durch moderne Steuerungen, aber
auch deren Risiken eingegangen werden.
I. E INF ÜHRUNG
Grundlage dieser Arbeit ist das Buch Normal Accidents:Living with High-Risk Technologies von Charles Perrow, welches erstmals im Jahr 1984 erschien, also einige Zeit
bevor das Thema IT-Sicherheit aktuell wurde. Viele seiner
Analysen in Bezug auf komplexe Systeme treffen jedoch auch
oder im Besonderen auf IT-Systeme zu.
Geschichte fertig sind teilt er Ihnen mit, dass am vergangenen
Wochenende die Lichtmaschine kaputt gegangen ist und erst
heute repariert werden kann. Nun bliebe ja immer noch der
Bus. Allerdings hat der freundliche alte Herr bereits im Radio
gehört, dass die Busgesellschaften mit der Aussperrung ernst
gemacht hat. Die Fahrer hatten sich geweigert weiterhin mit
ihrer Meinung nach nicht verkehrstüchtigen Bussen zu fahren.
Außerdem fordern sie mehr Lohn. Somit ist das nächste
System ausgefallen. Auch der Versuch ein Taxi zu rufen
scheitert, da aufgrund der Aussperrung alle Taxen belegt sind.
Schlussendlich rufen Sie den Sekretär der Personalleiterin an,
bitten um einen neuen Termin und erzählen ihm, dass bei
Ihnen heute alles schiefgelaufen ist. Der Sekretär gibt sich
am Telefon verständnisvoll, hält Sie jedoch im Stillen für unzuverlässig, da Sie sich zuerst so um das Vorstellungsgespräch
bemühen und dann nicht erscheinen. Er vermerkt dies in Ihrer
Akte und versucht einen möglichst ungünstigen Termin zu
finden, der von der Personalleiterin sicher geändert werden
wird. Sie nehmen sich vor, zu diesem Termin 2 Autos in
Reserve zu haben und zusätzlich noch ein Taxi vorzubestellen.
A. Ein ganz normaler Tag
B. Wer ist schuld?
Um die eingangs erwähnte Wechselwirkung von scheinbar komplett unabhängigen Systemen zu veranschaulichen,
gibt Charles Perrow in seinem Buch “Normal Accidents:
Living with High-Risk Technologies“ ein einfaches, alltägliches Beispiel [1]: Sie haben nach großen Anstrengungen an
diesem Morgen endlich ein lang ersehntes Bewerbungsgespräch. Jedoch hat Ihre Freundin beim Verlassen des Hauses
die gläserne, fast leere Kaffeekanne auf der angeschalteten
Heizplatte der Kaffeemaschine vergessen, infolge dessen diese
gesprungen ist. Da Sie jedoch früh morgens unbedingt Kaffee zum wach werden benötigen, suchen Sie hektisch nach
Filterpapier und einem Filter. Nachdem Sie diesen gefunden
haben machen Sie sich hektisch Ihren Kaffee und verlassen
eilig das Haus. Auf dem Weg zum Auto bemerken Sie, dass der
Schlüsselbund noch im Haus liegt. Das würde normalerweise
kein Problem darstellen, da Sie noch einen Zweitschlüssel unter einem falschen Stein versteckt haben (Redundanz). Jedoch
haben Sie den Schlüssel am vorhergehenden Abend einem
Bekannten gegeben, der im Laufe des Tages einige Bücher
bei Ihnen holen möchte (Der “Redundanzpfad“ ist nicht weiter
gangbar). Glücklicherweise haben Sie ja noch einen freundlichen alten Herren als Nachbarn, der seinen Wagen nur selten
fährt und regelmäßig warten lässt. Noch bevor Sie mit Ihrer
Nun stellt sich die Frage, was die primäre Ursache, die
zu dieser Verkettung unglücklicher Umstände führte. War es
menschliches Versagen, also das Nichtabschalten der Kaffeemaschine oder das darauffolgende Vergessen des Schlüssels
im Haus. Oder war es ein mechanischer Defekt, also der
Ausfall der Lichtmaschine? Oder trägt die Umwelt Schuld,
in Form der Aussperrung der Busfahrer und der daraus resultierenden Überlastung des Taxiverkehrs oder die Anordnung
des Systems, das ein Ausschließen ermöglicht und keine
Reservetaxen für Notfälle vorsieht. Je nach persönlicher Sicht
findet jeder für sich eine Hauptursache. Dies führt bei großen
Unfällen und Katastrophen dazu, dass wie beispielsweise bei
der Explosion der Deepwater Horizon Plattform die Verantwortung von einer Stelle an die andere Stelle weitergeschoben
wird. BP beschuldigt die Betreiberfirma, diese den Hersteller,
dieser wiederum BP usw. [6]
Auch im Alltagsbeispiel fällt eine klare Bestimmung der
Ursache schwer, da keiner der einzelnen Zwischenfälle für
sich genommen ein Problem darstellt. Für scheinbar jede
Eventualität wie Schlüsselvergessen, Autodefekt etc. existierte
eine Redundanz.
Nach Charles Perrow [1] sind solche Unfälle bzw. Katastrophen ab einem gewissen Komplexitätsgrad unvermeidlich.
Jedoch ist die Ursache hierfür nicht in menschlichem Versagen
zu suchen, sondern in der Komplexität des Systems, denn
erst die entstehenden Zusammenhänge führen die einzelnen
unabhaengigen Zwischenfälle zur Katastrophe.
Dieser Beitrag entstand im Rahmen des Konferenzseminars ÏT-Sicherheit”,
das im Wintersemester 2010/11 an der Universität Erlangen-Nürnberg
durchgeführt wurde. Es wurde organisiert vom Lehrstuhl für ITSicherheitsinfrastrukturen (Prof. Dr. F. Freiling).
Kilian Redel
19
ITSEC@i1 2011
X-2
Da jeder Mensch mit den Begriffen Unfall, Zwischenfall etc.
etwas anderes verbindet, sollen im folgenden Kapitel zunächst
einige Definitionen zu Systemen, Unfällen und dergleichen
erläutert werden. Im dritten Abschnitt der Arbeit soll anhand
des Kernschmelzunfalls im Block 2 des Three Mile Island, der
im Buch von Charles Perrow ausführlich behandelt wird, nochmals die Komplexität von derartigen Systemen veranschaulicht
werden. Im 4. Abschnitt sollen die Schwierigkeiten komplexer
Systeme auf den IT-Bereich übertragen werden. Als Beispiel
hierfür dient unter anderem Stuxnet, ein Wurm, der sich in
industriellen Steuerungsanlagen einnistet und das Verhalten
der Steuerung manipulieren kann.
II. B EGRIFFSKL ÄRUNG
A. Unfälle
Die Mindestanforderung an einen Unfall ist, dass es ein
“unbeabsichtigtes und unvorteilhaftes Ereignis “ ist. Diese
Mindestanforderung wird jedoch bereits durch ein bloßes
Verfahren mit dem Auto erfüllt. Niemand würde allerdings auf
die Idee kommen zu sagen, dass er einen Unfall hatte, wenn
er sich lediglich verfahren hat. Also erscheint eine genauere
Definition bzw. Unterteilung des Begriffs notwendig. Hierfür
ist es sinnvoll ein System zunächst in Bestandteile zu zerlegen.
Diese sind in aufsteigender Reihenfolge: Teil, Einheit, Subsystem und System. Ein Teil ist beispielsweise ein Ventil in einer
Kühlanlage eines Schlachthauses. Diese Kühlanlage wiederum
kann zusammen mit ihren anderen Bestandteilen als Einheit
betrachtet werden. Zusammen mit der Isolierung etc. bildet es
das Subsystem “Kühlhaus“. Dieses Subsystem bildet zusammen mit anderen Subsystemen das System “Schlachthaus“.
Nach dieser Aufteilung des Systems kann man den Begriff
Unfall ebenfalls in Störfall und Unfall differenzieren. Ein
Störfall betrifft lediglich einen Teil oder eine Einheit und kann,
muss jedoch nicht das System beeinträchtigen. Störungen bzw.
Schäden die ganze Subsysteme oder gar das komplette System
betreffen, also den Funktionsablauf vollkommen unterbrechen
oder den Ablauf so beeinflussen, dass kein Weiterbetrieb
möglich ist werden als Unfälle bezeichnet. Bei Unfällen unterscheidet man Komponentenunfälle und Systemunfälle. Erstere
werden durch einen oder mehrere Fehler bzw. Fehlfunktionen
verursacht, deren Zusammenhang logisch und vorhersehbar ist.
Im Eingangsbeispiel wäre dies die Nichtverfügbarkeit eines
Taxis aufgrund der Aussperrung. Der Systemunfall dagegen
ist durch mehrere Fehler verursacht, bei denen der Zusammenhang nicht vorhersehbar war. Im Alltagsbeispiel die Verkettung
des defekten Autos mit dem liegengelassenen Schlüssel.
B. Komplexe und Lineare Systeme
Wichtige Unterscheidungsmerkmale von Systemen sind, ob
sie komplex oder linear bzw. eng oder lose gekoppelt sind. Im
Folgenden sollen diese Eigenschaften näher erläutert werden
und auch auf einige deren Vor- und Nachteile eingegangen
werden.
1) Lineare Systeme: Ein lineares System kennzeichnet sich
in erster Linie durch die lineare Anordnung der einzelnen
Vorgänge. Auf Schritt A folgt stets der Schritt B. Im Falle
eines Ausfalls oder fehlerhaften Verhaltens eines Vorgangs
Kilian Redel
treten keine unvorhersehbaren Interaktionen auf. Wenn also
ein Schritt ausfällt bedeutet das in der Regel nicht, dass auch
ein darauffolgender Schritt fehlerhaft arbeitet. Die Anzahl der
Vorgänge spielt hierbei keine Rolle. Ein einfaches Beispiel
für ein lineares System wäre ein Montageband bei dem sich
nach Ausfall einer Maschine zwar die Teile stauen, jedoch
keine unvorhergesehenen Rückwirkungen auf andere Teile der
Produktion auftreten.
2) Komplexe Systeme: Im Gegensatz zu den linearen Systemen kann bei komplexen Systemen nicht immer exakt
vorhergesagt werden, welche Folgen eine Aktion hat. Dies
beruht darauf, dass auch Teile oder Einheiten, die in keinem
sequentiellen Zusammenhang stehen sich gegenseitig beeinflussen können. Viele Komponenten haben eine CommonMode-Funktion. Dies bedeutet, dass eine Komponente mehrere
Aufgaben übernimmt. Eine Komponente kann ein Teil, Einheit
oder ein ganzes Subsystem sein. Ein Wärmetauscher kann
beispielsweise als Kühlung für eine Komponente und als
Heizvorrichtung für eine weitere Komponente dienen. Fällt
also diese Komponente aus sind beide angeschlossenen Komponenten betroffen.
Zudem existiert bei komplexen Systemen die Möglichkeit von
unbekannten und unbeabsichtigten Rückkopplungen. Außerdem besitzen komplexe Systeme ein Vielzahl an Kontrollparametern mit einer Vielzahl von möglichen Wechselwirkungen auf andere Parameter. Es kann also leicht zu einer Art
Butterfly-Effect kommen. Auch sind bei komplexen Systemen
häufig lediglich indirekte Informationsquellen vorhanden sind.
Etwa wenn der Füllstand eines Wassertanks nicht direkt über
einen Schwimmer gemessen wird, sondern indirekt über den
Druck auf ein Ventil am Auslass.
Die Tatsache, dass ein System komplex ist bedeutet nicht, dass
zwangsläufig auch ein Katastrophenpotential vorhanden ist. So
ist auch eine Universität ein hochkomplexes System, jedoch
mit begrenztem Katastrophenpotential.
3) Komplex vs. Linear: Lineare Systeme besitzen den klaren Vorteil, dass sie durchschaubar sind. Es gibt keinerlei unerwartete Wechselwirkungen und sind daher leicht beherrschbar
und Unfälle sind vermeidbar. Da keine Spezialisierung der
Operateure erforderlich, kann das System von Generalisten
bedient werden, die die Abläufe überblicken und verstehen
können und im Fehlerfall eingreifen können. Das Bedienpersonal ist somit substituierbar. Dies führt zu einer besseren
Sytemregenerierung nach einem Unfall, da der Ausfall eines
Bedieners durch das Einsetzen eines anderen kompensiert
werden kann.
Im Gegensatz hierzu haben komplexe Systeme erhebliche,
mitunter potentiell gefährliche, Nachteile. Einer davon liegt
mitunter in den gegenseitigen Wechselwirkungen. Zwar bauen
die Konstrukteure eine Vielzahl an Sicherheitsvorkehrungen
ein, die diese Wechselwirkungen verhindern sollen, jedoch lassen sich zum Einen niemals alle Redundanzen beseitigen und
zum Anderen führen oft gerade diese Sicherheitsvorkehrungen
zur Steigerung der Komplexität und damit unter Umständen
zur Fehleranfälligkeit. Auch ist der Operateur in komplexen
Systemen auf indirekte Rückmeldungen durch beispielsweise
Leuchtmeldern Anzeigen angewiesen. Dies kann dazu führen,
dass etwa aufgrund eines Drahtbruchs an einem Sensor, ei-
20
ITSEC@i1 2011
X-3
ne Falschmeldung entsteht. Dies bewirkt unter Umständen,
dass der Operateur fälschlicherweise ein Fehlverhalten der
Anlage annimmt und Gegenmaßnahmen einleitet, die wiederum dazu führen, dass überhaupt erst ein Fehler entsteht.
Demzufolge müssten auch die Sensoren selbst überwacht
werden. Diese Überwachungskette lässt sich nun fast unbegrenzt weiterführen. Die Herausforderung bei der Entwicklung
komplexer Systeme besteht auch darin, dem Bedienpersonal,
das nicht den kompletten Prozess überblickt, nicht zu viele
Informationen anzuzeigen, um Überforderung zu vermeiden.
Dennoch müssen alle relevanten Informationen abrufbar sein,
damit im Ernstfall richtig reagiert werden kann.
Nach Abwägung aller Argumente scheint es, dass lineare
Systeme die erheblich besseren Systeme wären, da sie besser
beherrschbar, weniger fehleranfällig und im Fehlerfall leichter
wiederherstellbar sind. Daher versuchen Ingenieure möglichst
viele Prozesse zu linearisieren. So wurde beim Flugzeug der
komplexere Kolbenmotor von dem einfacheren Düsenantrieb
abgelöst. Allerdings lassen sich Common-Mode Funktionen
in vielen Fällen nicht vermeiden. Auch sind einige Prozesse, beispielsweise in Ölraffinerien oder Chemiefabriken, gar
nicht erst als lineare Prozesse realisierbar. Der entscheidende
Vorteil von komplexen Systemen ist jedoch ihre höhere Effizienz. So werden beispielsweise bei dem bereits aufgeführten
Wärmetauscher, die Ressourcen sehr effizient genutzt. Man
versucht daher komplexe Prozesse, wo dies ökonomisch und
technisch sinnvoll ist zu vermeiden und durch lineare zu
ersetzen.
C. Enge und lose Kopplung
Eine weiteres Unterscheidungsmerkmal von Systemen ist
die Art der Kopplung ihrer Komponenten. Die Art der Kopplung ist unabhängig von der Komplexität oder Linearität des
Systems.
1) Enge Kopplung: Enge Kopplung bedeutet, dass zwischen zwei Teilen keine Verzögerung in der Abarbeitung
möglich ist, es also keine Pufferung gibt die etwaige Zeitverzögerungen ausgleichen kann. Zusätzlich bedeutet enge
Kopplung auch eine Invarianz des Systems. Die Möglichkeit
zwei Komponenten zu vertauschen ist also nicht vorhanden. In den Bereichen Versorgung, Ausrüstung und Personal ist ebenfalls kaum Variation oder Verzögerung möglich.
Änderungsmöglichkeiten müssen von vornherein eingeplant
sein. Es führt nur ein Weg zum Ziel und jeder Fehler hat
zwangsläufig Auswirkungen auf das mit ihm eng gekoppelte System. Grundsätzlich sind eng gekoppelte Systeme sehr
effizient und schnell, jedoch auch unflexibel. Beispiel hierfür
wäre Just-In-Time Fertigung. Tritt hier eine Verzögerung in
einem Bereich auf hat dies sehr schnell Auswirkungen auf die
gesamte Produktion. Auch der Austausch von Lieferanten oder
eine Veränderung im Produktionsablauf ist nahezu unmöglich
bzw. zieht grundlegende Ablaufänderung mit sich.
2) Lose Kopplung: Bei loser Kopplung hingegen wirken
sich Fehler nicht zwangsläufig direkt auf die gekoppelte Komponente aus. Es sind meist alternative Methoden vorhanden die
ebenfalls zielführend sind und einzelne Sequenzen sind untereinander austauschbar. Ebenfalls möglich sind Verzögerungen
Kilian Redel
oder Variationen in Versorgung, Ausrüstung und Personal. Ein
Beispiel für lose Kopplung ist die Schule. Fällt ein Lateinlehrer
aus, kann dieser durch einen anderen Lateinlehrer oder, bei
einem kurzen Ausfall, sogar durch einen beliebigen anderen
Lehrer ersetzt werden ohne, dass die Bildung der Schüler
leidet.
III. T HREE M ILE I SLAND
Am 28. März 1979 ereignete sich im Kernkraftwerk Three
Mile Island etwas was nach Einschätzungen der Atomgutachter gar nicht hätte passieren können. Der Reaktorblock
2 des Kraftwerks geriet außer Kontrolle. Es war die erste
Kernschmelze in einem Großreaktor. Die Operateure der Betreiberfirma Metropolitan Edison Company sowie eine große
Zahl an Experten benötigten fast eine Woche bis der Reaktor wieder weitgehend stabil lief. Bis heute ist die einzige
Erklärung für das Ausbleiben eines Super-GAU Glück. Seit
diesem Unfall wurde in den USA kein weiteres Atomkraftwerk
gebaut. Erst Anfang des Jahres 2010 hat die amerikanische
Regierung Kreditzusagen für den Bau von zwei Reaktoren
angekündigt [7]. In diesem Kapitel soll zunächst kurz die
Technik des Kraftwerks erklärt und der Hergang des Unfalls
beschrieben werden. Im letzten Abschnitt wird der Unfall in
Bezug auf die Eigenschaften komplexer Systeme analysiert.
A. Technik
Das Kernkraftwerk Three Mile Island (TMI) besitzt,
wie auch 11 der 17 Atommeiler in Deutschland [8], die
Druckwasserreaktorbauform. Kennzeichnend für diese Bauform sind die zwei getrennten Kühlkreisläufe, Primär- und
Sekundärkreislauf. Um ein Sieden bei Betriebstemperatur
von über 300◦ C zu vermeiden steht das Kühlmittel im
Primärkreislauf unter Druck. Es wird durch den Reaktorkern
geleitet und nimmt dort, die von der Kernspaltung erzeugte,
Wärme auf. Von dort aus gelangt es in den Dampferzeuger
wo es das Wasser des Sekundärkreislaufs zum sieden bringt.
Der so erzeugte Wasserdampf wird über Rohrleitungen in
eine Dampfturbine geleitet, welche über den angeschlossenen Generator Strom erzeugt. Der Dampf wird anschließend
in einem Kondensator niedergeschlagen und von dort als
Wasser mit der Speisepumpe wieder dem Dampferzeuger
zugeführt. Der Kondensator wiederum wird mit Kühlwasser,
beispielsweise aus einem Fluss, gekühlt. Der Vorteil dieser
Bauform ist, dass durch die zwei getrennten Kühlkreisläufe
keine radioaktiven Stoffe das Reaktorgebäude verlassen, da nur
der Primärkreislauf radioaktiv ist. Nachfolgend zur besseren
Übersicht und Nachverfolgbarkeit der Abläufe ein Überblick
über den Block 2 des TMI. Deutlich in der Grafik zu erkennen
sind Primär und Sekundärkreislauf etc. Zusätzlich zu sehen
sind noch einige Sicherheitseinrichtung, deren Funktion bzw.
Fehlfunktion bei dem Unfall 1979 wichtige Rolle spielen.
B. Unfallhergang
Aufgrund von Problemen in der Pumpensteuerung fielen
am 28.März 1979 um 4:36 Uhr Ortszeit bei Arbeiten an der
Kondensatreinigungsanlage im nichtradioaktiven sekundären
21
ITSEC@i1 2011
X-4
Abbildung 1.
Vereinfachte Darstellung von Block 2
Kreislauf die beiden Hauptspeisepumpen aus. Angeblich aufgrund der Tatsache, dass jemand absichtlich oder unabsichtlich
eine Luftleitung mit einer Wasserleitung verbunden hatte. Dies
war möglich, da beide Systeme aufgrund eines Konstruktionsfehlers über den gleichen Anschluss verfügten.
1) Fehlfunktion Sicherheitsventil im Primärkreislauf: Als
Reaktion auf den Ausfall der Pumpen schaltete sich zunächst
der Turbosatz und darauf der Kernreaktor durch SCRAM
(Notabschaltung) ab, wodurch die nukleare Kettenreaktion
beendet wurde. Da jedoch nach einer Notabschaltung noch
eine immense Menge an Nachzerfallswärme frei wird stieg
der Druck im Druckhalter (Pressurizer) auf 7 bar über Normaldruck an. Um einen druckbedingten Leitungsbruch im radioaktiven primären Kühlsystem zu vermeiden war ein PORV
(Pilot operated relief valve) vorhanden. Dieses öffnete sich
korrekterweise aufgrund des Überdrucks. Nachdem der Druck
nach 13 Sekunden wieder unter 155 bar gefallen war schloss
sich das Ventil, anders als vorgesehen, nicht wieder. Dieses
Fehlverhalten blieb über mehr als zwei Stunden unbemerkt.
Währenddessen lief das Kühlmittel zunächst in den Abblasetank bis dieser voll war und hierauf, aufgrund einer gebrochenen Berstscheibe des Tanks, ins Containment, den Sicherheitsbehälter des Reaktors. Die Anzeigen im Kontrollraum zeigten
diesen, sich anbahnenden Kühlmittelverluststörfall nicht an
wodurch ein Schließen des Ventils ausblieb und der Druck
weiter sank.
2) Probleme im Speisewassersystem: Etwa zeitgleich ereignete sich an anderer Stelle des Kraftwerks ein weiteres
Problem. 42 Stunden vor dem Unfall wurden im Rahmen eines
Tests des Notfall-Speisewassersystem, zwei Absperrventile
geschlossen. Nach Ende des Tests wurden diese, entweder
wegen menschlichen Versagens oder aufgrund eines Verfahrensfehlers nicht wieder geöffnet. So nahmen, nach Ausfall der
Hauptspeisepumpen die Reserverpumpen zwar ihren Betrieb
ordnungsgemäß auf, konnten jedoch wegen der geschlossenen
Ventile den Dampferzeuger nicht mit Wasser versorgen und
die Nachzerfallswärme nicht abgeführt. Dieser Fehler wurde
jedoch nach 8 Minuten erkannt und die Ventile geöffnet.
Das Notspeisesystem konnte so den Dampferzeuger wieder
ordnungsgemäß mit Wasser versorgen.
3) Fehleinschätzung der Situation: Durch den Druckabfall im Primärkreislauf bildeten sich dort Dampfblasen,
Kilian Redel
die das Kühlmittel in den Druckhalter drückten. Da der
Füllstandsgeber seine Werte nur aus dem Druckhalter erhielt
und dieser nun mehr Wasser als normal enthielt, nahm der
Bediener an, dass das System überfüllt sei und stoppte die
korrekterweise angelaufene Notkühlung, da die Reaktorfahrer
in ihrer Ausbildung dazu angehalten wurden ein vollständiges
Volllaufen des Druckhalters unter allen Umständen zu verhindern, da die im Normalbetrieb im Druckhalter vorhandene
Dampfblase verhindern soll, dass Rohrleitungen im Fall eines
Druckstoßes bersten. Jetzt befand sich jedoch eine Dampfblase
im oberen Bereich des Reaktorbehälters.
4) Temperaturanstieg und weitere Fehleinschätzung durch
Bedienpersonal: Da die Pumpen nur noch Dampf ansaugten wurden diese abgeschaltet und man nahm an, dass der
Wasserfluss durch die natürliche Konvektion aufrecht erhalten
würde. Der Wasserfluss wurde jedoch durch Dampfblasen in
den Rohren blockiert und das stehende Wasser verwandelte sich zunehmend in Dampf, so dass 130 Minuten nach
der ersten Fehlfunktion der obere Teil des Reaktors nicht
mehr von Kühlflüssigkeit umgeben war. Durch die geringere
Wärmekapazität des Dampfes wurde nur noch eine geringe
Menge Wärme von den Brennstäben abtransportiert und die
Temperatur stieg weiter. Richtig wäre in dieser Situation
gewesen, den Druck im Primärkreislauf aufrecht zu erhalten
um ein Verdampfen des Wassers zu verhindern.
5) Knallgasbildung: Durch eine temperaturbedingte
Zirconium-Wasser-Reaktion oxidierte die Hülle der
Brennstäbe und Wasserstoff wurde freigesetzt. Dieser
gelangte, nachdem er sich zunächst am Reaktordeckel
gesammelt hat über das offene PORV zum Druckhalter
- Abblasetank und von dort mit dem Kühlmittel ins
Containment, wo sich zusammen mit Luftsauerstoff Knallgas
bildete. Nachdem sich das ausgelaufene Kühlmittel am
tiefsten Punkt des Sicherheitsbehälters (Reactorbuilding)
gesammelt hatte wurde es, aufgrund eines Schaltfehlers, von
dort in einen Tank im Hilfsanlagengebäude gepumpt, der
überlief und ein kleinerer Teil radioaktiver Gase aus dem
Wasser gelangte in die Umgebung.
6) Erkennung der Übertemperatur: Als um 6 Uhr die
nächste Schicht die Übertemperatur bemerkte und den
Kühlwasserverlust über ein Reserveventil stoppte war bereits
eine immense Menge Kühlmittel entwichen und die Radioaktivität im primären Kühlkreislauf 300-mal so hoch wie erwartet:
Die Kernschmelze war im Gange.
7) Erfassen des kompletten Ausmaßes und Sabilisierung:
Erst dreieinhalb Stunden nach Beginn des Unfalls wurde der
viel zu niedrige Wasserstand von hinzugekommenen Experten
bemerkt, neues Wasser in den Primärkreis gepumpt und etwas später ein Reservesicherheitsventil zur Druckreduzierung
geöffnet. Das Knallgasgemisch im Containment entzündete
sich nach 9 Stunden, wodurch dessen Innendruck kurzzeitig
fast seine Auslegungsgrenze erreichte. Erst nach 16 Stunden
wurden die Pumpen des primären Kreislaufs wieder in Betrieb
genommen und die Temperatur des Kerns, der zu einem
großen Teil geschmolzen war, begann zu sinken. Rund eine
Woche später waren Wasserstoff und Wasserdampf über Kondensatoren und durch einfaches Ablassen in die Atmosphäre
entfernt.
22
ITSEC@i1 2011
X-5
C. Analyse des Unfalls im Bezug auf Eigenschaften komplexer
Systeme
Der Unfall im Three Mile Island Kraftwerk veranschaulicht
deutlich die Gefahren komplexer Systeme: Eine ausführliche
Untersuchung des Unfalls kam zu dem Ergebnis, dass die
Hauptursache darin bestand, dass das offene PORV nicht
bemerkt worden war, weshalb das radioaktive Wasser austreten
konnte, wodurch zum Einen das Knallgas entstehen konnte
und es zum Anderen aufgrund mangelnder Kühlung zur Kernschmelze kommen konnte. Der Grund für das späte Erkennen
des offenen PORV liegt darin, dass die Kontrolleuchte lediglich den Stromfluss an der Steuerspule des Ventils anzeigte und
nicht, etwa über einen Endlagenschalter, in welcher Position
sich das Ventil befindet. Die Anzeige zeigte keinen Stromfluss,
so dass das Bedienpersonal davon ausging, dass das Ventil
geschlossen war.
Eine weitere Fehlerquelle aufgrund indirekter Informationsanzeigen war, dass der Füllstand des Kühlkreislaufs lediglich
aus dem Druckbehälter bezogen und so fälschlicherweise eine
Überfüllung des Primärkreislaufs angenommen wurde.
Auch die Eigenschaft der Wechselwirkungen in komplexen
Systemen wurde bei dem Unfall deutlich. So führte das
Fehlverhalten eines Ventils dazu, dass Kühlmittel austreten
konnte. Dieses verkettete sich mit dem Umstand, dass aufgrund der geschlossenen Ventile die Nachzerfallswärme nicht
sofort abgeführt werden konnte. Zwar behaupteten die für die
Wartung zuständigen Ingenieure die Ventile wieder geöffnet zu
haben. Dies kann jedoch ein Irrtum gewesen sein, wie wenn
man denkt die Haustür abgeschlossen zu haben, weil man es
immer macht. So hatten die Ingenieure hier etliche Ventile zu
stellen, so dass es passieren konnte, dass eben jene 2 Ventile
vergessen wurde (Heute fahren die Ventile nach Ziehen des
Schlüsselschalters automatisch wieder in Ausgangsposition).
Auch waren die Mitarbeiter laut des Untersuchungsberichts
unzureichend ausgebildet um die komplexe Situation korrekt
erfassen zu können, was auch daran deutlich wird, dass der
niedrige Wasserstand zu spät bemerkt wurde und erst nach
Eintreffen von Fachleuten die richtigen Gegenmaßnahmen
ergriffen wurden.
Es stellt sich die Frage inwieweit sich ein solcher Unfall heutzutage noch ereignen kann. Vermutlich werden die
eben genannten Fehler nicht noch einmal passieren, da sich
seit damals die Überwachungsmöglichkeiten sowohl bei der
Sensortechnik als auch im Bereich der Anzeigeinstrumente
verbessert haben. Eine moderne Steuerung kann beispielsweise
eine potentiell gefährliche Fehlermeldung direkt auf einen
zentralen Monitor schalten. Auch wird durch grafische Benutzeroberflächen eine wesentlich übersichtlichere Darstellung
als mit Leuchtmeldern ermöglicht. Es können beispielsweise
im Normalbetrieb nur die Grundinformationen bereitgestellt
werden und gleichzeitig über Menüs usw. genauere Informationen schnell abrufbar sein. Anfallende Störmeldungen
werden sofort in den Vordergrund gesetzt.
Doch entstehen eben durch diese besseren, leistungsfähigeren,
oft universalen Steuerungen, die zweifelsohne eine Steigerung
der Sicherheit ermöglichen, neue Fehlerquellen bzw. Bedrohungen, wie jüngst der Computerwurm Stuxnet gezeigt hat.
Kilian Redel
Auf Stuxnet und andere Gefährdungen sowie neue Komplexitäten, die durch den Einzug von Computertechnik in nahezu
alle Lebens- und Versorgungsbereiche entstanden sind soll im
nächsten Kapitel eingegangen werden.
IV. KOMPLEXIT ÄT UND DEREN G EFAHREN IM IT-B EREICH
Wie bereits erwähnt werden heutzutage die meisten großen
Industrieanlagen über Software gesteuert. In der Theorie
werden Informationen zwischen einzelnen Anlagenbereichen
ausgetauscht und automatisch ausgewertet, wodurch schnell
und ohne die Gefahr menschlicher Fehlentscheidungen von
der Software richtig gehandelt wird.
Fraglich ist in welchem Maße die Sicherheit von großen
Anlagen sich tatsächlich verbessert hat oder ob durch den
gestiegenen Automatisierungsgrad nur die Komplexität und
Effizienz gesteigert wurde.
In den folgenden Seiten soll, unter anderem anhand des
Stuxnet-Wurms, die Gefahr eines unsichtbaren Angriffs von
außen, die ohne Zweifel durch die mit der steigenden Automatisierung einhergehenden Vernetzung entstanden bzw. gestiegen ist, verdeutlicht werden. Außerdem soll auf die Versuche
durch gutes Softwareengineering sowohl Security, also der
Schutz gegen Angriffe von außen, als auch Safety, den Schutz
vor Fehlfunktionen, zu gewährleisten.
A. Unterschiede Software-Engineering / klassisches Engineering
Heute hält Software auch in Bereiche Einzug, die ehemals
klassischen Ingenieurswissenschaften vorbehalten waren, wie
etwa Fahrzeugbau, der nach wie vor eine Domäne der Maschinenbauer ist. Angefangen von Multimediasystemen, bis
zur Motorsteuerung kommt kein modernes Auto mehr ohne
Software aus. Einige Autos würden ohne Software sogar in
schnellen Kurven umkippen [2]. Jedoch weist die Entwicklung
von Software einige wichtige Unterschiede zur Entwicklungsarbeit in klassischen Ingenieurswissenschaften auf.
Software verursacht praktisch keinen Fertigungsaufwand.
Demnach ist die Entwicklung der Hauptbestandteil des Herstellungsprozesses, was dazu führt, dass man bestrebt ist
Software nach Möglichkeit wiederzuverwenden. Häufig wird
dieser Anpassungsaufwand jedoch unterschätzt, da scheinbar
nur wenige Zeilen Code geändert werden müssen und es treten
im Betrieb Fehler auf. Daher ist die im allgemeinen sehr
hohe Anpassungsfähigkeit von Software auch eine sehr große
Fehlerquelle. Da Softwaresysteme hochkomplex sind, schon
mittelgroße Programme bestehen aus mehreren Dokumenten
einigen tausend Zeilen Code, können kleine Änderungen oder
Fehler in der Ausführung zu großen Fehlern führen. Eine
weitere Schwierigkeit bei Softwaresystemen besteht darin,
dass Fehler sich in der Regel nicht ankündigen, wie dies beispielsweise bei einem falsch dimensionierten Brückenpfeiler
der Fall ist, sondern plötzlich auftreten können.
Im nächsten Abschnitt sollen anhand des Negativbeispiels
des Therac-25 mögliche Fehlerquellen von Software erläutert
werden aber auch wie durch gutes Softwareengineering eben
diese gemieden werden können.
23
ITSEC@i1 2011
X-6
B. Sicherstellung von Safety und Security
1) Safety: Mit dem Begriff Safety ist gemeint, dass das
Programm frei von Fehlfunktionen ist. Zunächst soll kurz der
Therac-25 berühmtes Beispiel für Softwarefehler beschrieben
werden. Der Therac-25 war ein Bestrahlungsgerät zur Behandlung von Tumoren, das zwischen 1985 und 1987 in den
USA und Kanada eingesetzt wurde. Durch Softwarefehler und
fahrlässiges Verhalten beim Umgang mit Fehlern kam es zu 6
Todesfällen.
Der Therac-25 war das erste Gerät seiner Baureihe, das eine
reine Computersteuerung besaß, die die notwendigen Parameter, wie Strahlungsintensität oder Stellung des Strahlungsarms
kontrollierte. Diese Software enthielt jedoch zwei Bugs die zu
den Unfällen führten.
Der Texas-Bug, verantwortlich für Unglücke in Texas, bestand darin, dass ein Flag, durch dessen Setzen Änderungen
von Benutzereingaben erkannt werden, von einer Subroutine
gelöscht wurde. Bei der Eingabe der Daten für die Bestrahlung hatte eine Technikerin versehentlich Röntgenstrahlung
(hohe Intensität) eingestellt. Zwar bemerkte sie den Fehler
und änderte den Eintrag, jedoch war sowohl das DataEntry
Complete Flag durch erreichen des unteren rechten Displayrandes bereits gesetzt, als auch das Flag für das Erkennen
von Korrekturen bereits gelöscht. Infolgedessen erhielt die
Patientin eine starke Überdosis.
Ein weiterer Fehler war der Washington-Bug, ein ähnlich
simpler, jedoch folgenreicher Fehler, der im Wesentlichen auf
einem Overflow beruht. Nach Einstellen der Behandlungsparameter wurde die Set-Up-Test-Routine aufgerufen. Hatte die
Variable Class3 den Wert null konnte mit der Behandlung
begonnen werden. Allerdings wurde die Variable mit jedem
Durchlauf der Routine inkrementiert und die Routine konnte
mehrere hundert Mal aufgerufen werden bis alles korrekt
eingestellt war. Da die Variable jedoch nur ein Byte groß
war wurde sie bei jedem 256. Aufruf wieder null. Deshalb
wurde nicht mehr überprüft in welcher Stellung sich etwa der
Strahlungsarm befand. Dies führte ebenfalls zu gefährlichen
Strahlenbelastungen für die Patienten.
Die Ursachen für das Entstehen bzw. Nichterkennen dieser
Fehler liegt unter anderem darin, dass die Software von einem
Entwickler allein über mehrere Jahre entwickelt wurde. Auch
hielt der Hersteller die Software für unfehlbar und beschränkte
die Tests Sicherheitsabschätzungen sowie die spätere Fehlersuche zunächst auf die Hardwareebene. Zu alledem kam
noch mangelnde Dokumentation des Programms und wenig
aussagekräftige Fehlermeldungen, wie “Fehler Nr. xy“, von
denen bis zu 40 pro Tag erschienen und vom Bedienpersonal
deshalb nicht mehr beachtet wurden [10].
Heute nimmt der Schutz vor Fehlfunktionen in der Softwareentwicklung, gerade bei sicherheitskritischen Bereichen wie
der Medizintechnik einen hohen Stellenwert ein. Es existieren Entwicklungsmodelle, wie das V-Modell, bei denen die
Softwareentwicklung in Schritte aufgeteilt wird. Dies beginnt
mit der Anforderungsanalyse, bei der die Anforderungen an
die Software umrissen werden und geht über Spezifikationsphase, Designphase, Grobentwurf bis zum Feinentwurf der
einzelnen Softwaremodule. Zwischen jedem einzelnen Schritt
Kilian Redel
wird validiert und verifiziert, ob die aus der höheren Stufe
gekommenen Anforderungen erfüllt sind. Danach geht es in
die Implementierung. Hier wird mit den einzelnen Modulen
begonnen und Schritt für Schritt bis zur Installation des
gesamten Systems vorgegangen [3]. Auch hier wird nach
jeder Phase getestet, ob die geforderten Funktionen vorhanden
sind und funktionieren. Zusätzlich holen sich Hersteller, wie
beispielsweise Siemens Healthcare, Unterstützung von auf
Softwaretests spezialisierten Unternehmen, um ihre Software
auf Fehlerfreiheit und Sicherheit zu überprüfen [9].
2) Security: Die Fehlerfreiheit und die Zuverlässigkeit von
Programmen hilft jedoch wenig, wenn die Software von außen
angreifbar ist und manipuliert werden kann, so dass der
fehlerfreie Betrieb nicht mehr gewährleistet ist. Zur Sicherung
der Software gegen unerlaubten Zugriff oder gar Manipulation
werden unterschiedliche Methoden, sowohl auf Software- als
auch auf Hardwareebene angewandt. Eine erste Methode zur
Abwehr von Angriffen ist das Schreiben von sicherem Code,
um beispielsweise einen von außen verursachten Systemabsturz durch einen provozierten Bufferoverflow zu verhindern.
Eine weitere Maßnahme ist das Verteilen von Zugriffsrechten.
Also dürfen zum Beispiel über das Benutzerkonto, unter
welchem eine sicherheitskritische Anwendung läuft, keine
Änderungen vorgenommen werden. Um dies zu ermöglichen
ist eine sichere Authentifizierung eines Benutzers notwendig,
damit nur der auf eine kritische Anwendung zugreifen kann,
der dazu berechtigt ist. Hierfür ist es nötig ein sicheres Authentifizierungsverfahren zu verwenden, das nicht etwa durch
einfaches Passwortraten zu knacken ist. Auch ist ein Schutz
der verhindert, dass unsichere Software auf den Rechner
gelangt, sinnvoll. Dies geschieht u.a. durch die Verifizierung
von Software, d.h. Software von bestimmten Herstellern wird
als vertrauenswürdig eingestuft und darf installiert werden.
Hierfür benötigt die Software ein Zertifikat, mit dem sie
nachweist, dass sie wirklich von einem sicheren Hersteller
ist. Eine einfache hardwareseitige Sicherheitsmaßnahme besteht darin, sicherheitskritische PC’s nicht in ein Netzwerk
einzubinden, über welches Internetzugang besteht. Auch ist
es sinnvoll solche Rechner nicht mit einem USB-Anschluss
oder CD-Laufwerk auszustatten, damit potentielle Schadsoftware gar nicht erst installiert werden. Allerdings kann bei
Wartungsarbeiten ein Zugriff auf diese Rechner über USBStick etc. vonnöten sein. Hier sollte durch den Einsatz von
Virenscannern, Firewalls etc., sichergestellt werden, dass keine
Schadsoftware auf den Rechner gelangt. Zu alledem ist es
extrem wichtig die mit dem System betrauten Mitarbeiter
ausreichend zu schulen und zu überprüfen, da viele Sicherheitsmaßnahmen hinfällig werden, wenn ein Mitarbeiter, mit
entsprechenden Zugriffsrechten absichtlich oder unabsichtlich
einen Usb-Stick mit Schadsoftware an den PC anschließt.
Trotz all dieser Vorsichtsmaßnahmen ist beispielsweise ein
Betriebssystem, egal ob Windows, Linux oder MAC derart komplex, dass es mit vertretbarem Kostenaufwand nicht
möglich ist, Sicherheitslücken komplett zu vermeiden.
Ein eindrucksvolles Beispiel für Gefährdungen von außen
gab in den letzten Monaten der Computerwurm Stuxnet, der
im nächsten Abschnitt betrachtet werden soll.
24
ITSEC@i1 2011
X-7
C. Stuxnet
Im Juni 2010 wurde erstmals der Wurm Stuxnet bekannt.
Er ist der erste seiner Art, der gezielt gegen ein industrielles
Steuerungssystem, in diesem Fall der Simatic S7 der Firma
Siemens, gerichtet war. Gefunden wurde er unter anderem in
den Steuerungsanlagen einer iranischen Anlage zur Urananreicherung. Stuxnet nutzt gezielt Lücken in Microsoft Betriebssystemen ab Windows 2000. Bei Infektion verschafft sich der
Wurm zunächst über verschiedene Windows-Sicherheitslücken
Administratorrechte. Die Installation selbst läuft in einem, vom
infizierten System als sicher eingestuften Prozess ab. Mithilfe
von signierten Zertfikaten der Firmen Realtek und JMicron
Technology, die als vertrauenswürdig eingestuft sind, werden
zusätzlich noch Treiberdateien geladen, um eine Weiterverbreitung zu ermöglichen. Ebenso sucht er im angeschlossenen
Netzwerk nach weiteren Stuxnetinstanzen und updatet diese
gegebenenfalls bzw. verbreitet sich weiter [4]. Auch wird,
sobald ein USB-Stick eingesteckt wird, dieser ebenfalls infiziert. Danach nistet sich der Wurm in einen auf dem Rechner
installierten Simatic Manager, der Software mit der die Simatic
Systeme programmiert werden, ein. Findet er zusätzlich noch
ein installiertes WinCC, mit welcher die Visualisierung für
diese Systeme erstellt wird, befällt er auch dieses. Nach aktuellen Erkenntnissen wird der Wurm allerdings nur aktiv, wenn
er auf Frequenzregler trifft. Mit diesen wird beispielsweise die
Drehzahl von Motoren gesteuert. Eine weitere Bedingung für
das aktiv werden ist, dass er auf sehr hochdrehende Motoren
trifft. Ist dies der Fall beginnt er deren Drehzahlen hoch
und runter zu fahren [5]. Motoren mit solchen Drehzahlen
sind u.a. in Anlagen zur Urananreicherung zu finden. Stuxnet
benötigt keinen Internetzugang, wenn er diesen jedoch findet
ermöglicht dies sowohl Updates als auch eine Fernsteuerung
der Anlage und eine Weitergabe von Informationen an den
Urheber.
Wichtig ist es deshalb sich der Risiken bewusst zu sein
und alles zu versuchen potentielle Fehlerquellen und Angriffsmöglichkeiten abzusichern. Dennoch werden Katastrophen, Stör- und Unfälle nach Charles Perrow unvermeidlich
sein sobald ein System eine gewisse Komplexität erreicht hat
[1].
L ITERATUR
[1] Charles Perrow, Normal Accidents: Living with High Risk Technology,
New Jersey, USA:Princeton University Press, 1999
[2] www.welt.de/motor/article1280688/Mercedes und der Elch Die perfekte Blamage.html
28.11.2010
[3] Jochen Ludewig u. Horst Lichter,Software Engineering: Grundlagen,
Menschen, Prozesse, Techniken, Heidelberg,Deutschland: dpunkt.verlag
[4] Nicolas Falliere, Liam O Murchu and Eric Chien: W23.Stuxnet Dossier
Version 1.3, November 2010, Symantec
[5] www.zeit.de/2010/48/Computerwurm-Stuxnet 28.11.2010
[6] http://www.ftd.de/politik/international/:oelkatastrophe-us-regierungweist-halliburton-mitschuld-zu/50188572.html 30.12.2010
[7] http://www.n-tv.de/politik/Obama-setzt-auf-Atomkraftarticle731934.html 30.12.2010
[8] http://www.kernenergie.de/kernenergie/Themen/Kernkraftwerke/
30.12.2010
[9] http://www.infoteam.de/de/referenzen/ 03.01.2011
[10] Martin Pfeifer: Berühmt berüchtigte Softwarefehler: Therac-25 ,
Universität Koblenz http://www.uni-koblenz.de/ beckert/Lehre/SeminarSoftwarefehler/Ausarbeitungen/pfeifer.pdf 03.01.2011
V. FAZIT
Durch den Einzug von IT in nahezu alle Lebensbereiche
ist vieles zweifelsohne sicherer geworden. Beispiele hierfür
sind die zahlreichen aktiven und passiven Assistenzsysteme
im Auto. Sie erfassen unzählige Parameter und werten diese
aus. So kann auf erkannte gefährliche Situationen schnell
und richtig reagiert werden. Auch in anderen Bereichen, wie
einem Atomkraftwerk kann, wie im dritten Kapitel erwähnt,
durch grafische Anzeigen, z.B. mit Hilfe von WinCC, die
Überwachung komplexer Systeme vereinfacht werden, so dass
Fehler besser und schneller erkannt werden. Ebenfalls enorm
ist die Effizienzsteigerung und damit die Kostensenkung.
Durch automatische Adresserkennung etwa arbeiten Sortierzentren so schnell, dass ein Paket meist innerhalb von 24 Std.
sein Ziel erreicht.
Doch im gleichen Moment entstehen neue Fehlerquellen
und Angriffsmöglichkeiten. Am Beispiel Therac-25 wurden
die möglichen Auswirkungen von Softwarefehlern deutlich.
Stuxnet hat gezeigt, dass auch IndustriePCs ohne Internetzugang angreifbar sind. In einem Paketzentrum ist so ein Angriff
nicht sehr gefährlich. Gerät jedoch ein Atomkraftwerk außer
Kontrolle ist die Situation ungleich kritischer.
Kilian Redel
25
Practical capabilities for UNIX
ITSEC@i1 2011
1
Mykola Protsenko
University of Erlangen-Nuremberg
Abstract — This paper aims to overview some efforts to
enhance the UNIX operating system’s security with a capabilitiesbased model. Starting with POSIX 1003.1e capabilities and
describing its flaws we move on to more sophisticated solution
called Capsicum, which is already planned for inclusion in
FreeBSD 9. Then, to demonstrate the usage of this approach, we
point out some general principles of changing legacy programs to
make them use Capsicum primitives.
I. INTRODUCTION
I
n this paper we try to overview some enhancements to the
classic UNIX security model which aim to add capabilities
to this system. In the next section we give a formal definition
of capabilities and compare it with other security models. Then
we describe how the classic UNIX security system works and
review the attempt to improve its strength with a concept
somehow approaching the capabilities model, namely so called
POSIX capabilities, introduced in POSIX draft 1003.1e, even
though they differ from the capabilities definition generally
known in computer science. After that we move on to
Capsicum – a new “real” capability system, planned for
inclusion in FreeBSD 9.
II. CAPABILITIES
In this section we will introduce the term “capabilities” and
review the place they take among other security concepts.
The environment we have to deal with is that of a multiuser
operating system, where different users may have numerous
processes (executing programs) running that are working
either on one distributed task or are performing several
different computations. Since running a process is the only
way the user can be active in our system, we will denote such a
process working on behalf of a user as a subject.
Each user also possesses some data stored in the system, also
called resource or object, which may be required by one/some
user processes for their computation (note, that any object can
be both subject and resource at the same time, for instance a
child process controlled by its parent process).
In this context we will call the ability (or the right to do so)
of a subject to perform some actions upon a certain resource
This paper was written as part of the conference seminar "IT Security"
which was organized by the Chair for IT Security Infrastructures (Prof. Dr. F.
Freiling) at the University of Erlangen-Nuremberg during winter term
2010/2011.
Mykola Protsenko
an authority. A set of such authorities is often called a domain.
Each subject always belongs to some domain meaning it has
exactly the rights described by the domain. Note that several
subjects may belong to the same domain simultaneously if they
possess the same set of authorities.
The above described environment defines the first and
obvious security goal: the data of one user should be protected
from the others. This concept is known as Discretionary
Access Control (DAC):
“The discretionary access control mechanism shall, either by
explicit user action or by default, provide that objects are
protected from unauthorized access.” [15]
Another very important issue one should always keep in
mind is that a program executed by one specific user should
not necessarily be trusted the way the user himself is, as even
the most trusted person (for instance, a system administrator)
can run buggy and exploitable software. This brings us right to
the next point regarding security goals: to minimize the harm
caused by malicious software, we should restrict its authority.
Since every process will require certain rights for its
computation, this restriction has its limits, so the optimum
from the security point of view is to give each subject the
minimum authority it requires to perform its task. This
fundamental principle is known in computer science as the
principle of least privilege [10].
Summarizing this two goals of protection, we come to a
simple general observation that different subjects should have
different authorities with respect to different resources.
The most simple and obvious way to store and manage the
corresponding information in the system is a so called access
matrix, presented by Lampson in [1]. In this matrix all
resources available in the system are presented in rows and
domains in columns. Each cell of the matrix contains the
authority, describing what actions the subjects of the
corresponding domain are allowed to perform on the resource.
Fig. 1 shows a small example of such a matrix in a system with
four resources and three domains. For the sake simplicity, the
possible authorities are restricted to read-, write- and write and
read access.
Domain A
Domain B
Domain D
Resource 1
read, write
–
–
Resource 2
–
–
read, write
Resource 3
read
read
–
Resource 4
write
–
–
Fig. 1. Lampson’s Access matrix.
26
ITSEC@i1 2011
2
Since the number of available resources, as well as the
number of domains may be quite big, it is not practical to store
it completely as it is in a real system. Usually one exploits the
fact that the matrix is sparse and stores it either by rows or by
columns.
It may appear, that those two alternatives are semantically
equal, but as described in [2], the way the system manages the
storage of authorities pretty much defines the security
properties of the whole system.
One option is to store columns of the matrix in each
resource. This means that every resource will have a so called
Access Control List (ACL) associated with it, which will
contain pairs <domain, authority>. Another approach is to
store the list of authorities plus corresponding references to a
resource in every subject (domain). This list is called a
Capability List, or C-list and its elements – capabilities. So
once again, we define the term capability as a reference to
some resource which includes authorities to use it.
Since in a capability-based model the authorities are
managed by subjects, there are two important things a system
must guarantee:
1) There is no way one can produce capabilities other than
by “legal” system calls, in other words the capabilities must
be unforgeable;
2) The delegation of capabilities from one subject to another
must also be controlled by the system.
These two properties imply that capabilities cannot be simply
casted from/to a simple bit-array or any other type, so that they
are always distinguishable from objects of other types. Next
we present a brief overview of advantages/drawbacks of both
models which were described in [2].
Using the ACL model it is very hard to implement a real
system with the high granularity of subjects, since all
authorities for each subject (domain) in the system must be
stored in the resource. This means that it is not possible to
create an arbitrary number of subjects with each having
different rights. As a consequence, it becomes hard to develop
software strictly conforming to the least privilege principle.
The next important question we have to consider is the
question of designation of resources. Here we use the word
“designation” to describe a method to name and find a certain
resource among others. As an example consider URL as a
designation of resources in the internet. Since a capability
includes a reference to an object, there is no need of another
way of designation, i.e. other namespace as that defined by
capabilities. In the ACL model on the other hand, the right to
access a resource is checked after a subject’s attempt to use it,
since the authorities are stored in resources. It means that a
subject must be able to designate a resource even without
having any authority upon it. This property of capability
systems is called no designation without authority. Another
related property, which capability systems have and ACL
based ones don’t, is that there is no ambient authority. The
ambient authority is defined in [2] as “authority that is
exercised, but not selected, by its user.” This means, that when
Mykola Protsenko
a subject tries to access some resource, he doesn’t have to
choose a corresponding authority and present it to the system
on the access attempt: the decision whether the access is
granted, happens automatically.
To understand, why those two properties are important, let us
take a look on one famous situation, known as a confused
deputy pattern [2, 11]. The definition, given in [2] follows:
“A deputy is a program that must manage authorities coming
from multiple sources. A confused deputy is a deputy that has
been manipulated into wielding its authority inappropriately.”
An example of such a confused deputy was presented in
[11], where a compiler is supposed to output both billing and
debug information, but on behalf of two different subjects: first
of the operating system and second of the invoking user. Now
suppose the name of the file, where the billing information is
stored (BILL), is hard-coded in the compiler program and the
name of the file for debug output is provided by the user
(DEBUG). If the compiler cannot distinguish this both
authorities given form different sources, the user will be able
to overwrite the billing information, passing BILL as a
parameter denoting the file name, where the debugging
information should be outputted, even if normally the user
would have no authority to access this file for editing. This is
where the property of ambient authority comes into play: the
compiler possesses two authorities for different purposes, but
trying to open the file BILL and writing the debugging
information there will succeed because the subject cannot
choose, which of two authorities to use for this action. In a
capability based system with no ambient authority this
situation would not be possible, as the compiler, trying to open
BILL with a capability granted from the invoker will fail and
output a corresponding error message, informing the user that
he has no rights to edit that file.
As we can see, the capability-based and ACL-based security
models are pretty far from being equivalent and the
capabilities provide a system with many desirable features.
Aside from rather theoretical capability-based operating
systems, like Hydra [3], Dennis’ and Van Horn’s design [4],
Burroughs’ B5000 [5] there are some currently developed
research operating systems (Eros [6], Coyotos, Asbestos).
Despite how good the design of those systems might be,
practical usage of them would be quite problematic, regarding
the lack of hardware drivers, software etc. This leads to the
idea that modifying an existing operating system and keeping
changes in the API as small as possible will allow (re-)using
existing applications with minimum efforts needed to make
them capability aware. For many reasons, it is clear, that
Unix/Linux systems suit best for such a kind of “upgrade”.
In the next chapters we will first overview the classical
UNIX security system and then discuss its enhancement
known as POSIX Capabilities describing why those are not
‘real’ capabilities according to the definition made in this
section and giving motivation for further improvement.
27
ITSEC@i1 2011
3
III. UNIX SECURITY SYSTEM
The classic UNIX security system is quite simple. All
subjects have an integer identifier, called user id (UID) which
identifies the user who executes a program. Users may also be
members of different groups, which also have their identifiers
– group ids (GID). Each resource in the system is a property of
exactly one user and belongs to only one group, though one
user may be a member in many groups simultaneously. The
ACL of each resource contains only three entries, dividing all
subjects in three categories: the resource’s owner, the members
of the group and all other subjects. There are also only three
types of authorities: read access, write access and a right to
execute a file. Each file has two additional flags, namely
set_uid and set_gid. If the set_uid flag is set, the
executed program receives the UID of the file’s owner, the
set_gid flag works analogous for GID. This gives a
possibility to execute programs on behalf of another user.
To access a resource, a subject invokes a system call, then
the right is checked by the system according to the ACL, and a
file descriptor is returned on success. The file descriptor is an
integer number that is indexing the FILE structure allocated in
kernel space.
The UNIX file descriptor itself has many properties of a
capability described in the previous section:
Even though it is just an integer, it names a resource and
authorizes to use it. The file descriptor also cannot be neither
forged nor delegated to other process bypassing system
control. However, using UNIX message passing one can send
a file descriptor to a subject, which itself would not be
authorized to obtain it [13].
For administrative purposes, there is a special user that has
an unlimited power in the system, meaning that he can access
any resource ignoring limitations defined by the ACLs. This
user is called a superuser or root and has UID=0.
It is clear, that “normal users” should be able to perform
certain actions only in a very restricted way and only in special
circumstances, like for instance, some network activities
should be restricted, the user should be able to change only his
own password or kill only his own processes etc. But the
described model is too far from being fine granular enough to
give normal users authorities for certain privileged operations
on purpose. So the usual way the users perform privileged
actions in the system is that they execute programs owned by
root that have the set_uid flag set and let this programs do
the job. The side effect of this approach is that a program,
which should perform certain action, gets not only the right to
accomplish its task, but also an unlimited power to manipulate
the whole system, which presents exactly the opposite of the
least privilege principle described in the previous chapter.
Usually such programs do not use all the privilege they get, but
in certain cases errors in such programs may cause a lot of
harm, including giving to the attacker exploiting such a bug the
control over the system [14].
There have been attempts to fix the lack of granularity in the
UNIX system’s ACL, allowing an unlimited number of
Mykola Protsenko
subjects in it [12], but it would not fix the problems described
above, since root would still be beyond any control.
IV. POSIX CAPABILITIES
The idea behind the so called POSIX capabilities [7] is to
split the power of root into smaller parts. In particular, each
subject has a subset of about 30 different authorities (called
POSIX capabilities), each of them allowing to perform a
certain privileged operation.
Here we present some examples (taken from [16]):
- CAP_DAC_OVERRIDE allows to override all DAC rules,
i.e. to access any file in the system;
- CAP_NET_BIND_SERVICE:
allows binding to
TCP/UDP sockets below 1024;
- CAP_NET_RAW: allow use of RAW and PACKET
sockets;
- CAP_SYS_BOOT: allows to reboot the system.
For the sake of flexibility, each object (process or file) has
not only one set of POSIX capabilities, but three of them: the
effective, the permitted and the inherited set. As the name says,
the effective set is the one, which is used to check the authority
to perform a certain action, so the action succeeds, if the
corresponding POSIX capability is in the process’s effective
set. The permitted set describes, which POSIX capabilities are
permitted to be in the object’s effective set, which implies that
the later one is always a subset of the first one. The inherited
set is used to determine POSIX capabilities a child process
gets when it is created. When a program is executing,
following rules are applied to determine the three sets of a new
process [17]:
1) pI’ = pI
2) pP’ = fP | (fI & pI)
3) pE’ = pP’ & fE
Where pI, pP, pE are the parent process’s inherited,
permitted and effective sets, fI, fP and fE – inherited,
permitted and effective sets of a file that is being executed and
pI’, pP’, pE’ – analogous the three sets of a child process.
As the first rule says, the inherited set is indeed inherited by
the child process without any changes. The child’s permitted
set contains all the POSIX capabilities from the file’s
permitted set plus those, which are both in the file’s and the
parent’s inherited sets (this is where inherited set is used). The
new process’s effective set includes all POSIX capabilities
from the file’s effective set, unless they are excluded by the
child’s permitted set.
As we can see, POSIX capabilities sets are restricted by the
sets of both the file that is being executed and the parent
process.
To manipulate its own POSIX capabilities sets, a process can
use the cap_set()system call. Of course, not all operations
are allowed: one can only remove capabilities from his
permitted set and a new capability can be included in the
effective or the inherited set only if it is in the permitted set.
To delegate POSIX capabilities to other processes, a capability
CAP_SETCAP is required.
28
ITSEC@i1 2011
4
To allow execution of legacy programs, which do not
support this model, the POSIX capability system provides a so
called legacy fixup mode [18], which is also the default
operation mode. In this mode programs with root set_uid
bits just have all capabilities in their sets emulating in this way
the “classic” behavior of the system.
For this purpose there is a structure task_struct [19]
assigned to each process, which includes several capabilitiesrelevant flags, like: “
- SECURE_NOROOT – enabling this gives no special
privileges to uid 0;
- SECURE_NO_SETUID_FIXUP – setting this bit
disables capability fixes when transitioning from or to uid 0
via setuid. This might be done for compatibility with
older programs that use setuid to reduce their privileges;
- SECURE_KEEP_CAPS – when set, a process can retain
its capabilities even when transitioning to a normal (not uid
0) user. This bit is cleared by exec()” (from [19]).
So to leave the legacy fixup mode, a process just needs to set
the
SECURE_NOROOT
and
the
SECURE_NO_SETUID_FIXUP flags using the prctl()
[20] system call.
The usage of POSIX capabilities is certainly a step towards
the least privilege principle and may improve the security of
applications. For some reasons, they have never been widely
used in practice, as stated in [19]:
“Capabilities are an interesting, but complicated, security
feature. For most of the ten years they have been part of the
Linux kernel, they have either been broken, ignored, or both.”
The other thing is that they are quite different form the
capabilities we have defined earlier in this paper. The main
difference is that a POSIX capability do not name a resource,
on which the possessed authority applies, for instance if a
process has CAP_NET_BIND_SERVICE in its effective set, it
can bind to any port less then 1024 and so on. So POSIX
capabilities do not have important properties that normal
capability systems have, like no designation without authority
and no ambient authority. This system also does not help
preventing the occurrence of a confused deputy pattern. For
the same reason, it would not be possible to restrict an
application’s access to the users data, in other words a process
started by some user will always have access to all his data.
It means that this model is not that flexible as true capability
systems are. From this point of view, the term “capabilities”
used in the corresponding POSIX draft is rather confusing,
since it does not match with a security model it describes.
V. CAPSICUM
As we have seen in previous section, dividing the privilege
of root user into a set of distinct authorities does not solve all
security problems. The idea of a practical system, which
should enhance the UNIX security system with true
capabilities was described in [8]. However, to our knowledge,
the proposed design was never widely used.
Next we will consider an another effort toward the least
privilege principle, namely the Capsicum capabilities for
UNIX [21]. This open source project has been developed in
the Cambridge University for about 3 years, there is a working
prototype for FreeBSD 8.x and it is planned for inclusion in
FreeBSD 9. Because of the freshness of this technique, there is
not much documentation or evaluating research work
available, so the one and only source of information about
Capsicum is the paper [9] presented at USENIX Security
Symposium 2010. In this section we present a brief overview
of this work regarding the main principles, the basic
implementation ideas and the adoption of legacy applications
to use this new approach, however without going as deep in
details, as the original paper does.
The main idea behind the Capsicum is to bring all
advantages of the capability based security into UNIX without
making too big changes in the system’s API to make it
possible to reuse as much existing code as it gets and to make
writing/rewriting applications for it easy as well. For this
matter, the Capsicum does not aim to replace the existing
UNIX security system and is rather to be considered as an
enhancement or an addition to it, which allows to use the
benefits of the capability based security for critical
Fig. 2. Structure struct capability.
Mykola Protsenko
29
ITSEC@i1 2011
5
Fig. 3. Simple application using Capsicum.
applications or parts of code. The technique, where critical
code is executed with restricted rights in a separated
environment, is called sandboxing [23].
To achieve this ambitious goal, authors have exploited the
fact, that UNIX file descriptors already possess a large part of
properties that a capability must have (see chapter 3).
According to [9], they have only few things that should have
been fixed, for instance if a file descriptor allows only read
access to a file, it also permits changing of a so called
metadata (the access rights for owner, group and others, i.e.
the contents of the ACL) using the chmod() system call. So
the solution was found by overwriting (wrapping) the existing
struct
FILE with a new structure struct
capability, which includes also a set of authorities. The
new capabilities and old-fashion file descriptors may coexist in
one process (see fig. 2 taken from [9]). To enter a so called
capability mode, where old file descriptors are no longer
allowed, the process executes the cap_enter() system call.
This system call sets a special per process capability mode
flag. Once entered, neither the process itself, nor any of its
successors can leave this mode.
Unfortunately, changing a file descriptor is not enough to
reach all security goals. After a process has entered a
capability mode, its access to system resources must be
restricted by his set of capabilities. Same as in true capability
based systems, there are only two ways the process can obtain
an authority to access something: either by inheriting it from
its parent or by having it granted form an other process. In
other words, capabilities are the only way of designation of
resources in the capability mode. This is achieved by
restricting the process’s access to system namespaces by
blocking/filtering critical system calls, like open() (note, that
in this context the word “namespace” denotes not only the file
system’s one, but also many others that are present in UNIX
system, like the one defined by processes IDs or network
protocols/interfaces). This goal is reached by some kernel
changes and a libcapsicum – the “library interface to
capability-mode services” [24], which presents the runtime
environment of the Capsicum capability mode.
This model defines the use cases of the Capsicum system or
how the applications should deal with it. The most basic
Mykola Protsenko
scenario goes as follows: the application starts in a noncapability mode and allocates all the resources needed for its
computation. Then corresponding file descriptors are
converted to Capsicum capabilities, restricting the rights to
those that are minimum and sufficient for the application to
perform its task. Those actions can be done in a really small
amount of code what makes it possible to keep it bug-less and
reliable. To perform the computation itself, which on the
opposite may contain quite large pieces of code, undebugged
and unreliable, new processes are spawned that inherit all
needed capabilities and then immediately enter the capability
mode. After that, they can only access the resources referenced
by these capabilities and can not cause much harm to the
system, even if the executed code were buggy, malicious,
exploited or all together. (See fig. 3 from [21]).
Of course, not all applications match this simple scheme,
especially interactive applications that have to communicate
with the user (See fig. 4 from [21]). In this situation processes,
which have already entered the capability mode, will have to
communicate with those outside of this mode, and maybe
sometimes receive new capabilities from them.
The very import part of the modification of applications to
use the Capsicum is do determine the resource dependencies,
because it is not always clear, which resources are needed by
the computation that should be sandboxed. To do that both
static and dynamic analysis must be used.
Now if we remind us on the confused deputy problem,
discussed in the second chapter, and consider the two above
described application patterns, we would see that this problem
is not directly prevented by the Capsicum capabilities. The
main problem we see here, is that all resources are allocated in
the environment with ambient authority, which makes it indeed
possible, that a deputy, organized in such way, will confuse
authorities. So if the compiler, presented as example of a
confused deputy in [11], would be programmed as described
above, the danger would be still present. To solve this
problem, we would need capabilities as the only way of
granting authorities on a system-wide basis, which is currently
not a feature of the Capsicum.
30
ITSEC@i1 2011
6
Fig. 3. Interactive application using Capsicum
VI. CONCLUSION
The Capsicum capabilities, compared with the so called
POSIX capabilities, present a much better approach to solution
of security problems that UNIX software usually has. Those
problems have arisen mostly because of the misuse of root
set_uid utilities and a lack of flexibility of the system’s
security model itself. On the other hand, the Capsicum should
rather be seen as a capability based sandboxing technique than
a true capability system since it still relies on ‘classical’
protection mechanisms as a DAC in form of simple-minded
ACLs. Even though the Capsicum provides sandboxed
processes with an environment with no ambient authority and
no designation without authority, the way the most Capsicumaware applications might be implemented does not necessarily
eliminate the problem of a confused deputy. Despite this fact,
the Capsicum sure does move the system development into a
right direction.
[15] United States Department of Defense. December 1985. DoD Standard
5200.28-STD http://www.fas.org/irp/nsa/rainbow/std001.htm
[16] List of POSIX capabilities http://www.gentoo.org/proj/en/hardened/
capabilities.xml#doc_chap4
[17] Linux kernel capabilities FAQ. http://ftp.kernel.org/pub/linux/libs
/security/linux-privs/kernel-2.4/capfaq-0.2.txt
[18] Serge E. Hallyn, Andrew G. Morgan. Linux Capabilities: making them
work.
[19] Jake Edge Restricting root with per-process securebits,
http://lwn.net/Articles/280279/
[20] http://www.kernel.org/doc/man-pages/online/pages/man2/prctl.2.html
[21] The Capsicum project http://www.cl.cam.ac.uk/research/security
/capsicum/
[22] Robert Watson’s talk on USENIX: http://www.youtube.com/
watch?v=raNx9L4VH2k
[23] Amit
Singh.
A
Taste
of
Computer
Security.
http://www.kernelthread.com/publications/security/sandboxing.html
[24] libcapsicum man page, http://www.cl.cam.ac.uk/research/security/
capsicum/man/libcapsicum.3.pdf
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
B. Lampson. Protection. Proceedings of the 5th Annual Princeton
Conference on Information Sciences and Systems, 1971, p. 437–443.
Mark S. Miller, Ka-Ping Yee, Jonathan Shapiro. Capability Myths
Demolished, Technical Report SRL2003-02, Systems Research
Laboratory, Johns Hopkins University.
Henry M. Levy. Capability-based Computer Systems. Digital P.,U.S.,
December 1984.
Jack B. Dennis and Earl C. Van Horn. Programming semantics for
multiprogrammed computations. Commun. ACM, 26(1):29–35, 1983.
Burroughs. Definition of the B5000 Information Processing System.
Technical report, Burroughs Corporation, 1961.
Jonathan S. Shapiro, Jonathan M. Smith, and David J. Farber. EROS: a
fast capability system. SIGOPS Oper. Syst. Rev., 33(5):170–185, 1999.
The
last
POSIX.1e
draft
describing
capabilities:
http://www.gsp.com/cgi-bin/man.cgi?section=3&topic=posix1e
Adam Langley. A Practical UNIX Capability System. 22nd June 2005
Robert N. M. Watson, Jonathan Anderson, Ben Laurie, Kris Kennaway.
Capsicum: practical capabilities for UNIX. Proceedings of the 19th
USENIX Security Symposium, 2010.
J. H. Saltzer, M. D. Schroeder. The Protection of Information in
Computer Systems. Proceedings of the IEEE 63(9), September 1975, p.
1278–1308.
N. Hardy. The Confused Deputy (or why capabilities might have been
invented). Operating Systems Review 22(4), October 1988, p. 36–38.
Andreas Grünbacher. POSIX Access Control Lists on Linux. SuSE Labs
http://archives.neohapsis.com/archives/postfix/2000-09/1476.html
CERT® Advisory CA-2003-25 Buffer Overflow in Sendmail
http://www.cert.org/advisories/CA-2003-25.html
Mykola Protsenko
31
An MD5 collision based attack on the SSL key infrastructure
ITSEC@i1 2011
1
An MD5 collision based attack
on the SSL key infrastructure
Julian Hammer Friedrich-Alexander-University Erlangen
Abstract—This is a documentation of an attack on the X.509
Public Key Infrastructure (PKI) made possible by the use of the
insecure MD5 hashing function in a commercial Certification
Authority (CA). By combining MD5 collision techniques and a
timing attack it was possible to forge a signature of a rogue
CA through a standard website certificate. The PKI is used to
authenticate Secure Socket Layer (SSL) connections to websites
or other internet services and its insecurity poses a significant—
not just theoretical—threat for all internet users.
I. I NTRODUCTION
The Secure Socket Layer (SSL) is used to encrypt and
authenticate access to domain based internet services, such
as websites or mail servers. The encryption restricts anyone
but the recipient from reading the content of the transferred
data. The recipient has to be authenticated, so that no one
else can masquerade as the intended recipient. This is done
using a hashing function and X.509 certificates, authenticating
the domain owner by a trusted certification authority. If the
authentication can be attacked, attackers could impersonate
themselves as any website, also known as man-in-the-middle
and phishing attacks. Most users and even specialists would
not be able to notice the attack and willingly give them
sensitive data. The goal of an attacker would be to become
a trusted certification authority. In this way arbitrary rogue
certificates could be issued, as no restrictions apply for certification authorities.
The Message-Digest algorithm 5 (MD5) was designed by
Ron Rivest in 1992 as a secure replacement for MD4 [1]. Its
purpose is to provide a practical, preimage resistant, second
preimage resistant and collision resistant hash function. Some
weaknesses were discovered in 1993 by Den Boer and Antoon
Bosselaers [2] and in 1996 by Hans Dobbertin [3]. But no
collisions were found until 2004, when Xiaoyun Wang and
Hongbo Yu presented a method, reducing the time to compute
a collision to one hour on a—at that time—high-end computer
cluster, at EuroCrypt [4]. Further improvements were done
reducing the complexity from initially 264 to 221 , thus taking
less than a minute on a notebook to generate MD5 collisions
[5].
All the attacks on the security of MD5 could not be transferred to the X.509 Public Key Infrastructure (PKI) so far. In
2007, Stevens showed in his Master’s Thesis [6] that a chosenprefix collision can be constructed with the result that the
This paper was written as part of the conference-simulation-seminar
“Seminar IT-Sicherheit” which was organized by the chair for IT Security
Infrastructures at the University of Erlangen-Nuremberg during winter term
2010.
Julian Hammer
signature of one certificate also validates another—different—
certificate. The practical application was considered difficult,
for lack of control over the to-be-signed part generated and
signed by the CA.
It was suggested that MD5 should no longer be used, and
measures against chosen-prefix collisions should be taken by
ensuring that the to-be-signed part generated by the CA could
not be predicted by a possible attacker. Most CAs switched to
SHA1, but by January 2009, 14% of all certificated analyzed
by NetCraft were still signed with the help of the MD5 hashfunction [7]. The X.509 PKI is organized in a way that allows
an attacker to attack any trusted CA and receive full trust
by anyone trusting the CA. This means that the attacker can
choose the weakest link without any drawback.
Thus the attack scheme was already lined out and the
practical obstacles had to be overcome: Predicting the to-besigned part generated by the CA with enough lead time to
compute a certificate and to-be-signed part with the same MD5
check-sum as the predicted to-be-signed part. The computed
to-be-signed had to be valid X.509, without certain limitations
normally imposed by signing CA.
In the preliminaries MD5 and X.509 will be explained, as
well as attack methods on MD5. After these basics the attack
will be outlined in further detail and each step explained in
the chronological order it took place.
The “author” did not do the research work, but merely wrote
this summary, thus takes no credit of the work done. The real
researchers and authors are Alexander Sotirov, Marc Stevens,
Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne
Osvik and Benne de Weger [8].
II. P RELIMINARIES
A. Hashing function terminology and requirements
A hash function takes any input data (as a bit string) and
returns a “fingerprint”, called hash, with a fixed length of k
bits. For the same input data the returned hash is always the
same.
The hash function H takes the bit string m as input and
returns the hash h.
h = H(m)
This function should fulfill the following requirements:
• practicality
Hash h of any bit string m can be computed efficiently
• preimage resistant
If a hash h is given, it is hard to compute a bit string m,
such that h = H(m). m is called the preimage of h.
32
ITSEC@i1 2011
2
input 1
second preimage resistant
If a bit string m is given, it is hard to compute a second
bit string m′ , such that m 6= m′ but H(m) = H(m′ ).
• collision resistant
It is hard to compute two bit strings m and m′ , such that
m 6= m′ and H(m) = H(m′ ).
To brute force a hash function that returns hashes with the
length of k bits is expected to take 2k hash computations to
find a second preimage and 2k/2 computations for a collision,
due to the birthday-paradox.
A hash function is “cryptographically strong” if no better
method for finding collisions is known than brute force and
2k/2 computations are too expensive to calculate.
Mi ||Mj will be used to represents the concatenation of
blocks Mi and Mj .
•
B. MD5
MD5 is a hashing algorithm based on the Merkle-Damgård
iterative construction [1]. The input data is padded to a
multiple of 512 bits and then split into blocks of 512 bits.
These “input blocks” shall be called M1 , M2 , ... Mn . The
function f is a one-way compression function which takes an
intermediate hash value (IHV) and an “input block” as input,
and returns the next IHV. An IHV has a constant length of 128
bits and shall be called IHV0 , IHV1 , ... IHVn . See Figure 1
for illustration.
IHV0
f
M1
f
M2
f
M3
IHV1
IHV2
IHV3
f
M4
padding
Hash
Fig. 1.
Structure of MD5
The first IHV (IHV0 ) is a constant value, defined by RFC
1321 [1]. The last IHV (IHVn ) is the hash of the input data.
Hereafter H(...) will be referred to MD5(...) for clarity.
C. Weaknesses in MD5
1) Collision: The structure of MD5 implies that if one or
more collision blocks can be constructed, they can be inserted
around data and produce a valid collision. The only restriction
is that the prefix has to be a multiple of 512 bits long. See
Figure 2 for illustration.
This was presented by Xiaoyun Wang and Hongbo Yu at
EuroCrypt 2005 [4] with two 512 bit blocks M1 , M2 and M1′ ,
M2′ with MD5(M1 ||M2 ) = MD5(M1′ ||M2′ )
Julian Hammer
P
input 2
=
P
IHVi
C
6=
C’
IHVi+k
S
=
S
MD5(P ||C||S) = MD5(P ||C ′ ||S)
Fig. 2.
MD5 Collision [9]
2) Chosen-Prefix Collision: The collision shown above is
very restricting in applicability, as the pre- and suffix have to
be the same for both inputs.
Marc Stevens presented a method called “chosen-prefix
collision” in his master thesis [6]. The method allows to
construct a collision for any pair of prefixes, such that
MD5(P ||C||S) = MD5(P ′ ||C ′ ||S).
First P and P ′ may not have the same size, they have to be
padded with A and A′ , which may have any content. Then B
and B ′ are computed using a “birthdaying” 1 step to prepare
the IHV for the set of “near collision blocks”, N C and N C ′ .
See Figure 3 for illustration.
D. X.509 PKI
X.509 is an ITU-T standard for, amongst other things, public
key infrastructures [11]. It defines the function of Certification
Authorities (CA), how they sign certificates and CAs, creating
a trust tree. A version 3 certificate contains the following:
• “to-be-signed” part
– Version
– Serial Number (has to be unique for every certificate
issued by a CA)
– Algorithm ID
– Issuer (Information about the CA issuing the certificate)
– Validity period (Not Before and Not After)
– Subject (Information about the subject of the certificate, especially the common name of the domain or
organization it was issued to)
– Subject Public Key Info (Algorithm and Public Key
of the key pair to be signed)
1 A “birthday attack” is a way of efficiently finding collisions, through
exploitation of the birthday problem. In this case collisions were not searched
for, but IHVs with a special (small) difference.
33
ITSEC@i1 2011
3
input 1
input 2
P
6=
P’
A||B
6=
A’||B’
IHVi
NC
6=
6=
IHVi′
NC’
RapidSSL http://www.rapidssl.com/
FreeSSL http://www.freessl.com/
• TC TrustCenter AG http://www.trustcenter.de/
• RSA Data Security
https://www.verisign.com/repository/root.html#rsass
• Thawte http://www.thawte.com/
• verisign.co.jp http://www.verisign.co.jp/
All of them are trusted by Firefox and use MD5, against
recommendations, since collisions were already presented in
2004. RapidSSL issues more certificates then any of the other
CAs, as a study revealed [12].
•
•
IHVi+k
S
=
S
MD5(P ||A||B||N C||S) = MD5(P ′ ||A′ ||B ′ ||N C ′ ||S)
Fig. 3.
MD5 Chosen-Prefix collision [10]
– Extensions (optional, e.g. restrictions for which the
key may be used, especially “CA = FALSE” forbids
the key holder to issue valid certificates himself)
• Signature Algorithm ID (e.g. “MD5 with RSA”)
• Signature
To obtain a certificate by a CA one has to issue a Certificate
Signing Request (CSR), which contains information for the
CA to use in “Subject” and “Subject Public Key Info” entries
in the certificate. The CSR has to be signed by the subject
private key to ensure that the requester holds the private
and public key. Common practice is that the CAs handle
the information from CSRs very conservatively and only use
checked information, thus the requester has little control over
the certificate’s content issued by the CA.
The trust is given by the user trusting the CA and all its
signed intermediate CAs and certificates. All modern browsers
come with a list of trusted CAs, which the browser developers consider “secure”. For requirements a CA has to fulfill, see http://www.mozilla.org/projects/security/certs/policy/
for Mozilla’s policy.
III. C ONSTRUCTION OF A ROGUE CA
A CA has to meet some requirements, in order to be
attacked using the chosen-prefix collision:
• Predictability of the issued certificate (of every bit, so the
MD5 hash can be predicted before the certificate is being
issued), especially:
– Serial number
– Validation period
• Using MD5 for the signature
• Accepted by all standard browsers
A. Possible Targets
In 2008, a search for such a “weak CA” brought up six CAs
still signing with MD5:
Julian Hammer
B. Prediction and Timing
Further investigation into the RapidSSL CA and certification
issuance practice showed that the serial numbers of certificates
are given out in sequential order and the increment per
weekend is between 800 and 1000. A weekend was chosen,
because it is a bit less than the estimated time to construct a
collision and the load on the CA will be less. See figure 4.
The higher increment on one weekend in September is due to
100 certificates being bought for investigative purposes.
It is also necessary to predict the exact time the certificate is
being issued, thus the exact validity period. The certificates are
issued exactly 6 seconds after finalizing the purchase, so the
certificate is valid from the time the user buys the certificate
+ 6 seconds and valid for exactly one year.
C. Attack scheme
The attack scheme was as follows:
• Buy one certificate on Thursday night to get the current
serial number, referred to as S
• Sunday night is referred to as time T
• The predicted serial number is S + 1000, which is higher
then it would normally be on Sunday night
• Some hours before time T , certificates are slowly purchased, to push up the serial number near S + 1000,
without raising suspicions
• 30 seconds before time T , the last certificates are bought
to bring the serial number up to S + 999
• Hopefully at T − 6s the predicted certificate can be
bought with the predicted serial number S + 1000 and
the computed collision blocks. If this wasn’t possible the
entire attack had to be abandoned
D. The Certificate Construction
As explained in section II-D, one has little control over the
certificate issued by the CA.
The whole content can be predicted, but only the following
can be freely adjusted:
• subject country
• subject organization
• subject common name
• subject public key (algorithm, modulus and public exponent)
The “near collision blocks” from the chosen-prefix collision,
as described in section II-C2, fit into the public key modulus
34
ITSEC@i1 2011
4
Fig. 4.
RapidSSL’s serial number increment per weekend [13]
TABLE I
R EAL CERTIFICATE ’ S “ TO - BE - SIGNED ” PART AS ISSUED BY R APID SSL
bytes
0-3
4-8
9-13
14-28
29-120
description
header
version number
serial number
signature algorithm
issuer
121-152
153-440
validity
subject
441-734
subject public key info
735-926
extensions
content
3
643015 (as predicted)
“md5withRSAEncryption”
country = “US”
organization = “Equifax Secure Inc.”
common name = “Equifax Secure Global eBuisiness CA-1”
from 3 Nov. 2008 7:52:02 to 4 Nov. 2009 7:52:02 (as predicted)
country = “US”
organization =
“i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org”
organizational unit (3 fields)
common name =
“i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org”
header, public key algorithm, another header,
RSA modulus (2048 bit) and public exponent
headers, key usage, ..., basic constraint (CA = FALSE)
of the real certificate and need to have corresponding blocks
at the same position in the forged certificate.
The forged certificate’s bits can be freely chosen to the
point where the “birthday bits” and “near collision blocks” in
the real certificate start, after which forged and real certificate
have to have the same content. With the certificate described
in Table I and the alignment required by MD5, three “near
collision blocks” can be inserted into the public key starting
from byte 512 to byte 704. Thus everything from byte 704
onward has to be identical in both certificates.
The “Netscape comment” extension gives the possibility to
hide arbitrary data within a certificate. By standard, it has to
be in IA5String format, but this is normally not checked, so
that it can serve to hide any bit string of any length.
Beginning with the “Netscape comment” extension at byte
500 there is complete freedom of the content in the forged
Julian Hammer
certificate. This overlaps almost completely with the public
key modulus from the real certificate: the first 26 bytes of
the public key modulus in the real certificate can be chosen
randomly (they do not overlap), then 12 bytes can be used
to insert “birthday bits” (called B and B’ in section II-C2),
3 ∗ 64 bytes for the “near collision blocks” and that leaves 26
bytes to choose freely to make the modulus valid and usable.
The number of birthday bits and “near collision blocks” are a
trade-off problem described in [6] and with improvements in
[14].
See Figure 5 on page 7 for exact comparison of the real
and forged certificates.
1) Birthday Bits: The “birthday bits” are used to search
for a pair of intermediate hash values (IHVs) produced by the
real and forged certificates, which are suitable for the “near
collision blocks”. These IHVs have less differences then IHVs
35
ITSEC@i1 2011
5
TABLE II
F ORGED CERTIFICATE ’ S “ TO - BE - SIGNED ” PART AS
bytes
0-3
4-8
9-11
12-26
27-118
description
header
version number
serial number
signature algorithm
issuer
119-150
153-212
validity
subject
213-374
subject public key info
375-926
extensions
content
3
65
“md5withRSAEncryption”
country = “US”
organization = “Equifax Secure Inc.”
common name = “Equifax Secure Global eBuisiness CA-1”
from 31 Jul. 2004 0:00:00 to 2 Sep. 2004 0:00:00 (in the past)
common name =
MD5 Collision Inc. (http://www.phreedom.org/md5)”
header, public key algorithm, another header,
RSA modulus (1024 bit) and public exponent
headers, key usage, basic constraint (CA = TRUE, Path Length = None)
subject key identifier, authority key identifier and
Netscape comment extension
of arbitrary prefixes would normally have.
The search for the “birthday bits” is called “birthdaying”
and is done by inserting random bit patterns in both the real
and the forged certificate. Each resulting IHV and pattern
is saved and all computed IHVs of the real and the forged
certificate are compared. Then the two bit patterns producing
the least differences between their resulting IHVs are chosen.
This attack exploits the birthday-paradox to reduce the number
of “near collision blocks”.
The attack was done with 72 “birthday bits”, leaving 3 bytes
of the public key modulus unused, which were arbitrarily set
to zero. The “birthday bits” pair is completely different for
both certificates and appears random.
See table III and figure 6 for illustration of IHV differences.
In the figure, each row represents the IHV state after one block,
each “pixel” represents the difference of one bit, with black
being no difference.
2) Near Collision Blocks: The prepared IHVs simplify and
reduce the number of “near collision blocks”, as less difference
has to be eliminated.
The computation of the “near collision blocks” (NCB)
is rather complicated and will not be explained here. The
following should be considered given:
• Each NCB eliminates differences between the IHVs of
both certificates
• NCBs of both certificates vary only in one or two bits
Three blocks were enough to reduce the difference to zero and
produce a collision, this is due to the expensive “birthdaying”
step. A detailed explanation of the algorithm used can be found
in the original paper [8].
See table III and figure 6 for illustration of IHV differences.
Fig. 6.
Differences of IHVs between real and forged certificate [16]
3) Valid and Usable RSA Modulus: In the 2048 bit of the
public key modulus, in the real certificate, 72 + 3 ∗ 512bits =
1608bits have to be inserted (see above). The modulus must
be valid, thus be a product of two primes, and usable, thus the
Julian Hammer
CONSTRUCTED
two primes q and p have to be known. This is necessary due to
the fact that the certificate signing request (CSR) needs to be
signed using the private key that corresponds to the modulus.
To make the predefined bit string (26 random bytes, 12
“birthday bytes” and 3 ∗ 64 “near collision block” bytes) B
with the free-to-choose 26 byte suffix S valid and usable, the
following was done: With N = B|| “208 one bits”
1) Choose random 224 bit integer p
2) Check if N mod p < 2208 or start over
3) Check if p and q = ⌊ Np ⌋ are primes or start over
4) Check if (p − 1)(q − 1) and the public exponent 65537
are coprimes or start over
5) n = pq is a valid modulus, containing the predefined bit
string and p and q are known
E. Realization of the Attack
The most compute and time intensive part is the computation of the “birthday bits”. This problem is very well
suited for parallelization in a cluster, especially with cell
processors as used in PlayStation 3s. This was made possible
at the “PlayStation Lab” of the Arjen Lenstra’s Laboratory
for Cryptologic Algorithms at EPFL, Lausanne, Switzerland.
They provided a cluster of 215 PS3s, which completed the
“birthday bits” calculation within 18 hours. The computation
of the three “near collision blocks” was done on a high-end
quad core computer, taking 3 to 10 hours.
The “birthday bits” and “near collision blocks” calculation
needed only 28 hours in total. As it was done in two stages
on different hardware, three attempts could be done in parallel
within 64 hours, thus on one weekend.
It took the researchers four weekends until the timing and
serial number prediction finally worked out and a forged
certificate was created. For their research they spent a total
of 657 USD on certificates by RapidSSL.
IV. C ONCLUSION , I MPACT
AND
P REVENTION
Not all of the certification authorities switched to better
hash functions, even long after MD5 was considered insecure
by cryptologists and security researchers. Their certificates
are the only security there is for most internet users from
being victims to scams and phishing and the like. By the
36
ITSEC@i1 2011
6
TABLE III
I NTERMEDIATE H ASH VALUES
IHV
IHV0
IHV1
IHV2
IHV3
IHV4
IHV5
IHV6
IHV7
IHV8
IHV9
IHV10
IHV11
IHV12
IHV13
IHV14
IHV15
real certificate
0123456789ABCDEFFEDCBA9876543210
058484A77F07A36382AAECF2DFE207A2
D52743425C3DAC23A9E62C6C9670622E
7789E58E3B45621A3E46A64CA9D7AC3A
CDA2CB5673D3D32092C7F1EF80CE5729
F08E24604482508B959A0B5762207A3F
A83EA6CCCC50B41A4BFADBC6D856B338
0B42EAAB4258AACA8C30BDB8192A1BC0
D21CED8CC56726B6BF2AE4A93D742C3A
DC1EDBFFF3C3E9E7BCEB3F9E2D0705BD
F0D655805A71A74EF8A6A630D11977D8
9808B5471E7130CC5A30A2ABF2BE4B4D
AA1F57B21A8732130CB0CAEF4BB9C746
151754FA2FCC5914E72B71B4300B6485
271EECDC4DAC9E9C471C34C833917E26
9ED7B966BD815C141B899DC64B528564
6=
6
=
6
=
6
=
6
=
6
=
6
=
6
=
≈
≈
≈
=
=
=
=
=
forged certificate
0123456789ABCDEFFEDCBA9876543210
713F764E78B5C9B03F8878F7A440551B
2AC9681DDB3B72D29A1422A515C9E4F4
104DD09F9F651E554C528578AC1F6885
15ADC95447929A2AC0EACF9E618E14EB
D6D6E59C0BDB1F701CB04C29A0573EA0
3AAB0CE98F1E9B2AC270A5A2C60FF605
DE3CCC11526732CA0FD8B9F5992A7673
D21CED8CCE3D7EB4C82ADCA94674243A
DC1EDBFFF49941E8BDEB379E2E07FDBC
F0D655805A479F4EF8A69E30D1196FD8
9808B5471E7130CC5A30A2ABF2BE4B4D
AA1F57B21A8732130CB0CAEF4BB9C746
151754FA2FCC5914E72B71B4300B6485
271EECDC4DAC9E9C471C34C833917E26
9ED7B966BD815C141B899DC64B528564
creation of the forged certificate and with that a forged
certification authority, any attacker could impose themselves as
any website or server and would be considered authentic. The
attacker would need knowledge of cryptography and access to
a computer cluster. Most victims would not be able to spot
any irregularities with the given certificate, even after close
inspection.
The created—forged—certification authority was deliberately already expired on its creation date, so as to show
only the possibilities without doing any damage. It can
be inspected at https://i.broke.the.internet.and.all.i.got.was.
this.t-shirt.phreedom.org/ and will be considered valid, as long
as the system date is set back to August 2004.
If the real certification authority, namely RapidSSL, would
have paid more attention to security rather than to ease of
operation, it would have been harder or almost impossible to
exploit the weak hash function:
• Randomization of the serial numbers
This requires the CA to store all serial numbers ever
generated by it, because they have to be unique
• Randomized “valid period” fields
The certificate was always signed 6 seconds after its
submission and valid for exactly one year. This could
be randomized, making it harder to predict.
• The “pathlength” parameter of the issuing CA could be
set to zero
Then only “end-user” certificates can be issued, as a
forged CA would be detectable by the victim.
Despite all prevention possibilities: an insecure hash function
has to be replaced by a secure one, at the latest when the first
collision exists. For example MD5 was not recommended by
the Bundesnetzagentur (Federal Network Agency of Germany)
in 1999, as it’s long term security was not given [17].
Verisign—owner of RapidSSL—responded to the attack and
announced, one day after publication of the attack, that they
have ceased using MD5 [18]. They would also replace any
certificate using MD5 free of charge. Several organizations
(Mozilla, Microsoft, Cisco, US-CERT and others) published
security advisories disapproving of the use of MD5.
The Secure Hash Algorithm 1 (SHA-1) [19] is based on the
same Merkle-Damgård structure as MD5, but collisions have
Julian Hammer
comment
constant to MD5
after
after
after
after
“birthday bits”
“near collision block” 1
MD5 hash
not yet been published. Neither for SHA-2, also based on the
same structure, but theoretical insecurities for both, SHA-1
and SHA-2, have been published. The US National Institute
of Standards and Technology is currently searching for a
replacement, to be called SHA-3, which will be announced
in 2012.
R EFERENCES
[1] R. Rivest, “The md5 message-digest algorithm,” RFC 1321 (Informational), April 1992.
[2] B. den Boer and A. Bosselaers, Collisions for the Compression Function
of MD5. Berlin; London: Springer, 1993.
[3] H. Dobbertin and H. Dobbertin, “The status of md5 after a recent attack,”
RSA Laboratories CryptoBytes, vol. 2, no. 2, p. 1, 1996.
[4] X. Wang and H. Yu, “How to break md5 and other hash functions;
eurocrypt,” 2005.
[5] V. Klima, “Tunnels in hash functions: Md5 collisions within a minute,”
2006, cryptology ePrint Archive, Report 2006/105.
[6] M. Stevens, On Collisions for MD5, 2007.
[7] (2009, January). [Online]. Available:
https://ssl.netcraft.com/
ssl-sample-report/
[8] M. Stevens, A. Sotirov, J. Appelbaum, A. Lenstra, D. Molnar, D. A.
Osvik, and B. de Weger, Short chosen-prefix collisions for MD5 and the
creation of a rogue CA certificate. Springer, 2009.
[9] A. Sotirov, M. Stevens, J. Appelbaum, A. Lenstra, D. Molnar, D. A.
Osvik, and B. de Weger, “collision.” [Online]. Available: http://www.
win.tue.nl/hashclash/rogue-ca/images/identIV.png
[10] ——, “chosen-prefix collision.” [Online]. Available: http://www.win.
tue.nl/hashclash/rogue-ca/images/diffIV.png
[11] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk,
“Internet x.509 public key infrastructure certificate and certificate revocation list (crl) profile,” RFC 5280 (Proposed Standard), May 2008.
[12] (2008, December). [Online]. Available: http://www.win.tue.nl/hashclash/
rogue-ca/
[13] A. Sotirov, M. Stevens, J. Appelbaum, A. Lenstra, D. Molnar, D. A.
Osvik, and B. de Weger, “increment per week.” [Online]. Available:
http://www.win.tue.nl/hashclash/rogue-ca/images/rapidssl-weekend.png
[14] M. Stevens, A. Lenstra, and B. de Weger, Chosen-prefix Collisions for
MD5 and Applications, 2009.
[15] A. Sotirov, M. Stevens, J. Appelbaum, A. Lenstra, D. Molnar,
D. A. Osvik, and B. de Weger, “Md5 collision certificate
alignment.” [Online]. Available: http://www.win.tue.nl/hashclash/
rogue-ca/downloads/alignment.pdf
[16] ——, “Differences in the md5 ihv.” [Online]. Available: http://www.
win.tue.nl/hashclash/rogue-ca/images/diff.png
[17] Geeignete Kryptoalgorithmen gemäß § 17 (2) SigV. Bundesnetzagentur,
1999, vol. 213.
[18] T. Callan, “This morning’s md5 attack - resolved.” [Online]. Available: https://blogs.verisign.com/ssl-blog/2008/12/on md5
vulnerabilities and mit.php
[19] P. J. D. Eastlake, “Us secure hash algorithm 1 (sha1),” RFC 3174
(Informational), September 2001.
37
ITSEC@i1 2011
7
Fig. 5.
Alignment of real and forged certificate [15]
Julian Hammer
38

Proceedings - IT-Sicherheitsinfrastrukturen

Transcrição

Documentos relacionados

als pdf-Datei - Digital Fernsehen

Lese gesamten Pressetext

USB-Gaming-Headset mit 5.1-Kanalwiedergabe

Umzugsservice

Streckenflugtipps

Bedienungsanleitung

DWG-, DXF- DWF -Viewer und Konverter

DH558 Anschlussreicher Full HD Projektor mit 3D Fuktion

Sonderbedingungen für den ExtraZins

Mechanisches Keyboard mit Einzel-LEDs