Mitternachtshacking

Diesmal ging es nicht um das Schweizer Postcard Debitsystem sondern um das britische Chip & PIN System. Steven Murdoch hat einen Kartenleser so modifiziert, dass man damit u.a. Tetris spielen kann, viel wichtiger jedoch, dass die eingegebenen Kartendaten inklusive der eingetippten PIN direkt an einen dritten Rechner geschickt werden, mit dem in Echtzeit eine Authentisierung an einem anderen Terminal möglich ist.

Der Ablauf sieht dann so aus:

Kunde –> Böses Terminal —> Hacker –> Normales Terminal –> Bank

• Der Kunde schiebt seine Karte in das Terminal und gibt die PIN ein um einen kleinen Betrag zu bezahlen
• Das Terminal leitet die Daten an den Hacker weiter
• Der Hacker verwendet eine programmierbare Karte und schreibt die Daten darauf
• Der Hacker authentisiert sich mit den Daten und der PIN an einem echten Terminal und bezahlt einen sehr hohen Betrag
• Der nichts ahnende Kunde wird um den hohen Betrag belastet

Im Grunde ist da nichts neues dabei, die Technik ist vergleichbar mit den Methoden die verwendet werden um Mittels Aufsatzgeräten die Magnetstreifen und PINs an deutschen Geldautomaten abzugreifen. Durch die Chipkarte wird es lediglich ein wenig schwieriger.

Das Problem ist m.E. auch weniger die technische sondern die politische Implikation. Theoretisch gilt in Großbritannien ein „Banking Code“ (d.h. die Banken haben durch geschickte Lobbyarbeit ein entsprechendes Gesetz vermieden) nachdem die Banken dem Kunden nachweisen müssen, unvorsichtig gehandelt zu haben. Praktisch ist das gleiche passiert, das auch schon in Deutschland zu sehen ist: Die Banken verweisen auf ihr angeblich 100% sicheres System mit Chipkarte und PIN und lehnen jede Verantwortung für Schäden ab. Und die deutschen Banken bekommen von offensichtlich wenig kompetenten Richtern am BGH auch noch Recht.

Für Kunden bleibt eigentlich nur das Fazit, die Nutzung dieser Systeme soweit wie möglich einzuschränken. Ich verwende meine EC-Karte ausschließlich zum Geldabheben am Automaten und ich rüttle jedes mal am Einschub und dem Tastenfeld in der Hoffnung, ein schlampig befestigtes Vorschaltgerät löst sich dann ab. Ich zahle praktisch niemals im Supermarkt mit EC-Karte sondern immer bar, da für mich nicht kontrollierbar ist was wie wo in diesem EC-Kartenterminal passiert. Und wo Kartenzahlungen notwendig sind nehme ich Kreditkarten, da ist die Haftungsregelung nämlich viel Kundenfreundlicher.

Ach ja, und die Karte sollte sich nicht nur am Terminal authentisieren sondern das Terminal auch an der Karte …

Ich habe mir unter diesem Titel zwar etwas anderes vorgestellt aber insgesamt war ich von den beiden Italienern positiv überrascht.

Insbesondere der erste Teil von Twix war richtig gut. Er hat eine Möglichkeit gefunden in Solaris 8, 9 und 10 verlässlich Kernel-Sicherheitslücken mit Hilfe von Exploits auszunutzen. Die Idee von ihm basiert darauf, 80 Byte mit psargs in die vom Kernel verwaltete Prozesstabelle zu schleusen, die im Gegensatz zum Stack ausführbar ist. Damit lassen sich etwa 19 Befehle, durch Chaining mit mehreren Prozessen sogar komplexere Exploits ausführen. Seine Methode funktioniert grundsätzlich zuverlässig mit allen Kernelexploits die den Stack nicht verändern, andernfalls muss man den Stackzustand manuell wieder herstellen, damit der Kernel nicht abstürzt.

Im zweiten Teil hat sgrakkyu sich mit Windows Race Conditions beschäftigt, insbesondere Kernel Races. Ein Thema sind Programme wie Windows Firewalls oder Virenscanner die sich mittels Kernel Space Hooking in das System einklinken. Das ist jedoch ein fehlerhaftes Design, da eine TOCTOU-Race Condition vorliegt.

Zu einem Zeitpunkt A findet der Hook statt und der Virenscanner prüft die übergebenen Daten. Zu einem späteren Zeitpunkt B findet der Rücksprung auf die echte API statt und die Windows-Funktion wird ausgeführt. Allerdings ist es unter bestimmten Umständen möglich, zwischen A und B die untersuchten Daten zu verändern.

Der Vortrag war sehr sehr technisch, ich habe vermutlich höchstens die Hälfte verstanden. Es lohnt sich jedoch, in den Phrack-Artikel der beiden reinzukucken. Einer der längsten die ich je gesehen habe. In dieser Qualität und auf diesem Niveau waren bisher nur die beiden Vorträge zum Barcode-Hacking und zu Mifare.

Tonnere Lombard ist einer der NetBSD-Entwickler und u.a. Maintainer des FVWM, eines X11 Windowmanagers, der zu meiner Unix-Anfangszeit State-of-the-Art war.

Die Präsentation von ihm behandelte typische Programmierfehler die zu Sicherheitslücken und diversen Problemen führen können. Insgesamt eher ein Vortrag für Leute die sich neu mit sicherer Programmierung beschäftigen, unabhängig davon aber zwar etwas chaotisch aber sehr kompetent präsentiert.

Wichtige Fehler:

• Buffer Overflows (Stack, Heap)
• Integer Overflows (z.B. 32-bit Code auf 64-bit Systemen)
• Synchronisierungsprobleme (Race Conditions, Signalbehandlungsfehler)
• Format String Bugs
• Injectionsangriffe (XSS, XSFR, SQL-Injection)
• Authentisierungsfehler

Das spannende war, die meisten Fehler wurden anschaulich direkt live vorgeführt.

Ein Beispiel: Integer Overflow (Fehler auf 64-bit Systemen)

• Falsch: unsigned long fl = (_flags & 0xffff0000) > 16;
• Richtig: unsigned long fl = (_flags & 0xffff0000L) > 16;

Der Source Code seiner fehlerhaften Programme ist bereits auf vulns.bsdprojects.net veröffentlicht.

Sehr amüsant fand ich seinen Kommentar beim Öffnen des Webbrowsers: „Hoffentlich kommt nicht der Schäuble angerollt, beim Öffnen dieses Terrortools“ und sein Fazit: „Es gibt keine Programmiersprache welche es erlaubt, das Gehirn abzuschalten„.

Nachtrag:

Ebenfalls eine lustige Idee ist die Gründung eines „Vereins“ mit dem Namen „‚ or 1=1 —“ um den Vereinsnamen als Login in Webformularen verwenden zu können. Das muss doch sogar für den GröIaZ legal sein.

Zwei Bilder vom 24C3, das BCC mit der „Heart of Gold“ …

und der Bundestrojaner des CCC

Der Mifare-Chip von Philips ist ja schon seit geraumer Zeit ein Thema, insbesondere der Mifare Classic, weil Philips bei diesem Chip nicht herausrücken will, wie die Verschlüsselung funktioniert. Das Thema ist jetzt durch Henryk Plötz und Karsten Nohl haben sich die Arbeit gemacht, den Chip aufzusägen, zu analysieren und ein komplettes Reverse Engineering der Transistoren durchzuführen. Das Ergebnis ist erschreckend.

Ein großer Teil der Arbeit, insbesondere die Kommunikation zwischen Kartenleser und Chipkarte wurde mit Hilfe der hervorragenden Arbeit von Milosch Meriac durchgeführt, der OpenPCD und OpenPICC entwickelt hat.

Bekannt ist schon länger, dass Mifare Classic einen proprietären Algorithmus verwendet, der einen 48-Bit Schlüssel verwendet (und damit eigentlich schon zu kurz für kommerzielle Anwendungen ist). Der Algorithmus war jedoch geheim. Henryk und Karsten haben den Algorithmus analysiert (allerdings noch nicht veröffentlicht), der auf einem einfachen LSFR basiert. Es gibt keine nicht-linearen Komponenten im Feedback, der Algorithmus bietet daher keine Forward Security. Hintergrund ist vermutlich, dass ein explizites Designziel eine geringe Komplexität war, um den Algorithmus mit wenig Transistoren und wenig Energie durchführen zu können.

Eine weitere Schwachstelle ist der Zufallszahlengenerator, der sich ausschließlich über die Zeit seit Aktivierung initialisiert. In Tests konnten die Referenten zeigen, dass durch geschicktes Timing immer die gleichen „Zufallszahlen“ produziert werden.

Eine dritte Schwachstelle ist die Verknüpfung von UID und Key in der Verschlüsselung. Die UID lässt sich beim Senden mit OpenPICC fälschen (sie steht jedoch auch in Block 0 und kann dort nicht verändert werden aber das prüfen die meisten Leser nicht ab) und der Key passend wählen, so dass der Reader meint, er hat einen anderen User authentisiert. Das ist möglich, ohne dass man den Key des eigentlichen Users kennen muss.

Das Fazit:

1. Security by Obscurity funktioniert nicht. Allerdings kriegt Philips ja bei MP3-Playern schlechte Kritiken, warum soll das bei Chipkarten so viel besser sein?

2. Mifare Classic ist quasi tot. Es ist nur noch eine Frage der Zeit bis der Algorithmus veröffentlicht ist und dann werden sich die Kryptoanalytiker drauf werfen und alle Schwächen finden.

3. Es wird Zeit zu migrieren.

Eine Antwort von Philips steht übrigens noch aus.

Für mein Verständnis war das der wichtigste Vortrag bisher auf dem ganzen Congress. Was mich ein wenig wundert ist, dass Heise zu diesem Thema gar nichts schreibt. Immerhin ist der am weitesten verbreitete RFID-Chip betroffen. Aber vielleicht war das Marketing des Vortrags nicht gut genug? 😉

Fabs, einer der Mitarbeiter von FXs Firma hat einen neuen Portscanner namens „PortBunny“ entwickelt und vorgestellt. Dabei ist er clever und aggressiv das Problem von Nmap angegangen, bei Rechnern mit nur wenig offenen Ports sehr lange für den Portscan zu brauchen. Einfach nur mehr und schneller Anfragen zu senden ist dabei keine Lösung weil das Netz Pakete verwirft, wenn es überlastet ist.

Die Idee von Fabs ist dabei recht clever. Er streut in den Scanprozess alle paar gesendete Anfragen ein Paket ein von dem er weiß, dass es eine Antwort erzeugt. Das kann z.B. ICMP Echo Request, ein ICMP-Fehler als Antwort auf ein UDP-Paket oder ein TCP-RST sein. Wenn diese Antworten nicht mehr zurückkommen, dann sieht der Portscanner das Netz ist überlastet und sendet seine Anfragen langsamer. Außerdem können die letzten Anfragen neu gesendet werden. Das Verfahren ähnelt in gewisser Weise der TCP Congestion Control.

Mit dieser Technik ist PortBunny in der Lage, das Netz recht effizient auszulasten, insgesamt deutlich besser als Nmap. Allerdings erzeugen die Trigger ca. 10% zusätzlichen Netzwerkverkehr. Source Code wurde keiner veröffentlicht, eventuell passiert das im Januar. Da sich PortBunny direkt im Linux-Kernel befindet (/dev/portbunny), muss, falls es veröffentlicht wird, zumindest das Modul unter der GPL veröffentlicht werden … naja, mal sehen.

Insgesamt hat mich der Vortrag nicht sonderlich beeindruckt. Die Idee mit den Triggern ist zwar ganz clever, aber das hätte man gut auch in Nmap integrieren können (und kommt vermutlich auch irgendwann da rein). Ansonsten ist der Scan lediglich schneller als bei Nmap (im günstigsten Fall so Faktor 2-10). Gegen die großen IPv6-Netze hilft das nur leider auch nicht. Wenn nicht gerade FX für den Vortrag gestanden hätte (um seine Firma zu promoten?) hätte es der Inhalt meiner Meinung nach wohl kaum ins Programm geschafft. Tja, so ist der Stand halt: keine Präsentationsslides, kein Source Code. Enttäuschend.

FX ist im Grunde eine Klasse für sich. Das Thema Barcode klingt auf den ersten Blick ja erstmal extrem langweilig aber FX hat was spannendes und ansprechendes daraus gemacht.

Zuerst mal zu den technischen Details:  FX hat sich mit 1D Barcodes (das sind die mit den Strichen) und 2D Barcodes (das sind diese Matrixfelder) beschäftigt, wobei 1D Barcodes aufgrund der geringen Datenmenge und den beschränkten Kodierungsmöglichkeiten sich als leicht angreifbar erwiesen haben.  Zu den 1D Barcodes gehören u.a. die Kodierungen Code39, UPC-A bis UPC-E, EAN8, EAN13 (das sind die auf den Lebensmitteln) sowie obskurere wie Postnet (der Code auf den Briefen). Bei den 2D Barcodes sind hauptsächlich PDF417, Data Matrix, Maxicode und Aztec Code zu nennen. Als Software zum Erzeugen von Barcodes empfiehlt er GNU Barcode (die Spezifikationen der Barcodes kann man aber auch für relativ wenig Geld erwerben). Zum Lesen verwendet er die Omniplaner SwiftDecoder Software, ein kommerzielles Produkt.

Neben vielen Anekdoten und technischen Erklärungen zum Vorgehen sind drei Punkte bei mir hängengeblieben:

1. Scanner-Konfiguration via Barcodes

Einige Scanner lassen sich via Barcodes konfigurieren. Dafür gibt es einen speziellen Barcode „Enter Configuration“, einen weiteren mit der eigentlichen Konfiguration und einen dritten „Save Configuration“. Das sieht schon mal recht vielversprechend für lustige Angriffe aus.

2. Anwenden von Barcodes im Supermarkt

Die Idee von FX war, man nimmt einen Barcode-Auszahlungsbeleg vom Pfandsystem, vervielfältigt diesen und kopiert ihn auf Aufkleber, die automatisch gescannt werden. Diese Aufkleber pappt man auf schwere Waren die auf der Unterseite den Barcode haben. Die meisten Kassierer ziehen die Ware nur über den Leser und statt dem Preis für das Sixpack bekommt man Geld zurück. Diesen Trick kann man auch in Verbindung mit Punkt 1 anwenden.

3. Es gibt ein paar Barcode-Systeme die recht sicher scheinen, zumindest hat FX auf die schnelle nichts gefunden. Dazu gehören u.a. das der Deutschen Post und der Deutschen Bahn. Außerdem bekam er bei seinen USA-Besuchen bei der Ausreise ebenfalls einen riesengroßen Barcode, der jedoch nie wieder eingescannt wurde. Ich wiederhole hier daher die Einladung an FX, diese Barcode-Systeme zu analysieren.

Heise hat einen sehr guten Artikel dazu, der die weiteren Angriffe wie SQL-Injection via Barcode oder fehlerhafte Verwendungen von Barcodes z.B. in Videotheken oder am Frankfurter Flughafen.

Im Vortrag „Automatic Memory Management“ ging es um automatisches Speichermanagement also Garbage Collection und die Frage ob es sinnvoll ist, den Speicher z.B. in einem C-Programm mittels malloc() und free() selbst zu verwalten oder das einem automatischen Prozess zu überlassen. Insgesamt eher eine Frage für Programmiersprachenentwickler und weniger für Hacker.

Hannes stellte dabei die verschiedenen Garbage Collection Ansätze vor, im einzelnen:

• Reference Counting
• Mark and Sweep
• Mark and Compact
• Copying GC
• Generational GC
• Incremental GC
• Memory Pool System

Und die Vorteile in der Systemsicherheit, insbesondere

• keine Memory Leaks
• keine Double-Free Bugs

Sein Fazit war, wenn man etwa den vierfachen RAM zur Verfügung hat, den das System zum normalen Ablauf braucht, dann ist Garbage Collection effizient, wenn der verfügbare RAM etwa dem benötigten entspricht und GC daher sehr oft laufen muss, ist eine manuelle Allokierung und Freigabe effizienter.

It’s so nasty, nasty, nasty … und die Virtuellen Maschinen wie Java werden in Zukunft sicher mehr. Die beiden Österreicher Roland Lezuo und Peter Molnar haben sich in ihrem Vortrag „Just in Time Compilers – breaking a VM“ intensiv mit der Cacao OpenSource JavaVM beschäftigt und eine Reihe von Möglichkeiten gefunden, aus den Beschränkungen der Virtual Maschine auszubrechen und außerhalb der Kontrolle eines Security Reference Monitors beliebigen Programmcode auszuführen.

Die meisten Lücken die in Cacao gefunden wurden sind Integer Overflows und alle sind wohl Programmierfehler, z.B. wenn 32bit-Code für 64bit-Systeme kompiliert wird und die größeren Integer nicht berücksichtigt.  Ein weiteres Problem kann darin liegen, dass die Entwickler des JIT-Compilers von den Eigenschaften der Programmiersprache ausgehen und nicht von den Möglichkeiten im verwendeten Bytecode. Ein Angriff bestand deshalb darin, speziell angepassten Bytecode zu erzeugen, der eine Schwäche des JIT-Compilers nutzt.

Die Gefahr dieser Angriffe ist durchaus real, in praktisch allen Browsern werken inzwischen eine Vielzahl von Vitual Maschines. Java, Flash, Silverlight, … und es werden eher mehr. Fukami ist an dem Thema Flash ja schon seit geraumer Zeit dran.

In diesem Vortrag ging es um die aktuelle Entwicklung in der Quantenkryptographie, hauptsächlich quantenkryptographische Schlüsselverteilung. Die Präsentation wurde in Form einer Diskussions- und Vortragsrunde von einer Gruppe Physiker gehalten, die sich mit Quantenkryptographie beschäftigt.

Eine Einführung in die Verschlüsslung zeigt die typischen Probleme, Schlüsselaustausch bei symmetrischer Verschlüsselung und Berechnung des Private Key aus dem Public Key bei Verwendung des RSA-Algorithmus (mit geringer Schlüssellänge). Anschließend wird auf die physikalischen Eigenschaften von Photonen, insbesondere ihre Polarisierung und die Polarisationsfilter eingegangen. Wichtig war der Hinweis aus die Unschärferelation von Heisenberg, die sich nicht umgehen lässt (auch nicht, wenn man clever ist). Zur Kodierung wird in den meisten Implementierungen das BB84 Protokoll verwendet.

Das eigentliche Problem der Quantenkryptographie liegt auch nicht in der Physik an sich sondern in fehlerhaften Implementierungen. Die Hersteller dieser Geräte versprechen, da die Physik absolut sicher ist, sind das natürlich auch die Geräte und diese Annahme ist leider falsch. Genau wie AES ein (ausreichend) sicherer Algorithmus ist, kann der Algorithmus fehlerhaft implementiert werden und einem Angreifer (z.B. über einen Side-Channel Angriff) Zugriff auf den Enryption-Key erlauben. Gegen das Quantenkryptographische System lassen sich beispielsweise Timing Channel Attacken ausführen.

Sehr spannend war, dass die Jungs das komplette selbstgebaute Gerät aus Singapur nach Deutschland gebracht haben um es live vorzuführen. Meine persönliche Meinung ist jedoch, dass die Quantenkryptographie noch etwas mehr verspricht, als die konkreten Implementierungen tatsächlich halten können. Außer für spezielle (z.B. militärische) Anwendungen macht der Einsatz der Quantenkryptographie noch keinen wirklichen Sinn.