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.
Das Fotografieren und Filmen im öffentlichen Raum ist (sofern man Persönlichkeitsrechte beachtet) in Deutschland nicht verboten. Es sei denn, die Policy ist bar jeder Rechtsgrundlage anderer Meinung und erfindet eine theoretische Gefahr durch einen potentiellen Angriff durch das Fotografieren.
Christoph Faulhaber hat das ausprobiert und wurde prompt aus den USA ausgewiesen.
Denn wenn der Behördenapparat die Sicherheit gefährdet sieht, sind die Grundrechte in der Praxis nichts mehr wert. Grundlegende Bildung wie das Zitat von Benjamin Franklin gehört in Deutschland nunmal nicht zur Staatsbürgerkunde.
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.
Der Videostream ist unter aller Sau. Dafür, dass Fefe die Klappe weit über den schlechten Stream von Wikipedia aufgerissen hat, soll sich der CCC mal kräftig an die eigene Nase fassen. Das Motto „Dragons everywhere“ lässt sich vermutlich am besten mit „gemeinsam in die Röhre gucken“ übersetzen. Die Liste der Known Problems im Stream ist übrigens die einzige gepflegte Seite im Congress-Wiki.
Ach ja. Wenn ich lese, dass die Tickets vor der Keynote schon ausverkauft waren und sich am Vortag schon lange Schlangen gebildet haben, wie stellt sich der CCC das in den kommenden Jahren mit Leuten vor die erst am 27.12. von auswärts anreisen können? Reservierungen braucht es ja angeblich nicht, dafür stehen die, die von weiter her kommen dann vor verschlossenen Türen? Wird das in den kommenden Jahren eine „nur für Berliner“-Veranstaltung?
Mein Eindruck ist ja langsam, dass der Congress seine besten Zeiten hinter sich hat.
Update:
Haha, jetzt sind die ganzen angeblich gelösten Known Problems aus dem Wiki gelöscht worden, vermutlich damit das besser aussieht. Ist beim CCC ja inzwischen wie bei Wikipedia.
Update Day 2:
Der Stream läuft immer noch nicht stabil. Sobald beliebte Vorträge stattfinden, kriegt man vielleicht 10 Sekunden zusammenhängende Übertragung, der Rest hängt. Lieber CCC, das ist echt schlechteste Qualität wenn ich Euer Wikipedia-Genöle der letzten Monate anschaue.
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.
