Mitternachtshacking

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.

Der Chaos Computer Club veranstaltet sein alle paar Jahre stattfindendes Camp zur Zeit auf dem ehemaligen Militärflugplatz und jetzigen Museumsgelände in Finowfurt, etwa 60 km nördlich von Berlin an der A11 Richtung Stettin gelegen. In der Gegend bin ich gelegentlich und da ich nicht weit weg günstig übernachten kann, bietet es sich an, das Camp in diesem Jahr zu besuchen. Die Vortragsthemen sind zwar nicht ganz so spannend wie auf dem jährlichen Congress aber ein paar Vorträge dürften wertvoll genug sein, um die Reise zu rechtfertigen.

Das Camp ist gar nicht so einfach zu finden. In Finowfurt von der Ausfahrt Richtung Stadt, dann dem Schild zum Flugzeugmuseum folgen und dann immer gerade aus in den Wald. Irgendwo steht dann ein Aufpasser vom CCC der die Leute auf den Parkplatz lotst, damit die nicht direkt auf den Flughafen draufbrettern.

Das Gelände selbst ist im Grunde ein großes Freilichtmuseum mit diversen alten Flugzeugen aus der ehemaligen DDR und der früheren Sowjetunion. Die Vorträge finden in den ehemaligen Bunkerhangars statt, da ist es wenigstens schön kühl. Davor stehen die Zelte und Wohnmobile der Teilnehmer. Die meisten liegen faul unter Schutzplanen oder im Schatten der alten Militärflieger. Das hat schon was lässiges, so mit dem Notebook unter einem Flieger und wireless im Internet surfen. Nur mit dem Strom ist es ein wenig knifflig.

Den Tag gestern habe ich leider verpasst, da war ein wichtiger Kundentermin. Aber heute ist Action angesagt. Zu den Vorträgen schreibe ich noch eigene Beiträge.

Bildnachweis: Diese Bilder sind frei verwendbar, unter Nennung der Quelle: BerlinVR.de