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.
du brauchst kein msn client beim opfer sondern pidgin oder adium
Comment by tobias — 2. Januar 2010 @ 11:33
Ah ok, das hatte ich falsch verstanden. Danke. Aber generell sehe ich das Problem mit Instant Messaging Clients nicht flächendeckend in europäischen Unternehmen. Pidgin und Co. sogar noch weniger als die „offiziellen“ Clients. Die Amerikaner sind da zugegebenermaßen ganz anders drauf.
Comment by Christian — 11. Januar 2010 @ 11:48
Kommentare gesperrt wegen Spam
Comment by Christian — 27. Januar 2010 @ 20:31