28. Dezember 2008
Der Vortrag an sich war recht cool. Die einzelnen Themen wurden kurz angesprochen und ausreichend vorgestellt, dass man die nötigen Informationen bekam um sich bei Interesse weiter damit zu beschäftigen.
Mailinator bietet eine in den USA beliebte Wegwerfmailadresse. In die Postfächer aller Nutzer kann jeder reinschauen, daher sollte man sich da keine Passwörter hinschicken lassen. So etwas habe ich auch schon mal gemacht, mein Blogeintrag ist von März 2008. Allerdings hat Ben das automatisiert.
Das ist auch nicht so ganz neu, insbesondere wird das in neuer Hardware schon gemacht. Ich schrieb über die Probleme im Mai 2008 und Fefe hat neulich erst wieder was gefunden. Allerdings gibt es inzwischen eine ganze Reihe von Möglichkeiten, da was anzustellen:
- Auf der Black Hat 2008 wurde für den System Management Mode (SMM) etwas in diese Richtung vorgestellt. Peter Stuge von Coreboot könnte sich damit auskennen.
- Mit einem EFI-BIOS kann man sogar Module einbinden, die z.B. TCP/IP und das Filesystem beherrschen und die /etc/shadow nach außen mailen.
- Eine dritte Variante sind PCI-Cards mit Option ROM. Der gesamte Code im Option ROM wird ebenfalls im Ring 0 mit vollen Rechten über das System ausgeführt.
Das ist mal ein cooles Rootkit und wäre vielleicht eine Idee für den Bundestrojaner. Vielleicht wird man in Zukunft über Hardware Anti-Virus nachdenken, also ein Programm, das den PC nach Malicious Hardware scannt.
Die Microsoft libxml-Bibliothek erlaubt zusätzliche Attribute sowohl in Start- als auch in End-Tags. Der Anti-XSS-ISAPI Filter filtert aber nicht alles richtig raus. Beispiel:
</a style=“background:expression(alert(document.cookie))“>
Das ist mal ein cooler XSS, oder 🙂
Außerdem gibt es einen esoterischen Fehler im Internet Explorer, der dadurch behoben wird, dass der Server(!) eine Header-Option setzen muss, damit sich der Browser korrekt verhält. Das erinnert mich an das Security Flag in IPv4. Das ist genauso sinnvoll.
Es gibt ein neues Plugin für den GCC, Dehydra, von Mozilla. Damit kann man statische C und C++ Source Code Analyse durchführen. Natürlich kann man damit nicht alle Fehler finden aber das ist immer noch besser als grep.
Man baue eine ITX-Box mit Wifi Hacking und Re-Injection. Mit 12 Volt-Anschluss für das Auto. Bedienbar über Web, z.B. von einem iPhone aus. So kann man Remote WEP-Cracking durchführen ohne so gefährliche Waffen wie Laptops mit sich rumzuschleppen. Zukünftig vielleicht auch für den Asus EEE oder den Atheros AR5315.
Sehr cool das alles.
Ich suche übrigens immer noch eine/n Programmierer/in, der Assembler, C und Python beherrscht 🙁
Nachtrag:
Jetzt nicht mehr.
Wie letztes Jahr (PortBunny) machte die Einführung des Vortrags FX mit launischen Kommentaren wie „I’m his Boss“. Ich bin sicher, dass FX das gut meint aber die Arbeit von Fabs ist inzwischen so gut und umfangreich geworden, er könnte sich besser präsentieren wenn der „Übervater“ nicht ständig daneben stehen würde. Die Folien kommen auf den Videoaufnahmen leider nicht gut rüber, weiß auf schwarz sollte man eventuell auch nochmal überdenken.
TCP ist ein Protokoll aus den 80ern (RFC 793, 1981), das keine echten Sicherheitsfunktionen bietet sondern lediglich auf Robustness optimiert wurde. Bekannte Probleme sind die TCP Reset Attacks die 2004 von Paul Watson veröffentlicht hat und auf die mit TCP Source Port Randomization reagiert wurde (erinnert einen das zufällig an die Dan Kaminsky DNS Lösung?). Eine weitere Schutzmaßnahme ist die Sequence Number Randomization, die in RFC 1948 beschrieben ist.
Ich versuche mal, die DoS-Szenarien zusammenzufassen, das ist jedoch weder ganz korrekt und schon gar nicht vollständig, im Zweifelsfall verweise ich auf das Video und die Slides von Fabs.
DoS-Szenarien:
- Backlog Queue SYN-Flooding
- Half-open Connections können von der Anwendung nicht abgebrochen werden
- Dienste sollten neue Verbindungen schnell annehmen können, um die Backlog-Queue wieder zu leeren
- Congestion Control Hacking
- man simuliert eine Gigabit-Verbindung um große TCP Windows zu bekommen (z.B. durch ACKs, bevor man die Daten tatsächlich sieht)
- man kann steuern, wie man auf Pakete des Kommunikationspartners antwortet
- der Kommunikationspartner sendet sehr schnell Daten und flutet seine eigene Verbindung
- Man kann eine Verbindung auch in FIN_WAIT1 halten … sehr lange (abhängig von der RTT)
- Der Control Block bleibt offen, so kann man den RAM füllen
- Größe des Control Blocks abhängig von der Window Size
- Fefe’s TCP_DEFER_ACCEPT Bug
Das größte Problem mit all diesen Fehlern ist, dass eigentlich eine Überarbeitung der Architektur von TCP notwendig wäre. Aktuelle Arbeiten beschäftigen sich jedoch eher mit TCP für Satellitenstrecken (hohe Bandbreite aber auch hoher Roundtrip). Eine sicherheitsgetriebene Überarbeitung von TCP dürfte aktuell nicht realistisch sein.
Ein paar Ideen von Fabs sind darüber hinaus recht clever, beispielsweise viele Verbindungen aufmachen und das Congestion Window zu tunen. ich warte ja, dass das mal irgendjemand richtig cool implementiert. Insgesamt hat mir der Vortrag ganz gut gefallen, man hätte jedoch noch ein paar „Doomsday“ und „wir werden alle störben“ Nachrichten einbauen können 🙂 Schade, dass die Folien noch nicht online sind.
Stefan Esser ist wahrscheinlich einer der besten PHP Security Spezialisten, die es gibt. Bekannt wurde er insbesondere durch einen Month of PHP Bugs, als er jeden Tag eine neue PHP Sicherheitslücke veröffentlichte.
Übersicht der Produkte
- ZendGuard
- onCube PHP Encoder
- Source Guardian (unter verschiedenen Namen)
Übersicht der Techniken
- PHP Bytecode Encryption
- Obfuscation
- Anti-Fuzzing Protection
Der PHP Bytecode besteht aus: Opcode, Result(-Operand), Operand 1, Operand 2, Extension, PHP Source Code Line Number. Insbesondere vergessen einige Encrypter, die Source Code Line Number zu entfernen. Das erleichtert später eine Zuordnung und Analyse. In der ZendEngine gibt es fünf Operand-Typen: CONST, TMP (temporary variable), VAR, CV (compiled variable) und UNUSED. Der Executor führt den Bytecode aus, dabei hat jeder Opcode mit jedem Operand-Typen seinen eigenen Opcode-Handler.
Stefan Esser hat sich umfangreich mit allen Möglichkeiten beschäftigt, verschlüsselten PHP-Bytecode wieder zu decrypten. Seine verwendeten Techniken sind recht cool aber wie bei einigen anderen Vorträgen hat das für mich leider keine echte praktische Relevanz. Stefan Esser plant, seine Software im Januar zu veröffentlichen
Die Präsentation von Stefano und Kuza behandelt sehr spezielle und sehr clevere Angriffe gegen Webanwendungen und Browser. Viele der Angriffe basieren auf Lücken und Fehlern im Browser, Objekte und Zugriffe korrekt zu filtern. Leider sind die meisten Angriffe inzwischen so speziell, dass man sich im Detail damit auseinandersetzen muss. So nebenbei einlesen geht leider gar nicht mehr.
Die Risiken von Cross Site Scripting (XSS) sind seit 2005 durch eine Veröffentlichung von Amit Klein bekannt. Erweiterung zum Code Flow wurden 2008 bekannt. Die kritischen Lücken drehten sich hauptsächlich darum
- HTML zu erzeugen
- Dokumenten-Inhalte zu verändern
- Dokumenten-URLs zu verändern
- Windows zu öffnen/schließen
Insbesondere beschränkt sich XSS nicht darauf simple Cookies auszulesen.
Manipulierte HTML-Objekte (IMG, OBJECT, FORM, …) erlauben häufig Javascript-Ausführung. Ein Beispiel ist die Nutzung von Iframes in IMG-Objekten, die Javascript-Ausführung im IE7 erlaubt.
Aktuelles Thema ist Javascript in CSS. insbesondere kann eine solche Javascript-Funktion Inhalte der Seiten auslesen. Mit HTML5 ist sogar der Zugriff auf entfernte Seiten möglich. Mit der Injektion in eckige Klammern ist die komplette Kontrolle über Objekte möglich:
some_var = document[user_input]; -> setzt man user_input auf ‚cookie‘ enthält man Zugriff auf die Cookies. Das funktioniert auch umgekehrt.
Die diversen Erweiterungen von HTML, insbesondere HTML5 erlauben neue Angriffe wie Client-Side SQL-Injection. Browser-Hersteller sind auch in Zukunft gezwungen, neue Möglichkeiten und Funktionen für Webentwickler zu Implementieren, die häufig unzureichend geplant oder auf schwachen Sicherheitsfunktionen wie der Same-Origin-Policy basieren.
Der Inhalt des ganzen Vortrags von Jürgen Pabel dreht sich um die Möglichkeiten, eine komplette Festplatte, insbesondere die Systemplatte zu verschlüsseln. Das kann entweder in Software oder neu auch in Hardware erfolgen. Dabei geht es nicht um verschlüsselte Container oder Archivdateien sondern tatsächlich um Verschlüsselung auf Plattenebene. Die gängigen Varianten sind:
- USB/Firewire-Festplatte mit Crypto-Controller (Fingerprint/PIN-Authentication)
- Festplatte mit SATA Security Option
- Software-Treiber
- Hardware-Modul (PC-Card)
Kritisch ist die Pre-Boot-Authentication. Normalerweise lädt das BIOS diese Software von einem unverschlüsselten Bereich der Platte. Bei Linux muss das in die Boot-Partition integriert werden. Von dort werden die Schlüssel zum Zugriff auf die verschlüsselten Bereiche bereitgestellt. Unter Linux wird dann einfach die Systempartition durch Device Driver Hooking gemountet, in Windows muss der NT-Kernel um die Verschlüsselungsfunktion mittels Low-Level Filter Driver erweitert werden.
Für den Anwender ist die wichtigste Unterscheidung vermutlich, dass es unter Linux noch keine „in-place“ Verschlüsselung gibt, auf einer verschlüsselten Platte muss immer erst ein neues Filesystem angelegt werden. Windows-Software kann bestehende Partitionen in der Regel bei der Installation nachverschlüsseln.
Die detaillierte Produktvorstellung fand ich jetzt nicht so spannend, ich schätze das ist ein Abfallprodukt seiner Consulting-Arbeit. Ich persönlich verwende Utimaco SafeGuard Easy und TrueCrypt, mit beidem habe ich gute Erfahrung gemacht. Utimaco verschlüsselt die ganze Platte und TrueCrypt nochmal einzelne Container. Und meine Passwörter liegen in einem KeePass-Safe in einem TrueCrypt-Container auf einer Utimaco-verschlüsselten Platte. Und für die ganz wichtigen Sachen gibt es bei TrueCrypt noch Hidden Volumes. Ich denke, das dürfte ausreichen.
Als Übersicht der verschiedenen Möglichkeiten und Technologien fand ich den Vortrag jedoch ganz interessant.
Ich bin in Saal 1 sitzen geblieben, weil sonst nirgendwo Plätze zu kriegen sind. Jetzt muss ich mir leider den DNS-Vortrag von Dan Kaminsky antun. Ich halte den ja für etwas überschätzt.
Die von Dan vorgestellte Agenda lässt meine schlimmsten Befürchtungen wahr werden. Es geht um die DNS-Lücke die er so toll konspirativ gehandhabt hat. Der halbe Vortrag dreht sich also um die Ursachen und theoretischen Folgen der DNS-Geschichte und darum, wie toll Dan ist. Egal. Betrachten wir es wie Hollywood: die Show ist sehr gut.
Entdeckt hat die Lücke im Grunde schon 1999 Daniel Bernstein. Aber 99 hat sich halt noch keiner darum gekümmert. Erst neun Jahre später wurden die Angriffe aktuell.
Dan wirft jedenfalls kräftig mit Screenshots und dicht beschriebenen Slides um sich, mit denen er einen Angriff demonstriert. Das sieht recht locker aus, in der Praxis handelt es sich aber um einen harten Brute Force Angriff auf eine 16-Bit Transaction ID und die muss halt erst einmal erraten werden. Das kann man natürlich automatisieren aber das kann auch mal eine ganze Weile dauern. Dan kommentiert das zusätzlich auf seine lockere Art, darum wirkt das recht einfach und sehr lustig. Aber so schnell kann man die Präsentationsfolien nicht lesen. Entweder man sieht sich das im Stream nochmal an oder wartet ob die Slides veröffentlicht werden.
Zum Ende kommt dann die große Politik. Was braucht es, um DNS fit für das aktuelle Jahrtausend zu machen. Für Dan ist DNSSEC die Lösung. Alternative Ansätze wie DNSCurve von Bernstein werden erst abgekanzelt bevor Dan sich zu konkreter Kritik (insbesondere zu hohe CPU-Anforderungen durch die Crypto) herablässt.
Das Kernproblem bleibt jedoch … DNS ist die einzige global verteilte Infrastruktur, sie wird für alle möglichen Anwendungen inkl. Sicherheitsfunktionen und Authentisierung verwendet und eine Lösung für Secure DNS ist nicht in Sicht. Trotz aller Aufrufe von Dan Kaminsky.
27. Dezember 2008
Der Congress ist jetzt offiziell ausverkauft. Nur wer von weit her kommt, USA und so, wo es Chaos mit dem Wetter geben soll, kommt noch rein. Berliner die noch kein Ticket haben, haben jetzt Pech gehabt.
ich bin dieses Jahr mit einem Asus Eee 1000H auf dem Congress unterwegs, der ist klein und leicht und gut tragbar und das Akku läuft auch schön lange. Natürlich habe ich das System neu installiert, Dual-Boot, Linux und XP, alle Hackingtools drauf, die Festplatte ist verschlüsselt, BIOS-Passwort, alle Schikanen. War ’ne Menge Arbeit zu Weihnachten. Aber man weiß ja nie unter den ganzen Hackern auf dem Congress 😉
Jedenfalls verlangt die Asus-Software wie bei den meisten Herstellern die Annahme einer Lizenz:
Und ganz ehrlich, das ist mal eine Lizenz ganz nach meinem Geschmack. Jetzt muss ich mir nur noch eine passende Lizenz ausdenken und einfügen 🙂
Nachtrag zum Cold Boot Attack-Vortrag von Jacob Appelbaum. Die Genies von Princeton (dort liegt die Software zum Download) sind leider manchmal nicht so genial. Der folgende Screenshot ist von einem Server des Center for Information Technology Policy der Princeton Universität. Wo liegt der Hund begraben?
Genau: Der Code, die Signaturen und der Public Key liegen im gleichen Verzeichnis auf dem gleichen Server. Wenn ein Angreifer also den Server kompromittiert und die Software manipuliert, kann er trivial mit seinem eigenen privaten Schlüssel neue Signaturen erzeugen und seinen Public Key auf dem Server ablegen. Eine standardmäßige Kontrolle würde eine Kompromittierung daher nicht erkennen. Da könnte man auch billige MD5-Hashes verwenden, die sind genauso toll und leichter zu bedienen.
Wenn man schon Archive signiert, dann muss der Public Key entweder mittels Zertifikat auf einen bekannten Root-CA Key zurückgeführt werden oder auf einem anderen Server liegen. Ansonsten kann man sich den Unsinn mit den Signaturen gleich sparen.
