 Also willkommen zusammen, zu diesem Vortrag, zum Thema Shopshifting. Shoplifting hat gar nichts mit Shopshifting zu tun, nur das Ergebnis ist ähnlich. Und ich stelle euch vor, Cast0, Fabian Bräulein und Dexter aus Berlin und einige haben vielleicht schon das ein oder andere Gesicht gesehen. Und habe vielleicht von den MyFair-Problemen gehört, die GSM SimCart Hacks oder Bad USB. Und diese Leute und die Leute in ihrem Umfeld sind dafür verantwortlich. Also ein Warma-Plaus. Vielen Dank. Es ist toll, wieder hier zu sein, sich wieder eine neue Technologie anschauen und Verwundbarkeiten in Technologie. Unsere Forschung widmen wir größtenteils Technologien, die viele von uns täglich benutzen, die aber alt sind, weit verbreitet und unsicher. Wir haben eine Weide gebraucht, um Zahlungsprotokolle und Helope zu nehmen. Und das lag teilweise daran, dass wir einfach nicht gedacht haben, dass wir irgendwas finden würden. Denn immerhin arbeiten einige der besten Leute in unserer Industrie bei Banken und die Banken haben das beste Risiko-Management. Und zumindest in meiner Erfahrung sind Banken gut daran, gut dabei der Sicherheits-Evolution, mit der Sicherheits-Evolution Schrittzeiten. Das dachte ich, aber bis zur Mitte des Jahres, als wir angefangen haben mit unserer Forschung, aber jetzt sind wir hier, um diese Illusion den Leuten zu nehmen, die sie noch haben. Immerhin in zwei sehr weit verbreiteten Protokollen haben wir gefunden, dass es riesige Lücken gibt, die schon seit Jahren da waren. Die meisten dieser Protokolle werden zur Zahnung benutzt, also wenn ihr in einem Laden mit eure Karte bezahlt. Und diese Protokolle sind ZVT und Poseidon. Sie werden für ganz verschiedene Dinge benutzt, aber sie sind immer an einem Zahnungstermine verwendet. Das eine spricht zwischen der Kasse und dem Zahnungstermine. Der Kassierer tippt also einen Preis ein und dann wird dieser Preis an das Termine übertragen. Und das Termine braucht dann die Karte, hört eine Pinn-Nummer und dann spricht dieses Termine über ein wieder anderes Protokoll mit einem Service-Provider, der da mit den Banken spricht. Und damit wird dann die tatsächliche Zahnung freigegeben. Im Laufe dieses Protokolls werden dann verschiedene Dinge validiert und ganz zum Schluss das Ergebnis wieder zurück an die Kasse gesandt. Und so funktioniert eine Zahnungstransaktion. Sie basiert auf zwei Protokollen. Beide davon sind relativ alt und wahrscheinlich weil sie so alt sind, sind sie sehr weit verbreitet. In Deutschland findet man kaum etwas anderes als diese beiden Protokolle. Wir schauen uns das Ganze auch noch mal von einem internationalen Standpunkt an, aber es läuft darauf hinaus, dass diese Probleme in den meisten Ländern anzutreffen sein dürften. Also schauen wir uns zunächst ZVT und Poseidon an und ihre Sicherheitslücken. ZVT ist also das Protokoll zwischen der Kasse und dem Zahnungstermine. Aber in den meisten Fällen passiert das über ein Netzwerk-Protokoll, manchmal über einen seriellen Anschluss, aber heutzutage fast immer über ein Netzwerk. Wenn also ein Betrüger in Zugriff auf das Netzwerk gelangen kann, das könnte zum Beispiel in einem Hotel passieren, aber das ist das selbe Wenang für die Zahlung und für die Gäste benutzt. Fangen wir also mit etwas ganz Einfachem an, was man nicht mal hacken muss. In diesem Fall will der Angreifer die Magnetstreifendetails abgreifen. Dann sollte die Kassierer eine Anfrage an das Terminal stellen und das Terminal schickt die Daten zurück. Aber der Angreifer kann sich zwischen diese beiden Schalten in dieser Verbindung. Das heißt, man funktioniert als Proxy zwischen der Kasse und dem Zahnungsterminal und befindet sich im lokalen Netzwerk. Wir schauen uns auch noch Internet-Angriffe an, aber momentan reden wir über lokale Netzwerke. Man spooft also und bekommt diese Autorisierungs-Anfrage und fängt diese ab. Wir nehmen diese Anfrage und leiten sie nicht weiter, sondern senden eine andere Anfrage, die sagt, liest die Karte. Dann wird das Display anzeigen, was der Kunde erwartet, die Karte einführen zu der Kunde, und dann wird der Magnetstreifen ausgelesen und über das Netzwerk an den Angreifer gesendet. Da ist noch keine Transaktion passiert. Anschließend würde der Angreifer eine tatsächliche Autorisierungs-Anfrage mit den Informationen aus den Magnetstreifen schicken. Das heißt, ohne dass es jetzt die Karte braucht, kann das Terminal jetzt die Transaktion ausführen. Also zunächst hat der Angreifer die Magnetstreifendaten angefragt und anschließend wurde die eine Transaktion ausgeführt. Das heißt, niemand merkt einen Unterschied, aber der Angreifer hat eine Kopie des Magnetstreifens. Es gibt Länder, in denen der Magnetstreifen genug ist, um eine Karte vollständig zu klonen. Zum Glück tun das die meisten Länder außer den USA nicht, und dadurch ist dieser Angriff relativ ineffektiv. Sagen wir nun, dass der Betrüger auch die PIN-Nummer abgreifen möchte. Schließlich braucht man in Deutschland nur den Magnetstreifen und die PIN-Zahl, um zu bezahlen. PIN-Transaktionen sollten so funktionieren oder sind die einzigen Transaktionen, die überhaupt irgendwie verschlüsselt sind. Das seht ihr auf dem oberen Teil dieser Folie, wie eine Transaktion funktionieren sollte. Auch wieder über ZVT fragt die Kasse wieder beim Terminal eine Autorisierungsanfrage und sagt, bitte, diesmal brauche ich die PIN-Zahl, vielleicht ist das auch schon voraus konfiguriert. Und jetzt passiert innerhalb dieses Terminals diese ganze Autorisierungssicherheitsmagie. Es gibt eine Haupt-CPU, die die ganze Netzwerkkommunikation betreibt, die so ein bisschen sicher sein sollte, aber das nicht wirklich, das hat auch schon ein bisschen Vorführung für ein paar Jahre gezeigt. Aber das ist nicht unser Thema heute, wir kümmern uns um die Standardsicherheit. Innerhalb dieses Terminals gibt es also jetzt ein Hardware-Sicherheitsmodul. Und dieses HSM macht die ganze schwere Arbeit mit Kryptoschlüsseln und so weiter. Sie ist auch verbunden mit dem Display und der PIN-Tastatur der Maschine. Jetzt sagt man also diesem HSM innerhalb dieses Terminals, ich brauche eine PIN und es zeigt das auf dem Display an, kriegt den Input und verschlüsselt diesen PIN mit einem Schlüssel, den nur die Zahlungsfirma haben sollte. Das heißt, niemand sieht diese PIN-Zahl außer dem Zahlungsanbieter. Und der Unterhalteil dieser Folie zeigt euch, wie ein Angriff funktionieren könnte. Dieses Angriff benutzt eine andere Nachricht, um tatsächlich die PIN-Zahl zu bekommen. Es würde also sagen, zeig Text an und gib mir die Eingabe zurück. Das würde wunderbar funktionieren. Also zeigst einen Text an, der Kunde gibt einen Zahl ein und bekommt diese Zahl zurück. Diese sehr flexible Funktionalität, wir wissen nicht so wirklich, wofür man sie eigentlich brauchen sollte, aber zum Beispiel für so Sachen wie Postleitzahlabfragen, also tipp irgendwas ein und schick es über das Netzwerk zurück. Man kann es wirklich kaum gebrauchen, weil diese Nachrichten signiert sein müssten. Wir wissen nicht genau, wer sie signieren sollte. Wir haben versucht, jemand zu finden, der es tut, aber niemand ist verantwortlich. Also es gibt hier Standards, von denen niemand weiß, wie sie gebraucht werden sollen. Und dieser Message Authentication Code MAC, also der Nachrichten-Autativierung-Code, den braucht man. Das heißt, wenn man in ein Läden nach Postleitzahl infragen muss, dann muss man diese Anfrage signieren. Und wenn wir unsere, bitte gibt eine Geheimzahlabfrage haben wollen, dann müssen wir sie signieren oder jemanden finden, der uns das signiert. Aber das geht jetzt ins richtige Hacking über und deswegen gebe ich über an Fabian, der die meiste Forschung geleistet hat. Also gut. Um die Hauptwerte für diese zufälligen Text zu finden, haben wir eine time-based Side-Channel-Verwundbarkeit untersucht. Damit das vernünftig funktioniert, mussten wir Nachrichten direkt verschicken. Um das zu erreichen, benutzten wir ein aktives JTAG-Interface, das wir für die Haupt-CPU gefunden haben, auf dem PCB gefunden haben und haben unser eigenes Assembliprogramm hochgeladen. Und dann haben wir Nachrichten mit unseren Texten hin und her geschickt und haben die Zeit gestoppt, die es braucht, bis es antwortet. Wir tun das und wir versuchen, jeden möglichen Wert für den ersten Byte dieser Arbeit wert ist. Wenn du das tust, okay, das ist jetzt ein bisschen sehr vereinfachter, aber wir kommen noch dazu. Du wirst sehen, dass für einen Wert, einen bestimmten Wert, dieser HSM ein bisschen länger braucht, um zu beantworten. Vielleicht fünf CPU-Sägeleunen. Jetzt hast du bereits den ersten Byte dieser 8 Byte Mac und dann kannst du das gleiche für den zweiten Wert machen. Warum funktioniert das? Sie benutzen einen symmetrischen Schlüssel, um die Mac zu berechnen innerhalb der HSM. Es gibt das, welches der Zahlungsprozessor hat. Dieser wird benutzt, um den korrekten Mac für jeden Text verwendet. Und das ist mein erster Punkt, man sollte doch asymmetrische Kryptografie verwenden, das ist nicht gut. Der Vergleich zwischen der korrekten Mac innerhalb der HSM und die Mac, die wir überall diese Display-Text-Matchets reintun, wird per Byte verglichen. Es vergleicht, ob der erste Byte reinkommt, vergleicht das mit dem Byte drinnen. Gibt es zurück, kommt es zurück, sofort zurück und dann vergleicht das zweite Byte. Und es kommt sofort zurück. Und die Zeit, die es braucht, um ein weiteres Byte zu testen, können wir messen. Damit, mit der korrekten Mac für den Bitte ändern, geben Sie Ihre Pin ein Screen, können wir euch eine Demonstration geben, wie das im wirklichen Leben funktioniert. Das machen wir mit einer GoPro. Das ist das Setup. Hier brauchen wir den Computer mit dem Green Text auf dem schwarzen Terminal. Hier haben wir ein ganz normales Registrierkasse mit Windows XP. Da haben wir das Zahlungsterminal. Die zwei sind mit einer Fritzbox verbunden wie in einem stinknormalen Netz. Es gibt ein weiteres Teilnehmer. Das ist mit LAN verbunden, könnte aber auch mit Wi-Fi verbunden sein. Was wir jetzt hier haben, was hier läuft, ist die Software des Angreifers. Wir initialisieren jetzt eine Zahlung an der Registrierkasse. Wir machen einen mendingen Mittel zwischen den zwei Geräten. Wir lassen diese Nachricht fallen und ersetzen sie mit der ersten Nachricht. Bitte lesen Sie die Karte. Bitte geben Sie Ihre Karte ein. Jetzt sehen wir die Kartendaten. Sie sind ein bisschen zensiert für unsere Sicherheit. Er hat die Pin eingegeben. Das war jetzt ziemlich schnell, aber was ihr gesehen habt, wurde eingegeben. Er wurde angezeigt, sobald er sie eingegeben hat. Das war ja sein Fake Pin Entry, sein Pin-Eingabe-Screen. Das ist die erste Demo. So stehen wir die Pin. Können wir die Quittung zeigen? Diese Zeile in der normalen Transaktion, wenn er das Girocard sagen sollte. Jetzt ist sozusagen ein Text drin. Aber wer achtet schon auf diese kleinen Nachrichten auf der Quittung? Das bedeutet, dass die Transaktion durchgegangen ist, ohne dass die Pin durchgereicht wurde. Aber wir können unseren Angriff auch scheitern lassen zum ersten Mal. Dann steht da Systemfailer Pin Incorrect. Dann machen wir eine zweite Transaktion. Und dann sieht das wieder in Ordnung aus. Oder in größeren Installationen macht das eh ne hin ein externer Printer, der an der Restrikasse hängt. Und dazu muss die Quittung per Linie gesendet werden, ohne Authentifizierung. Und in einem größeren Setup könnten wir daher diese Meldung an den Drucker abfangen und manipulieren, damit diese Auffälligkeit nicht auftritt. Das war der Angriff gegen den Kunden. Also jeder von euch, der einfach mit, sozusagen, Karten bezahlt. Es gibt einen weiteren Angriff, der den Merchand oder Händler-Account angreift. Es gibt nach den Banken solche 770.000 derartige Kunden in Deutschland. Denn heutzutage selbst der kleinste Laden nimmt ja Kartenzahlung an. Schauen wir uns diesen Angriff an. Da versuchen wir, das komplette Geld zu bekommen, welches transferiert wird in unseren eigenen, unsere Anbankkonto umzuleiten. Wir gehen davon aus, wir haben Zugriff auf das Netzwerk. Wir versuchen aber nicht mehr in den Mittel zwischen der Registrierkasse zu werden, sondern zwischen dem Kassenterminal und dem Internet. Denn dort ist dann der Payment-Processor, also der Verwalter. Das machen wir wieder per Apps-Boofing. Es gibt hier wieder eine Nachricht in der Spezifikation, um die Terminal-ID zu resetten. Denn die gibt wieder zu welchem Konto der Account dieses Kunden, dieses Payment-Processor zugeordnet wird. Wenn wir das gesetzt haben, dann erzählen wir dem Terminal, dass das Terminal in eine Diagnose-Schleife geht. Da verwenden wir das Protokoll dazu und initiieren eine Nachricht auf dem Poseidon-Protokoll. Denn wenn wir die Terminal-ID resetten, dann wird sich das Terminal neu konfigurieren auf seine, sozusagen, ID. Und das Handler-Logo, das auf jeder Quittung gezeigt wird, ist dann eben auch, wäre das sozusagen das Angreifers, das möchten wir nicht. Das heißt, das Terminal muss eine neue Übertragung machen, eine neue Diagnose. Wir haben die Antwort. Und jetzt können wir wieder diese Anfrage mit der Originalanfrage ausschauen und niemand wird überhaupt merken, dass es jemals gab. Und auch das ist wieder möglich, weil es keine Authentifizierung gibt. Kommen wir zur tatsächlichen Transaktion. Wenn der Port am Backend schon der richtige ist, dann können wir einfach alle Nachrichten weiterleiten. Der Port am Backend, jeder Zahnungsverarbeiter hat eine eigene IP-Adresse, aber aus Grund des Loadbalancing haben sie 100 verschiedene Ports und jeder Port kümmert sich um 50.000 Terminals. Aber jedes Terminal hat nur einen einzigen Port, das für das verantwortlich ist. Und wenn wir den haben, dann kriegen wir für jede Zahlung Geld in unseren Konto. Und ansonsten, wenn das noch nicht tut, können wir einfach Anfragen weiterleiten. Aber jetzt sehen wir uns das mal anreifern. Hier haben wir ein Zahnungsterminal. Wir haben das konfiguriert. Das ist ein anderer Händler sein. Welcher es ist, das zeigen wir euch später. Hier haben wir wieder den PC des Angreifers, der die durchwertige Software am Laufen hat. Und jetzt geben wir die Registrierung aus, damit wir den Terminal Nachrichten schicken können. Und jetzt setzen wir die Terminal ID neu von der Korrektin zu unserer eigenen, also die wir aus unserem Vertrag mit dem Zahnungsanbieter haben. Wir schreiben sie jetzt. Und jetzt bekommt das Terminal schon seine neue Konfiguration verschlüsselt, wie ihr sehen werdet. Aber sie kommt an. Also das passiert alles mit echten Terminals für echte Transaktionen. Also alle, die das bei den Banken schauen, danke, dass ihr uns noch nicht blockiert habt. Aber wir haben das 3G-Netzwerk benutzt, also falls sie die IP-Adresse blockiert haben. Also ihr kennt das, das würde normalerweise auf den Casmin-Bong gedruckt werden. Und dieses Terminal sagt jetzt, dass es SR-Labs gehört. Normalerweise wäre das hier die volle ID, die wir ein bisschen zensiert haben. Das ist die komplette Konfiguration und ist auch konfiguriert, um Prepaid-Karten ausgeben zu können. Normalerweise würde das auf dem Terminal ausgedruckt werden. Aber weil das ziemlich uncool wäre, weil ihr es dann erkennen könntet, haben wir einen Output auf unser Notebook umgleitet. Jetzt starten wir den Man in the Middle Server für diesen letzten Teil, der das Logo austauscht. Und wir werden jetzt eine Demo-Transaktion ausgeben. Also so wie das die Casting Software vorhin gemacht hat, machen wir das jetzt hier auch. Und wie ihr seht, gehört dieses Terminal jetzt oder immer noch. Könnt ihr das sehen? Das gehört jetzt zu CCC-Veranstaltungs-GmbH. Und so klaut man also vom Händler Geld, während man noch im Laden ist. Das ist das erste Problem, man muss in einem Laden sein. Das zweite Problem ist, dass der Angreifer auch ein Händler sein muss. Wir haben also nur von einem Händler-Account zu einem anderen Händler-Konto gewechselt. Aber du musst als Händler angemeldet sein. Ich weiß nicht, wie gut organisiert die Kriminellen sind mit echten Geschäften. Aber die nächste Methode, die wir euch zeigen werden, hat diese Probleme nicht. Man muss also nicht im Laden sein und man muss nichts vorher konfiguriert haben. Das ist ein Angriff auf das Poseidon-Protokoll, das zwischen dem Terminal und dem Zahlungsanbieter benutzt wird. Der dritte Angriff also. In diesem Fall schauen wir uns die Initialisierung-Routine von Poseidon an. Das wird normalerweise vom Zahlungsanbieter gemacht, wenn du deinen Terminal vorkonfiguriert bekommst. Also er hat diese ganzen Konfigurierungsschritte gemacht, damit dein Terminal mit deinem Bankkonto spricht. Das Terminal sind eine Poseidon-Initialisierung-Routine an das Backend. Das Backend holt sich die Konfiguration für dieses Terminal ab, schickt es an das Terminal und verschlüsselt ist dabei, symmetrisch verschlüsselt mit einem Schlüssel, den nur die beiden haben. Soweit so gut, das ist das Protokoll mit dem im Fonds geteilten Schlüssel. Aber genau dieser Schlüssel wird nicht in einem Terminal verwendet, sondern in vielen, vielen Terminals. Also alles, was die Authentifizierung noch bringt, ist der Benutzername. Und dieser Benutzername ist öffentlich. Die Idee ist also, dass wir unser eigenes Terminal nehmen, das wir von eBay bekommen haben. Wir haben drei davon für sieben Euro bekommen, inklusive Versand. Und unser Terminal so konfigurieren, dass es einfach irgendein Terminal irgendwo in Bonn der Maus Shop ist. Und an dieser Stelle muss ich mich fast entschuldigen, weil in diesem Heck gar kein Hacking stattfindet. Es ist einfach nur kaputt. Ihr werdet es sehen. Man braucht nur ein paar Parameter, um dein Terminal als ein anderes zu konfigurieren. Und zuerst ist das Service Management Password, das sollten eigentlich nur Service Techniker haben. Das Zweite ist die Terminal-ID. Und das Dritte ist die Nummer des Ports am Backend, das Terminal von deinem Opfer verweitet. Woher kriegen wir das erste? Das kann man einfach googeln. Das findet man im Internet in irgendwelchen internen Dokumenten. Das ist das Sable für alle Zahnungsterminals eines Zahnungsanbieters. Also komplett unabhängig von Modellen haben alle Modelle das Sable Password. Die Terminal-ID findet ihr natürlich auf jeder Quittung. Und man kann sie aber auch raten, weil sie inkrementell sind. Und für das letzte gibt es 100 verschiedene Möglichkeiten. Und schau einfach nach, welcher der Ports mit einer Erfolgsnachricht antwortet. Jetzt haben wir also alle drei. Lass uns mal vormachen. Für diese Demo müssen wir nicht im selben Netzwerk sein, wie wir schon gesagt haben. Das ist das Terminal hier für den CCC, das wir euch gerade gezeigt haben. Wir werden das einfach vom Netzwerk trennen. Hier haben wir ein Terminal, ohne eine ID. Wir haben das gerade wieder auf den Fabrikszustand zurückgesetzt. So würde man das auch von Ebay bekommen, wenn der Verkäufer seine Arbeit sauber gemacht hat und auf die Fabrikeinstellung zurückgesetzt hat. Das Service Password. Wir haben die Terminal-ID eingegeben. Der Port am Backhand ist schon korrekt. Und jetzt geben wir eine erweiterte Diagnose aus, um die neue Konfiguration zu bekommen. Und was kannst du tun, wenn du hier mal registriert bist? Was kannst du dem Opfer antun? Wir werden das gleich vorführen mit dem Prepaid-Guthaben. Wenn also das Opfer dieses Feature aktiviert haben, dann werden wir das auch aktiviert haben, weil wir das Terminal des Opfers sind. Also wir können einfach so viele Prepaid-Guthaben ausdrücken, wie wir wollen und das dann zu tatsächlichem Geld konvertieren, indem wir Premiumberufnummern anrufen oder so, vielleicht 50 Euro von O2 wird sein natürlich. Ba! Benutzt jemand O2-Prepaid? Nein. Schade. Zeigen wir es der Kamera. Irgendjemand wird das schon jetzt nicht finden. Es ist doch O2. Wir werden auch gleich zeigen den zweiten Weg Geld zu bekommen. Und das ist noch einfacher. Wir werden uns Geld überweisen. Das ist eine Funktion Rückerstattung. Und sie ist komplett unabhängig von vorherigen Überweisungen. Und wir können das mit jedem Bankkonto machen. 100, 100 hört sich gut an. Können wir wieder zurück zu den Folien gehen, bitte? Okay, das ging ziemlich schnell. Wollen wir das zusammenfassen, was gerade passiert ist? Irgendwo in Deutschland ist ein Terminal mit einer bestimmten Terminal ID. Und diese Terminal ID sagt, dieses Terminal ID gehört zu einem bestimmten Händler, einem Händlerkonto. Jedes Geld, das in diesen Terminal geht, geht zu dem Händlerkonto. Und alles, was mit dem Terminal bezahlt wird, das wird über dieses Konto bezahlt. Das zweite Terminal, das wir haben, haben wir auf die genau selbe Terminal ID gesetzt. Es hat einen kryptografischen Prozess. Es registriert sich am Backend. Das lässt sich seine, die originale ID. Aber der Händler kann weiterhin tun, was er will. Das erste Terminal ist eine geklonte Terminal. Das kann genau dieselben Sachen tun. Wenn man hier Geld einzahlt, kriegt das der Händler. Wenn wir ein Refund, eine Rückerstattung machen, dann kommt das Geld natürlich raus aus dem Konto, dieses Händler aus diesem Händlerkonto. Ziemlich eindeutig. Das sind drei Nummern, die wir relativ leicht finden konnten, basierend auf dem Terminal, was wir bei eBay gekauft haben. Was ist sozusagen große Betrug, denn jemand hier machen könnte. Erstens, man muss das nicht manuell machen. Das geht über das Protokoll ZVT, das kann man auch skripten. Und wenn man jetzt viele Terminal IDs hätte, die richtig sind, dann geht das. Und die werden inkrementell zugewiesen werden. Das heißt, wenn du eine Terminal ID kennst, dann kennst du weitere hunderte von tausenden IDs, natürlich einfach durch Inkrementierung verstellen. Wenn du registrierst deinen Terminal über ZVT mit einer ID des Händlers nach dem anderen, machst das zehn von tausend Mal, schickst Rückerstatterungen an jedes einzelne Konto in Deutschland. Durch das Poseidomprotokoll funktioniert das. Wahrscheinlich geht das aber auch in anderen Kontos. Das ist mehr oder weniger ein Art Dialekt eines internationalen Halbstandards. Das wirkt wahrscheinlich in anderen, das arbeitet in anderen Ländern wahrscheinlich auch. Das heißt, man könnte hier eine sehr große Betrugsmasche drauf bauen. Es ist zum Glück bis jetzt nicht passiert und es gibt immer noch Zeit, das zu reparieren. Das müssen die Banken dann machen. Also wenn wir das mal so zusammenfassen bei den drei Angriffen. Wir haben zwei Protokolle in Deutschland, die für Bezahlung genutzt werden. Beide sind total kaputt. Wir haben ein Projekt, Kunden im Laden. Den kann man sozusagen das Geld klauen, wenn man ihnen die Magnetkarte klaut. Und es ist für die Händlerkonten wichtig. Wir haben das über Torf gemacht, funktioniert hervorragend. Also das Torprotokoll. Und zufälligerweise, diese Protokolle wurden unabhängig voneinander designt. Aber der Kerngrund für die Fehler sind dasselbe. Denn sie haben den Shared-Key, den Secret-Key auf den Terminals verwendet. Und da alle den selben Signing-Key haben. Und deswegen können wir ein Terminal als ein anderes sich ausgeben lassen. Und die Authentifizierung läuft exakt, weil überall der gleiche Key drin ist. Es ist sicher, solange jedes Terminal von einem guten Menschen verwendet wird. Aber das ist natürlich eine unsinnige Annahme. Diese Protokolle ist total kaputt. Und wir müssten eigentlich hier gar keine weitere Forschung gemacht haben. Wir hätten aufhören können. Aber wir wollten diese Schlüssel haben. Und deswegen ist Dexter hier mit uns. Und der hat das Hardware-Hacking gemacht. Und er wird uns jetzt erzählen, was er gemacht hat. Also, dann mal los. Lass uns über das HSM reden. Das HSM-Modul, das haben wir untersucht. Das ist das Modul, wo alle besonderen Dinge passieren. Das ist das Bild, so sieht das HSM-Modul aus. Und das ist eine Smart-Karte auf Koks. Es ist ein Keypad dran. Und es abwirtschaftet alle diese wichtigen Daten. Du möchtest natürlich, dass diese ganzen Bereiche gut geschützt sind. Damit es gibt mehrere Schutzmechanismen. Zum Beispiel, eine Besonderheit ist, das ist der Static SD-ROM. Da sind die Secret Keys drin. Und da gibt es keine Backups. Wenn die Batterie ausgeht, dann sind die Keys weg. Es ist natürlich relativ leicht, ein Backup zu löschen. Um das Modul sind ein paar Schalter. Und diese Schalter, wenn ein Angreifer das Ding aufmacht, werden diese Schalter ausgelöst. Dann funktioniert es nicht mehr. Aber das kann man natürlich besiegen. Es gibt noch bessere Schutzmechanismen als diesen. Es gibt eine Art Gitternetz unter dieser Kappe. Das ist so aus Metall. So eine Art Gitterfolie. Und die ist sozusagen im Häusel gelegt. Innerhalb der Kappe dieses Moduls. Und wenn man da ein Loch reinbohrt oder reinschneidet in die Kappe, dann wird sozusagen dieser Mesh zerschnitten. Und das löst die Sicherheitsmodul aus. Wir haben noch eine mechanische Schwäche gefunden in diesen Terminals. Wenn man genau hinschaut, dann auf die Bilder, sieht man in den Ecken kleine Bögen. Dort ist der Mesh sozusagen dort mit Strom versorgt von dem PCB. Dort ist es direkt zu den Schaltkreisen, die sozusagen die Korrektheit des Stromfussers das Mesh messen verbunden. Und Smart Cards haben natürlich sowas nicht. Und das ist immer eingeschaltet. Das Problem ist, es gibt nur diese Verbindung, diesen vier Ecken, nicht an den Seiten. Das heißt, an den Seiten kommt man in das HSM ran mit irgendwelchen metallischen Dingen, wie einem Bohrer oder so, ohne. Und das Ganze ist festgeklebt, also mit Kleber. Und dieser Kleber macht auch einen kleinen Zwischenraum, weil der Platz braucht. Wie kommen wir denn da hin? Kann man das da irgendwas drunterschieben und so das Mesh besiegen? Und wir haben etwas gefunden von einem Arzt. Das ist eine ganz dünne Pinzette. Und damit sind wir unter die Kappe gekommen, unter den Mesh, direkt zu dem HSM. Und wir haben noch ein bisschen experimentiert. Und da gibt es sozusagen einen bestimmten Punkt, nämlich die Stromversorgung, die haben wir kurz geschlossen. Und dann ist diese Temper Protection, dann kann man das Mesh besiedeln und passiert nichts. Dann sehen wir die Erdung auf der linken Seite. Und das ist unser Kurzschluss, den wir erzeugt haben. Damit, das ist der Schutz durch das Mesh. Und wir haben einfach einen Lüttekolben benutzt, um das zu unterbrechen. Das war sehr schwierig. Und dann bist du sozusagen, hast du physischen Access zu dem Null, zu dem S-Ram, zu dem J-Tag. Und wenn der J-Tag nicht arbeitet, dann kommt man auch an das Flasch ran. So haben wir das das erste Mal gemacht. Also, da haben wir den J-Tag angeschlossen, an das HSM. Und es funktioniert weiterhin, es ist nicht kaputt. Und funktioniert immer noch irgendwie. Und jetzt kannst du alle möglichen Sachen machen. Du kannst Debuggen, du kannst Experimente machen, Reverse-Engineering. Oder du kannst den Ramm auslesen und den S-Ram auslesen und die Secrets auslesen. Wir haben für Experimente gemacht, um das HSM verwenden, als eine Art Oracle verwendet. Wir müssen den Authentication Code für den Pean Entry-Screen erkennen. Diesen falschen Screen, den wir gezeigt haben, habt ihr die Bilder gesehen, die hier geschützt werden. Was hat das gemacht? Der Text-String, den wir signieren möchten, und an den S-Ram S-Sect wird. Das ist der Wert 41, 41. Und du gibst einfach einen Wert, an der nicht stimmt. Das ist nicht wichtig. Das ist einfach rein. Und dann wird das HSM das vergleichen. Das sagt nicht Fehler. Das passt nicht, aber kein Problem. Und wir ziehen nun einfach den Ramm aus. Und da ist ja der korrekte Weg, der ja da verglichen wurde. Tja, das war dann... Das ist dann das nicht so sichere Hardware-Sicherheitsmodul. Das gebe ich es dann mal an Karsten zurück. Danke. Also ein bisschen Hardware-Hacking-Spaß. Das war nicht wirklich nötig, aber wir dachten, aber es ist wichtig, um zu zeigen, dass das möglich ist, dass man mehrere Möglichkeiten hat, das auszunutzen. Im nächsten werden wir zeigen, was geändert werden muss, damit diese Protokolle sicher werden. Und was nicht passieren darf, ist, dass dann wieder eine Art Secret Key in einem unsicheren Modulist, der an 100.000 von Kunden geht. Das wäre Security, bei Security, das funktioniert einfach nicht. Wir brauchen einen besseren Ansatz. Was brauchen wir? Das erste Mal, warum sind diese beiden Protokolle so furchtbar kaputt? Wie wir früher gesagt haben, beide haben das Problem, dass Keys über ganz viele Geräte verteilt werden. Die Terminals, manche davon sind sicher. Manche sind sehr, sehr unsicher, wie dieses eine Modul, was wir ganz gerade angeschaut haben. Der schwächste Verbindungsglat macht dann die Sicherheit von allen Systemen aus. Diese systemweiten Keys haben unterschiedliche Bedeutung in beiden Protokollen. In ZFET ist eine MAC, eine Message Signature, deren Verbindung relativ sicher ist, solange man für Public Key Verschlüsselung verwendet. Wenn nur einer unterzeichnen darf, dann funktioniert das, dann ist das sicher. In diesem Saal haben die Terminals, als sie designed worden, dann kannte man irgendwie Publikatürpfer nicht. Und sie benutzen symmetrische Signaturen. Und die sind in 770.000 Kopien in Deutschland verteilt. Das vergrößert das Problem und wird noch vergrößert durch den Einsatz in beschissenen HSM, die sogar man einfach von Timing-Side-Channel-Attacks gegenüber vorwundbar sind. Vor Sidon, auf dieser Seite, geht es nicht um kriptografisch signatieren, sondern um Authentifizierung. Schauen wir uns das an wie Online Banking. Beides ist ja so eine Art Online Banking-Locking zu dem Händlerkonto. Und wenn diese alle diese simplen Benutzernahmen verwenden und jeder benutzt dasselbe Passwort, bzw. den kriptografischen Key, das kann unmöglich sicher sein. Das kann nicht repariert werden, solange jeder dasselbe Zertifikat verwendet, kann das nicht sicher werden. In beiden Fällen brauchen wir mehr individuelle Schlüssel eindeutig zugewiesen, zumindest mittelfristig. Glücklicherweise haben beide Protokolle eine Grundlage, dass man neue Keys an die Terme verschicken kann. So könnte man jedem Termen einen neuen Key geben, einen unterschiedlichen. Das heißt, die Zukunft sollte klar sein. Das heißt klar, man muss das Backend anpassen, die Systeme im Hintergrund. Aber es ist schon klar, wie wir aus dieser Katastrophe rauskommen. Jeder kriegt seinen anderen Key, jedes Termen bekommt seinen. Ganz langfristig, wenn die Leute die HSM Chips angreifen, individuell angreifen und dann sozusagen einen einzelnen Händler versuchen zu betrügen, dann müssen wir sozusagen die Möglichkeit, skalierbaren Betrug zu machen gegen 100.000 Ziele, das wäre dann schon mal verhindert. Langfristig bessere Protokolle, kurzfristig individuelle Keys. In jedem dieser Keys, ganz kurzfristig, bestimmte Funktionen abschalten, die man einfach nicht braucht. Wie viele Shops müssen irgendwelche Informationen über SIM Karten ausdrucken müssen. Wie viele Kunden müssen wirklich die Rückerstattungen machen. Das könnte man abschalten. Gleich eben in ZNet WVT. Wie viele Händler möchten, brauchen ein neu konfigurbares Termel über das Netzwerk ohne jede Bestätigung. Vielleicht eine kleine Nachricht, ist das okay? Das könnte vielleicht schon helfen, weil dann muss jemand physisch anwesend sein. Abschalten, was man nicht braucht. Und komische Sachen erkennen. Dann erspare ich euch den Rest des Leises, den habt ihr schon gelesen. Eine bisschen internationalere Perspektive. Alles, was wir hier besprochen haben, ist basiert auf Deutschland und unsere Nachbarländer. Wir vermuten, dass sehr viele Probleme in den meisten anderen Ländern auch existieren. Die ZVT Alternative heißt HPI. Das ist erheblich neuer. Das hat immer noch keine Verschlüsselung. Das wurde designed in 2003. Das war ein Zahlungsprotokoll. Wenn das jemand näher kennt, schickt mir eine E-Mail. Sie haben auf jeden Fall eine intelligente Sache gemacht. Sie haben Funktionalität, die niemand braucht, rausgeworfen. Die Fernverwaltung ist nicht drin, das Terminus. Die wenigen Verwendungen von HPI, die wir in Deutschland gefunden haben, haben aber diese Funktionalen wieder genauer eingemacht als Erweiterungen. Das heißt, der Hersteller scheint es sehr nützlich zu finden, diese Fernverwaltung zu haben. Und wenn das Protokoll das nicht kann, dann addieren sie es eben einfach weiter. Wenn das Protokoll das nicht unterstützt, dann bauen sie es als Erweiterung nach. Natürlich hat die Forschungsgemeinschaft, natürlich muss die Forschungsgemeinschaft das noch überprüfen in anderen Ländern. Und vielleicht mit ein bisschen Why Shark, kann man das normalerweise leicht tun. Ähnliches geht für Poseidon, wie ich gerade gesagt habe, ist das mal ein Dialekt eines Isoständers, der als erstes von Mastercard und Visa kam. Das ist also das Standardprotokoll fast auf der ganzen Welt. Und in manchen Fällen haben wir Verschlüsselung gesehen, aber das ist egal. Ändert euch daran, dass der Angriff durch einen vollständigen Autorisierungszyklus geht. Alles macht es korrekt, aber jeder hat denselben Schlüssel. Was wir jetzt noch brauchen, ist ein Protokoll, mit dem man Schlüssel austauschen kann zwischen den zwischen einzelnen Terminals. Wenn jemand dazu mehr weiß, dann kommt er von zu. Aber soweit wir wissen, gibt es keine einzige Instanz, in der dieses Isoprotokoll wirklich mit einem sinnvollen Schlüsselverwaltungsprotokoll benutzt wird. Und damit zumindest die Grundlage hätte sicher sein zu können. Aber auch das übergeben wir wieder an die Forscher-Community, um das in den eigenen Ländern nachzuvollziehen. Als Schlussverhörung gibt es also zwei Protokolle, die in Deutschland für Zahnungen verwendet werden. Beide muss man als unsicher und überroht betrachten. Zum Glück können diese Dinge relativ schnell beruben werden. Das heißt, man kann diese Systeme verbessern, bevor es echten Betrug gibt. Und wir als Forscher sollten das tun. Aber wir als Kunden sollten niemand mehr glauben, wenn er sagt, ja, du hast wahrscheinlich dem Angreifer deine Pinzei gegeben, deswegen daher kommt diese betrügerische Zahnung in deinem Konto. Davon gab es schon mehrere Fälle in diesem Jahr in Deutschland. Und es ist an der Zeit, dass wir Ihnen zeigen, wer wirklich schuld ist an den Verbundbarkeiten und der Tatsache, dass wir schon so lange offen sind. Vielen Dank. Wir haben noch sieben Minuten für Fragen und Antworten. Vielen Dank noch mal unseren Sprechern für einen rein theoretischen Talk zu der Sicherheit. Wir haben fünf Minuten von Q&A. Und Mic 2 start. Wie macht man die Veröffentlichen? Macht ihr Full Disclosure? Wie viel Zeit habt ihr Ihnen gegeben, um darauf zu reagieren? Wir haben die normalen Responsible Disclosure Praktiken vollzogen. Das heißt, wir haben tatsächlich zuerst versucht, diese Sachen Leuten zu erklären, von denen wir dachten, dass sie sie beheben können. Das war vor ungefähr einem Monat. Und habt ihr schon irgendeine Reaktion gehört? Ich bin mir sicher, dass irgendjemand an einem Fix arbeitet, aber das würde natürlich niemand Biene erzählen. Und eine Frage aus dem Internet. Könnt ihr sagen, gibt es eine einfache Reparatur, wie eine neue Firmware Flaschen in Determinants? Kann man einfach nur eine neue Firmware Flaschen? Das ist alles gut. Gibt es einfach einen Fix? Du hast dir gezeigt, der Unterschied zu dieser Forschung und der Forschung von vor zwei Jahren ist, dass jetzt Probleme, die dem Protokoll sind. Das heißt, wir brauchen wirklich neue Protokolle, neue Versionen. Das sind also keine Probleme in der Implementierung. Muss man also alle Determinants austauschen? Ich glaube, die einzige Antwort ist, dass wir eine lange Reise, in der wir die systemweiten Schlüssel durch individuelle Schlüssel austauschen. Das wäre eine extreme Hilfe. In der Zwischenzeit sollten wir an besseren Protokollen arbeiten, damit wir uns nicht ständig wieder in dieser Situation finden. Mein klar, es dauert Jahre, um Protokolle zu verändern, aber diese Jahre sollten wir benutzen. Wie viele Versuche habt ihr gebraucht, um die, wie viele Systeme habt ihr kaputt gemacht, um die Kiste rauszukriegen, wie viele Versuche das gebraucht? Drei oder sowas. Das Erste war vielleicht, überraschenderweise ein sofortiger Erfolg. Wir haben den S-Ramen kommen, ohne ihn zu zerstören. Das Zweite haben wir kaputt gemacht und das Dritte hatte ein paar Probleme, aber die haben wir umgegangen. Wenn ihr dem Mesh vorbeigegilt, hat es am ersten Mal geklappt? Beim ersten Mal hat es funktioniert, mit ein bisschen Vorbereitung und dann eine Stunde tatsächliche Arbeit. Das Erste haben wir zerstört, damit wir überhaupt sehen konnten, wie es gebaut wird. Wir wussten, wie es funktioniert, weil wir schon vor ein paar Auseinander genommen hatten. Wir haben das erste Mal geklappt. Wir haben das erste Mal geklappt, weil wir schon vor ein paar Auseinander genommen hatten, weil sie kaputt waren und zu schauen, wie sie funktionieren und den Flash auszulesen. Könntet ihr beschreiben, was das Terminal tut, was passiert, was für eine Meldung kommt, wenn die Bank die Transaktion nicht behandelt? Ich glaube nicht, dass das Terminal irgendwas speichert. Es hat im Grunde keinen Zustand. Es bekommt einen Befehl, schaut in seiner Konfiguration nach, die Terminal-ID gibt es weiter an HSM, um eine Kind zu bekommen und vergisst dann alles. Wird diese Transaktion noch mal wiederholt später? Gute Frage. Das ist nicht Teil der Anrufe, die wir gezeigt haben, aber was passiert ist, dass du in einem Kassenschnitt machst und alle Transaktionen, die sich über den Tag angesammelt haben, werden an den Zahnungsdienstleister weitergeleitet und in diesem Augenblick gibt der Zahnungsanbieter alle Transaktionen weiter an die Bank. Dann wird die Zahnung nicht mehr umkehren. Also eine Zahnung des selben Tages, weil dann die Bank die Informationen schon bekommen hat und dann werden keine Informationen mehr auf dem Terminal gespeichert. Eine Frage. Wird die Kommunikation, die ihr genutzt habt, auch Replay-Angriffe machen? Könnte das ohne Terminal machen? Wenn ihr die Kommunikation zwischen Terminal und Prozessor aufgezeichnet habt? Klar, wir können Nachrichten einschleusen. Die meisten davon sind nicht mit einem Magnetstreifen geschützt. Ein Magnetstreifen kann man auslesen, ohne jedes Problem. Aber es ist einfach nützlich, ein Man in the Middle zu sein, dass jemand seine Karte in das Terminal stecken will und das würdest du nicht bekommen, wenn du einfach irgendwelche zufälligen Nachrichten stecken würdest. Es gibt jetzt niemanden mit einer Karte. Eine schnelle Frage? Ihr habt gesagt, es gibt die Möglichkeit, individuelle Keys an jedes Terminal zu verteilen. Das heißt, ihr habt noch ein identisches Terminal wie andere. Wenn der Payment Prozessor individuell Keys verteilt und es gibt zwei Terminals, wird derselben als die, was passiert? Ja, gute Frage. Wenn der Betrüger erst alle Terminals übernimmt und dann die Schüsse sendet, wird das nicht funktionieren. Es muss schneller sein, als die Bösen. Danke noch einmal euch drehen.