Mitternachtshacking

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.