Mitternachtshacking

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 bin dieses Jahr mit einem Asus Eee 1000H auf dem Congress unterwegs, der ist klein  und leicht und gut tragbar und das Akku läuft auch schön lange. Natürlich habe ich das System neu installiert, Dual-Boot, Linux und XP, alle Hackingtools drauf, die Festplatte ist verschlüsselt, BIOS-Passwort, alle Schikanen. War ’ne Menge Arbeit zu Weihnachten. Aber man weiß ja nie unter den ganzen Hackern auf dem Congress 😉

Jedenfalls verlangt die Asus-Software wie bei den meisten Herstellern die Annahme einer Lizenz:

Und ganz ehrlich, das ist mal eine Lizenz ganz nach meinem Geschmack. Jetzt muss ich mir nur noch eine passende Lizenz ausdenken und einfügen 🙂

Nachtrag zum Cold Boot Attack-Vortrag von Jacob Appelbaum. Die Genies von Princeton (dort liegt die Software zum Download) sind leider manchmal nicht so genial. Der folgende Screenshot ist von einem Server des Center for Information Technology Policy der Princeton Universität. Wo liegt der Hund begraben?

Genau: Der Code, die Signaturen und der Public Key liegen im gleichen Verzeichnis auf dem gleichen Server. Wenn ein Angreifer also den Server kompromittiert und die Software manipuliert, kann er trivial mit seinem eigenen privaten Schlüssel neue Signaturen erzeugen und seinen Public Key auf dem Server ablegen. Eine standardmäßige Kontrolle würde eine Kompromittierung daher nicht erkennen.  Da könnte man auch billige MD5-Hashes verwenden, die sind genauso toll und leichter zu bedienen.

Wenn man schon Archive signiert, dann muss der Public Key entweder mittels Zertifikat auf einen bekannten Root-CA Key zurückgeführt werden oder auf einem anderen Server liegen. Ansonsten kann man sich den Unsinn mit den Signaturen gleich sparen.

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 😉