daily.out
2010-03-25
Pwn2Own: Prüfung der Nachrichten 2010
Ich überprüfe meine Pwn2Own Vorhersage an zwei Beispielen:
Heise, ansonsten für jede Schlagzeile zu haben, lieferte nicht nur einen korrekten und sachlichen Bericht, sondern wies sogar im letzten Absatz auf die Punkte hin, deren Fehlen ich sonst immer kritisiere und in meiner Vorhersage befürchtet hatte: In der Show werden lange vorbereitete Exploits vorgeführt und man kann aus einem "Stehenbleiben" nicht auf Sicherheit schließen, weil die Hacker manches Ziel gar nicht in Angriff genommen haben.
Wenn jedoch ein Ziel "fällt" dann kann man aufgrund der Schwere des Einbruchs auf die Gefährlichkeit des Fehlers schließen. Beispielsweise wäre ein Angriff, der Interaktion auf Opferseite erfordert, nicht so gravierend wie einer, der ohne Opferhilfe funktioniert. Ebenso sind erreichte Systemrechte schwerwiegender als weniger erlangte Rechte.
MacTechNews passierte diesbezüglich ein Ausrutscher. Dort steht etwas von "innerhalb kürzester Zeit gehackt" und erlangten "systemweiten Zugriffsrechten". Es ist jedoch beides falsch, denn das Besuchen der präparierten Seite geht zwar schnell, aber das Finden des Fehlers und das Schreiben des Exploits war lange vor der Vorführung vorbereitet und dauerte seine Zeit. So etwas macht auch Charlie Miller trotz seiner Erfahrung nicht an einem Tag. Wer es nicht glaubt, mag ihn fragen oder seine Tweets und Interviews lesen.
Den speziellen vorgeführten Exploit hat er laut ZDNet "in weniger als einer Woche geschrieben". Bevor er jedoch mit dem Schreiben überhaupt anfangen konnte, war noch andere Arbeit zu erledigen: Das Fuzzing zur Provozierung von Fehlern und deren Analyse auf Tauglichkeit. Dabei versorgt man das Zielprogramm mit vielen unerwarteten Eingaben und schaut, ob Fehler auftreten und wie man diese nutzen könnte. Insgesamt war also locker mehr als eine Woche nötig.
Er hat auch keine root-Rechte erlangt, sondern eine Shell im Kontext des angegriffenen Benutzers, der seine Seite besuchte, gestartet. Das ist das typische Vorgehen bei solcher Fehlerausnutzung, nur daß man sonst noch die Shell an einen Port bindet, um ihr per Netz dann komfortabel weitere Befehle geben zu können. In dem Bericht von MacTechNews kommt straferschwerend hinzu, daß sie die irreführenden Passagen fett gedruckt haben. Auch eine Art, Fehler zu markieren ;-)
Aktualisierung 2010-03-26
Natürlich sind solche Bugs gefährlich und ärgerlich. Allerdings kann man sie nicht mit letzter Sicherheit während der Programmierung vermeiden. Was man tun kann, ist wie immer, Safari im Sandkasten einzusperren. Das geht mit meiner Anleitung problemlos und sorgt dafür, daß kein Exploit mit Hilfe solcher Bugs ausbrechen kann, insbesondere kann Safari damit keine anderen Programme öffnen.
Wünschenswert wäre, daß Apple einen solchen Sandkasten hart einprogrammiert für Safari verwendet. Das ist seit Leopard möglich und würde Safaris Teilnahme an solchen Wettbewerben sinnlos machen. Allerdings ist eine extern definierte Sandbox wie in meinem Beispiel ebenso sicher.
Aktualisierung 2010-04-02
Im Gegensatz zur oben beschriebenen Sandbox-Lösung sind Anti-Viren-Programme gegen solche Angriffe völlig wirkungslos:
Man besucht per Web-Browser eine "böse" präparierte oder eine normalerweise "gute" aber nun von Dritten manipulierte Seite. Der Web-Browser hat eine oder mehr ungünstig programmierte Stellen, die einen Pufferüberlauf ermöglichen. Diese Stellen hat ein Angreifer durch Bombardieren des Web-Browsers mit zufälligen ungültigen Eingaben (Fuzzing) bei sich zu Hause entdeckt und dann eine Eingabe entwickelt, die dieses fehlerhafte Verhalten zum Einschleusen von Code in den Web-Browser ausnutzt. Diese Eingabe, der Exploit, wird durch den Besuch der Seite vom Web-Browser verarbeitet. Er "verschluckt" sich daran und führt ungewollt untergeschobene Anweisungen aus. Typischerweise solche, die eine Shell öffnen. Dieser wird dann gesagt, sie möge einen Port öffnen und dort auf weitere Befehle von außen warten. Oder eben wie im Falle des iPhones bestimmte Dateien an den Angreifer schicken. In keinem Fall können hier Anti-Viren-Programme eingreifen, da es nichts zu Scannen gibt auf der Platte. Der Web-Browser interpretiert einfach ausgedrückt irrtümlich die Seite teilweise als Befehle, die er ausführen soll. Eine Sandbox verhindert das Ausführen der eingeschleusten Befehle, weil sie dem Browser verbietet, andere Programme zu öffnen und auf Verzeichnisse mit privaten Daten zuzugreifen und alles, was er sonst noch nicht tun sollte.
2010-03-21
Pwn2Own Vorhersage
Auch in diesem Jahr findet wieder ein Hacker-Wettbewerb statt, bei dem man die Geräte gewinnen kann. In den letzten beiden Jahren sah das unter anderem so aus:
- daily.out: MacBook nicht gehackt in zwei Minuten
- daily.out: MacBook wieder nicht gehackt in zwei Minuten
Für dieses Mal erwarten die Hacker Charlie Miller und Dino Dai Zovi, daß die Presse wieder einmal völlig das Thema verfehlt und Sensations-Schlagzeilen formuliert, die nichts mit der Realität zu tun haben. Auf Twitter mutmaßen sie seit ein paar Tagen, welche Dummheiten dabei rauskommen könnten wie zum Beispiel "iPhone gehackt in 3,6 Sekunden".
Die Presse ignorierte bisher jedes Mal die Zeit, die die Hacker an Vorbereitung benötigen: Das ist zum einen die Zeit, überhaupt einen Fehler in einem Programm zu finden. Zum anderen die Zeit, einen passenden Exploit zu schreiben. Zum Start des Wettbewerbs liegen die Exploits in der Regel auf den Web-Servern der Hacker und warten darauf, während der Veranstaltung aufgerufen zu werden. Der Aufruf dauert solange, wie man braucht, die Adresse einzutippen. Die Presse vermeldet dann diese Eingabe als Hack-Zeit.
Die Hacker amüsieren sich leicht frustriert über so viel Dummheit der Presse und überlegen, verkürzte Adressen zu verwenden, um Tippzeit für die Web-Adressen zu sparen, damit sie ihre "Bestzeit" nochmals unterbieten können.
Charlie Miller schreibt ferner auf Twitter, daß er nicht 20 Apple-Bugs auf der CanSecWest-Konferenz enthüllen wird, sondern, wie er 20 Apple-Bugs gefunden hat. Damit spielt er auf bereits geschriebene falsche Presse-Artikel an, die ersteres behaupten.