| M | D | M | D | F | S | S |
|---|---|---|---|---|---|---|
| « Jul | Sep » | |||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | ||
Die Präsentationen der Black Hat 2007 sind jetzt auch online.
http://www.blackhat.com/html/bh-media-archives/bh-archives-2007.html
Cool stuff, z.B.
um mal ein paar herauszuheben.
Die Anwender sind wenn ich mir das so recht überlege sogar noch aus einem weiteren Grund die angeschmierten.
Hardware-Hersteller haben in der Regel kein besonderes Interesse, für alte Hardware noch neue Treiber für neue Systeme zu entwickeln. Die Entwicklung ist aufwendig und teuer und mit einem Treiber allein kann man in der Regel kein oder nur wenig Geld verdienen. Lieber verkauft man neue Hardware, am besten gleich mit jedem Betriebssystem-Update dazu. Gefürchtet sind hier bei den Anwendern vor allem die Hersteller von Grafikkarten, allen voran Nvidia, die anscheinend gerne mal für eine wenige Jahre alte Grafikkarte keinen Treiber mehr bereitstellen wollen.
Bisher konnte man sich darauf verlassen, dass ein paar clevere Hacker sich da schon was einfallen lassen. Die Jungs von ngohq.com bieten eine Reihe für die Nvidia-Grafikkarten eine Reihe von modifizierten INF-Files an, so dass sich neue Treiber auch noch für ältere Grafikkarten nutzen lassen. Die Treiber selbst funktionieren wunderbar und werden natürlich nicht modifiziert (das wäre wohl auch ein Urheberrechts- und Lizenzverstoß), lediglich der Installer erhält ein anderes Konfigurationsfile, das ihm mitteilt, der Treiber würde auch für ältere Karten noch funktionieren. Nvidia scheint das nicht zu gefallen, vermutlich weil sie da glauben dadurch weniger Hardware zu verkaufen. (Bei mir ist das ja umgekehrt … ich schaue zuerst, welche Hardware zukunftsfähig ist und in fünf Jahren auch noch funktioniert, bevor ich irgendwo Geld ausgebe. Aber das scheinen manche Verkaufsfritzen nicht zu realisieren.) Jedenfalls hat Nvidia versucht, ngohq.com mit Hinweis auf US Copyright abzumahnen. Da ngohq.com jedoch in Israel sitzt sind sie damit voll ins Leere gelaufen.
In Zukunft wird Nvidia dafür nicht mehr US Recht bemühen müssen. Das Zurückziehen der Zertifikate für den Treiber dürfte genügen, Notfalls wird halt eine künstliche Sicherheitslücke eingebaut. Verlierer ist der Anwender, der dann ohne Treiber für seine 500 Euro Grafikkarte dasteht, die fast noch neu ist und der sich nun eine neue Grafikkarte kaufen darf. Oder doch lieber OpenSuSE Linux. Das gibt es in diversen Internet-Shops bereits für 12 Euro inkl. Versand.
Gestern schrieb ich über die Problematik (für den Anwender), wenn Microsoft Treiber von im Grunde vollkommen legalen und legitimen Treibern zurückzieht, weil diese dem Kontrolldenken von Microsoft widersprechen. Natürlich besteht die Gefahr, dass mit einem solchen Treiber auch das Digitale Restriktionsmanagement von Windows ausgehebelt wird. Aber das ist primär ein Problem der Content Industrie und weniger von Microsoft. Leider lässt sich der Eindruck nicht vermeiden, dass Microsoft die Wünsche Hollywoods wichtiger sind als die Wünsche und Bedürfnisse der eigenen zahlenden Kunden.
Das ganze scheint jedoch keine großen Verwerfungen zu verursachen. Dem 08/15-User von Windows ist das recht egal und viele andere sind inzwischen sowieso bereits zu Linux gewechselt. Interessant wird es jedoch , wenn ein wichtiger weit verbreiteter Treiber zurückgezogen werden muss, weil er z.B. eine dicke Sicherheitslücke enthält. Und genau das ist nun passiert: In einem Grafikkartentreiber von ATI, wurde von Alex Ionescu eine Sicherheitslücke gefunden, mit der sich beliebiger Programmcode in den Kernel von Vista schleusen lässt. Ionescu hat dafür einen Proof-of-Concept Exploit namens „Purple Pill“ entwickelt und veröffentlicht aber wieder zurückgezogen, als er erfuhr, dass es von ATI noch keinen Patch für die Lücke gibt.
Wenn Microsoft konsequent ist, müsste das gleiche Verfahren wie beim gestern beschriebenen Atsiv-Treiber angewandt werden. Sperren des Zertifikats durch Verisign, Aufnahme des ungültigen Zertifikats in die Kernel-Sperrliste von Vista. Nur, dann funktioniert der Grafikkarten-Treiber von ca. 50% aller Vista-Notebooks nicht mehr. Ich als Kunde wäre „not amused“. Übrigens auch interessant, eine Aufnahme eines ungültigen Zertifikats in die Kernel-Sperrliste erfordert einen Reboot und kann nicht dynamisch erfolgen. Wenn das in der Server-Version von Windows 2008 genauso bleibt, werden sich die Administratoren freuen, alle halblang ihre Server neu booten zu müssen. Irgendwer bei Microsoft hat da nicht richtig nachgedacht.
Microsoft hat für das aktuelle Problem jetzt erst einmal ATI gedrängt, dringend ein Update für den Treiber zu entwickeln, der dann neu digital signiert wird. Der neue Treiber wird dann via Windows Update verteilt und wenn Microsoft davon überzeugt ist, ausreichend viele Anwender mit dem neuen Treiber versorgt zu haben, wird anschließend, vielleicht in zwei oder drei Monaten das Zertifikat des alten Treibers gesperrt, der alte Treiber kann dann nicht mehr verwendet werden. Übrigens blöd, wenn man dann einen Rechner mit einem der älteren Treiber neu aufsetzen will.
Ich könnte mir vorstellen, dass wir in den nächsten Monaten ein interessantes Katz-und-Maus Spiel erleben werden. Joanna Rutkowska geht sogar soweit, Grafiktreiber als „Malware Compliant“ zu bezeichnen. Die Bad Guys werden versuchen, neue Lücken in diversen Kernel-Treibern zu finden und Microsoft wird jede Woche (oder zumindest jeden Monat zum Patchday) eine Reihe von Treibern wieder sperren müssen. Und jedes mal wird es ein paar Microsoft-Kunden geben, die noch kein Treiberupdate bekommen haben, deren alter Treiber jedoch gesperrt wird und deren System dann nicht mehr funktioniert. Wenn ich Microsoft wäre, würde ich spätestens jetzt kalte Füße bekommen.
Ollie Whitehouse von Symantec, früher @stake sieht das im Grunde ganz genauso, er kann bei seinem jetzigen Arbeitgeber halt nur nicht so über Microsoft lästern.
Microsoft hat mit Vista im 64-Bit Modus strenge Richtlinien eingeführt, welche Treiber von Vista in den Kernel geladen werden und welche nicht. Die wichtigste Anforderung von Kernel-Mode Treibern ist, dass alle Treiber von Microsoft digital signiert werden müssen (KMCS – Kernel Mode Code Signing). Die vollständigen Anforderungen beschreibt Microsoft in den Driver Signing Requirements for Windows.
Microsoft begründet diese Anforderung damit, ihre Kunden vor bösartigem Programmcode schützen zu wollen. Kernel-Mode Rootkits, die nicht über eine digitale Signatur verfügen, werden nicht mehr in den Vista Kernel geladen und können daher auch ihre Schadwirkung nicht mehr entfalten. Im Grunde eine sinnvolle Funktion. Aber mit einem Haken. Microsoft lässt den Kunden keine Wahl mehr, ob sie andere Treiber vielleicht doch laden wollen. Gut, es gibt eine spezielle Boot-Option mit der man diese Anforderung deaktivieren kann, aber diese Option muss bei jedem Neustart mit angegeben werden. Außerdem funktioniert eine Reihe anderer Software (hauptsächlich Mediensoftware) nicht, wenn Vista ohne KMCS gestartet wurde. Praktisch ist daher nicht wirklich nutzbar. Bei Windows XP möchte das Betriebssystem ebenfalls einen signierten Treiber und wenn die Signatur fehlt, bekommt der Anwender einen Hinweis, kann sich aber entscheiden den Treiber doch noch zu installieren. Bei Vista geht nichts mehr.
Die Firma Linchpin Labs hat nun am 20.07.2007 einen signierten Treiber namens Atsiv veröffentlicht, der mit einem eigenen PE-Loader ausgestattet ist und damit beliebige, auch unsignierte Treiber und Bibliotheken in den Vista-Kernel nachladen kann. Aus der Beschreibung von Linchpin Labs:
Atsiv is a command line tool that allows the user to load and unload signed or unsigned drivers on 32 bit (x86) and 64 bit (x64) versions of Windows XP, Windows 2K3 and Windows Vista. Atsiv is designed to provide compatibility for legacy drivers and to allow the hobbyist community to run unsigned drivers without rebooting with special boot options or denial of service under Vista.
Als Anwender oder Entwickler ist das eine praktische Sache. Man kann so Treiber für eigene Hardware entwickeln oder andere Erweiterungen programmieren, ohne auf die Signatur von Microsoft angewiesen zu sein. Das hilft, weil es eine Reihe von Treibern auch für aktuelle Hardware gibt, die nicht digital signiert ist. Diese Hardware kann vom Anwender mit Hilfe des Atsiv-Moduls genutzt werden. Das hilft auch, weil es die geschlossene Vista-Plattform für Funktionen öffnet, die Microsoft vielleicht nicht vorgesehen hat, die ich als Anwender vielleicht aber machen möchte.
Bereits am 03.08.2007 hat Microsoft reagiert. Scott Field, der Windows Security Architect schreibt in seinem Blog, welche Maßnahmen Microsoft dagegen ergriffen hat: Das an Linchpin Labs ausgestellte Zertifikat wurde am 02.08.2007 zurückgezogen. Auf Drängen von Microsoft hat Verisign das Zertifikat auf die Revocation List gepackt, das Zertifikat wird folglich nicht mehr anerkannt. Das Microsoft Sicherheitsteam hat das gesperrte Zertifikat zusätzlich in die Kernel-interne Sperrliste aufgenommen, die mit dem nächsten Update aktualisiert wird. Das Update der internen Sperrliste erfordert allerdings einen Systemreboot. Und damit nicht genug, der Atsiv-Treiber wird von Microsoft Defender als Schadprogramm eingestuft und vom System des Benutzers entfernt.
Spätestens jetzt bekomme ich Bauchschmerzen. Es ist eine Sache, wenn z.B. mein Virenscanner ein Programm wie Cain & Abel, das sich auf meinem Rechner befindet, als Schadprogramm charakterisiert und mir anbietet es zu entfernen. Die Wahl darüber bleibt schließlich weiterhin bei mir und ich kann meinem Virenscanner beibringen dieses (und andere Hackingtools) auf meinem Rechner zu ignorieren. Vista gibt mir diese Möglichkeit nicht mehr. Das Zertifikat wurde gesperrt und der Treiber ist damit nicht mehr funktionsfähig. Nur um das klarzustellen, eigene Treiber im Betriebssystem sind eine vollkommen legale und legitime Angelegenheit. Dabei handelt es sich weder um einen Urheberrechtsverstoß (solange die verwendete Vista-Version legal erworben wurde), noch um einen Lizenzverstoß (da 3rd-Party Treiber ja generell erlaubt sind). Trotzdem verbietet Microsoft es mit über technische Maßnahmen, das Betriebssystem so zu nutzen wie ich möchte. Ohne, dass ich gefragt wurde, werde ich als Anwender bevormundet.
Oder mit den Worten von Peter Gutmann: the longest suicide note in history.
In der Taugshow (österreichisch für Talkshow) von monochrom war ich nur so ca. 45 Minuten. Irgendwie fand ich das nicht so ganz lustig. Die Show war auch nicht wirklich gut besucht, da sind einige Plätze leer geblieben. Ich habe mir ja etwas mehr Show erhofft, so im Sinne des RFID-Songs auf dem CCC aber dann wurde es nach Überwindung der technischen Schwierigkeiten erstmal doch eine recht zähe Talkshow, die ich nicht komplett angekuckt habe.
Egal. Das RFID-Video von YouTube kommt hier jedenfalls rein:
Der notorische Dan Kaminsky mit seinen jährlichen Black Ops. Ich frage mich ja, was er dann auf dem Congress im Dezember bringt, weil da kann er seine Black Hat Slides nicht schon wieder recyceln. Das gab übrigens ganz schön Buh-Rufe von den Zuhörern, dass auf den Slides nicht mal „Black Hat Conference“ durch „Chaos Communication Camp“ ausgetauscht war. Ich frag mich ja, was eigentlich originäre Arbeit von Dan in den Präsentationen ist und was er so zugetragen bekommt. Beim Thema Flash-Vulnerabilites fand ich den Vortrag von Fukami inhaltlich um Klassen besser. Nur die Show und das gehampel auf der Bühne hat Dan besser drauf.
Angriffe mit Flash und DNS Rebinding
Jedenfalls hat Dan das Thema Flash und DNS Rebinding wieder aufgegriffen und ein wenig genauer erklärt. Das Problem wurde wohl erstmals 1996 als Princeton Attack veröffentlicht und für Flash von Dan Boneh von der Stanford University genauer untersucht. Zurückzuführen lässt sich das alles auf die „Same Origin Policy“, die davon ausgeht, dass eine Datenquelle mit einem Rechnernamen identisch ist. Nur stammen die Daten von einer IP-Adresse und der Rechnername aus DNS. Und die DNS-Einträge lassen sich schnell mal ändern. Zu einem Zeitpunkt zeigt www.example.com auf einen Webserver und lädt die Flash-Applikation, zu einem späteren Zeitpunkt (nur Sekunden später) auf eine private interne IP-Adresse und führt einen Angriff aus. Damit lässt sich natürlich sehr schön jede Firewall umgehen.
Dan unterscheidet zwischen Angriffen Level 1 (nur der Browser ist betroffen), Level 2 (Web-Plugins werden zum Angriff verwendet) und Level 3 (Plugins mit Socket-Funktion werden verwendet, Angriffe in das LAN sind möglich). Sockets finden sich beispielsweise in Flash und Java. Java war übrigens das Originalziel der Princeton Attacke von ’96.
Für das DNS-Rebinding sieht Dan als alter DNS-Hacker drei Möglichkeiten:
Und nun setzt Dan ein paar Bausteine zusammen. Dazu verwendet er den Browser mit einer speziellen Flash-Anwendung, den Angreifer, der über den Browser in das lokale Netz eindringen will und einen speziellen Proxy (Slirpie). Dabei handelt es sich um einen Multiprotokoll-Server, der TCP-Stream von/zum Flash, HTTP für den Browser, DNS für das Rebinding und XML-Socket zur Kontrolle der Policy unterstützt. Anscheinend hat Dan sowas programmiert, leider jedoch nicht veröffentlicht.
Mit einem Rückgriff auf Slirp (1995) und PPTP ist es damit möglich, VPN über den Browser einzurichten, wobei der Browser nicht als VPN-Client sondern als VPN-Gateway dient. Scary!
Provider Hostality
Der zweite Teil des Vortrags beschäftigt sich mit der Thematik eines neutralen Netzes. Welche Möglichkeiten gibt es, um eine Provider zu entdecken, der einzelne Webseiten in seinem Netz bevorzugt transportiert und andere Seiten ausbremst oder noch schlimmer Content manipuliert in dem z.B. Werbeeinblendungen verändert werden.
Hier gab es ein paar interessante Ideen, z.B. über einen transparenten Proxy, der alle Seiten cached zu ermitteln, ob der Provider irgendwas manipuliert. Als geeignetes Werkzeug bietet sich ein Sniffer im Browser an, hier hat Dan etwas mit dem Namen „Inspector Pakket“ gebastelt aber leider auch noch nicht veröffentlicht.
Mal sehen, was davon demnächst als reale Software auftaucht. So ein Metasploit als Flash im Browser um die Angriffe von innen auszuführen wäre schon cool 🙂
Fefes ersten Vortrag habe ich ja leider verpasst, aber zum zweiten Vortrag bin ich dann doch rein, obwohl ich anfangs ein wenig skeptisch war. Ein paar Sachen muss man Fefe jedoch neidlos zugestehen … was C angeht hat er richtig Ahnung. Die Kernaussage war dafür recht schlicht: „Lesbarer Code ist wichtiger als Optimierung“.
Don’t use Inline
Range checks
Strength Reduction
Sizeof
Tail recursion
Aliasing
Dead Code
Inline Assembler
Shifting
Pre- vs. Post-Operation
Memory Hierarchien
Aha … also gute Neuigkeiten für Spaghettiprogrammierer wie mich … einfach weitermachen, der Compiler optimiert das schon. 🙂
Gil Dabah, u.a. Autor des diStorm Disassembler hat in diesem Vortrag die Möglichkeiten des Binary Patchings am Beispiel von zwei Microsoft Lücken (VML, ANI) vorgestellt und dabei ein wenig Werbung für seinen Arbeitgeber ZERT (Zeroday Emergency Response Team) gemacht. Insgesamt war der Vortrag aber sehr ausgewogen, er hat nicht nur auf Vorteile des Binary Patchings hingewiesen sondern auch auf die möglichen Probleme und Gefahren und es den Teilnehmern überlassen, daraus ihren Schluss zu ziehen. Der Vortrag hat mir auch aus diesem Grund recht gut gefallen.
Patching wird von Gil definiert als Änderung von Daten oder Code, die das Verhalten eines Programms verändern. Das vielleicht bekannteste Beispiel von Binary Patching sind Game Cracks, nach deren Anwendung sich ein Spiel ohne zugehörige CD bzw. Registrierungscode spielen lässt.
Typische Probleme beim Patchen von Binaries sind:
Insgesamt ist daher das Ändern von Systemdateien gar nicht so einfach. Der Binärpatch kann auf verschiedene Art erzeugt werden:
PE-Patching
Per-Version Patching
Hot Patching Bytes
Spot Patching
Eine Lücke, für die ZERT einen Patch entwickelt hat ist die VML (Vector Markup Language) Lücke, ein Zeroday, der am 19.09.2006 von Adam Thomas von Sunbelt Software gefunden wurde. Die Lücke wurde zu diesem Zeitpunkt aktiv im Internet genutzt, um in Systeme einzubrechen. der VML-Bug ist ein einacher Stack-based Buffer Overflow in der Datei VGX.DLL, die von allen Internet Explorer 6 Versionen in Windows XP SP2 verwendet wird. DEP (Data Execution Prevention) würde vor dem Exploit schützen, wird jedoch standardmäßig beim IE nicht verwendet. Der Angriff benötigt lediglich fehlerhafte Attribute in der VML-Fill-Methode und ist daher einfach auszuführen. Ein typischer „surf and geht owned“-Exploit.
<v.rect><v.fill method=“AAAAAAA…“></v.fill></v.rect>
Das Patchen des VML-Binaries ging relativ einfach vonstatten, da VGX.DLL eine In-proc DLL ist die registriert und deregistriert werden kann. Der Ablauf erfolgt dann wie folgt:
Beim ANI-Fehler musste zum Patchen eine andere Methode angewandt werden, da die USER32.DLL sich so nicht ändern lässt. Die verwendete Technik nennt sich in-memory patching:
Allerdings wird diese Technik in 64 Bit Vista nicht mehr funktionieren, da nur signierte Bibliotheken geladen werden können.
Fazit und Risikomanagement:
Am Ende bleibt es halt doch immer dem Sicherheitsbeauftragten und dem Administrator überlassen zu entscheiden, was sie tun wollen.
Lisa Thalheim hat im Vortrag Twisting Time ein paar Probleme konkurrierender Programme vorgestellt. Dabei ging es um typische Programmierfehler, die zu Concurrency Bugs führen. Ursache sind entweder Programme oder Threads von Programmen, die parallel (simultaneously) ablaufen können und entweder gemeinsam auf eine Ressource zugreifen oder miteinander kommunizieren müssen. Hier treten leicht schwer zu findende und unregelmäßig auftretende Fehler auf.
Der Vortrag selbst war eigentlich ein reiner Grundlagenvortrag, von meiner Einschätzung her das Niveau eines Proseminars an der Uni. Für Leute, die damit noch nie zu tun hatten sicher interessant, da alle Grundlagen erklärt wurden, für Programmierer die sich damit schon beschäftigt hatten eher langweilig, da außer ein paar anschaulichen Source Code Abschnitten nichts wirklich neues vorgestellt wurde. Im Zusammenhang mit dem Stichwort „Twisting Time“ hätte ich mir vielleicht auch noch einen Hinweis auf zeitkritische Sidechannel-Angriffe vorstellen können.
Typische Fehler sind:
Race Conditions sind für den Angreifer in der Regel am interessantesten.
Die Ursachen für Race Conditions sind praktisch immer drei Hauptursachen:
Race Condition am Beispiel eines Ringpuffers
#define CELLS 32
int rbf[CELLS];
int rbf_idx = 0;
uint32_t num_elems;
void rbf_store( int data ) {
if (rbf_idx == CELLS)
rbf_idx = 0;
rbf[rbf_idx] = data;
rbf_idx++;
num_elems++;
}
Wenn dieser Code konkurrierend abläuft, kann es passieren, dass die if-Abfrage des ersten Threads einen rbf_idx-Wert kleiner CELLS ergibt, danach wird dieser Thread angehalten, ein zweiter Thread für die if-Abfrage durch, ebenfalls mit einem Wert in rbf_idx kleiner CELLS, der erste Thread schreibt folglich in den Puffer und erhöht den Index, anschließend schreibt der zweite Thread in den Buffer (wobei damit der reservierte Speicherbereich bereits überschritten wird) und erhöht den Index. Da rbf_idx jetzt bereits größer ist als CELLS, wird in Zukunft immer über den eigentlich reservierten Speicher des Buffers hinaus geschrieben. Ursache für diesen Fehler ist ein vergessener Lock, der den Bereich rbf_store sichert, da dieser Bereich nur einmal konkurrierend betreten werden darf.
Locking Fehler liegen entweder an komplett fehlenden Locks bzw. fehlender Synchronisation, da sich der Entwickler der Konkurrenz nicht bewusst war oder inkonsequentem Einsatz, bei dem einzelne Funktionen nicht richtig gesichert werden.
File System Race Condition
$TempDir = $Config{'tmpdir'} . "logwatch." . $$ . "/";
if ( -d $TempDir ) { rmdir ($TempDir); }
if ( -e $TempDir ) { unlink ($TempDir); }
mkdir ($TempDir,0700);
Bei File System Race Conditions handelt es sich praktisch immer um TOCTOU-Fehler (Time Of Check vs. Time Of Use). Ein Zustand wird zu einem Zeitpunkt A geprüft und das Wissen über diesen Zustand zu einem Zeitpunkt B verwendet, ohne zu beachten, dass sich dieser Zustand auf einem Multithreaded-System in der Zwischenzeit geändert haben kann. TOCTOU-Fehler treten besonders gerne bei temporären Dateien auf und sind sehr schwer zu vermeiden, da es in Unix keine atomare (d.h. nicht unterbrechbare Aktion) zum Prüfen und Anlegen einer Datei gibt. Exploits sind oft über Symlinks möglich, die Präsentation gibt hier ein cleveres Beispiel einer temporären Syslog-Datei verlinkt auf /root/.bash.
Signal Races
Signal Races sind die dritte Klasse häufiger Race Conditions und am schwierigsten zu verstehen. Dabei werden Signal-Handler konkurrierend eingesetzt, beispielsweise beim Beenden von Programmen oder Schreiben von Logfiles. Der klassische Fehler ist der Aufruf einer non_reentrant Funktion (d.h. einer Funktion die z.B. aufgrund interner Variablen nicht konkurrierend mehrfach aufgerufen werden darf) oder die Verwendung von non_reentrant Signal Handlers.
Signal Races findet man beispielsweise im Zusammenhang mit sigaction() und nicht offensichtlich erkennbar mehrfach genutzten Ressourcen (z.B. libc-Funktionen mit internen statischen Variablen die bei konkurrierenden Aufrufen überschrieben werden). In C++ kann man nach Singletons wie instanceOf suchen.
Die sehenswerte Präsentation (PDF, 1.0 MB) enthält die kompletten Source Code Beispiele.
Auf dem Camp wurde der Vortrag zu RFID von Milosch Meriac, dem Hauptentwickler der RFID-Hardware und von Henryk Plötz gehalten, der an der Software schraubt. Der Vortrag war recht ähnlich zum RFID-Vortrag von Harald Welte und Milosch Meriac auf dem letzten Congress.
RFID-Standards
Als Einleitung wurde wieder der RFID-Standard ISO 14443 vorgestellt, der Proximity Integrated Circuit Cards (PICC) definiert. Der Standard beschreibt im Detail
1. Physical Characteristics
2. RF Power & Signal Interface
3. Initialization & Anti-collision
4. Transmission Protocol
Hauptsächlich gibt es zwei verschiedene Kartentypen, Typ A, die Mifare-Karten von Phillips und Typ B, die z.B. bei ePassports zum Einsatz kommen. ISO 14443 setzt Amplitude Shift Keying (ASK) Modulation ein, die so kodierten Signale des Receivers (PDC) sind aus 5-10 m empfangbar, die Antwortsignale der Karte (PICC) liegen 60-80 dB unter der Signalstärke des Senders und sind typischerweise aus maximal 2 m empfangbar. Ein Anti-Collision-Protokoll soll unterschiedliche Karten in Reichweite des Empfängers trennen. Dazu werden UIDs (Unique Identifier mit 4, 7 oder 10 Byte) verwendet. Auf dem Congress im Dezember gab es dazu einen interessanten Vortrag einer holländischen Gruppe, die durch gezielte Erzeugung von Kollisionen einzelne Karten ausblenden konnte.
Kartentypen
ISO 14443A
Mifare Classic
Mifare DESfire
T=CH
Hardware
Milosch hat sehr schön die benötigte Hardware beschrieben, im einfachsten Fall reicht eine triviale Kupferspule mit LED und Kondensator. Für die komplexeren Angriffe gibt es einen von ihm entwickelten RFID Sniffer/Sender, mit dem auch trivial Replay-Angriffe möglich sind. Die benötigte Hardware kann man entweder bei www.OpenPCD.org fertig kaufen oder anhand der Anleitungen und Vorlagen selbst bauen.
Work in Progress
Ein paar Sachen funktionieren noch nicht ganz:
Und für folgendes benötigen die Jungs dringend Hilfe:
Hier kann jeder mithelfen!