Mitternachtshacking

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

• das macht der Compiler von alleine wo es sinnvoll ist
• in modernen Compilern ist da eine sehr gute Optimierung

Range checks

• kann man immer machen
• optimiert der Compiler gegebenenfalls automatisch weg wo sie unnötig sind

Strength Reduction

• der Compiler macht automatisch shifts draus

Sizeof

• optimiert der Compiler automatisch, auch bei mehrfachem Einsatz
• keine „magic numbers“ verwenden

Tail recursion

• kann man in eine nichtrekursive Funktion auflösen
• macht der gcc automatisch
• nicht icc und sun-cc

Aliasing

• der Compiler muss hier sehr vorsichtig optimieren
• (außer der gcc, der optimiert alles weg, aber dafür hat Fefe ja einen Bugreport geschrieben)
• hier ist manuelle Optimierung möglich (aber lohnt sich kaum)

Dead Code

• Compiler/Linker kann Code bzw. Objectfiles weglassen
• Beim kompilieren von Bibliotheken jede Funktion in ein eigenes Objectfile packen

Inline Assembler

• braucht man praktisch nie
• ist blöd zu debuggen
• besser nicht (lohnt sich auch kaum bei modernen Compilern)

Shifting

• schwer in C zu programmieren
• optimiert der Compiler automatisch

Pre- vs. Post-Operation

• auch hier kaum noch Optimierungsmöglichkeiten

Memory Hierarchien

• hier lässt sich am meisten tunen
• ein Cache Miss schlägt mit 250 CPU-Cycles Penalty zu buche
• das ist meist der teuerste Schaden und am wichtigsten zu optimieren

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:

• verschiedene Binary Versionen
• Code Änderungen / Verschiebungen des Programmcodes im Binary
• Kein Platz im Binary für Zusatzcode
• Konkurrierendes Hot Patching von Microsoft
• Windows File Protection, das Änderungen an Systembibliotheken verhindert
• Virenscanner Probleme (modifizierte Binaries)

Insgesamt ist daher das Ändern von Systemdateien gar nicht so einfach. Der Binärpatch kann auf verschiedene Art erzeugt werden:

PE-Patching

• Ein Portable Executable Binary ist ein komplettes ausführbares Programm unter Windows.
• Beim PE-Patching wird das komplette Programm angepasst, was auch Änderungen der PE-Struktur erfordert
• In kurzer Zeit nicht verläßlich durchzuführen, da meist größere Änderungen erforderlich sind
• Insgesamt sehr aufwendig

Per-Version Patching

• Jede einzelne Version eines Binaries wird passend gepatcht
• Benötigt alle vorhandenen Programmversionen
• Wenn einzelne Versionen unbekannt sind, kann der Patch nicht angewandt werden

Hot Patching Bytes

• Möglich, wenn der Patch nur an wenigen Stellen angewandt werden muss
• 7 Bytes sind oft nicht genug

Spot Patching

• Einfach, da lediglich Search & Replace verwendet wird
• Geht nicht, wenn z.B. die Patch-Signatur nicht statisch ist

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:

1. Einlesen der VGS.DLL
2. Finden der Signatur
3. Patchen des Binaries
4. Speichern der gepatchten PATCHEDVGX.DLL
5. Deregistrieren der VGX.DLL
6. Registrieren der PATCHEDVGX.DLL

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:

1. Mittels knownDLLs die Patch-DLL jedem Prozeß hinzuladen
2. Im RAM die USER32.DLL finden und patchen

Allerdings wird diese Technik in 64 Bit Vista nicht mehr funktionieren, da nur signierte Bibliotheken geladen werden können.

Fazit und Risikomanagement:

• Don’t use 3rd-party patches!
• Do you trust patches from people that don’t own the source code?
• What about liability and vendor support?
• If not patched, you are already vulnerable!
• Do you want to stay unprotected?
• ZERT supplies source code of the patches

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:

• Deadlocks (das Programm hängt komplett)
• Livelocks (das Programm hängt in einer Endlosschleife)
• Fehlerhafte Kommunikation
• Fehler in der gemeinsamen Datennutzung
• Race Conditions

Race Conditions sind für den Angreifer in der Regel am interessantesten.

Die Ursachen für Race Conditions sind praktisch immer drei Hauptursachen:

• Vergessene Locks in konkurrierenden Zugriffen
• File System Races (TOCTOU-Fehler)
• Signal Races

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

• 16×4 = 64 Byte Speicher
• 10 Byte Read-Only Factory-Programmed, davon 7 Byte UID
• 6 Byte PROM, davon 2 Byte Lock-Bits
• 48 Byte nutzbarer Speicher
• Keine Verschlüsselung
• Keine Security-Funktionen außer der UID

Mifare Classic

• Weitverbreiteter Standardtyp
• 1-4 KB Speicher
• Proprietärer Stream-Cipher („Crypto1“) mit 48 Byte Schlüssellänge, bisher nicht gebrochen
• 4 Byte UID
• ACLs für einen Speicherbereich für Geldwerte auf den nur mit INCREASE/DECREASE-Kommandos zugegriffen werden kann
• Multiple User-Areas mit unterschiedlichen Schlüsseln
• Multi-Application-fähig

Mifare DESfire

• Mifare Classic-kompatibel
• DES/3DES Verschlüsselung
• 7 Byte UID

T=CH

• In ISO 14443-4 definiert
• APDUs vergleichbar zu kontaktbasierten Karten nach ISO 7816
• Wird in vielen ePassports verwendet

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:

• Anticollision tut noch nicht so 100%, aber daran arbeitet das Team
• Bereitstellen von Mifare-Samples um die Verschlüsselung zu brechen
• OpenPDC/OpenPICC OS nach FreeRTOS portieren

Und für folgendes benötigen die Jungs dringend Hilfe:

• Brechen der Mifare-Verschlüsselung
• OpenPCD und OpenPICC in ein Standalone-Sniffer/Replay-Gerät kombinieren
• RFID Fuzzing Suite

Hier kann jeder mithelfen!

Seit jetzt, heute, Mitternacht gilt der neue § 202c StGB.

Bildnachweis: Chaos Computer Club

Marco Gehrcke gab in seinem Vortrag Online Search zu Beginn einen Überblick über die Diskussion zum Bundestrojaner, inzwischen Remote Forensic Software genannt, in den USA und in Deutschland. Interessant der Vergleich einer Hausdurchsuchung, die öffentlich erfolgen muss und einer Rechnerdurchsuchung, die geheim bleiben soll. Hier bestehen erhebliche verfassungsrechtliche Bedenken. Ich möchte die angesprochenen wichtigen Punkte nur mal in Stichwörtern zusammenfassen, es gibt genug Sekundärliteratur, die genauere Informationen liefert.

Begründung für den Trojaner:

• Verschlüsselung verhindert Strafverfolgung

Funktionen des Trojaner:

• Standort- bzw. IP-Adressbestimmung um Anonymisierungsdienste auszuschalten
• Aufzeichnung aller eingetippten Daten und gelesenen Dokumente
• Keylogger-Funktionen zum Auslesen von Passwörtern und Encryption Keys

Problem: Wie kommt der Trojaner auf den Rechner

• Installation vor Ort durch herkömmlichen Einbruch
• Definierte Schwachstellen durch die Betriebssystemhersteller

Gefahren:

• Zu wenig Ressourcen für die Polizei, um geeignete Software für alle Betriebssystem-Versionen zu entwickeln (OpenBSD-User sind immun?)
• Antivirus-Software erkennt die Remote Forensic Software nicht, Virenschreiber bauen auf diesen Funktionen auf
• Hintertüren im Betriebssystem können z.B. durch Kriminelle missbraucht werden
• Strafverfolgungsmöglichkeiten werden auf Bagatellstraftaten ausgedehnt (z.B. einfache Urheberrechtsverletzungen)
• Verletzung der staatlichen Souveränität bei grenzüberschreitenden Ermittlungen
• Durchsuchungen erfolgen heimlich (wie bei der Gestapo oder Stasi) und nicht mehr öffentlich wie das unser Grundgesetz fordert

Online Durchsuchungen verletzen elementare Grundrechte. Die notwendige Abwägung von Sicherheit gegenüber Freiheit scheint hier nicht erfolgt zu sein. Dazu gab es von Marco Gercke ein schönes Zitat: „Es ist nicht Aufgabe des Staates dafür zu sorgen, dass jedes noch so kleine Verbrechen effizient verfolgt werden kann.“

Was wäre die Alternative?

• Verbot anonymer Kommunikation
• Verbot von verschlüsselter Kommunikation

Gercke argumentierte nun, bevor diese Verbote kommen, sei eine gelegentlich stattfindende Online-Durchsuchung mit Richtervorbehalt das kleinere Übel. Ich denke hier genau umgekehrt. Die Online-Durchsuchung scheint von vielen, gerade technisch kaum versierten Mitbürgern akzeptiert zu werden, weil sie nicht verstehen worum es sich dabei handelt und vor allem, dass es sich um einen massiven Angriff auf die grundgesetzlich geschützten Bürger- und Freiheitsrechte handelt. Es steht zu befürchten, dass gerade auch durch die um Zuge des letzten G8-Gipfels in Heiligendamm erfolgte Ausweitung der Definition der „Terroristischen Vereinigung“ (§ 129a StGB) praktisch jeder Demonstrant unter Verdacht steht und damit heimlich durchsucht werden kann. In der ehemaligen DDR genügten dazu „Westkontakte“ in der Bundesrepublik zukünftig wohl „Demonstrationskontakte“. Ein Verbot von verschlüsselter Kommunikation würde jedoch auch der letzten Oma mit Internetbanking klar machen, dass hier etwas grundlegend verkehrt läuft. Der öffentliche Aufschrei würde folglich auch den sitzhaftesten Bundesinnenminister aus dem Amt rollen. Und das wäre dann das kleinstmögliche Übel.

Andreas Gietl berichtete über den Entwurf des neuen Telekommunikationsgesetzes und die Auswirkungen auf die Kommunikation. Die relevanten Gesetzesartikel sind:

§ 110 TKG-E

Enthält die Pflicht zur Speicherung von Kommunikationsdaten

§ 113a TKG-E

Enthält die diversen Regelungen zur Speicherung:

• Dienstanbieter muss für 6 Monate speichern
• DSL/Dialin-Anbieter müssen speichern
• WLAN-Anbieter wohl nicht, da es keine Teilnehmerkennung gibt
• Im Mobilfunk müssen IMSI, IMEI und Standortdaten gespeichert werden
• Bei E-Mail Kommunikation müssen Absender, Empfänger, IP-Adressen und jeder Abruf gespeichert werden
• Inhaltsdaten werden nach Abs. 8 nicht gespeichert
• Löschung einen Monat nach Ablauf der Speicherpflicht
• Anonymisierungsdienste werden praktisch verboten, da diese Dienste die Identitäten vor und nach der Anonymisierung speichern müssen
• Allerdings ist die Rechtsprechung nicht einig, ob Anonymisierungsdienste ein Telekommunikations- oder ein Mediendienst sind

§ 113b TKG-E

• Zweckbindung (Straftaten, erhebliche Gefahren, Nachrichtendienste)
• Zitiergebot

§ 110g StPO-E

• richterliche Anordnung
• bei erheblichen Straftaten

§ 161/163 StPO i.v.m. § 113 TKG

• Staatsanwaltliche Ermittlungen
• Beschränkt auf sowieso gespeicherte Daten
• Abgestufter Schutz, wenn Daten sowieso z.B. zu Abrechnungszwecken gespeichert werden dann ist das über den Staatsanwalt zulässig, für den Abruf der Daten aus § 113a TKG-E ist die richterliche Anordnung aus § 110g notwendig.

Die Vorratsdatenspeicherung widerspricht jedoch der Rechtsprechung des Bundesverfassungsgerichts zu Art. 10 GG (Volkszählungsurteil: Speicherung von persönlichen Daten ohne konkreten Zweck ist unzulässig). Die Bundesregierung versucht daher offensichtlich den Verfassungsverstoß über den Umweg einer EU-Richtlinie zu legitimieren. Bisher gibt es dazu die Solange-Urteile, die im Kern sagen, solange EU-Recht gleichen Rechtsstandards wie das Grundgesetz genügt, mischt sich das Bundesverfassungsgericht nicht ein. Die Vorratsdatenspeicherung könnte laut Gietl daher entweder ein Solange-3- oder ein JetztReichts-1-Urteil provozieren.

Ausgang: Unklar.

Weitere Informationen: www.andreas-gietl.de

Der Vortrag von Sergio ’shadown‘ Alvarez von n runs war irgendwie wieder so ein typischer n runs Vortrag wie auf dem Congress auch immer. Da wird ein aktuell relevantes Thema verwendet, dann etwas Forschung darum getrieben, die sicher gar nicht mal schlecht ist (Shadown hat über 80 Sicherheitsprobleme und Bugs an die diversen Virenscanner-Hersteller gemeldet) und dann wird für den CCC ein Vortrag zusammengestellt, der bestenfalls auf Management Niveau noch jemanden vom Hocker reißt, weil einfach gerade gar keine Details drin sind.

Sicher richtig ist, dass von Lücken in AV-Software rund 90% der Computer betroffen sind. Das ist nicht wenig. Andererseits ist es so, dass die AV-Hersteller eben auch eine sehr effektive Methode haben, über Updates der Scan-Engine auch die Fehler schnell zu beheben. Man vergleiche die täglichen Updates mit dem monatlichen Patchday von Microsoft.

Interessant fand ich gerade noch die Zusammenstellung der Mythen:

• AV-Software ist sicher
• AV-Software macht das Netzwerk sicherer
• AV-Software wird von Sicherheitsspezialisten entwickelt
• AV-Software verhindert alle Infektionen
• AV-Software entdeckt auch komplett unbekannte Viren

Die Realität ist eher:

• Sehr alte Viren werden oft nicht mehr entdeckt (richten aber auch keinen Schaden mehr an)
• Eine Reihe von Binary-Packern werden nicht erkannt
• Längst nicht alle Archiv-Formate werden erkannt (wenn auch alle wichtigen)
• Spezielle Funktionen in Archiv-Formaten sind nicht implementiert (z.B. gzip concatenation)

Die Probleme führt er auf folgende Hauptursachen zurück:

• Fest einprogrammierte Passwörter in Binaries (gut, kommt in den besten Familien vor)
• Fest einprogrammierte Verschlüsselungskeys in Binaries (kommt auch öfter mal vor)
• AdminConsole-Passwörter in Konfigurationsdateien (es gab da einen Fall von Trend Micro)
• Client Listener (das ist ein echter Knackpunkt)
• Null DACLs für Registry Settings, Config Files und Handles (auch das stimmt zu 100%)
• Schlechte Inputvalidierung (viele Integer-Fehler)
• Probleme mit großen Dateien >2GB
• Weit verbreitete Programme/Filetypen sind oft noch nicht enthalten
• Zu viele Formate, die ein Parser verstehen muss

Und dann gab es noch eine kurze Demo mit einem Fuzzer, bei dem er dann den Virenscanner zum Absturz gebracht hat. Cool … mit Fuzzing findet man also Virenscanner-Lücken. Das ist sooo neu, da braucht es gleich einen Month of the AV-Software Bug(MoAVSWB).

Fukami ist einfach gut. Der Vortrag über Testing und Exploiting Flash Applications war allererste Sahne. Am Anfang kurz die Grundlagen erklärt, dann typische Problemklassen beschrieben, die Sicherheitsrisiken an konkreten Beispielen vorgeführt und das alles so, dass der HighLevel-Betrachter verstehen konnte, dass Flash ein Problem sein kann aber gleichzeitig mit so vielen Details, dass mir jetzt auch klar ist, wo genau die Probleme sind.

1. Die Grundlagen

Von Flash gibt es eine Reihe von Generatoren, die Flash-Movies erzeugen können jedoch nur den offiziellen Player von Adobe, da keine weiteren Player erlaubt sind. Flash besteht aus einer Skriptsprache (ActionScript, aktuell ist v2 weit verbreitet und v3 kommt gerade mit neuen Funktionen). Flash ist u.a. für Audio/Video-Anwendungen sehr beliebt. Zu Flash kommt Flex dazu, eine SDK mit IDE, im Grunde besteht das aus Flash 9, Interface Libraries und einem Eclipse Plugin. AIR ist die Adobe Integrated Runtime für Desktop-Anwendungen. Bereits wenn man an dieser Stelle auf Flash guckt, fallen ein paar gefährliche Eigenschaften auf: Flash kann HTTP Request Forgery, kann JavaScript, … äh

2. Die Sicherheit

Flash hat seit Version 7 ein Security Modell, das hauptsächlich auf der „Same Origin Policy“ basiert. In Version 8 und 9 wurde das Modell vereinfacht, aber auch ein Player Version 9 wendet die alte Policy an, wenn ein Flash Version 7 Movie abläuft. Darüber hinaus gibt es in Flash einen Persistent Local Datastore für Shared Objects. Da kann der Flash-Movie beliebige Daten hereinlegen, maximal jedoch 100 KB. Die Daten haben kein Expiration Date, sind nicht einfach löschbar und auf einigen Plattformen sogar Cross-Browser erhalten. Damit hat man schon einen krass permanenten Speicher, wenn man einen Webseitenbesucher wieder identifizieren will.

3. Die Angriffe

Das fängt schon mal an mit Local Connection Objects die verwendet werden, damit zwei Flash-Movies miteinander Nachrichten austauschen können. Die Nachrichten werden nicht gefiltert, da kann mal also sehr gut XSS oder JavaScript durchschleusen. Und Flash kann ja bekanntlich Javascript. Lustig ist es auch mit den Variablen. Für uninitialisierte Variablen gilt in etwa das gleiche wie bei PHP mit register globals. Da man Variablen über die URL, FlashVar oder localVars.AS-Objekt übergeben kann, ist jede uninitialisierte globale Variable eine potentielle Gefahr. Die Sandbox in der Flash abläuft ist zwar ganz sinnvoll, aber weitgehend beschränkt auf die Same Origin (FQDN) Policy sowie eine Cross Domain Policy, die als XML-File geladen werden kann.

4. Client Side Attacks

Auf Client-Seite ist vieles möglich, XSS, XSF (Cross Side Flashing), Mass Exploits, Backdoors und vieles mehr. Die Funktion getURL() in ASv2 erlaubt beispielsweise JavaScript- und DOM-Aufrufe. Fukami spricht hier von PDNF (Potentially Dangerous Native Function). Außerdem gibt es HTML in Flash (HTML-Injection beispielsweise durch das CreateTextField oder den Anchor-Tag), dafür muss die Anwendung aber als Flash 7 kompiliert werden.

5. ActionScript v3

Noch viel lustiger wird es mit ActionScript Version 3, da gibt es lustige neue Funktionen. Auf jumperz.net gibt es einen in Flash programmierten Portscanner, der vom Client aus die IP-Adresse 127.0.0.1 scannt. Die Gefahr von Socket-Operationen sollte eigentlich bekannt sein, JavaScript verzichtet aus gutem Grund darauf.

6. Tools

• Flare – Decompiler
• MTASC – Compilter
• Flasm – Disassembler
• SWFmill – SWF/XML-Converter
• Debugger-Version des Flash Players
• SWFTools – Programme zur SWF-Manipulation, z.B. swfcombine
• haXe – ASv2/v3-Compiler

7. Neue Lücken

Neue Lücken werden kommen, beispielsweise:

• RTMP/AMF buffer overflows
• Data handling Fehler für Media Server / Plugins
• Breaking the Sandbox
• ASv3 Decompiler / Source Code Analyzer
• RTMP/AMF Proxy/Fuzzer
• DNS Rebinding

8. Weitere Informationen

www.flashsec.org

Zusammenfassend ein richtig klasse Vortrag mit coolen wenig bekannten Informationen.

Der Vortrag von Nibbler war ein reiner und sehr kurzer Grundlagenvortrag. Im Grunde wurden hauptsächlich die ganzen Protokolle von SS7 vorgestellt und kaum weitergehende Informationen geboten obwohl Nibbler den Eindruck hinterlassen hat, mehr zu wissen. Verglichen mit dem Internet ist das in etwa so, wie wenn man erwähnt, dass es die Protokolle IP, TCP und UDP gibt, außerdem die TCP-Protokolle HTTP, SMTP und FTP sowie die UDP-Protokolle DNS und NTP. Aha. Ein nicht informierter kann mit dieser Information praktisch nichts anfangen, ein Eingeweihter langweilt sich.

In Folge sind daher auch eine Reihe von Leuten bereits während des Vortrags gegangen und es gab kaum weitere Nachfragen zum Thema. Dabei wäre das vielleicht gar nicht so langweilig, da könnte man mehr daraus machen. Harald Welte entwickelt beispielsweise an einem OpenSource Mobiltelefon, die Kenntnisse über SS7 sind da durchaus hilfreich, um zu verstehen was an der GSM-Schnittstelle passiert. Das iPhone wird sukzessive gehackt, auch wenn das längst nicht so schnell geht, wie sich einige das erhofft haben. Auch hier ist grundlegendes Wissen über SS7 und GSM anscheinend hilfreich.

Zu den Inhalten: Im Gegensatz zu vorherigen Verfahren wie CCITT#5 ist das Signalisierungsverfahren Signalling System 7 (kurz SS7) ein Out of Band Verfahren, das daher von den Endgeräten kaum noch anzugreifen ist. Schwerpunkte in der Entwicklung waren Verlässlichkeit (Reliability bzgl. Nutzererfahrung und Billing) sowie die internationale Standardisierung. Die wichtigsten Komponenten sind SSP (Service Switching Point), STP (Signal Transfer Point) und SCP (Service Control Point). Die einzelnen Punkte sind via A- (Access), B- (Bridge bzw. Diagonale), C- (Cross), E- (Extended) oder F-Links (Fully Associated) miteinander verbunden, die jeweils unterschiedliche Aufgaben erfüllen. Als Layer 1 Protokoll kommt G.703 zum Einsatz, die interessanten Protokollfunktionen befinden sich auf den Layer 2 Signal Units. Die wichtigsten Units wurden angesprochen, u.a. ISUP, OMAP, SCCP und TCAP. Dieser Teil ging aber kaum über die Informationen hinaus, die auch bei Wikipedia zu finden sind.

Zusammenfassend … auch wenn das Thema vielversprechend ist, den Vortrag fand ich zu langweilig und trocken.