Mitternachtshacking

Die Präsentation von Stefano und Kuza behandelt sehr spezielle und sehr clevere Angriffe gegen Webanwendungen und Browser. Viele der Angriffe basieren auf Lücken und Fehlern im Browser, Objekte und Zugriffe korrekt zu filtern. Leider sind die meisten Angriffe inzwischen so speziell, dass man sich im Detail damit auseinandersetzen muss. So nebenbei einlesen geht leider gar nicht mehr.

Die Risiken von Cross Site Scripting (XSS) sind seit 2005 durch eine Veröffentlichung von Amit Klein bekannt. Erweiterung zum Code Flow wurden 2008 bekannt. Die kritischen Lücken drehten sich hauptsächlich darum

• HTML zu erzeugen
• Dokumenten-Inhalte zu verändern
• Dokumenten-URLs zu verändern
• Windows zu öffnen/schließen

Insbesondere beschränkt sich XSS nicht darauf simple Cookies auszulesen.

Manipulierte HTML-Objekte (IMG, OBJECT, FORM, …) erlauben häufig Javascript-Ausführung. Ein Beispiel ist die Nutzung von Iframes in IMG-Objekten, die Javascript-Ausführung im IE7 erlaubt.

Aktuelles Thema ist Javascript in CSS. insbesondere kann eine solche Javascript-Funktion Inhalte der Seiten auslesen. Mit HTML5 ist sogar der Zugriff auf entfernte Seiten möglich. Mit der Injektion in eckige Klammern ist die komplette Kontrolle über Objekte möglich:

some_var = document[user_input]; -> setzt man user_input auf ‚cookie‘ enthält man Zugriff auf die Cookies. Das funktioniert auch umgekehrt.

Die diversen Erweiterungen von HTML, insbesondere HTML5 erlauben neue Angriffe wie Client-Side SQL-Injection. Browser-Hersteller sind auch in Zukunft gezwungen, neue Möglichkeiten und Funktionen für Webentwickler zu Implementieren, die häufig unzureichend geplant oder auf schwachen Sicherheitsfunktionen wie der Same-Origin-Policy basieren.

Der Inhalt des ganzen Vortrags von Jürgen Pabel dreht sich um die Möglichkeiten, eine komplette Festplatte, insbesondere die Systemplatte zu verschlüsseln. Das kann entweder in Software oder neu auch in Hardware erfolgen. Dabei geht es nicht um verschlüsselte Container oder Archivdateien sondern tatsächlich um Verschlüsselung auf Plattenebene. Die gängigen Varianten sind:

• USB/Firewire-Festplatte mit Crypto-Controller (Fingerprint/PIN-Authentication)
• Festplatte mit SATA Security Option
• Software-Treiber
• Hardware-Modul (PC-Card)

Kritisch ist die Pre-Boot-Authentication. Normalerweise lädt das BIOS diese Software von einem unverschlüsselten Bereich der Platte. Bei Linux muss das in die Boot-Partition integriert werden. Von dort werden die Schlüssel zum Zugriff auf die verschlüsselten Bereiche bereitgestellt. Unter Linux wird dann einfach die Systempartition durch Device Driver Hooking gemountet, in Windows muss der NT-Kernel um die Verschlüsselungsfunktion mittels Low-Level Filter Driver erweitert werden.

Für den Anwender ist die wichtigste Unterscheidung vermutlich, dass es unter Linux noch keine „in-place“ Verschlüsselung gibt, auf einer verschlüsselten Platte muss immer erst ein neues Filesystem angelegt werden. Windows-Software kann bestehende Partitionen in der Regel bei der Installation nachverschlüsseln.

Die detaillierte Produktvorstellung fand ich jetzt nicht so spannend, ich schätze das ist ein Abfallprodukt seiner Consulting-Arbeit. Ich persönlich verwende Utimaco SafeGuard Easy und TrueCrypt, mit beidem habe ich gute Erfahrung gemacht. Utimaco verschlüsselt die ganze Platte und TrueCrypt nochmal einzelne Container. Und meine Passwörter liegen in einem KeePass-Safe in einem TrueCrypt-Container auf einer Utimaco-verschlüsselten Platte. Und für die ganz wichtigen Sachen gibt es bei TrueCrypt noch Hidden Volumes. Ich denke, das dürfte ausreichen.

Als Übersicht der verschiedenen Möglichkeiten und Technologien fand ich den Vortrag jedoch ganz interessant.

Ich bin in Saal 1 sitzen geblieben, weil sonst nirgendwo Plätze zu kriegen sind. Jetzt muss ich mir leider den DNS-Vortrag von Dan Kaminsky antun. Ich halte den ja für etwas überschätzt.

Die von Dan vorgestellte Agenda lässt meine schlimmsten Befürchtungen wahr werden. Es geht um die DNS-Lücke die er so toll konspirativ gehandhabt hat. Der halbe Vortrag dreht sich also um  die Ursachen und theoretischen Folgen der DNS-Geschichte und darum, wie toll Dan ist. Egal. Betrachten wir es wie Hollywood: die Show ist sehr gut.

Entdeckt hat die Lücke im Grunde schon 1999 Daniel Bernstein. Aber 99 hat sich halt noch keiner darum gekümmert. Erst neun Jahre später wurden die Angriffe aktuell.

Dan wirft jedenfalls kräftig mit Screenshots und dicht beschriebenen Slides um sich, mit denen er einen Angriff demonstriert. Das sieht recht locker aus, in der Praxis handelt es sich aber um einen harten Brute Force Angriff auf eine 16-Bit Transaction ID und die muss halt erst einmal erraten werden. Das kann man natürlich automatisieren aber das kann auch mal eine ganze Weile dauern. Dan kommentiert das zusätzlich auf seine lockere Art, darum wirkt das recht einfach und sehr lustig. Aber so schnell kann man die Präsentationsfolien nicht lesen. Entweder man sieht sich das im Stream nochmal an oder wartet ob die Slides veröffentlicht werden.

Zum Ende kommt dann die große Politik. Was braucht es, um DNS fit für das aktuelle Jahrtausend zu machen. Für Dan ist DNSSEC die Lösung. Alternative Ansätze wie DNSCurve von Bernstein werden erst abgekanzelt bevor Dan sich zu konkreter Kritik (insbesondere zu hohe CPU-Anforderungen durch die Crypto) herablässt.

Das Kernproblem bleibt jedoch … DNS ist die einzige global verteilte Infrastruktur, sie wird für alle möglichen Anwendungen inkl. Sicherheitsfunktionen und Authentisierung verwendet und eine Lösung für Secure DNS ist nicht in Sicht. Trotz aller Aufrufe von Dan Kaminsky.

Der Congress ist jetzt offiziell ausverkauft. Nur wer von weit her kommt, USA und so, wo es Chaos mit dem Wetter geben soll, kommt noch rein. Berliner die noch kein Ticket haben, haben jetzt Pech gehabt.

Ich habe oben den Titel von den Präsentationsfolien von Jacob Appelbaum genommen, in der Agenda steht Advanced memory forensics: The cold boot attacks.

Eine typische Annahme über Computer ist, wenn man das Gerät abschaltet, ist der RAM gelöscht. Diese Annahme ist falsch. DRAM mit refresh hält Bits normalerweise sehr zuverlässig, ein zufälliger Bit-Flip tritt kaum auf. Ohne refresh treten diese Bit-Flips auf, aber selbst nach mehreren Sekunden ist der RAM-Zustand bei weitem nicht zufällig. Man kann immer noch Daten extrahieren. Inzwischen gibt es umfangreiche Arbeiten zu diesem Thema.

Bei einem Cold Boot Angriff bringt man das System zum Absturz, versorgt den RAM erneut mit Strom und liest ihn aus. Dazu kann man den Rechner beispielsweise mit einem speziell zusammengestellten System von USB booten, das den RAM so wenig wie möglich überschreibt (<10 KB). Interessant ist das bei einem Rechner mit Screenlock und Festplattenverschlüsselung. Der Festplattenverschlüsselungskey muss schließlich im RAM vorliegen, wenn das System läuft.

Der Code der Tools, eine FAQ und Videos sind komplett veröffentlicht. Happy Hacking.

Das Apple-iPhone-Hacking ist so ein Vortrag, dessen Inhalte mich eigentlich gar nicht interessieren. Ich habe kein iPhone und ich will mir auch keines zulegen (das Android/Linux Google-Phone würde mich eher interessieren). Aber egal, ein paar interessante Themen werden bestimmt angesprochen.

Die Apple-Hacker schaffen es im Schnitt 24-48 Stunden nach einem Patch von Apple ihr Programm wieder zu aktualisieren. Das ist schon sehr cool. Dafür dürfen sie auch Werbung für ihre Apple-powned T-Shirts machen 🙂

Das iPhone ist im Grunde wie zwei Computer gebaut. Es gibt einen Application-Prozessor, der die Anwendungen laufen lässt (das iPhone-OS und von iTunes geladene Anwendungen) und einen Baseband-Prozessor, der die Funkverbindung hält. Das iPhone-OS basiert auf MacOS X. Allerdings gibt es einen zusätzliche Dienst, den Lockdownd, der die Aktivierung und die laufenden Programme kontrolliert. Das OS läuft von Flash, eine Read-only Systempartition und eine schreibbare Userpartition. Damit wird ein Filesystem-Check bei einem Absturz vermieden. Die Programme müssen alle digital signiert werden, das Code-Signing wird im Kernel verifiziert. Der Kernel befindet sich auf der RO-Systempartition und ist ebenfalls signiert.  Nebenbei ist auch noch das Filesystem AES-verschlüsselt und der Schlüssel kann nicht ausgelesen werden. Die Signaturprüfung lässt sich beim Booten jedoch umgehen. Die komplette Beschreibung des Bootprozesses schenke ich mir hier, die ist recht kompliziert. Am Anfang steht jedoch der nicht signierte LLB, der modifiziert werden kann.

Es gibt noch ein paar weitere Schwächen, z.B. Buffer Overflows im Zusammenhang mit Zertifikaten. Den kann man nutzen, um die Funktion zur Prüfung digitaler Signaturen dazu zu bringen, immer mit „true“, d.h. einer gültig erkannten Signatur zurückzuspringen. Dieser Buffer Overflow wird verwendet, um ein nicht-signiertes iPhone-OS zu starten. Einer der Kernfehler Apples war, die Sicherheitsmechanismen einzeln zu aktivieren. So konnte anfangs die Firmware analysiert werden, bevor sie verschlüsselt wurde.

Der Baseband-Prozessor läuft nahezu unabhängig vom Applikation-Prozessor. Das Booten des Baseband-Systems sieht ähnlich aus. Der Bootrom lädt den Bootloader, der die Firmware lädt. Die Firmware kann übrigens richtig geschrottet („bricked“) werden und sie ist mit einer RSA-Signatur gesichert. Die Firmware ist auch für den SIM-Lock des Providers verantwortlich. Der Bootloader ist im neuen iPhone ebenfalls signiert und schützt nach dem Start den Bootrom.

Im Bootloader v3.9 gibt es ein paar Fehler, u.a. den Bleichenbacher Angriff (Code) gegen die RSA Signatur. Einzelne Exploits wie der JerrySIM Buffer Overflow sind inzwischen jedoch „verbrannt“. Aktuelle Exploits überschreiben nicht die Firmware sondern patchen sie während der Laufzeit im RAM.

Insgesamt ist das Reverse Engineering des iPhone schon sehr cool. Apple hat einige Arbeit reingesteckt, das zu erschweren und die Jungs hier waren extrem clever. Ich sehe halt nur für mich keine praktische Anwendung.

Der Saal 2 ist hoffnungslos überfüllt. Erstaunlich für einen Vortrag der sehr technisch ist und für den die meisten Anwesenden vermutlich keinen direkten Anwendungsfall finden. Aber sowohl Karsten Nohl als auch Starbug sind durch den Mifare-Hack natürlich bekannt geworden. Und Karsten verspricht sogar, nach dem Vortrag kann jeder mit Reverse Engineering beginnen … 🙂

Ok, man muss ein paar Voraussetzungen mitbringen … beispielsweise das Chip-Layout verstehen. Oder wenige µm dünne Leiter mit winzigen Nadeln anpieksen und neu verdrahten, um die entschlüsselten Daten abzugreifen. Adlerauge sei wachsam. Aber ansonsten ist das ganz einfach.

Zuerst nimmt man Aceton oder rauchende Salpetersäure (also was Karsten für gewöhnlich so im Haushalt hat) um den Kunststoff um den Chip wegzuschmelzen. Dann rubbelt man vorsichtig mit Sandpapier oder Polierpaste Mikrometer für Mikrometer von der Oberfläche weg. Am besten mit der ruhigen Hand von Starbug. Mit einem guten optischen Mikroskop (am besten ein Konfokalmikroskop, hat vermutlich auch jeder zuhause) kann man dann die Schaltkreise fotografieren. Die Fotos setzt man  zu einem Gesamtbild des Chips zusammen (so wie Google das mit den Satellitenbildern macht) und wiederholt das rubbeln, fotografieren und zusammensetzen für jede Schicht des Chips. Zur Interpretation der Fotos findet man Hilfe bei Siliconzoo.

Zuerst muss man einzelne Schaltungen wie ANDs, NORs etc. finden. Dann folgt man den Leitern der einzelnen Elemente durch die diversen Schichte bis man herausgefunden hat, wie die Elemente miteinander verknüpft sind. Das Ergebnis ist der Schaltplan. Quasi der Source Code des Chips. Um das zu erschweren, werden Dummyzellen in den Chip eingebaut, unnötige Verdrahtungen, nicht verwendete Funktionen, etc. Mit etwas Übung kann man die nutzlosen Schaltungen jedoch herausfiltern. Bei sehr großen Chips dürfte das allerdings kaum praktikabel sein.

Inzwischen haben das auch die meisten Chip-Hersteller verstanden und implementieren starke Algorithmen wie AES. Der nächste Schwachpunkt wird daher laut Karsten vermutlich die (un-)sichere Speicherung von Masterkeys in Chips werden. Masterkeys werden in Hardware verschlüsselt gespeichert und mit proprietären Algorithmen vor der Verwendung entschlüsselt. Wie man proprietäre Algorithmen analysiert haben Karsten und Starbug jedoch bereits vorgeführt.

Ich frage mich, ob das bei der Premiere-Verschlüsselung auch funktionieren würde?

Der Vortrag von Anne Roth zeigt eigentlich nur eines:

Der Staat hat sich in den letzten 10 Jahren vom Beschützer zum Bedroher gewandelt. Egal in welchem Land.

Angefangen vom § 129a in Deutschland über die Anti-Terrorgesetze in Europa oder Übersee … diese Gesetze werden  nicht wie ursprünglich den Bürgern versprochen gegen Terroristen eingesetzt … ganz im Gegenteil. In der Praxis gibt es unzählige Beispiele wie diese Gesetze verwendet werden, um Familien und Schulschwänzer zu bespitzeln (UK), Umweltschützer zu verfolgen (Portugal), Tierschützer einzusperren (Österreich) oder Bürgerrechtsaktivisten auszuspionieren (Neuseeland).

Ich habe geschwiegen, als sie die Umweltschützer holten,
denn ich war ja kein Umweltschützer.
Ich habe geschwiegen, als sie die Bürgerrechtaktivisten holten,
denn ich war kein Bürgerrechtsaktivist.
Ich habe geschwiegen als sie die letzten kritischen Journalisten holten,
denn ich war auch kein Journalist.
Als sie mich holten war niemand mehr da,
der dagegen hätte protestieren können.

— nach Martin Niemöller

… ist leider ausgefallen wegen Erkrankung des Referenten.

In Saal 2 ist jetzt der Vortrag von Saal 1 (Terrorist All-Stars von Anne Roth) gepatcht worden. Nicht uninteressant, da sieht man mal wieder wie gerne Staaten weltweit die Bürgerrechte mit Füßen treten. Aber für mich leider nicht so relevant. Nunja, so kann ich mich wenigstens in Ruhe akklimatisieren.

So, ich bin angekommen. Wie geplant, erfreulicherweise  kein Stau. Aber eben auch nicht rechtzeitig zu Fefes Vortrag. Naja egal, Fefe wird die FEM-Leute schon treten, bis die Videos da sind.

Meine DECT-Nummer vom letzten Jahr war leider schon vergeben, jetzt habe ich eine ähnliche neue: 2267.

Falls ich nicht gerade in einem spannenden Vortrag bin (da mache ich das Telefon höflicherweise aus) bin ich darüber erreichbar. Es sei denn, ich bin gerade nicht im BCC. So ab 50 m vor dem BCC bucht sich mein Telefon leider aus. Mein Hotel ist 500 m weit weg 🙂

Mein erster Eindruck: Irgendwie ist wenig los. Ok, das übliche Gedränge auf den Gängen aber der Catering-Bereich erscheint aufgeräumter als sonst und sogar im Hackcenter hätte ich leicht noch einen Platz kriegen können. Internet funktioniert, Telefon auch, mal sehen, was wird.

Nachtrag:

Ach ja, Ralf und Vido, die von mir noch ein Bier bzw. eine Bionade  ausgegeben bekommen, dürfen die Nummer natürlich auch gerne nutzen. Ihr solltet lediglich noch eure E-Mail Adresse wissen mit der ihr den Kommentar abgegeben habt, damit nicht jeder Leser hier auf dem Congress ein Freibier will 🙂

Nachtrag 2:

Der erste Eindruck hat getäuscht. Inzwischen wird es richtig voll. Glücklich, wer Strom und Ethernet hat. Wie ich 😉