| M | D | M | D | F | S | S |
|---|---|---|---|---|---|---|
| « Nov | Jan » | |||||
| 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 | ||||||
Das Jahr 2007 neigt sich dem Ende, daher nur noch ein letztes Foto:
Gleich im neuen Jahr geht es weiter, ich danke allen treuen Lesern (und auch den untreuen), wünsche einen guten Rutsch ins neue Jahr und freue mich, auch 2008 diverse Themen in der IT-Security kommentieren zu können.
Die aufgelegten Folien will ich kommentarlos als Fotobeweis dokumentieren 🙂
Tim Pritlove hat dann zum Ende noch ein paar Statistiken geliefert:
Das war’s, nächstes Jahr, gleiche Zeit, gleicher Ort.
Alexander Kornbrust ist neben David Litchfield vermutlich der wichtigste Oracle Sicherheitsexperte den wir haben. Wenn von ihm ein Vortrag zu Oracle Security kommt, dann kann man eigentlich immer etwas wichtiges erwarten.
Zu Beginn gab es einen kurzen Abriss zu alten Lücken, insbesondere PL/SQL-Injecion-Fehler. Hier hat Oracle in den letzten Jahren über 1000 Fehler behoben und verwendet inzwischen einen Fortify-Sourcecode-Scanner um weitere Lücken zu erkennen. Das Spiel heißt jetzt nicht mehr „Hacker gegen Oracle“ sondern „Hacker gegen Fortify“. Dummerweise ist der PL/SQL-Code der nicht von Oracle ist weiterhin dramatisch schlecht da die Entwickler in den Unternehmen nur auf ihre Business-Logik achten und teilweise noch nie von SQL-Injection gehört haben. Eine einzige Lücke reicht einem Angreifer jedoch aus um die komplette Datenbank zu übernehmen.
Eie weitere Fehlerklasse hat David Litchfield auf der Black Hat DC 2007 vorgestellt, dort nutzte er eine Lücke im Cursor aus die jedoch inzwischen behoben ist. Der Hack zeigt jedoch, dass weiterhin mit Lücken zu rechnen ist und immer mehr Angriffe automatisiert werden.
Ein Thema mit dem sich Alexander als erster intensiv beschäftigt hat sind „Database Rootkits“. Dabei werden einzelne Einträge wie Benutzer und Passwörter oder Jobs in der Datenbank versteckt. Diese Rootkits haben darüber hinaus den Vorteil, plattformunabhängig und nur datenbankspezifisch zu sein. Eine Variante ist die Modifikation der Database-Views. Die meisten Tools verwenden Views um auf die Inhalte von Tabellen zu kucken. Ein Eintrag kann so in einem View verborgen werden während er in der Tabelle selbst weiter enthalten ist. Es gibt inzwischen sogar kommerzielle DB-Rootkits, z.B. von Argeniss, inzwischen von Gleg aufgekauft. Von Paul Wright (PDF) gibt es ebenfalls ein Rootkit-Whitepaper, außerdem eine neue Methode von David Litchfield, der im Memory (PPT) einzelne Funktionen patcht.
Die wichtigsten Probleme aktuell sind:
Die Listener sind ab 10g automatisch geschützt, die Hauptprobleme werden weiterhin Patches sein, da viele Anwender nicht kurzfristig oder regelmäßig Patches einspielen können.
Eine weitere neue Funktion mit Missbrauchspotential ist die Transparent Data Encryption (TDE) die auf jeder neuen Oracle-Installation vorhanden ist und nicht deinstalliert werden kann (jedoch zur Nutzung eine eigene 10.000 USD/CPU Lizenz verlangt). Wenn die TDE eingesetzt wird, hilft sie dem Angreifer, relevante Daten zu finden da nur wichtige Sachen verschlüsselt sind (und die Entschlüsselung beim Query ja transparent erfolgt). Wenn sie nicht eingesetzt wird, gibt es ganz neue Erpressungsmethoden. Einfach die TDE aktivieren und kritische Daten verschlüsseln. Das passiert (da transparent) unsichtbar für den Nutzer. Nach einem Reboot bzw. Neustart der Datenbank ist dann der Schlüssel weg und das Unternehmen zahlt sicher gerne für das fehlende Passwort.
Weitere Themen waren Skripten in Clients für SQL*Plus, die z.B. beim Starten des Oracle-Clients automatisch nach der Anmeldung ausgeführt werden (quasi wie ein Trojaner) sowie Shellcode in Tablenamen, z.B. wenn ein Table „!rm -rF /“ heißt 🙂 Cooles Zeug.
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.
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:
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:
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.
| Funktion | Hardware | Javacard | Prozessorcard |
|---|---|---|---|
| Timing | X | – | – |
| T1 Sniffing | X | – | X |
| Direct Convention | X | – | X |
| Indirect Convcention | X | X | X |
| Ease of Use | low | high | med |
| Secrecy | low | high | high |
| Special Hardware | X | – | X |
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:
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:
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 🙂
Monochroms zweiter Auftritt, diesmal die ganze Künstlergruppe und nicht nur Johannes Grenzfurthner …
Man erkennt das auf den Fotos recht schlecht, da es im Raum sehr dunkel war … das sind Figuren auf Stöcken die von oben in einem kleinen Miniaturtheater gespielt haben. Leider etwas verwackelt, weil die Belichtungszeit meiner Kamera zu lange war. Trotzdem fand ich das Spiel sehr amüsant, eine richtig gute Idee und ein klasse Kontrast zur sonstigen Hightech-Veranstaltung
Aber dass Johannes beim Applaus beinahe Roland Gratzer vergessen hat, seinen tapferen Gitarristen und Mitsänger … 😉
Das Reverse Engineering von Embedded Devices ist ein immer wiederkehrendes Thema auf dem Congress, in diesem Jahr mindestens zum dritten Mal vertreten. Trotzdem ist es immer wieder interessant mit welchen verbesserten Methoden die Firmware von Embedded Systeme analysiert wird.
Die wichtigsten Eigenschaften zur Analyse von Embedded Devices sind:
Zugriffsmöglichkeiten auf die Firmware bestehen an mehreren Stellen:
Das Filesystem das in so einer Firmware verwendet wird ist in der Regel romfs, squashfs oder cramfs. Außerdem gibt es so lustige Sachen wie bFLT (Binary Flat Format) oder das BCC Protokoll.
Geräte mit einem solchen System sind beispielsweise
In der zweiten Hälfte stellte Dash seine Analyse der Elmeg-Anlage vor. Die Analyse der Firmware greift auf das Tool UWfirmforce von Überwall zurück, das Khorben 2006 auf dem Congress vorgestellt hat.