27. Dezember 2010

27C3: Adventures in analyzing Stuxnet

Category: CCC,Hacking — Christian @ 23:53

Bruce arbeitet für Microsoft und die bisherigen Vorträge von Microsoft-Mitarbeitern (insbesondere auch der von Bruce Dang auf dem 25C3) waren immer sehr durchwachsen. Man konnte gut erkennen, dass die zwar viel wissen aber nichts davon sagen dürfen. Insofern ging ich mit niedrigen Erwartungen in diesen Vortrag.

Microsoft hat das erste Sample eines Programms das die LNK-Lücke ausnutzt von AV-TEST bekommen. Von dort wurde angefangen zu analysieren. Microsoft wusste damals nicht, dass mehrere Lücken ausgenutzt werden. Sie haben deshalb nur mit einer gerechnet und mussten in kurzer Zeit ~1MB Binärcode dekodieren und analysieren.

Bug 1: LNK-Files

  • LNK Files contain a link to its target
  • The shell needs to know what icon represents the target
  • Control panel links can have dynamic icons
  • Shell gets the icon by LoadLibrary() the target
  • LoadLibrary() automatically executes DllMain() so attacker gets code execution in the context of explorer.exe

Fix is to check if the applet is registered before loading dynamic icons.

Und ganz toll, das haben die Microsoft-Entwickler innerhalb von einer Stunde herausgefunden, nachdem die Lücke jahrelang übersehen wurde. Mein Gott sind die alle toll und werden die von Bruce gelobt. Man könnte fast meinen, Microsoft hat die besten Entwickler die alles sofort wissen und nie Fehler machen. Schon seltsam.

Bug 2: Task Scheduling (nur Vista/Win7)

  • Scheduled Tasks werden in einem User-schreibbaren XML-File gespeichert
  • Eine Prüfsumme des XML-Files wird (sicher) in der Registry gespeichert
  • Der Hash-Alogrithmus zur Verifizierung der Integrität ist CRC32
  • Kollisionen leicht zu erzeugen, User-Wechsel auf LocalSystem möglich

Fix: Algorithm was changed to SHA256

Bug 3: Keyboard Layout (nur WinXP)

  • in win32k.sys
  • ein Integer aus dem Layout-File wird für einen globalen Array im Kernel verwendet
  • keine Prüfung des Integer-Werts, daher kann irgendwohin gesprungen werden

Fix: Prüfung des Integers

Bug 4: Spooler Subsystem

  • entdeckt von Dan Kaminsky, der das Schadprogramm im Netzwerk laufen lies.
  • es gibt zwei Spezialfälle in denen der Spooler nicht auf Gast-Rechte zurückfällt
  • bekannte Problematik von Windows XP, absichtlich so programmiert
  • der Print-Spooler erzeugt zwei Dateien mit LocalSystem-Rechten
  • ein EXE-File, das ausgeführt werden soll
  • ein MOF-File, das automatisch ausgeführt wird, wenn es in einem bestimmten Verzeichnis liegt

Fix: Rechtezuweisung überarbeiten

Und das Summary, die Leute die bei Microsoft arbeiten sind alle gaaaanz tolle Helden und arbeiten alle super zusammen und finden in Minuten alle Lücken die sie auch sofort fixen können. Naja, wenigstens war dieses mal nur der halbe Vortrag eine Marketingshow.

27C3: Die gesamte Technik ist sicher

Category: CCC,Hacking — Christian @ 23:49

Dominik und Frank erklären die gängigen Angriffsszenarien gegen den neuen Personalausweis, insbesondere die Angriffe mit Schadprogrammen auf dem Client bei Verwendung eines Basislesers (d.h. PIN-Eingabe an der normalem PC-Tastatur) sowie Relay- bzw. Man-in-the-Middle-Angriffe bei der mittels virtueller Smartcard die Informationen der realen Smartcard an einen fremden Rechner relayed werden.

Ich denke den Vortrag sollte sich jeder Nutzer eines neuen Personalausweises anhören.

Fazit:

  • Authentisierung mit nPA sicherer
    • Zugriff auf ein physisches Objekt notwendig
    • Starke Kryptographie
  • Signatur mit nPA sicherer
    • Kommunikation zum Ausweis ist verschlüsselt
  • Attraktives Angriffsziel
    • eSign und eID auf derselben Chipkarte
    • höherer Schaden bei Missbrauch

Wichtigste Empfehlung: Vermeidung des Basislesers und öffentlicher Terminals, nur Nutzung von Standardleser und Komfortleser aus vertrauenswürdiger Quelle.

Offen bleiben die rechtlichen Implikationen. Ist die Nutzung der eID bereits ein rechtssicherer Identitätsnachweis der anstelle einer digitalen Signatur genutzt werden kann? Wenn ein Händler die eID ausliest, muss dann der Eigentümer des Ausweises den Missbrauch nachweisen weil die eID gleiche Rechtswirksamkeit wie die digitale Signatur erhält? Die Betreiber von Online-Shops fordern das bereits.

Meine persönliche Meinung ist ja, in den nächsten 3-5 Jahren kristallisiert sich heraus, was da passiert und bis dahin werde ich mit meinem noch länger gültigen alten Ausweis einfach die Füße still halten. Einen neuen Ausweis kann ich ja immer noch beantragen wenn es Sinn für mich macht

27C3: Recent advances in IPv6 insecurities

Category: CCC,Hacking — Christian @ 23:47

So, van Hauser (Marc Heuse) kenne ich von seinem letzten IPv6-Vortrag und die Entwicklung bei THC beobachte ich auch kontinuierlich. Insofern werde ich da vermutlich erst zur Hälfte reinzoomen und solange was über den neuen Personalausweis anhören.

Der Vortrag wiederholt die alten Angriffe von 2005 und bringt dann ein paar neue Sachen, mit denen man sich z.B. alle Windows 2008/7/Vista-Rechner lahmlegen lassen, die IPv6 aktiviert haben. Sehr schön ist die Übersicht der Möglichkeiten, IPv6-Netze doch irgendwie zu scannen und die Analyse seiner Scan-Ergebnisse. Die meisten Angriffe z.B. gegen die Autoconfiguration oder Multicast setzen jedoch schon einmal Zugang zum lokalen Netzwerk voraus.

Das neueste Tool lässt sich von Marcs Firma herunterladen: http://www.mh-sec.de/downloads/thc-ipv6-1.4.tar.gz Und es soll im Januar 2011 ein paar neue Webseiten geben: http://www.ipv6security.info und http://www.ipv6hacking.info.

27C3: Hacking iButtons

Category: CCC,Hacking — Christian @ 21:36

Ok, iButtons waren mir jetzt neu. Beim ersten Lesen des Fahrplans hab ich ja gedacht, das ist wieder mal irgendwas wo jemand mit dem iPhone rumspielt. Also eher langweilig. Statt dessen war das hier ein extrem cooler Vortrag. Christian hat gezeigt, wie man iButtons, also in ein rundes Metallgehäuse zusammen mit einer Batterie eingelegte Chips angreifen kann.

Das erste Hindernis bei einem Angriff ist, an den Chip im Gehäuse ranzukommen. Wenn man das Gehäuse einfach öffnet geht die Stromversorgung des SRAMs verloren und die Daten sind weg. Aber man kann das Gehäuse mit etwas Aufwand und feinmechanischen Kenntnissen auffräsen und mit einem gekühlten Chip (der bei Stromverlust die Daten noch ca. 0,5 Sekunden erhält) die Stromversorgung wieder herstellen. Der ausgebaute Chip wird dann an eine von ihnen entwickelte Hardware angeschlossen, die gezielt bestimmte Fault-Angriffe ausführt und so auf den Schlüssel kommt:

4176 Screenshot 1

Die angewandten Tricks sind schon vom allerfeinsten. Ich habe am Anfang leider nur mit einem halben Ohr hingehört aber den Vortrag höre ich mir garantiert nochmal an. Da stecken soviele Ideen und Verknüpfungen drin, das ist extrem genial gelöst. Ganz ehrlich, das dürfte der beste Hacking-Vortrag des ganzen CCC werden

27C3: hacking smart phones

Category: CCC,Hacking — Christian @ 21:33

Passend zum vorherigen Vortrag über Feature-Phones geht es direkt mit etwas mehr Smartphone-Inhalt von Ilja van Sprundel weiter. Ilja erklärt erstmal detailliert das SMS-PDU Format. Auch hier will ich nicht drauf eingehen sondern auf den Vortragsstream verweisen, wenn das jemand im Detail wissen will. Danach folgen weitere Formate wie MMS, WAP, etc.:

4265 Screenshot 1

Ansonsten bringt der Vortrag wenig wirklich neue Erkenntnisse. Ja, der iPhone-Browser ist ein Alptraum, was Funktionen und Möglichkeiten angeht, weil die kaum alle sicher zu bekommen sind. Ja, Office Formate und PDF sind ein zweiter Alptraum. Das kennt man ja schon vom Blackberry. Der damalige Vortrag von FX (Call to arms, some provided) hatte im Gegensatz zu Iljas Vortrag wenigstens noch ein paar konkrete Angriffspunkte enthalten.

Schade, die bisherigen Vorträge von Ilja fand ich etwas informativer und spannender.

27C3: SMS-o-Death

Category: CCC,Hacking — Christian @ 21:29

Collin Mulliner und Nico Golde arbeiten im T-Labs der TU-Berlin und berichten über die Sicherheitsprobleme von Feature-Phones (das sind halb-intelligente Telefone, etwas weniger intelligent als Smartphones) mit SMS. Nur 16% aller Telefone sind Smartphones aber praktisch alle Mobiltelefone sind heute Feature-Phones die SMS unterstützen. Diese Telefone gibt es mit praktischen allen Verträgen umsonst weil sie günstig sind und sie sind auch im Rest der Welt weit verbreitet. Es gibt Standardsoftware für diese Telefone und ein gefundener Fehler funktioniert auf sehr vielen Geräten. Die am meisten verbreiteten Hersteller sind Nokia, Samsung, SonyEricsson, LH, Motorola und Micromax (in Indien). Die Telefone wurden gebraucht auf eBay organisiert und hatten oft noch vertrauliche Daten im Speicher.

SMS kann unzählige Funktionen wie FlashSMS, VCard, MMS, Multipart-SMS, …. viele dieser Funktionen sind kaum gebräuchlich und der unterstützende Programmcode kann deshalb leicht bisher unentdeckte Fehler enthalten. Ein Fehler in einem einfachen Feature-Phone mit nur einem Prozessor erlaubt die Kontrolle über das Telefon und SMS ist ein echter Remote-Bug, einfach eine SMS wegschicken und fertig.

Das Problem bei der Analyse ist allerdings, es gibt keinen Debugger, es gibt kein öffentliches SDK, JTAG (Reverse Engineering) ist nicht lustig bei 10+ verschiedenen Telefonen, man muss echt Arbeit investieren. Die Lösung für die TU war deshalb, ein eigenes privates GSM-Netz aufzubauen. Das hat den Vorteil, dass SMS umsonst sind und kein Netzbetreiber Zugriff auf die SMS mit 0-Day-Exploits bekommt. In diesem eigenen GSM-Netz hat man außerdem komplette Kontrolle über alle Geräte und Logfiles. Zum Glück gibt es mit OpenBSC, OpenBTS, nanoBTS (3500,- Euro Basisstation) und OsmocomBB OpenSource-Software für den Betrieb von GSM-Equipment.

Das SMS-PDU-Format ist erstaunlich komplex. Auf die Details möchte ich hier nicht eingehen. Dafür gibt es diesen Screenshot aus dem Vortrag:

4060 Screenshot 1

Beispielsweise sind folgende Geräte betroffen:

4060 Screenshot 2

Oder:

4060 Screenshot 3

Fazit: gegen alle Telefone waren Denial-of-Service Angriffe mit relativ einfachen SMS möglich. Von Reboot des Geräts über Abschalten bis zum kompletten Freeze ist alles dabei. Weil einige Telefone bereits Crashen bevor der Empfang der SMS dem Netz gegenüber bestätigt wird, kann über wiederholte Auslieferungsversuche ein Telefon dauerhaft aus dem Netz gehalten werden. Über die konkreten Auswirkungen eines verbreiteten DoS-Angriffs auf Mobiltelefone muss noch diskutiert werden. Möglicherweise kann man Netzbetreiber oder Hersteller erpressen.