29. Dezember 2009
DECT ist das Standardprotokoll für Schnurlostelefone in Europa.
DECT verwendet zwei proprietäre Algorithmen (DSAA: DECT Standard Authentication Algorithm und DSC: DECT Standard Cipher) die beide optional sind. DSC ist inzwischen Reverse Engineered. Ich bin jetzt kein Cryptoguru, darum habe ich die Details nicht alle verstanden aber prinzipiell wird schon klar, dass der Algorithmus nicht der Weisheit letzter Schluss ist. Das ist ein generelles Problem mit geheimer Crypto, da basteln irgendwelche Ingenieure was und müssen sich dann von den Mathematikern sagen lassen, das taugt nichts.
Der einzige Nachteil dieser Arbeiten ist, dass die Industrie inzwischen mit deDECTed zusammenarbeitet um die Lücken im System zu schließen. Wenn irgendwann also die alten DECT-Telefone ausgetauscht werden (das kann gut mal 15 Jahre dauern) dann hat sich das mit den Lücken.
28. Dezember 2009
FX, obwohl kein Flash-Programmierer berichtet (nein, ranted) über das Sicherheitsmodell von Flash. Wir wissen bereits von den Vorträgen von Fukami, dass das ein echtes Problem ist. Gerade mit den Erweiterungen in Flash 9 und später sind Sockets und damit viele neuen Angriffe gegen den Client möglich. Die Prinzipien wie Same Origin Policy sind im großen und ganzen bekannt. Ihre Schwächen von Dan Kaminsky aufgedeckt worden. Viele Sicherheitseinstellungen z.B. zu Flash LSOs können nur über eine Flash-Applikation auf der Webseite von Macromedia gemacht werden. Zusätzlich listet Securityfocus rund 40 Sicherheitslücken in Flash auf.
Angriffe gegen Flash:
- DNS Rebinding (siehe Dan Kaminsky)
- OS Enumeration (um targeted Exploits schreiben zu können)
- Exploits
- etc.
Malware
- Redirector/Downloader
- Binary Exploits
- Web Attack Vehicle
- z.B. SWF AdJack/Gnida
- z.B. Downloader Trojans
Flash-Malware wird nebenbei extrem schlecht von Virenscannern erkannt. Da Flash meistens komprimiert wird, ist die Erkennung von unkomprimierten Dateien noch viel schlechter. Virustotal ist Zeuge. Aber das ist nichts neues.
Flash besteht aus zwei Virtual Machines, AVM1 (das Originalflash und für über 80% des Flash-Inhalts im Internet zuständig) und AVM2 (nach ECMA-262, für ActionScript3, fast wie Javascript). Theoretisch ist das recht clever, praktisch ist das ein echtes Problem. AVM1 wurde mit SWF3 eingeführt und mit SWF4 auf eine Turing-komplette Maschine erweitert. SWF5 hat dann Typen eingeführt. SWF9 hat die AVM2 eingeführt. Aktuell ist SWF10 und alles muss abwärtskompatibel sein! Flash kann Code an verschiedenen Stellen enthalten: DoAction, DoInitAction, DefineButton2 im ButtonRecord2 sowie zwei weitere Stellen. Viele Tools analysieren nur den Code in DoAction bzw. DoInitAction.
Nun gibt es ein neues Tool, den Blitzableiter, einen Flash File Parser in C# der auch auf Mono laufen soll. Und damit kommt auch die bei FX schon übliche Marketingveranstaltung seiner neuen Software. SWF Obfuscation ist nicht sehr sinnvoll. Die meisten Flash-Obfuscator erzeugen invaliden Code der von statischen Codeanalysetools nicht mehr akzeptiert wird. Insgesamt funktioniert Blitzableiter mit 82% der von Fukami bereitgestellten Flash-Programme, bläht den Code jedoch auf 224% auf. Ob das Programm wirklich nützlich ist, vermag ich nicht zu beurteilen.
Praktisch muss das Tool jedoch nicht nur Flash sondern auch diverse andere Formate parsen können. Damit läuft FX meiner Meinung nach in die Falle der meisten Virenscanner, dass Parser für diverse Fileformate extrem Komplex sind, die dann wieder Exploits nach sich ziehen. Außerdem werden diverse Virenscannerhersteller schnell nachziehen können und ebenfalls Flash-Analysetools in ihre Scanner integrieren wenn da ein Markt vorhanden ist.
Leider ist der CCC chronisch mit der Bereitstellung eines Videostreams überfordert. Für die große Klappe die Fefe vorher gespuckt hat, ist das gerade eine extrem peinliche Aktion.
Wenn schon nichts anderes spannendes dabei ist (nein, der GoogleLunarXPrice interessiert mich nicht wirklich) und ich den Tag sowieso im Büro verbringe, kann ich die Zeit auch nutzen, kurz in die Lightning-Talks hineinzutunen. Für mich scheinen die spannenden Themen dieses Jahr sowieso in den Kurzvorträgen angesprochen zu werden. Die folgende Liste ist nicht vollständig, ich habe nur notiert, was ich persönlich interessiert.
Über den Nutzen staatlich produzierter und öffentlich verfügbarer Daten und ihrer Auswertung, weil die staatlichen Webseiten unter aller Sau sind. Das Problem sind die Formate der Daten, ihre Lizenzen und die Art der Veröffentlichung.
Link: http://opendata.hackday.net/
Termin: 24. und 25. April 2010 in Berlin
- Mifare Classic Universal toolKit (MFCUK)
Ein OpenSource Toolkit für Angriffe gegen die Mifare Classic Chipkarte. Das Toolkit implementiert den DarkSide Angriff und kann ein Mifare Classic SoftTag emulieren.
Link: http://code.google.com/p/tk-libnfc-crapto1/
Eine Linux-Distribution mit statisch gelinkten Tools. Nur das notwendigste. Keine Bibliotheken, Vermeidung von Libc (das wird Ulrich Drepper nicht gefallen) und keine Kernelmodule.
Link: http://suckless.org
OpenPGP SmartCard on a stick. Das ist in etwas so etwas wie ein Aladdin eToken nur mit einer OpenSource Hardware und offenen Schnittstellen. Damit ist die Kompatibilität mit Linux und Co. weitgehend gewährleistet. Die Version 1 enthält nur die Smartcard und kostet 38,- Euro, die Version 2 wird auch Flash-Speicher enthalten und in einem Alugehäuse erscheinen. Mal sehen, was der kostet.
Link: http://www.privacyfoundation.de/crypto_stick/
Mit Hilfe des bei vielen Softwarepaketen enthaltenen Favicons lässt sich z.B. das verwendete CMS enumerieren. Für Nmap gibt es ein Script, das die Favicons ausliest und die Hashes verwendet um die Software und ggf. Version zu bestimmen. Das ist mal eine lustige Enumeration-Idee.
Link: http://www.owasp.org/index.php/Category:OWASP_Favicon_Database_Project
- Apache + Slowloris = FAIL
Es geht um einen Apache Bug der nicht gefixt wird aber für einen DoS-Angriff geeignet ist. Erklärung, Details und Tools hinter dem Link.
Link: http://ha.ckers.org/slowloris/
27. Dezember 2009
Agenda:
- Getting into the network
- Bypassing internal packet filters
- Poisoning the Cache
Aus der Agenda hört sich das ein wenig wie „How to own the network“ an. Das Problem ist aber schon einmal, wie kommt man auf einen internen Server, wenn man nicht gerade einen 0-Day Bug hat den man dafür verschwenden will. Ok, man kann es mit Client-side Attacks versuchen, aber die Zuverlässigkeit ist halt nicht zwingend gegeben. Das klingt bei gezielten Angriffen leichter als es ist. Das philosophieren über Exploits und Information Gathering mit Emoticons in MSN ist zwar nett, bringt uns aber in der Praxis nicht weiter. Wie viele Leute in den Unternehmen verwenden denn wirklich MSN auf Linux? Geschweige denn, dass man für die verwendete Software dann tatsächlich einen Fehler mit einem exploitable Bug findet.
Egal. Der nächste Schritt ist, den internen Paketfilter zu umgehen. Die Idee geht wie folgt: Um einen Sicherheitsmechanismus in Layer n zu umgehen, muss man Layer n-1 angreifen. Um also einen IP-Paketfilter (Layer 3) zu umgehen, muss man den Devicetreiber in Layer 2 attackieren. Beispielsweise indem man an der MTU rumfummelt, dafür bieten sich in Gigabit-Ethernet Jumbo-Frames an. Wenn der Empfänger mit Jumbo-Frames nicht umgehen kann, besteht die Möglichkeit eines Buffer Overflows. Wenn man Glück hat findet man einen Bug im e1000 Linux Ethernet-Treiber der noch nicht gefixt ist.
Jetzt geht es an den Squid-Cache. Squid cached nicht nur Webseiten sondern auch DNS. Und von Dan Kaminsky wissen wir, dass DNS eine komplizierte Sache ist. Da gibt es diverse Probleme mit Sequenznummern und zufälligen Ports. Nur leider verwendet Squid immer noch den gleichen (zwar zufälligen aber solange der Cache läuft statischen) Port für alle DNS-Anfragen. Und der lässt sich herausfinden. Dafür verwendet Fabs einen recht coolen Trick der das Verhalten von Hide-NAT ausnutzt. Jetzt fehlt nur noch die richtige Transaction-ID um falsche DNS-Einträge in den Cache zu bringen. Und da könnte uns helfen, dass wir bereits Antworten in die Reply-Queue bringen können, bevor der Squid eine Frage stellt. Wenn die Queue nicht zu klein wäre. Wir müssen also verhindern, dass der echte DNS-Server die Antwort bekommt, um von innen eine passende Antwort zu spoofen. Dafür nutzt man ggf. wieder einen Fehler im Devicetreiber aus, dessen Details im Vortrag zu finden sind.
In Summe hatte ich mir zwar unter dem Vortrag was anderes vorgestellt, die Ideen in den von Fabs vorgestellten Exploits sind jedoch für mich ganz brauchbar. Da kann man noch mehr daraus machen. Und zumindest kann man sich darauf verlassen, dass Fabs Vorträge noch etwas Neues bringen und ab und zu sogar noch zum Lachen sind.
Schade ist nur, dass die Video-Streams des CCC von so furchtbar schlechter Qualität sind.
Seit Jahren ist bekannt, dass die in GSM verwendete Verschlüsselung nicht besonders gut ist. Es gibt diverse Angriffe durch schlechte Implementierung (Teile des Schlüssels bestehen aus 0-Bits), die Möglichkeit zu Sniffen durch Man-in-the-Middle Angriffe (IMSI-Catcher) und natürlich seit 1994 bekannte Probleme mit der eingesetzten A5-Verschlüsselung. A5/1 gilt seit 1997 in akademischen Kreisen als gebrochen. Seit spätestens 2008 gibt es Rainbow Tables die jedoch nicht veröffentlicht wurden. Einer der Gründe mag sein, dass es genug Wege gibt, die Verschlüsselung zu umgehen.
GSM funktioniert wie folgt. Die Basis-Station sendet einen Beacon, das Mobilgerät antwortet mit der IMSI (vgl. dem Usernamen, der in Zukunft durch die TMSI ersetzt wird). Benötigt wird dazu der MCC (Mobile Country Code) und der MNC (Mobile Network Code). Sobald ein Mobilgerät die richtige MCC/MNC-Kombination findet, bucht es sich bei der stärksten Basisstation ein. Um einen IMSI-Catcher zu bauen braucht man nur noch ein wenig Hardware. Empfohlen wird OpenBTS ein USRP und eine 52 MHz-Clock. Allerdings ist die Nutzung in Deutschland illegal.
Um die Verschlüsselung zu Brechen haben Karsten und Co eine Menge Leute geholfen, Rainbow Tables zu berechnen. Besonders hilfreich waren Nvidia-Grafikkarten mit CUDA. Ich will jetzt aber nicht auf die Krypto-Details eingehen.
Das Hauptproblem mit GSM ist, dass es keine Lösung für die Zukunft gibt. A5/3 ist ebenfalls schon akademisch gebrochen, ein neuer Algorithmus ist aktuell nicht in Sicht. Mehr auf Reflextor.com.
Philippe Oechslin ist bekannt durch seine Crypto-Arbeit über Rainbowtables, darum konnte man sich von diesem Vortrag viel erwarten. Allerdings habe ich die ersten 10 Minuten leider verpasst.
Eine Demo zeigte, wie schlecht Verschlüsselung regelmäßig implementiert ist. Die Software (den Namen nannte er nicht) implementiert drei Passwörter, eins zum Zugriff auf den privaten Bereich, eins zum Zugriff auf den öffentlichen Bereich und ein Panikpasswort zum Löschen der Verschlüsselungskeys. Die Passwörter sind hintereinander in einem Control Block angeordnet. Wenn man nun die Reihenfolge der Passwörter im Control Block austauscht, kann man mit dem Panikpasswort den privaten Bereich entschlüsseln.
Die nicht mehr angebotene Software von DataBecker „PrivateSafe“ ist ein anderes lustiges Programm. Es gibt zwar ein Passwort, jedes Zeichen im Passwort wird aber nur für ein einfaches logisches Shift verwendet um eine Prüfsumme zu erzeugen die dann verifiziert wird. Aus diesem Shift lässt sich einmal die Länge des Passworts ermitteln, außerdem kann man aus der Bitfolge für jedes Zeichen ermitteln, ob es als letztes Bit eine 0 oder 1 hat. Damit lässt sich der Suchraum massiv einschränken. Im Ergebnis können über eine triviale Analyse die Passwortkandidaten gefunden werden, ohne die komplexe Blowfish-Berechnung zu nutzen. Mit den Passwörtern die auf die Prüfsumme passen probiert man dann den eigentlichen Algorithmus aus. Blowfish hat ein langsames Keysetup, darum kann man direkt nur ca. 25.000 Passwörter pro Sekunde ausprobieren. Mit der Schwachstelle lässt sich das Passwort über 15.000x schneller brechen (2,5 Stunden statt 1,7 Jahre).
Eine weitere Schwachstelle liegt in der Nutzung von Passwörtern ohne Salt. Dadurch lassen sich Rainbowtables berechnen, die das spätere Cracken von Verschlüsselungssystemen stark beschleunigen.
Fazit: Crypto ist schwer korrekt zu implementieren. Deshalb OpenSource, da ist die Implementierung verifizierbar.
25. Dezember 2009
Heute habe ich ein wenig mit einem ASUS A7SV gespielt, weil das Gerät aus verschiedenen Gründen für ein bestimmtes Projekt möglichst gut abgesichert werden soll. Dazu gehört neben Festplattenverschlüsselung eben auch ein BIOS-Passwort, damit sich nicht ganz so trivial von CD booten lässt.
Dabei ist mir folgendes aufgefallen:
Wenn man auf den Power-Knopf rechts oben am Gerät drückt, startet das Gerät, es kommt das BIOS-Passwort und dann die Pre-Boot Authentisierung meiner Festplattenverschlüsselung. Startet man den Rechner jedoch über einen speziellen Hotkey, der auf dem Asus-Gerät mit einem Film-Symbol belegt ist, startet der Rechner direkt in die Pre-Boot Authentisierung. Das BIOS-Passwort wird nicht abgefragt.
Qualifiziert das nun für eine Sicherheitslücke?
15. Juli 2009
In den Vereinigten Arabischen Emiraten hat nach einem Bericht von The Register die Telefongesellschaft Etisalat ein Update an netzeigene Blackberrys verteilt, das eine Anwendung enthält, mit der alle Daten des Blackberry ausspioniert werden können:
„The update is labelled: „Etisalat network upgrade for BlackBerry service. Please download to ensure continuous service quality.“ The signed JAR file, when opened, reveals an application housed in a directory named „/com/ss8/interceptor/app“, which conforms to the Java standard for application trees to be named the reverse of the author’s URL. („Interceptor“ isn’t the subtlest name for spyware, though.)“
Das ist sozusagen die arabische Variante des Bundestrojaners. Aufgeflogen ist das anscheinend nur zufällig, weil die Server bei denen sich die Spyware anmelden sollte überlastet waren und die Spyware deshalb die Batterie leer gezogen hat. Weder von Etisalat noch von RIM oder SS8 war für The Register eine Auskunft zu diesem Vorfall erhältlich. Ich könnte mir gut vorstellen, dass man dort Toter Mann spielt und hofft, dass Gras über die Sache wächst.
Die Idee an sich ist natürlich clever. Provider-Updates vertrauen die meisten Anwender und wenn es sich auch noch um eine korrekt signierte Anwendung handelt, dann muss ja alles damit korrekt gelaufen sein. SS8 ist übrigens ein recht bekannter Anbieter von „lawful interception“, wobei das mit dem lawful also gesetzmäßig bekanntlich so eine Sache ist. Die CIA oder die NSA beispielsweise fängt gerne mal Nachrichten auch illegal ab, wie seit dem Abtritt von Bush allgemein bekannt ist.
Im Grunde erstaunt mich ja weniger, dass so ein Update überhaupt verteilt wird sondern mehr, dass der Benutzer tatsächlich noch gefragt wurde, ob er das installieren möchte. Soweit ich weiß, unterstützen alle modernen Symbian-Telefone Firmware over-the-Air Updates auch ohne, dass der Benutzer etwas davon merkt. Und dann kann man alles mögliche mit so einem Telefon anstellen. Vielleicht ist das mit dem Virenscanner auf dem Telefon doch keine so blöde Idee, WENN der Scanner so eine Sauerei überhaupt bemerken kann.
Ich hoffe ja, dass mein gutes altes Nokia 6310i gegen so einen Krempel immun ist 😉
8. Juli 2009
Well, this is my goodbye header for milw0rm. I wish I had the time I did in the past to post exploits, I just don’t :(. For the past 3 months I have actually done a pretty crappy job of getting peoples work out fast enough to be proud of, 0 to 72 hours (taking off weekends) isn’t fair to the authors on this site. I appreciate and thank everyone for their support in the past.
Be safe, /str0ke
Schade. Jetzt bleiben nicht mehr viele. Mir fällt so spontan nur noch ein:
Weitere Exploit-Archive nehme ich (bitte verlinkt) gerne in den Kommentaren entgegen.
(via Heise)
Nachtrag:
Heute, 11.07. funktioniert Milw0rm wieder und es gibt Updates vom 10.07. Ich hoffe ja, es finden sich genügend Unterstützer für Milw0rm, die Str0ke ein wenig entlasten. Ich würde so ein Exploit-Archiv ja auch hosten, ich brauche nur noch einen geeigneten Server im Ausland 😉
