Mitternachtshacking

Flash ist inzwischen ein beliebter Loader für Malware und andere Schadprogramme, da Flash eine Reihe von Sicherheitslücken enthält. Fukami von SektorEins ist vermutlich einer der besten Flash-Experten die es bei uns gibt. BeF ist der Autor von erlswf. Die Analyse von Flash ist nicht trivial, weil Flash  mit Obfuscation-Techniken gesichert werden kann.

Javascript kann via ExternalInterface.call() geladen werden. Darüber sind eine Vielzahl von Angriffen möglich. Erlswf prüft Flash-Dateien und kann typische Probleme wie ungültige Komprimierung oder unbekannte Opcodes herausfiltern. Dazu muss man das SWF-Format kennen.

SWF ist ein Containerformat und besteht aus einem Header, einem File Attribute Tag, diversen Daten-Tags und einem End Tag. Die Daten-Tags können Aktionen (DoAction, …) Mediadaten (Bilder, Filme), etc. enthalten. Dabei unterscheiden sich die Tags bei ActiveScript2 und 3 grundlegend. doAction aus AS2 besteht aus einem Header, vielen Actions und einem EndAction Tag. doABC besteht aus einem Opcode und Optionen. Flash 9 unterstützt außerdem die Funktion loadBytes, mit der eine Bytefolge gelesen, on the fly verändert und interpretiert werden kann.

Zur Analyse von Flash-Dateien gibt es keine brauchbaren dynamischen Tools wie Sandboxen, die den Flash-Lauf analysieren. In der Praxis beschränkt man sich zur Zeit daher auf die statische Analyse der Flash-Dateien. Dabei ist die Obfuscation natürlich störend. Ein Großteil des Vortrags beschäftigt sich mit den Möglichkeiten, Flash zu analysieren und Obfuscation aufzudecken. Insgesamt eine coole umfangreiche Arbeit aber wiedermal etwas, das für mich keine besondere Relevanz hat.

In der Agenda stehen nur Ralf-Philipp Weinmann, Andreas Schuler, Erik Tews, auf der Bühne saßen sie jedoch zu viert und erklären uns, wie DECT funktioniert. Für diesen Vortrag habe ich mich kurzfristig entschlossen. Leider ist auf ihrer Webseite deDECTed.org noch nichts online.

Vorläufer von DECT sind CT1(+) und CT2. CT1 und CT1+ darf ab 01.01.2009 nicht mehr verwendet werden, da die Frequenzen für GSM reserviert sind. DECT wird praktisch überall verwendet, in Schnurlostelefonen, Wireless ISDN, Babyfon, Notrufen, Türöffnungssystemen, schnurlosen EC-Kartenleser und sogar Verkehrsleitsysteme (u.a. von Siemens). Vermutlich gibt es über 30 Millionen DECT-Endgeräte in Deutschland.

Typische Kürzel:

• FP – Fixed Part (Basisstation)
• PP – Portable Part (Handgerät)
• RFPI – Radio Fixed Part Identity (Identifikationsnummer)
• IPUI – International Portable Users identity (Nummer des eingewählten Geräts)
• DSC – DECT Standard Cipher (geheim)
• DSAA – DECT Standard Authentication Algorithm (geheim)
• UAK – User Authentication Key

DECT ist standardisiert im ETSI Standard 300175, verwendet GFSK Modulation und nutzt in Europa die Frequenz 1880-1900 MHz. Das DECT-Protokoll mit A- und B-Feld erinnert ein wenig an ISDN und den D- und B-Kanal. Das Telefon sendet nicht im Idle-Mode (keine Funkaktivität!), synchronisiert sich mit der Basisstation und initiiert die Verschlüsselung. Bei einem Gespräch wird der aktuell beste Kanal (wenig Rauschen, keine Aktivität) verwendet.

Sniffen ist nicht so einfach, da die Stationen nicht synchronisiert sind. Viele Pakete enthalten keine Adressen, die Zuordnung ist daher nur über Kanal und Slot möglich, das durch die fehlende Synchronisation erschwert wird. Außerdem ist nicht bekannt, in welchem Kanal und Slot ein Endgerät anfängt zu senden. Zum Descrambling der Pakete muss zusätzlich die Framenummer bekannt sein, ein Problem wenn Frames verloren gehen.

• USRP DECT Sniffer, kann alle Pakete aller Kanäle sniffen jedoch nicht senden. Insbesondere ist das Time-Multiplexing ein Problem. Kosten ca. 1000 Euro.
• ComOnAir II DECT Sniffer, als Basisstation für SIP gedacht. Kosten ca. 23 Euro. Kommt jedoch nur mit Windows-Treiber. Linux-Treiber Entwicklung ist knifflig, da der Baseband-Chip ein spezieller DECT-Chip ist, der nirgendwo sonst verwendet wird.
• ComOnAir III Karte ist etwas größer, hat eine LED, kann zerlegt werden. Kernchip ist ein SC14421.

Wenn keine Verschlüsselung aktiv ist, kann man DECT ganz einfach mitsniffen und damit Gespräche abhören und aufzeichnen. Dafür genügen Standard-DECT-Geräte. Wenn Verschlüsselung aktiv ist, dann wird es etwas komplizierter. Man muss eine Basisstation simulieren und mit dem Telefon unverschlüsselt kommunizieren. Die Gespräche relayed man dann an die eigentliche Basisstation. Das funktioniert, weil sich das Netzwerk nicht am Endgerät authentisieren muss. Das erinnert mich an die IMSI-Catcher im GSM-Netz, die machen das ganz genauso. Ein klassischer Man-in-the-Middle Angriff mit Rouge Basestation.

DECT setzt einen geheimen Algorithmus zur Verschlüsselung ein, DSAA. Praktisch besteht das aus vier Algorithmen, A11, A12, A21 und A22, die reverse engineered wurden. Das ist schon sehr cool 🙂 Die Details führe ich hier nicht auf, die kann man später sicher noch nachlesen. Die Cryptanalysis hat mehrere Schwächen im Algorithmus gezeigt, insbesondere für rundenreduzierte Versionen des Cassable-Algorithmus, die volle Version ist jedoch noch nicht gebrochen. Die Cryptanalysis wird im Detail auf der CT-RSA 2009 vorgestellt, Source Code in Java und C ebenfalls.

Ein weiterer Angriffspunkt sind die verwendeten Zufallszahlengeneratoren, die in allen untersuchten Geräten schlecht waren. Hier bietet sich ein weiterer Ansatz, die Verschlüsselung zu brechen

RFID verbreitet sich rapide in unserem Leben und ermöglicht (noch theoretisch) die Komplette Überwachung der Menschen im täglichen Leben.

Der Vortrag von Henryk Plötz und Karsten Nohl stellt die aktuellen Angriffe auf RFID inkl. aktuellen Informationen zu Mifare vor.

• Proxy/Relay Attack, der Angreifer klinkt sich quasi wie bei einem Man-in-the-Middle Angriff ein. Man kann dann die Datenübertragung manipulieren.
• Emulation Attack, man simuliert mit komplexerer Elektronik, ein RFID-Tag zu sein, am besten ein anderer 🙂 Das funktioniert besonders gut bei Zugangskontrollsystemen.
• Replay, bei dem man aufgefangene Signale einfach identisch wieder abspielt. Das klappt natürlich nur, wenn keine Krypto mit Zufallszahlen (Nonces) im Spiel ist. Insbesondere Mifare Classic hat hier ein Problem, weil die „Zufallszahlen“ vorhersagbar sind.
• Brute Force Key Search, oft nicht möglich wenn das über die Karte erfolgen muss, mit vielen Algorithmen aber möglich, wenn man die Algorithmen in FPGAs implementiert da die Schlüssellänge oft recht kurz ist. Eine Folge der „Security by Obscurity“ und den geheimen Algorithmen. Rainbowtables sind ebenfalls denkbar.
• Algebraische Angriffe, dabei wird die Rückgabe ausgewertet um geeignete neue Anfragen zu finden, die auf den Schlüssel zurück schließen lassen. Sogenannte „Guess-and-Determine“ Angriffe. Ein Tool zur Auswertung ist beispielsweise MiniSAT.

Weitere Karten mit schwacher Crypto sind

• Mifare Classic, Hitag2
• Legic Cards
• einige Atmel Cards

RFID Tools:

• TI EVM, kann für Fuzzing verwendet werden
• OpenPCD, Multi-Protocol RFID Reader
• OpenPICC, RFID Emulator

Ganz neu gibt es den OpenPICC2, der ganz coole neue Funktionen mitbringt.

Die Präsentation von Tor Bjorstadt (wie kriegt man eigentlich so einen norwegischen Strich durch das o?) lieferte einen aktuellen Überblick der Fortschritte in der  Stream Cipher Entwicklung.

Die bisherigen verwendeten Verfahren sind alle nicht mehr so ganz taufrisch:

• E0: wird in Bluetooth verwendet … broken
• A5/1, A5/2: wird in GSM verwendet … broken
• Mifare Classic: in den RFID-Karten … broken
• Keeloq: häufig in Garagentoröffnern … broken
• EU Nessie 2000-2003: …  alle 6 Verfahren mit Lücken
• RC4: in Webbrowsern, WEP und WPA … zeigt deutliche Schwächen

Aktuell bleibt uns nur AES-CTR als verlässliches Verfahren.

Die  EU hat deshalb einen neuen Wettbewerb, eSTREAM (ENCRYPT Stream Cipher project), gestartet bei dem nicht nur ein Algorithmus sondern eine Auswahl an Algorithmen für die sichere Implementierung entwickelt werden sollten. Dabei gibt es ein Profil 1 zur möglichst performanten Implementierung in Software und ein Profil 2 zur möglichst ressourcenschonenden Implementierung in Chipkarten. Für jedes Profil sollten vier Algorithmen zur Auswahl gestellt werden. 24 Algorithmen wurden eingereicht, etwa die Hälfte wurde im Laufe des Wettbewerbs gebrochen.

Algorithmen in Profil 1: HC-128, Rabbit, Salsa20/12, SOSEMANUK

Die Details der Algorithmen kann man in der begleitenden Doku von Tor nachlesen. Ein paar Highlights:

• HC ist nach dem Entwickler „Hongyun’s Cipher“ benannt und der einzige Algorithmus mit S-Boxen.
• Salsa20/12 ist von D. J. Bernstein und verwendet 12 von 20 spezifizierten Runden. Der Algorithmus mit allen 20 Runden ist Salsa20/20. Eine Weiterentwicklung ist ChaCha.
• SOSEMANUK bedeutet in einigen Sprachen Snowsnake (Schneeschlange), weil der Algorithmus Anleihen der Algorithmen Snow und Serpent verwendet. Er ist  der komplizierteste Algorithmus und wurde daher auch als Frankencypher bezeichnet.

Im Hardware Profil gibt es die Algorithmen: Grain, MICKEY, Trivium

• Grain ist der kleinste Algorithmus  und lässt sich in etwa 1300 NANDs implementieren.
• MICKEY steht für Mutually Irregular Clocking KEYstream generator … harhar

Ein vierter Algorithmus, F-FCSR-H wurde gebrochen, Angriff sind in Realtime durchführbar, der Algorithmus wurde folglich zurückgezogen. Das zeigt, dass neue Algorithmen nicht automatisch sicherer sein müssen.

Fazit:Im Zweifel ist AES-CTR noch die beste Methode

Außerdem läuft gerade die NIST SHA-3 Hash Function Competition.
Aktueller Stand: 64 Submissions, 51 akzeptiert, 17 gebrochen 🙂

Das Thema bleibt spannend.

Sowjet-Unterzögersdorf ist die letzte sowjetische Enklave auf österreichischem Boden. Wer nicht weiß wo das liegt, hier ist eine Karte:

Für die letzten aufrechten Kommunisten ist das Leben nach dem Zusammenbruch der Sowjetunion nicht leichter geworden. Sogar die Farbe von den Schildern der Freundschaft blättert ab:

Die Unterzögersdorfer haben sich deshalb mit neuen Technologien vertraut gemacht und ein Computerspiel entwickelt, das ihre Situation darstellt:

mit Screenshot:

Und Johannes Grenzfurtner, der Chef von Monochrom kann endlich wieder entspannt in die Zukunft blicken:

Nachtrag:

Johannes, wenn Du die Fotos willst, schreib ne Mail oder einen Kommentar. Ich warte auf die Beta!

Eines muss man den Italienern lassen, sie haben schon immer unkonventionelle Ideen gehabt.

• Netphun: ICMP redirect (13 attacks that works)
  • Tools: hping, scapy, irpas, icmp_redirect, netwag
• Netphun: ICMP PMTU DoS
  • hat keine praktische Relevanz
• Blind SQL Injection: Mappable method cause blind hurts too
  • Tools: Charmap
• Diverse andere Sachen aber wenig, das mich noch interessiert hat

Die meisten Sachen wurden nur ganz kurz angesprochen, ich schätze mal man muss in seinem Blog nachlesen um die Details zu bekommen.

Thorsten Holz ist dem einen oder anderen bereits durch seine Arbeit für das deutsche Honeynet Project bekannt. Außerdem beschäftigt er sich seit geraumer Zeit mit Botnetzen und Schadprogrammen.

Klar, auf die üblichen Phishing-Mails fällt praktisch niemand mehr herein. Vielleicht noch ein paar trottelige Ebay-Nutzer, aber generell ist das nicht mehr State-of-the-Art. Die Angreifer verwenden daher Schadprogramme wie Viren, um Zugriff auf Zugangsdaten wie Ebay oder Online-Banken zu bekommen. Diese Viren enthalten einen Keylogger, der die ausgespäten Daten zu einem Server im Internet, der Dropzone schickt. Meist ist die Dropzone auch ein gehackter Rechner. Schadprogramme werden häufig mittels Social Engineering verbreitet, beispielsweise durch E-Mails mit dringend zu öffnendem Attachment. Aktuelle Trojaner sind beispielsweise Nethel/Limbo und ZeuS/Wsnpoem/Zbot.

Nethel/Limbo verwendet sogenannte Browser Helper Objects, Plugins für den Internet Explorer und klaut Zugangsdaten, Passwörter und Cookies. ZeuS verwendet keine BHO sondern injiziert sich direkt in Windows-Systemprozesse. Er kann außerdem HTML-Code in Webseiten injizieren, z.B. zusätzliche Formularfelder für die SSN oder CC-Nummer. Und er stiehlt sogar Zertifikate. Details zu ZeuS findet man bei reconstructer.org.

Dropzones entdeckt man am besten mit Honeypots, die von einem Angreifer übernommen werden können und genau beobachtet werden. Dann analysiert man, welche Netzwerkverbindungen vom Honeypot aufgebaut werden. Typische Honeypots sind Capture-HPC, HoneyClient, phoneyc. Alternativ kann man in einem Honeypot auch auf Spamattachments klicken und schauen was passiert. Dabei versucht man das typische Verhalten von Menschen automatisiert zu simulieren, das heißt den Browser starten, Webseiten ansurfen, Credentials eingeben, usw. Dazu wurde ein SimUser basierend auf AutoIT mit 17 Verhaltenstemplates entwickelt. Schadprogramme können auch mit CWSandbox analysiert werden.

Ziele von Zeus in Deutschland sind hauptsächlich Volks- und Raiffeisenbanken und Fiducia, international praktisch alle größeren und kleineren Banken. Der Zugang zu einem Bankaccount ist zwischen 10 und 1000 USD wert, Kreditkarten nur noch 0,40-20 USD und Identitäten nur noch 1-9 USD.

Mein Geschäftsmodell wäre ja jetzt, die Dropzones zu finden, zu hacken und die dort hinterlegten Daten weiterzuverkaufen. Dazu muss man weder Viren programmieren noch macht man sich selbst groß die Finger schmutzig. Aber Thorsten hat die Daten leider schon alle an AusCERT gemeldet. 😉

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.

• Replace Your Face Just Like The Laughing Man

• Weaponizing Mailinator

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.

• BIOS Rootkits in gebrauchter Hardware

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.

• Random XSS

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.

• Code Audit

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.

• ITX & WEP-Cracking

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.

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