Reverse engineering techniques to find security bugs - A case study of the ANI
URL: video.google.com/videoplay?docid=-7185841369679533904
Dauer: 61 Minuten
-7185841369679533904
Übersicht
Notizen
Die Präsentation beschreibt wie man aus Sicherheitsupdates Schwachstellen findet und diese attackiert. Sie beginnt mit einer Live Präsentation des ANI Exploits. Der Exploit läuft auf einem Webserver und erhält Zugriff auf den Client sobald dieser die Webseite mit einem Browser betritt. Der Exploit funktioniert auf dem Betriebssystem - also auch auf einem Firefox.
Alex Sotirov geht auch auf die Updatepolitik von Microsoft an. Laut seinen Aussagen werden die Security Updates meist heimlich durchgeführt. Eine Sicherheitslücke wird also Update geschlossen und in Wirklichkeit gibt es 5 weitere Schwachstellen. In den Security Bullets findet man natürlich auch die Kopfzeile des ersten Fehlers.
Er zeigt ein paar Tools, mit denen er in seinem Beruf arbeitet um Sicherheitslücken aus Patches zu erschließen und die es ihm möglich machten den .ANI Bug zu finden. Dazu gehört der IDA Pro Disassembler mit seinem mächtigen Plugin BinDiff. Live analysiert er ein Microsoft Update und deckt sogar Fehler im Paket auf.
Außerdem zeigt er die neuen Schutzmechanismen in Vista, zeigt welche Schwachstellen sie haben und wie man sie umgehen kann. Die /GS stack cookies sind aus Performancegründen nur in Funktionen mit Arrays aktiv, müssten aber auch bei Structures aktiv sein. Allerdings würde das ein komplettes rekompilieren des Betriebssystem benötigen. Dadurch werden vermutlich nur gefährliche Systemfunktionen gepatcht (insofern hier nichts vergessen wird).
Eine weitere Neuerung in Vista ist ASLR (Address space layout randomization). Ohne die zufällige Adressvergabe ist es vorhersehbar in welchem Adressbereich bestimmte Systemprogramme arbeiten. Hacker versuchen nun Pointer auf selbst kontrollierten Speicher zu legen um so Code einzuschleusen.
Viele Browser Exploits nutzen zum Beispiel Heap Spraying. Der Speicher wird einfach mit so viel ausführbarem Code überladen, bis man einfach verwendbaren Code treffen kann. So nutzt er in einem Beispiel eine JavaScript Schleife die 200 MB an Shellcode in den Speicher schreibt.
Eine Technik, die verhindern soll, dass man jeglichen Inhalt im Arbeitsspeicher als Programmcode ausführen kann ist DEP (Data Execution Prevention), das von modernen CPUs unterstützt wird, aber natürlich auch im System vorhanden sein muss. Im Internet Explorer ist es z.B. deaktiviert - selbst unter Vista. Auch manuell nachinstallierte Software wird nicht durch DEP geschützt. So z.B. der Firefox. Das hat man aus Gründen des Komforts gemacht. In Windows 2003 (Server) funktioniert der Schutz auch für manuell installierte Programme.
Dennoch gibt es verschiedene Möglichkeiten das DEP zu umgehen. Man braucht nur den Adressbereich der ntdll.dll, den man wegen einer 2 Byte Länge nach maximal 256 Möglichkeiten herausbekommt (so genau habe ich den Part nicht verstanden).
Wie entwickelt man also richtig? Hier rechnet er gnadenlos mit C++ ab, das zwar wegen OO Highlevel Programmierung bietet. Aber von einem Großteil der Entwickler auf mit low-level C Programmierung gefüttert wird. Was es oft unsicher macht. Auch geht er natürlich auf die PHP Programmiersprache ein, die zum schlechten Programmieren einlädt (kann wohl fast jeder bestätigen). Als Tipps gibt es den Zuhöhrern auf den Weg, sie sollen ihre Funktionen nach Benutzerrechten und Datenquelle splitten. Damit interne Funktionen nicht direkt mit unverifizierten Daten aus der Außenwelt gefüttert werden.
Zuletzt rechnet er mit ein paar Systemen wie ActiveX, der Google Desktop Suche mit Web-Integration und der PHP Eigenschaft register_globals ab. Auch an Mac OSX sieht er nicht vorbei
Zudem bringt er ein positiv-Beispiel an PHP Entwicklung: MediaWiki. Das sich im Gegensatz zu WordPress von Anfang an um Sicherheit Gedanken gemacht hat.
In dem endlosen Patchen von Software die ursprünglich nicht für Sicherheit ausgelegt ist, sieht er auch kaum Sinn.
Links
Diskussionen???
URL: video.google.com/videoplay?docid=-7185841369679533904
Dauer: 61 Minuten
-7185841369679533904
Übersicht
Alex Sotirov is a vulnerability engineer at determina. He will discuss some latest techniques in reverse engineering software to find vulnerabilities. Particularly, he'll discuss his technique that lead him to find the ANI bug (a critical new bug in WinXP and Vista).
Alex will describe the tools he uses for reverse engineering and show how he reverse engineered ANI Bug. He will continue to discussed Windows security mechanisms (ASLR, /GS) and describe how ANI exploit bypasses them.
Notizen
Die Präsentation beschreibt wie man aus Sicherheitsupdates Schwachstellen findet und diese attackiert. Sie beginnt mit einer Live Präsentation des ANI Exploits. Der Exploit läuft auf einem Webserver und erhält Zugriff auf den Client sobald dieser die Webseite mit einem Browser betritt. Der Exploit funktioniert auf dem Betriebssystem - also auch auf einem Firefox.
Alex Sotirov geht auch auf die Updatepolitik von Microsoft an. Laut seinen Aussagen werden die Security Updates meist heimlich durchgeführt. Eine Sicherheitslücke wird also Update geschlossen und in Wirklichkeit gibt es 5 weitere Schwachstellen. In den Security Bullets findet man natürlich auch die Kopfzeile des ersten Fehlers.
Er zeigt ein paar Tools, mit denen er in seinem Beruf arbeitet um Sicherheitslücken aus Patches zu erschließen und die es ihm möglich machten den .ANI Bug zu finden. Dazu gehört der IDA Pro Disassembler mit seinem mächtigen Plugin BinDiff. Live analysiert er ein Microsoft Update und deckt sogar Fehler im Paket auf.
Außerdem zeigt er die neuen Schutzmechanismen in Vista, zeigt welche Schwachstellen sie haben und wie man sie umgehen kann. Die /GS stack cookies sind aus Performancegründen nur in Funktionen mit Arrays aktiv, müssten aber auch bei Structures aktiv sein. Allerdings würde das ein komplettes rekompilieren des Betriebssystem benötigen. Dadurch werden vermutlich nur gefährliche Systemfunktionen gepatcht (insofern hier nichts vergessen wird).
Eine weitere Neuerung in Vista ist ASLR (Address space layout randomization). Ohne die zufällige Adressvergabe ist es vorhersehbar in welchem Adressbereich bestimmte Systemprogramme arbeiten. Hacker versuchen nun Pointer auf selbst kontrollierten Speicher zu legen um so Code einzuschleusen.
Viele Browser Exploits nutzen zum Beispiel Heap Spraying. Der Speicher wird einfach mit so viel ausführbarem Code überladen, bis man einfach verwendbaren Code treffen kann. So nutzt er in einem Beispiel eine JavaScript Schleife die 200 MB an Shellcode in den Speicher schreibt.
Eine Technik, die verhindern soll, dass man jeglichen Inhalt im Arbeitsspeicher als Programmcode ausführen kann ist DEP (Data Execution Prevention), das von modernen CPUs unterstützt wird, aber natürlich auch im System vorhanden sein muss. Im Internet Explorer ist es z.B. deaktiviert - selbst unter Vista. Auch manuell nachinstallierte Software wird nicht durch DEP geschützt. So z.B. der Firefox. Das hat man aus Gründen des Komforts gemacht. In Windows 2003 (Server) funktioniert der Schutz auch für manuell installierte Programme.
Dennoch gibt es verschiedene Möglichkeiten das DEP zu umgehen. Man braucht nur den Adressbereich der ntdll.dll, den man wegen einer 2 Byte Länge nach maximal 256 Möglichkeiten herausbekommt (so genau habe ich den Part nicht verstanden).
Wie entwickelt man also richtig? Hier rechnet er gnadenlos mit C++ ab, das zwar wegen OO Highlevel Programmierung bietet. Aber von einem Großteil der Entwickler auf mit low-level C Programmierung gefüttert wird. Was es oft unsicher macht. Auch geht er natürlich auf die PHP Programmiersprache ein, die zum schlechten Programmieren einlädt (kann wohl fast jeder bestätigen). Als Tipps gibt es den Zuhöhrern auf den Weg, sie sollen ihre Funktionen nach Benutzerrechten und Datenquelle splitten. Damit interne Funktionen nicht direkt mit unverifizierten Daten aus der Außenwelt gefüttert werden.
Zuletzt rechnet er mit ein paar Systemen wie ActiveX, der Google Desktop Suche mit Web-Integration und der PHP Eigenschaft register_globals ab. Auch an Mac OSX sieht er nicht vorbei
Zudem bringt er ein positiv-Beispiel an PHP Entwicklung: MediaWiki. Das sich im Gegensatz zu WordPress von Anfang an um Sicherheit Gedanken gemacht hat.
In dem endlosen Patchen von Software die ursprünglich nicht für Sicherheit ausgelegt ist, sieht er auch kaum Sinn.
Links
- datarescue.com/idabase/index.htm
- en.wikipedia.org/wiki/ASLR
- en.wikipedia.org/wiki/Data_Execution_Prevention
Diskussionen???