Mit dem Getränkeautomaten in die Cloud
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 102 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/43227 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
Chaos Communication Camp 201960 / 102
1
6
8
14
17
18
19
20
25
27
28
29
30
34
35
36
39
41
47
52
53
54
55
58
59
63
65
67
71
79
81
84
85
86
87
91
92
93
94
95
96
97
98
99
100
101
00:00
Point cloudAutomatonPerspective (visual)Systems <München>Smart cardStrategy gamePICA <Bibliotheksinformationssystem>JSONXMLLecture/Conference
01:03
Point cloudAutomatonActive contour modelMeeting/InterviewComputer animation
01:34
Systems <München>Smart cardTerminal equipmentGraphics tabletComputer animation
02:03
Port scannerVirtual memoryPoint cloudSystems <München>InformationUpdateAutomatonSmart cardDisplayHacker (term)Computer animation
03:43
Port scannerMainframe computerService (economics)Version <Informatik>MicrosoftNetBIOSWindows MobileLeadWINDOWS <Programm>Client (computing)Buffer overflowAuthenticationCodeServer (computing)Crash (computing)Patch (Unix)InformationVerbindungsloser DienstDesktopSoftwareVersion <Informatik>Windows CE
04:32
Server (computing)HTTPVector graphicsDatabaseConfiguration spaceAutomatonSystems <München>Droop speed controlSmart cardWeb browserComputer animation
05:33
Proxy serverServer (computing)APIGateway (telecommunications)Dynamic Host Configuration ProtocolHTTPProxy serverLogarithmJSONComputer animation
06:05
World Wide WebSSLTransport Layer SecurityCiphertextAlgorithmServer (computing)YES <Computer>Flow control (data)OpenSSLScientific modellingLösung <Mathematik>8 (number)Proxy serverSource codeComputer animation
07:33
Computer hardwareWhiteboardProxy serverFlow control (data)LaptopPublic key certificate
08:16
XMLVersion <Informatik>Server (computing)Interface (computing)Computing platformMittelungsverfahrenDroop speed controlAbruf <Informatik>VERKAUF <Programm>LengthProcess (computing)AuthenticationBALL <Programm>InformationConfiguration spaceAutomatonMetadataTerminal equipmentBeat (acoustics)Server (computing)SummationZusammenhang <Mathematik>Interface (computing)Negative numberService (economics)Computer animation
11:50
AuthenticationLaptopAddierwerkSmart card
12:30
System administratorAbsolute valueDatabaseProgram flowchart
13:28
SoftwareAuthenticationCryptanalysisLecture/ConferenceMeeting/Interview
13:52
Statische AnalyseWINDOWS <Programm>DebuggerCarriagewayAdvanced Encryption StandardCodeTOUR <Programm>ClefCarriagewayBlock (periodic table)Operating systemAsynchronous Transfer ModeLogical constantWINDOWS <Programm>SoftwareVapor barrierEncryptionRandReverse engineeringVariable (mathematics)DeciphermentRoundingDatabaseDatabaseMikroarchitekturHacker (term)BlogLineare TransformationClefDisassemblerAdvanced Encryption StandardCodeMilitary operationStatische AnalyseDebugger
18:49
ClefNullNumberComputer animation
19:15
9 (number)Lineare TransformationBlock (periodic table)ClefNullDatabaseProcess (computing)Office <Programm>DiagramProgram flowchart
20:20
9 (number)Computer wormWorld Wide WebAuthenticationMoment (mathematics)State of matterSource codeComputer animation
20:46
Server (computing)USB <Schnittstelle>Computer fileAsynchronous Transfer ModeMobile appOccamUSB-StickUpdateParsingLecture/Conference
22:09
Generating functionMoment (mathematics)DatabaseUSB-Stick
23:02
Version <Informatik>SoftwareComputer animation
23:33
OLEDemoscenePOWER <Computerarchitektur>Network switching subsystemWhiteboardRAMMenu (computing)World Wide WebERNA <Programm>SummationString (computer science)Hard disk drivePatch (Unix)SummationComputer fileComputer data loggingFunction (mathematics)Patch (Unix)SoftwareComputer animation
26:11
CodeUSB <Schnittstelle>Server (computing)AuthenticationAdvanced Encryption StandardAgreeablenessMittelungsverfahrenLebendigkeit <Informatik>Order (biology)Computer animation
26:35
TwitterBlogSmart cardSlide ruleMittelungsverfahrenPressureAutomatonÖko <Programm>Token ringTOUR <Programm>Meeting/InterviewComputer animationLecture/Conference
29:08
Block (periodic table)Ende <Graphentheorie>InternetMeeting/Interview
30:08
TwitterBlogTranslation (relic)Heat waveLecture/ConferenceComputer animation
30:33
Finite element methodJSONComputer animation
Transcript: German(auto-generated)
00:16
Hier im CCC-Umfeld beschäftigen wir uns ja über die Jahre immer wieder mit ungefähr den gleichen Themen,
00:21
aber immer wieder aus einer etwas anderen Perspektive oder auf einem etwas höheren Niveau. Und gerade das Thema elektronische Bezahlsysteme bietet sehr viel Potenzial zum Lachen und zum Weinen. In der Vergangenheit gab es zum Beispiel beim 29C3 schon mal einen Vortrag über Mensa-Karten und wie man es schafft, dass da plötzlich Tausende von Euros drauf spawnen. Und vor zwei Jahren gab es beim 34C3 auch den Ladesäulen-Talk
00:43
und auch der ist thematisch so ein bisschen verwandt mit dem, was ihr jetzt hört. Genau, Janis Streib ist unser Speaker. Er ist Student und erzählt euch jetzt live von der Front, wie das aussieht mit diesen elektronischen Bezahlsystemen. Und deswegen bitte ich euch um einen ganz herzlichen Applaus für Janis und wünsche euch ganz viel Spaß mit ihm.
01:09
Ja, wer in einer Hochschule studiert oder in einem großen Unternehmen arbeitet, kennt das sicher. Es gibt Automaten und man kann, wenn man Durst oder Hunger hat, sich an solchen Automaten
01:21
einen mehr oder weniger gesunden Snack oder Getränk kaufen und diesen dann mit einem, mit der Studentenausweis oder mit dem Mitarbeiterausweis bezahlen. Diese Systeme begegnen dann einen häufig dann auch in der Kantine oder in der Mensa oder in der Cafeteria.
01:41
Und man kann, man lädt diese Karten dann an solchen Aufladeterminals wieder auf, also aufwärtern. Manchmal gibt es dann auch noch solche Statusterminals. Auf solchen Terminals kann man dann sehen, wie viel Geld man auf der Karte hat und was man in letzter Zeit so gebucht hat.
02:04
Die Architektur bei diesen Systemen sieht häufig irgendwie so aus. Wir haben unsere Vending-Maschinen. In dem Shangho nennt man diese häufig auch Vending-Maschinen-Controller. Dieser kommuniziert über MDB, das ist ein serielles Protokoll, mit dem Vending-Reader.
02:21
Dieser Vending-Reader wickelt die Bezahlung ab und kommuniziert dabei mit einem Backend-Object TPS, wo dann die Buchungen durchgeführt werden, also bei diesen cloudbasierten Systemen. So ein Bezahlvorgang sieht dann ungefähr so aus.
02:42
Man hält die Karte an den Automaten, an den Vending-Reader. Der Vending-Reader holt Informationen über den Kunden, wie zum Beispiel, was ist der Kartenstand. Manchmal auch solche Dinge wie Date of Birth, also Geburtstag, wenn man die alkoholische Getränke verkauft. Der Nutzer wählt dann das Produkt aus, der Preis wird nachgeschlagen
03:05
und schließlich erfolgt der Verkaufsprozess mit dem Update des Kontostands in der Cloud. Der Nutzer erhält letztlich das Produkt. Wie bin ich dazu gekommen? Eigentlich sollte ich für solche Waschmaschinen-Abwärter eine Integration für ein neues Kartensystem bauen.
03:27
Das ist dieses Gerät mit dem roten Feld und dem Zwei-Zeilen-Display unten links. Aber wie das nun so ist als Hacker, wenn man ein unbekanntes Gerät mit Ethernet-Anschluss vor sich liegen hat,
03:41
man macht erst mal einen Portscan. Und da hatte ich dann schon so eine erste Überraschung erlebt. Da scheint nämlich ein VNC-Server auf den Kisten zu laufen. Das ist offenbar ein Real VNC. Und wenn wir da mal in der export.db nachschauen, finden wir unter anderem einen Null-Authentication-Bypass,
04:04
der womöglich auf die Version passen könnte. Na ja, ausprobiert. Zack, interessant läuft ein Windows CE drauf. Wir können hier wunderbar an diesem Desktop auch ein wenig explorieren. Es gibt einen vollwertigen Explorer und wir können uns da mal ein bisschen umschauen.
04:24
Genauso können wir der Software beim Arbeiten zuschauen. Wir sehen, wie die heißt offensichtlich CS Core. Na ja, somit ergibt sich für unser System folgendes Bild. Wir haben durch das Explorieren, habe ich bereits gefunden,
04:40
sind dann offensichtlich zwei Datenbanken auf diesem Vending-Reader. Zum einen die Static.db für statische Konfiguration. Zum anderen die Work.db. Da werden wohl temporäre Arbeitsdaten abgespeichert. Diese Datenbanken haben relativ wenig erkennbare Struktur von außen. Es ist also davon auszugehen, dass die in irgendeiner Form verschlüsselt sind.
05:01
Sie lassen sich auch nicht mit irgendeinem gängigen Datenbank-Browser öffnen. Gut, spannend. Meine Neugier war somit geweckt. Wir haben hier also noch den VNC als Vektor. Und ich habe mich daraufhin weiter beschäftigt,
05:20
allerdings ausschließlich mit dem Vending-Reader, weder mit dem Kartensystem, was dahinter verwendet wird, was meistens dann Myfair oder Deathfire ist, noch mit dem Vending-Machine-Controller, also dem Getränkeautomaten. Ich habe also begonnen, eine oberflächliche Analyse durchzuführen. Es wäre nämlich eigentlich auch erstmal offensichtlich spannend,
05:40
was denn auf diesem HTTPS-Kanal so läuft. Klar, einfaches Setup. Wir machen ein Man-In-The-Middle-Gateway. Dahin läuft ein Reverse-Proxy. Wir loggen die Requests mit und schicken die Daten weiter an den Backend-Server.
06:02
Um ein bisschen zu schauen, was wir dafür für Anforderungen brauchen, lohnt es sich einmal, mit Wireshark mitzuschneiden, was denn überhaupt gesprochen wird. Und wer jetzt schon mit scharfem Auge hinschauen erkennt, das ist wohl ein SSLv2-Kleintello. Und wir bekommen außerdem die unterstützte Cipher-Liste, also die unterstützte Liste der kryptographischen Verfahren,
06:23
die für diesen Handshake genutzt werden können. Wenn man sich die mal nochmal genauer anschaut, dann stellt man auch fest, die sind schon ganz schön antiquiert. Unter anderem finde ich es sehr exotisch, SSLv2-RC4-Export40-MD5.
06:43
Das habe ich sonst auch noch nie in freier Wildbahn gesehen. Damit haben wir aber ein kleines Problem für unseren Mittenproxy. Denn es gibt erstaunlich wenige Implementationen, die aktuell noch SSLv2 und RC4 oder Triple-Desk können.
07:01
Und weil ich mir nicht jetzt umständlich ein altes OpenSSL mit sonstigen Paketen zusammenblinken wollte, habe ich mich ein wenig umgeschaut, wie man das dann auch einfach hinkriegen könnte. Und die Lösung war Java 8. Tatsächlich kann man, wenn man Java 8 lang genug drauf tritt,
07:20
noch SSLv2-Klein-Tello und RC4-Triple-Desk anmachen. Also eigenen Reverseproxy geschrieben und ausprobiert. Eigentlich wollte ich in diesem Video einfach nur ausprobieren, funktioniert der Handshake. Wir sehen hier jetzt mein Test-Setup.
07:41
Mein Laptop dient als Proxy. Und zack, da haben wir schon Request. Das war so ein bisschen unerwartet, weil ich eigentlich noch nicht das gefälschte Zertifikat auf dem System platziert habe vorhin. Heißt, offensichtlich passiert hier keinerlei Zertifikatverifizierung.
08:04
Cool, brauchen wir weniger Arbeit. Fette Lücke gefunden. Können wir uns mal die APIs genauer anschauen. Gerade eben schon in dem Video gesehen hat, es gibt zwei API Endpoints. Der erste API Endpoint ist die sogenannte Heartbeat API.
08:21
Die wird für alles benutzt, was mit der Konfiguration der Vending-Reader im Zusammenhang steht. Zum Beispiel stellt sie die Static-DB bereit für die Geräte, also sprich die Konfiguration. Und wird im regelmäßigen Intervall und auch beim Start des Vending-Readers einmal gepollt.
08:41
Das Ganze ist eine XML-API und sieht ungefähr so aus, das ist jetzt ein Request des Vending-Readers. Der Vending-Reader schickt ein bisschen Metadaten über sich, was das für ein Gerät ist. Und schickt außerdem eine Scharprüf-Summe an den Server von seiner Static-DB. Ist noch keine Static-DB auf dem Gerät,
09:02
also ist es ein neues Gerät frisch aus dem Karton, schickt er einfach eine leere Prüf-Summe. Und ich habe mir den Request eine Weile angeschaut und festgestellt, irgendwie gibt es da nicht so eine richtige Authentifikation. Das Einzige, was sich wohl zwischen verschiedenen Vending-Readern in diesem Request unterscheiden scheint, ist diese lustige Plattform-ID.
09:24
Und irgendwoher kann man die doch bekannt formen. Ja, richtig, wird beim Boot angezeigt. Also cool, das heißt, über diese Hard-Bit-API können wir schon Static-DB beantragen von beliebigen Geräten und wir müssen sie nur rebooten, um an diese ID zu kommen.
09:42
Praktisch sind zwar noch verschlüsselt, aber vielleicht können wir damit ja später noch etwas anfangen. Die zweite API, oder nein, erst mal hier die Übersicht. Wir sehen also schon, wir haben diesen Provisionierungs-Pfad gebrochen und offensichtlich auch die komplette Komplikation im Backend,
10:00
die kann man komplett abfangen, ohne dass man irgendwie den Vending-Reader manipulieren muss. Dann gibt es die zweite API, das ist die API X. Ich habe keine Ahnung, für was das X stehen soll. Auf jeden Fall dient diese Schnittstelle zur Interaktion mit den Nutzerkonten.
10:22
Zum Beispiel werden darüber die ganzen Verkaufsprozesse geregelt, da gibt es drei Stück. Das erste ist Vent, also ich kaufe etwas. Das zweite ist Negative Vent, also ein negativer Kauf. Das wird verwendet, wenn man zum Beispiel Pfannflaschen an einem Pfannflaschenautomaten zurückgibt. Dann gibt es Revalue, das ist das Aufladen
10:41
der Karte an einem Terminal gegen Bargeld oder andere Bezahlungsmittel. Da ist tatsächlich eine Authentifikation drin. Diese wird aus der Static DB gelesen und ist tatsächlich pro Gerät verschieden.
11:01
Als weiteren Dienst auch zur Interaktion mit dem Kontoverlauf, so kann man zum Beispiel den Kontoverlauf des Nutzers abrufen. Interessanterweise wird auch der Kontoverlauf darüber angelegt, allerdings über einen separaten Request. Das bedeutet, wenn eine normale Zahlung erfolgt,
11:21
passiert erstmal kein Eintrag in der Kontohistorie. Das passiert in einem separaten Request und muss nicht zwangsläufig was mit der Zahlung zu tun haben, wie sich später herausgestellt hat. Außerdem, für die Freunde der obskuren API-Interfaces handelt es sich um eine CSV-API. Da werden comma-separierte Werte
11:41
geschickt, die sich pro Anfangswert in der Länge unterscheiden und im Format. Mit den Informationen, die wir nun haben, sprich, da wir aus Mende-Mittelangriff auch die Authentifikation haben können, können wir nun einfach mit meinem Laptop
12:02
ein Revalue ausführen. Man sieht, 100 Euro mehr auf dem Konto, problemlos, auch ohne dass der Nutzer irgendetwas tun musste. Ich musste nur einmal die Karten-ID herausfinden oder die Wallet-ID und kann dann mit
12:21
einem API-Token in Freibuchungen durchführen. Praktisch. Hier sieht man einmal einen Auszug aus dem Administrationsinterface, was die Administratoren des Systems, also der Betreiber des Systems sehen kann.
12:41
Das ist jetzt aus einem anderen Zeitpunkt des Kontos, also nicht das eben von der Buchung, sondern das ist ein anderer Zeitpunkt. Wir sehen unten in der Mitte, ganz unten links, sehen wir den Kontostand, das sind hier 722,76. Und oben sehen wir die Kontohistorie mit einer Wertstellung vom 13.06.2020
13:03
und es wurde irgendwie ein Betrag von 2000 Euro gebucht. Das ist ein nettes Beispiel, wo man sieht, dass offensichtlich die Kontohistorie in Keinselalverbindung mit tatsächlich dem gebuchten Kontowert steht. Also sprich, man könnte zum Beispiel, wer jetzt Böses im Kopf hat,
13:21
abitäre Buchungen einfach in der History verstecken. Gut, nun wäre es eigentlich irgendwie noch spannend, wenn man versteht, wie diese Datenbanken funktionieren. Denn noch ist es uns nur möglich, Angriffe zu fahren, wenn wir ursprünglich ein Geheimnis, also
13:41
die Authentifikation gegen die API durch ein Mende-Mittel-Angriff und durch Zugang zu einem solchen Wending wieder erschnüffelt haben. Dazu muss man jetzt quasi diese Software ein bisschen tiefer analysieren und mal mit einem beliebigen Reverse-Engineer-Tool genauer anschauen.
14:02
Dabei hat man ein bisschen das Problem, dass das Ganze eine Windows PE CE6 Arm executable ist. Das ist ein sehr exotisches Format, zu dem es quasi keine Debugger gibt und auch nur relativ wenige Disassembler können das korrekt darstellen. Ida kann das. Aber ich muss
14:20
mich wohl vorerst mit einer statischen Analyse zufrieden geben. Also ich kann nicht beobachten, wie die Datenbank entschlüsselt wird. Sondern ich kann nur anschauen oder versuchen zu identifizieren, wie das funktioniert. Dazu geht es nun ein sehr praktisches Tool, das nennt sich Findgrip. Das habe ich einfach mal auf die Bannerie geworfen. Das Findgrip sucht
14:42
in Banneries nach Spuren von bestimmten Verschlussungsverfahren. Zum Beispiel sucht es hauptsächlich nach Konstanten, die in einer S-Box, eine inverse S-Box gefunden sind. Das bedeutet doch sehr stark hin, dass hier wohl ein AES-Wendel enthüllt.
15:01
Wenn man jetzt schaut, wo diese Werte benutzt werden, kann man dann herausfinden, wo diese Verschlüsselung stattfindet. Allerdings sollten wir dazu etwas verstehen, wie AES funktioniert. Dazu ein kurzer Disclaimer. Auch wenn AES relativ
15:21
einfach aussieht und es vielleicht auch ganz lustig wäre, das zu bauen. Es ist eher eine schlechte Idee, das in Production Code einzusetzen. Nur so ein Hinweis. Aber AES ist prinzipiell relativ einfach. Das ist jetzt natürlich eine starke Vereinfachung. Aber vom Prinzip besteht
15:41
AES nur daraus, dass wir unseren Key nehmen, daraus sehr viele Keys machen und diesen in mehreren Runden auf unseren zu verschlüsselten Block XORen und zwischendurch immer wieder mal diese linearen Transformationen durchführen. Also Subbytes, Shift-Draws und Mix-Columns. Das sorgt ein bisschen für Diffusion da drin. In der
16:01
letzten Runde lassen wir eines dieser Diffusion-Schritte weg und haben am Ende unsere 128-Bit verschlüsselte Daten. Wir haben jetzt unsere Verschlüsselungsfunktion identifiziert. Wir können auch anhand der Operationen ungefähr erkennen, dass es vermutlich auch AES-Verschlüsselung ist.
16:20
Das sieht sehr danach aus nach At-Wound-Key und entsprechend diesen Transformationen. Und können nun ein wenig Monkey-Patchen und können versuchen, den Key zu extrahieren. Praktischerweise gibt es in dieser Software eine Log-Funktion, die auch Hex dampen kann. Und das ist ziemlich cool, denn damit können
16:42
wir, sobald wir einen Key identifiziert haben, diesen entsprechenden Register Hex dampen und kriegen dann sauber im Log-File einen schön formatierten Key. Das hat auch wunderbar funktioniert. Hier unten in der letzten Zeile sieht man dann den extrahierten Schlüssel. Nur irgendwie hat er nie
17:02
funktioniert. Egal, welche AES-Implementation ich benutzt habe, egal welche Varianten ich eingesetzt habe, ich habe es irgendwie nie geschafft, irgendwas Sinnvolles aus dieser Static-TV rauszufinden. Irgendwie doof. An dieser Stelle habe ich quasi aufgegeben und gedacht, okay, das war's damit. Ich werde das wohl nicht rausfinden, wie diese
17:21
Verschlüsselung funktioniert. Doch dann kam irgendwann mal mit einem Admin des Systems gesprochen und der hat dann irgendwas am Rande erwähnt von wegen, wir haben da so ein Entschlüsselungstool, damit können wir alle Datenbanken von allen Geräten öffnen, auch von den alten. Funktioniert super, ruhig ein wenig
17:43
hellhörig. Das hört sich nämlich ein bisschen so an, als ob da irgendwie überall die selben Keys benutzt werden. Na ja, gut, schauen wir mal. Wir haben jetzt aber praktisch auch dieses Tool und dieses Tool, das können wir jetzt debuggen, weil das ist x86, das ist eine halbwegs
18:02
verbreitete Architektur auf einem halbwegs verbreiteten Betriebssystem. Da können wir mit dem IDA-Debugger reingehen. Nun gut, schrittweise gehen wir jetzt einfach mal durch. Das ist jener Schritt, der aus dem einen 256-Bit-Keys ganz viele Keys macht.
18:27
Und dort habe ich einmal beobachtet, wie diese Expansion funktioniert. Was wir jetzt gleich sehen, ist ein Video aus IDA, in dem ich einmal mir diese Variable anschaue, in dem der Expanded Key gespeichert wird, und
18:42
jede Runde der Expansion-Script einmal durchsteppe. Und dort sollten wir eigentlich sehen, wie es diese Variable füllt. Schauen wir uns das mal an. Und man sieht auch, das ist ein relativ großes Feld an Zahlen, die da gefüllt werden, und sehen so, ja, füllt so langsam, geht voran. Jetzt fängt er aber wieder von vorne an.
19:02
Komisch. Das geht eine Weile so, bis er fertig ist. Und dann steht da irgendwas ein paar Daten da und ganz viele Nullen. Das heißt, irgendwie unsere Key Expansion macht irgendwie was anderes wie die übliche Key Expansion. Wir
19:22
bekommen aus einem Key einen anderen Key und ganz viele Nullen. Wenn man das jetzt wieder in unsere Grafik von vorhin einsetzt, also wir nehmen die ganzen Nullen und den Key 1, dann Es zerfällt dieser ganze Prozess ein bisschen. Diese XORs kürzen sich
19:40
weg, weil XOR mit Null tut ihr nichts. Und wir bleiben irgendwie darauf liegen. Das ist prinzipiell nur noch eine einfache XOR-Verschlüsselung mit einem festen Schlüssel, wo man noch ein bisschen
20:08
Null-Paddings hat. Das heißt, wir suchen uns eine dieser Null-Padding- Blöcke, machen einmal XOR plus etwas lineare Transformationen und finden damit den Schlüssel raus. Praktisch.
20:21
Nun können wir also über die Heartbeat-API mit bekannter Board-ID uns frei Haus eine Datenbank besorgen. Das braucht meistens einen kleinen Verkaufsmoment. Entschlüsseln und öffnen. Also sprich, wir haben jetzt frei Haus alle unsere Konfig, die wir brauchen. Wir müssen jetzt nicht mal mehr im Ende mitteln, um an Authentifikationsdaten zu kommen.
20:51
Also gut. Es ist so ziemlich alles kaputt, was ich mir angeschaut habe.
21:00
Also dachte ich, ich wäre fertig. Ich gehe zu dem Admin hin, er zeigt mir das alles und dann meinte er irgendwann, hey, hier haben wir eine neue Version, probiere ich die doch mal aus. Er drückt mir einen USB-Stick in die Hand und meint so, ja, einfach einstecken, müsste automatisch funktionieren. Dann wurde ich wieder stutzig. Wie werden denn hier die Updates verteilt?
21:25
Interessant. Offensichtlich also über USB-Stick. Diese Vending-Reader haben auf der Rückseite einen USB-Pod. Und da kann man einen USB-Stick einstecken. Ich habe das eine Weile angeschaut und rausgefunden, okay, man kann da einen XML-File drauflegen, eine
21:41
sogenannte CMD.xml. Und wenn man da eine Weile auch wieder in IDA sucht, findet man einen ziemlich großen Parser. Und da gibt es auch so spannende Kommandos wie Copy-File oder Execute-File. Und die CMD.xml ist auch nicht signiert in irgendeiner Form.
22:00
Also wir können, ja, die Integrität dieser Datei wird nicht wirklich überprüft. Das heißt, ich könnte mir so eine kleine CMD.xml erzeugen, die auf einen USB-Stick packen. Das ist jetzt einmal auf der Rückseite des Vending-Readers angeschlossen.
22:21
Das braucht einen Moment, bis das ausführt. Und wenn wir den USB-Stick wieder anschließen, haben wir uns
22:42
einmal ein paar nützliche Daten kopiert. Also von USB-Stick, wenn ich das jetzt sehe, ist Core-Exil, unsere Datenbanken und somit auch alle Geheimnisse. Ganz nebenbei können wir auch beliebig Code ausführen. Recht praktisch.
23:03
Spannender wird es dann noch, wenn man sieht, wie die Vorversion aussieht. Wenn man da genauer hinsieht, erkennt man da so ein netter USB-Port vorne dran. Das hat man wohl bei der alten, das hat man wohl irgendwann mal behoben. Aber diese Version hing bei uns jahrelang damit ungefähr herum. Und läuft größtenteils mit derselben
23:20
Software. Also beunruhigend, kann man sagen. Ich bin ein bisschen, ich habe jetzt noch ein wenig Zeit, das heißt ich kann hier noch einmal etwas durchgehen, wie man ein bisschen mit dieser Analyse gemacht hat.
23:45
Bei der Analyse hat es natürlich sehr geholfen, dass diese C-Score-Exe sehr ausführliche Log-Dateien schreibt. Das ist sehr hilfreich, hier sind sogar Funktionsnamen drin und dadurch war es sehr einfach, Funktionen zu identifizieren nach der Analyse.
24:03
Diese Strings, die können wir nämlich suchen in der Binary. Und dann wiederum auflösen, wo diese verwendet würden. Auf irgendeine Weise können wir entsprechend die Funktion identifizieren. So sieht dann so ein Paser aus, wenn man dann mal Funktionen findet.
24:29
Jetzt habe ich noch ein kleines Problem beim Reverse-Ingenieren. Nämlich beim Monkey-Patchen, beim Herausfinden des Keys, hat sich herausgestellt, dass sich die Software da ein bisschen gegen wehrt.
24:41
Sie sagt nämlich, FS ist ExaSafe, failed. Interessant, ist ExaSafe, okay, offensichtlich prüft irgendwie diese Binary sich selber. Scheint wohl irgendwie CRC zu sein, weil man sieht da vorne CRC in it.
25:01
Aber wenn CRC, das kommt mir irgendwie auch komisch vor, das dient ja eigentlich eher zur Erkennung von Bit-Fehlern. Hier wird es aber vermutlich als integriertes Check benutzt. Also ist ExaSafe, hört sich schon so ein bisschen so an. Das ist in mehrerlei Hinsicht komisch, denn das Ganze lässt sich durch einen relativ einfachen Patch aushebeln.
25:22
Also man kann einfach sagen, der Check returnt immer, passt alles, ist korrekt. Oder man kann einfach, die Summe ist ja praktischerweise gegeben, die die Binary haben möchte. Also man kann einfach ausrechnen, was man da für eine Summe hat, braucht.
25:41
Und solange einfach an seinen Binary das so verändern, dass das wieder passt. Oder noch viel einfacher, der Pfad dieser Binary ist hardcoded. Das heißt, wenn wir einfach an den richtigen Ort die richtige Datei legen und irgendwo anders unsere gefakte Binary ausführen, dann funktioniert das auch wunderbar.
26:06
Gut, das wäre es so weit bei mir. Ich glaube, wir haben nur noch etwas Frage für QA. Wir sehen hier nochmal etwas als Übersicht die gefundenen Lücken. Und nun freue ich mich auf eure Fragen und bedanke mich, dass ihr hier trotz der Wärme hier im Zelt die paar Minuten mit mir verbracht habt.
26:37
Ja, vielen herzlichen Dank, Janis, für diesen sehr aufschlussreichen und augenöffnenden und amüsanten Talk.
26:43
Wir haben jetzt noch einiges an Zeit für Fragen, also bestimmt eine Viertelstunde. Wenn ihr Fragen habt, dann kommt gerne hier zu unseren beiden lebenden Mikrofonständern, die jetzt Mikrofone hochhalten. Also wenn ihr was fragen wollt, wie ihr eure Getränkeautomaten hacken könnt oder zu anderen speziellen Themen, dann kommt gerne zu den beiden und stellt Fragen.
27:04
Seid nicht schüchtern, sehr gut. Einen Applaus für den ersten Frager. Bitteschön, du hast das Wort. Was denkst du, wie man das am besten nutzen könnte, um wirklich, ich sag mal, gratis einzukaufen?
27:22
Also um wirklich gratis einzukaufen. Man kann sich natürlich verschiedene Angriffsszenarien an der Stelle vorstellen. Also zum Beispiel, man schaut sich an, welche Nutzer gibt es im System. Man geht einmal die, man sucht, also man bruteforst sich ein paar Ideas zusammen, erzeugt bei anderen Leuten, sagen wir mal, einen Cent Buchungen.
27:46
Gerade bei so größeren Setups sind ja ganz gerne mal 20.000 Karten unterwegs und bucht denen allen vielleicht einen Cent ab. Das merkt niemand und bucht sich selbst die Differenz auf. Das ist zum Beispiel möglich, sobald man irgendwie eines dieser Geheimnisse in die Finger bekommen hat.
28:04
Ansonsten gibt es auch verschiedene Varianten, das zu verschleiern. Es kann natürlich immer sein, dass es dann auffällt, wenn irgendwo Geld auftaucht, also im Gesamtsystem. Deswegen, aber man kann ja auch fremd buchen, weil dann muss man ja nichts authentifizieren beim Kauf. Vielen herzlichen Dank. Bitte die zweite Frage von dem Mikrofon hier vorne.
28:23
Moin, moin. Erstmal vielen Dank für den Talk. Du hast jetzt ja praktisch viel mit meinem Mittel gemacht, das heißt, du hast ein Netzwerk gehangen, wobei es auch eine externe IP gab in einem deiner Slides. Ich glaube, beim M-Lab-Scan hast du es rausgelassen, aber an der anderen Stelle war nochmal sichtbar. Was mich interessiert ist, von dem Transport von den Daten her, hast du getestet anhand der Daten, die von der Karte selber kommen,
28:47
ob du damit im Backend irgendwas machen kannst. Sprich wurde jetzt von der Karte selber bloß eine ID übertragen. Ich habe den Anfang des Talks nicht ganz mitbekommen, ich bin ein bisschen später gekommen. Oder konntest du auch weitere Daten damit einschleusen?
29:01
Also der Kartenleser ist als USB-Tastatur angeschlossen. Also sprich, da kommt nur der gewünschte Sektor, den man entsprechend in diesem Kartenleser eingestellt hat, eingegeben. Das kann je nach Setup alles Mögliche sein. Zum Beispiel eine der verschlüsselten Blöcke auf der Karte kann der Inhalt übergeben werden. Und dann wird diese ID nur benutzt, um den Nutzer aufzulösen.
29:25
Also über die Karte selber lässt sich da relativ wenig tuner machen, weil alles der Rest ist dann cloudbasiert dahinter. Okay, also der nutzt generell auch bloß die ID von der Karte, 125kHz oder 13757? Die ID von der Karte, genau. Oder irgendwie den Inhalt eines Blockes. Das kann man entsprechend einstellen und dann weiter vorne im Kartenleser.
29:43
Okay, aber du hast dann nicht getestet. Ich meine, wenn nur innerhalb der Blöcke davon auch Daten genutzt werden, zum Beispiel bei einer etwas komplexeren Karte, die halt keine reine ID-Karte ist, ob davon Daten dann ebenfalls ans Backend weitergegeben werden? Soweit ich beobachtet habe, nein.
30:02
Alles klar, danke. Vielen herzlichen Dank. Haben wir sonst noch Fragen aus dem Internet oder aus dem Zelt? Sieht so aus, als wären alle Fragen abschließend beantwortet worden. Dann danke ich noch einmal ganz herzlich Janis für den interessanten Talk. Vielen herzlichen Dank. Ich bitte euch noch einmal um einen herzlichen Applaus für Janis.
30:25
Vielen Dank auch an unsere ganzen Technik-Engel und vor allem an unsere Translation-Engel, die hier bei der Hitze im kochenden Zelt weiterarbeiten, damit alle Leute kochen.