Mitternachtshacking

In der Präsentation „Unusual Web Bugs“ von kuza55 ging es Schlag auf Schlag mit den unterschiedlichen Sicherheitslücken in Browsern und Servern, in PHP und anderen Sprachen. Das ging so schnell, viele Punkte konnte ich gar nicht mitschreiben, ich hoffe die FeM-Leute kriegen das Video bald (und brauchbar) kodiert. Die folgenden Stichpunkte sind daher lediglich meine eigene Gedächtnisstütze, schaut Euch das Video selbst an.

• XSS bei angemeldeten Benutzern
  • Missbrauch des Passwort-Managers
  • Automatisches Einfügen von Passwörtern in Formulare
• Session Fixation
  • Abhängig von Cookies und Regeneration der Cookies
• Cache auslesen (nur IE)
  • mittels XMLHttpRequest
• Sonstige Cookie-Spiele
  • Logout durch blockieren des Cookie (CSRF/Flash, Firefox-Tool)
  • Login als der Angreifer (Cookie via Flash in Header einschleusen)
  • Hilfreich ist, dass die Cookie Policy schwächer als die Same Origin Policy ist
• IE FindMimeFromData
  • Encoding-Angriffe gegen SQL-Server (Multibyte-Char)
• und vieles mehr

Ferruh Mavituna hat einiges in diesem Bereich gemacht und bietet u.a. ein SQL Injection Sheet auf seiner Homepage an. Eine andere Quelle ist Ha.ckers.org.

Für meinen Geschmack richten sich die meisten Probleme jedoch gegen den Browser und nicht gegen den Server und die Webapplikation. Angriffe gegen Browser sind mehr für Leute, die Schadprogramme auf die Clients bekommen wollen und ich bin sicher, einige der Angriffe sind bereits im berüchtigten MPack implementiert. Für meine Pentest-Arbeit sind jedoch Lücken in Serverapplikationen nützlicher, da lässt sich auch legal (§ 202c StGB) noch der eine oder andere Exploit anwenden.

Post-Exploitation, d.h. die effiziente Datensammlung von gehackten Systemen wird immer wichtiger, da in den nächsten Jahren insbesondere bei Windows weniger Lücken und Exploits zu erwarten sind. Luke Jennings hat sich in seinem Vortrag (bereits auf der Defcon 15 gehalten (PDF)) daher mit Windows Access Token beschäftigt. Diese Token werden von Windows für praktisch alles verwendet, angefangen von Zugriffsrechten auf Dateien bis hin zu den Rechten mit denen Prozesse gestartet werden und ob sich ein Benutzer anmelden darf.

Mit einem fremden Token sind daher interessante Angriffe möglich, vom Datendiebstahl über Impersonation bis zur lokalen und domainweiten Rechteeskalationen. In älteren (nicht gepatchten) Windows Systemen gibt es darüber hinaus einen Fehler, dass solche Token nicht komplett gelöscht werden wenn sich ein Benutzer abmeldet. Dieses Token kann mit speziellen Tools wiedergefunden und genutzt werden.

Die Programme find_user und incognito sind von Luke veröffentlicht worden und kann entweder von der Milwaukee Area Defcon Group oder von SourceForge heruntergeladen werden.

Bei den Vorträgen von Ilja hab ich regelmäßig das Problem, dass ich höchstens die Hälfte davon verstehe. Das geht immer so weit in C- und Kernel-Interna, das brauche ich normalerweise nicht und ich programmiere auch nicht besonders gern. Diesmal habe ich zwar ganz gut verstanden, worum es ging aber die potentiellen Lücken zu einem Exploit zu entwickeln ist nochmal ein eigener Schritt.

Der erste Teil beschäftigte sich mit /dev/kmem und möglichen Race Conditions beim Auslesen des Kernel-Speichers. Die Lücken sind auf NetBSD bezogen, können aber ähnlich in allen anderen Systemen auftreten, die noch /dev/kmem verwenden (neuere Systeme greifen auf sysctl bzw. /proc zu und benötigen /dev/kmem nicht mehr).

Das Auslesen der Prozesstabelle via /dev/kmem funktioniert im Detail wie folgt:

1. Finde die Prozesstabelle im Kernel-Speicher
2. Finde die passende Prozessstruktur in der Prozesstabelle
3. Finde den Zeiger in der Prozessstruktur, der z.B. auf den Prozessnamen zeigt
4. Lese die Informationen auf die der Zeiger der Prozessstruktur zeigt
5. Gib die Daten aus

Zwischen den Schritten zwei und drei kann eine interessante Race Condition auftreten. Das kommt vor, wenn während dieses Ablaufs der Prozess beendet wird und aus der Prozesstabelle verschwindet. Der Angriff sieht dann wie folgt aus:

1. die Prozessstruktur wird wieder freigegeben
2. der Speicher kann reallokiert werden
3. wenn der Angreifer die Kontrolle über diesen Speicherbereich bekommt, kann er dort beliebigen Inhalt hineinschreiben
4. der Inhalt sollte aussehen wie eine Prozessstruktur
5. die Stelle an die der Pointer zeigt kann ausgelesen werden

Ein wunderbarer Data Leak direkt aus dem Kernel mit allen damit verbundenen Sicherheitsimplikationen. Noch schöner ist es, dass zwei SGID-kmem NetBSD-Programme (trsp/trpt) ihre Privilegien beim Starten nicht verwerfen und sogar core-Files einlesen (womit sie anfällig für manipulierte core-Files werden). Damit dürfte unter geeigneten Umständen eine Rechteeskalation zur Gruppe kmem und damit der komplett lesende Zugriff auf /dev/kmem möglich sein.

Eine zweite Fehlerklasse verursacht der Systemaufruf snprintf() in C, der zwei Eigenschaften hat. Zum einen ist der Rückgabewert der Funktion beim Schreiben in einen Puffer nicht die Zahl der tatsächlich geschriebenen Zeichen sondern die Zahl der geschriebenen Zeichen wenn alles in den Puffer gepasst hätte. Zum zweiten gibt snprintf() bei einem Fehler -1 als Rückgabewert zurück. Einige Funktionen prüfen jedoch den Rückgabewert nicht sondern verwenden ihn direkt zur Zeigermanipulation. Bei geeigneten mehrfachen Aufrufen mit Fehler (-1) kann dieser Zeiger dann auf eine beliebige Adresse gesetzt werden.

Der letzte Teil des Vortrags beschäftigt sich mit Out of Band Daten bei TCP. Dafür wird das Urgent-Flag und der Urgent-Pointer im TCP-Header genutzt. Allerdings gibt es kaum noch Anwendungen die Out of Band Daten nutzen.

Das Senden von OOB-Daten ist recht einfach: send(fd, data, len, MSG_OOB);

Das Lesen ist etwas kniffliger, da beim Empfänger Out of Band Daten normalerweise einfach ignoriert werden. Mittels der Funktion: fcntl(fd, F_SETOWN, getpid()); kann der Filehandle so gesetzt werden, dass OOB-Daten empfangen werden.  Der Aufruf recv(fd, buf, len, MSG_OOB); kann dann zum Lesen genutzt werden. (Alternative Unix-Versionen haben andere Konstantennamen, MSG_OOB ist dann entsprechend anzupassen).

Eine Alternative ist OOB_INLINE, mit der Daten beim Empfänger auch in den normalen Empfangsdatenstrom eingebunden werden können. Und hier bekommen spätestens Intrusion Detection Systeme Probleme denn wie soll das IDS erkennen, dass die Daten zwar OOB gesendet aber Inline empfangen werden. Und pauschal Inline-Empfang anzunehmen ist auch nicht möglich eben weil das Standardverhalten des Empfängers einfach das Ignorieren der Daten ist.

Ich sag ja … ist immer krasses Zeug mit dem sich Ilja da beschäftigt.

Nun gab es doch noch den bereits vermissten Vortrag zur Schweizer Postcard. Die beiden Referenten hatten schon auf dem letzten CCC gezeigt, dass die Schweizer Karte nur einen 320-Bit RSA-Key verwendet, der innerhalb von 24 Stunden gecrackt werden konnte. Damit ist nicht nur diese eine Karte kompromittiert, da es sich um den Privaten Schlüssel der Issuing Party handelt, d.h. mit diesem Schlüssel können neue Karten digital signiert werden. Interessanterweise hat das die Schweizer Presse nicht wirklich interessiert.

In diesem Jahr ging der kompakte Vortrag über die Möglichkeiten, SmartCards zu clonen, d.h. komplette identisch funktionierende Kopien herzustellen. Dazu musste jedoch zuerst das verwendete Kommunikationsprotokoll analysiert werden, was sich recht mühsam herausstellte. Zum Einsatz kamen eine Javacard, eine Prozessorcard und die Überlegung, das ganze mit spezieller Hardware zu machen wie es die Briten kurz vorher vorgeführt hatten.

Die komplette verwendete Hardware und Software und weitere relevante Informationen sind auf der Webseite Postcard-Sicherheit.ch veröffentlicht.

Meiner Meinung nach ist hier neben der technischen Sicherheit vor allem die politische Implikation interessant. Die Schweizer Öffentlichkeit hat von den Sicherheitsproblemen gar keine Kenntnis genommen (im Gegensatz zum Bericht aus Großbritannien, dort hat die BBC eine Fernsehsendung zu den Lücken der Chip&PIN-Karte gesendet). Ebenso werden vom Anbieter, der Schweizerischen PTT die Probleme kleingeredet oder komplett abgestritten. Das Risiko liegt also wie in Deutschland alleine beim Kunden. Ein Umkehrung der Beweislast bei sämtlichen unklaren Zahlungen solcher Karten, d.h. die Bank muss dem Kunden grob fahrlässigen Umgang nachweisen, ist daher dringend geboten.

URLs zum Thema:

• Postcard-Sicherheit.ch
• InfinityUSB Smartcard-Reader
• Atmel GCC Compiler/Libc
• Vortragsfolien und Software
• Französische Carte Bleue
• SmartCard OS
• Wikipedia ISO 7816

Fefe schreibt in seinem Blog: „Im Moment läuft hier in Saal 1 das großartige Monochrom-Puppentheater. Eine Beobachtung, die man so auch wohl nirgendwo anders machen kann: im Publikum sitzen tatsächlich Leute, Notebook mit WLAN auf den Knien, und gucken sich den Stream aus Saal 2 an.“

Stimmt 🙂 Ich habe das auch gemacht … in Saal eins das Monochrom-Puppentheater gekuckt und ab und in den Live-Stream von Saal 3 (Embedded Device Hacking) gekuckt. Da habe ich nicht so viel neues erwartet.

Ebenfalls sehr praktisch ist das Live-Reinhören mit dem DECT-Telefon. Das ist eigentlich der Hauptgrund, warum ich das Telefon dabei habe:

• Raum 1: 8001
• Raum 2: 8002
• Raum 3: 8003

Und meine eigene Nummer dieses Jahr ist die -2167, falls mich jemand anrufen möchte. Aber bitte nicht gerade während eines Vortrags, da ist das Telefon meistens ausgeschaltet.

Generell bestätigt sich jedoch mein Eindruck, dass der CCC deutlich weniger technisch ist als die letzten Jahre. Dafür hat der Politik- und Kunstanteil gewonnen, mit Big Brother, Bundestrojaner, Vorratsdatenspeicherung aber auch mit Monochrom und dem Filmwettbewerb „Das Panoptische Prinzip“. Das ist zwar lustig aber ich bin mir nicht so ganz sicher ob es sich lohnt, nächstes Jahr wieder nach Berlin zu fahren.

Ach ja, das Programm von Sec hat 1069 Zeilen … falls das nächstes Jahr wieder gefragt wird 🙂