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.

Immunity hat einen Debugger veröffentlicht, der den Schwerpunkt auf die schnelle und effiziente Entwicklung von Exploits legt. Aus der Webseite:

• A debugger with functionality designed specifically for the security industry
• Cuts exploit development time by 50%
• Simple, understandable interfaces
• Robust and powerful scripting language for automating intelligent debugging
• Lightweight and fast debugging to prevent corruption during complex analysis
• Connectivity to fuzzers and exploit development tools

Ob der so toll ist, wird sich zeigen. Immunity ist schon immer recht gut im Marketing gewesen. Fefe hat dazu ja auch eine eigene Meinung.

Jedenfalls gibt es das Tool for free und ankucken kostet nichts (außer Zeit).

Jesse Ruderman von der Mozilla Foundation hat eine Reihe von Fuzzern zur Prüfung von Webbrowsern veröffentlicht, schreibt Heise. Die beiden Tools jsparsefuzz.js und jsfunfuzz.js erzeugen fehlerhaftes Javascript und können damit potentielle Sicherheitslücken aufdecken. Im Grunde nichts neues, Fuzzer für Webbrowser gibt es eine Reihe, beispielsweise die Browser Crash Test Suite von JdM.

Erstaunlich ist eher, dass Mozilla nicht früher selbst aktiv geworden ist sondern lange Zeit das Feld anderen überlassen hat. Von HD Moore, Michal Zalewski und eben JdM gibt es schon seit geraumer Zeit Fuzzer für Browser und bisher waren die Browser-Hersteller immer in der defensive. Das kann sich vielleicht nun ändern.

Im Grunde bestätigt das aber nur meine Meinung vom Juli. Browser Fuzzing ist kein relevanter Security Markt mehr. Die Fuzzer für Netzwerkprotokolle finde ich viel spannender. Bei VoIP und VPN geht bestimmt noch was. Und nicht zu vergessen, Milosch Meriac braucht dringend jemanden, der einen RFID-Fuzzer programmiert. Da geht noch viel!

War eigentlich klar.

Ich frage mich ja, ob man analog zur Versteigerungsplattform von WabiLabiSabi eine Plattform zum Verkauf von Viren, Trojanern und Botnetzen einrichten könnte. Oder wird das durch den § 202c illegal?

Ein interessanter Artikel auf TecChannel: Viren unter Linux.

Fazit:

• Zweifelsohne ist die Viren-Gefahr auch für Linux vorhanden.
• Die Linux-Distributoren wären gut damit beraten, die Virengefahr ernst zu nehmen.
• Linux ist genauso anfällig wie andere Systeme.

Der Witz dabei? Der Artikel ist von 2001.

Joanna Rutkowska hat den Source Code ihrer Blue Pill veröffentlicht. Das ist eine Software mit der sich ein laufendes Betriebssystem in eine virtuelle Umgebung verschieben lässt. Das Schadprogramm fungiert dann praktisch als Hypervisor und und kann aus dem eigentlichen System heraus kaum noch erkannt werden. Der Name leitet sich von der Blauen Pille ab, die Neo in Matrix angeboten bekommt.

Welchen Nutzen oder Schaden das haben wird ist noch nicht klar. Zum einen behauptet Matasano, dass es nicht möglich ist eine unidentifizierbare Blue Pill zu schreiben. Zum zweiten hilft das vielleicht, dass Virenscanner-Hersteller ihre Produkte mittelfristig mit Gegenmaßnahmen aufrüsten. Die Herausforderung von Matasano ist jedenfalls erst einmal im Sande verlaufen, die finanziellen Forderungen von Joanna stehen dem entgegen.

Ist mir ja gerade erst richtig aufgefallen:

28. Juli – 02. August: Black Hat USA 2007 in Las Vegas

03. August – 05. August: DefCon 15 in Las Vegas

08. August – 12. August: Chaos Communication Camp in Berlin/Finowfurt

Kann man nicht meckern 🙂

Vor den bösen Hackern ist aber auch gar nix sicher. Die Probleme mit Virenscannern und Backup-Software sind ja schon lange bekannt, aber natürlich wird auch alles andere angegriffen.

Der neueste Gag ist, Software anzugreifen, die eigentlich für die forensische Analyse gedacht ist. Auf der aktuell laufenden Black Hat Conference in Las Vegas hat es Guidance Software erwischt, den Hersteller von EnCase der von Behörden am häufigsten eingesetzten Software zur forensischen Analyse.

Passiert ist eigentlich noch nichts. ISec hat ein wenig mit Fuzzern rumgespielt und die EnCase-Software zum Absturz gebracht. Ich glaube nicht, dass das besonders schwierig war. Interessant ist eher die Haltung von Guidance Software dazu. Das sei keine Sicherheitslücke, die Angriffe seien konstruiert und übrigens gäbe es keine Crash-sichere Software. Das kommt mir irgendwie bekannt vor. Da können wir in den nächsten Monaten sicher ein paar spannende Exploits erwarten, denn wer sich so ignorant verhält, hat es nicht anders erwartet.

Zur Erinnerung, Guidance Software ist übrigens der Laden, der 2005 böse gehackt worden ist. Da sind von allen Kunden die Kreditkartendaten geklaut worden. Der Schaden war vor allem deshalb so hoch, weil Guidance widerrechtlich die drei Ziffern der CVV gespeichert hat, was gemäß den Richtlinien von Visa und Mastercard streng verboten ist. Es trifft also keinen falschen.