[Rika]

1. Das Problem liegt nicht in der Größe von ARP-Requests, sondern in der Anfälligkeit von RC4 egegnüber Known Plaintext. Du kannst blindlings heraus raten daß an bestimmter Stelle entweder ein ARP-Header oder IP-Header steht, was genau ist dabei vollkommen egal (macht etwa 5% Unterschied aus). Die SNAP-Kodierung stört dabei nicht. (kann man da eigentlich auch auf DIX-Encoding umstellen?)
2. Der Trick mit kaputten Beacon Requests basiert auf den kaputten Implementierungen vieler APs und WLAN-Router. Klar, gibt für andere Geräte auch andere bekannte Tricks.
3. Sicher, daß man mit so wenig Traffic auskommt?
4. Das Problem mit TKIP ist die Art und Weise wie der Key aus dem Preshared Key abgeleitet wird, mit den in WPA stark eingeschränkt definierten Parametern gibt's da einige böse Probleme. WPA ist halt kein Standard, sondern ein Framework, wo Parameter definiert werden müssen. Und da sich die meisten Hersteller an Mickeysoft's Implementierung orientieren...
5. Bei WEP64 hat das Geburtstagsparadoxon sehr wohl Einfluss auf RC4, WEP128 ist ja nur die Beseitigung dieser Problems. Sozusagen als zusätzliche Vereinfachung des Problems. Man kann die Fehler bei RC4 ja kaum noch aufzählen...

Dieser Beitrag wurde von Rika bearbeitet: 26. September 2004 - 14:07

[PaxTrax]

1) Ich muss mein Post oben korrigieren. Sollte natürlich heissen 24 Bit IV, nicht 16 Bit.

Jetzt zu Deinem Post

Zitat

1. Das Problem liegt nicht in der Größe von ARP-Requests, sondern in der Anfälligkeit von RC4 egegnüber Known Plaintext. Du kannst blindlings heraus raten daß an bestimmter Stelle entweder ein ARP-Header oder IP-Header steht, was genau ist dabei vollkommen egal (macht etwa 5% Unterschied aus). Die SNAP-Kodierung stört dabei nicht. (kann man da eigentlich auch auf DIX-Encoding umstellen?)

Hmpf.... Nein, nein, nein..... am besten Du liest Dir mal ein paar Threads von netstumbler.org -> Unix Forum durch. Die sind auch die Entwickler von weplab und aircrack zu Hause, die das vielleicht besser beschreiben als ich. Es hat nichts mit Known Plaintext zutun, sondern monitoring nach ARP Requests. Wie soll man erraten können, ob es sich um einen ARP oder IP Header handeln soll? Ist doch alles verschlüsselt. Hmpf.....

Zitat

2. Der Trick mit kaputten Beacon Requests basiert auf den kaputten Implementierungen vieler APs und WLAN-Router. Klar, gibt für andere Geräte auch andere bekannte Tricks.

Noch nie davon gehört, aber kann ja sein... Quelle dafür bitte!

Zitat

3. Sicher, daß man mit so wenig Traffic auskommt?

Ja, ich habs doch getestet.

Zitat

4. Das Problem mit TKIP ist die Art und Weise wie der Key aus dem Preshared Key abgeleitet wird, mit den in WPA stark eingeschränkt definierten Parametern gibt's da einige böse Probleme. WPA ist halt kein Standard, sondern ein Framework, wo Parameter definiert werden müssen. Und da sich die meisten Hersteller an Mickeysoft's Implementierung orientieren...

WPA von MS? WPA wurde von der WiFi - einer Vereinigung von Hardwareherstellern entwickelt. http://de.wikipedia.org/wiki/WPA Was hat MS damit zutun? Ableitung von PSK? Ist mir auch völlig neu. Quelle bitte!

Zitat

5. Bei WEP64 hat das Geburtstagsparadoxon sehr wohl Einfluss auf RC4, WEP128 ist ja nur die Beseitigung dieser Problems. Sozusagen als zusätzliche Vereinfachung des Problems.

Der ganze Satz ist Unfug! Das Geburtstagparadoxon wird bei WLAN im Zusammenhang mit dem 24Bit-IV-Raum gebraucht. Dieser sollte eine IV-Kollision im besten Fall logischerweise erst nach 2^24 Frames bringen. Allerdings besteht - dank des Geburtstagsparadoxons bereits nach 4824 Frames eine 50% Wahrscheinlichkeit, das eine Kollision auftritt (die IVs werden zufällig gewählt). Nach 8791 Frames besteht bereits eine 90% Wahrscheinlichkeit. Runtergerechnet auf 802.11b bedeutet dies unter Volllast nach bereits 10 Sekunden eine Kollision.

Siehe auch:

Schneider,B (1997) Applied Cryptography, 2. Augabe, Wiley 1997 und
freudl, F (2003) WEP, Sicherheitsanalyse und mögliche Attacken, http://www.sec.informatik.tu-darmstadt.de/...itungen/WEP.pdf

oder meine Diplomarbeit zum Thema WLAN Sicherheit.......

Zitat

Man kann die Fehler bei RC4 ja kaum noch aufzählen...

Ich will dich ja nicht blosstellen, aber RC4 ist ziehmlich sicher! Oder willst du sagen SSH ist unsicher (ja, auch dort wird RC4 verwendet)? Der Fehler liegt in der RC4 Implementation in WEP.

gruß,
PaxTrax

[Rika]

1. Lies dir noch mal das originale WEPCrack-Paper durch, da stehst drin - es geht darum daß du eben weißt daß entweder ARP- oder IP-Header vorhanden ist, aber kein anderer Müll. Für mich sind das 2 aus 256 Möglichkeiten allein für das erste Byte.
2. http://www.computec.ch > Dokumente > Kategorie=? - muss ich mal bei Gelegenheit nochmal durchsuchen.
3. Also unter 2 Stunden @ 11 MBit/s hab ich's selber noch nicht hingekommen. Ist deine Leistung einmalig (... Glückssache) oder durchschnittlich?
4. WPA ist ein Framework, die Hersteller müssen dabei leider nach den Einschränkungen von WPA unter Windows richten. Genauso wie du IPSec mit AES als Cipher unter dem Windows-integrierten IPSec-Treiber vergessen kannst, schränken die Parameter die Sicherheit empfindlich ein. Ein Regular in de.comp.security.misc (Jürgen Nieveler?) hatte mal darüber berichtet, wie man WPA erfolgreich angreifen kann. Klar daß nur PSK davon betroffen ist.
5. Nochmal: Das Geburtstagsproblem ist bei RC4-40 noch ein _zusätzliches_ Problem, von Brutce Force mal ganz abgesehen...
6. Ja, war etwas unklar ausgedrückt...

[PaxTrax]

Zitat (Rika: 26.09.2004, 17:16)

1. Lies dir noch mal das originale WEPCrack-Paper durch, da stehst drin - es geht darum daß du eben weißt daß entweder ARP- oder IP-Header vorhanden ist, aber kein anderer Müll. Für mich sind das 2 aus 256 Möglichkeiten allein für das erste Byte.
2. http://www.computec.ch > Dokumente > Kategorie=? - muss ich mal bei Gelegenheit nochmal durchsuchen.
3. Also unter 2 Stunden @ 11 MBit/s hab ich's selber noch nicht hingekommen. Ist deine Leistung einmalig (... Glückssache) oder durchschnittlich?
4. WPA ist ein Framework, die Hersteller müssen dabei leider nach den Einschränkungen von WPA unter Windows richten. Genauso wie du IPSec mit AES als Cipher unter dem Windows-integrierten IPSec-Treiber vergessen kannst, schränken die Parameter die Sicherheit empfindlich ein. Ein Regular in de.comp.security.misc (Jürgen Nieveler?) hatte mal darüber berichtet, wie man WPA erfolgreich angreifen kann. Klar daß nur PSK davon betroffen ist.
5. Nochmal: Das Geburtstagsproblem ist bei RC4-40 noch ein _zusätzliches_ Problem, von Brutce Force mal ganz abgesehen...
6. Ja, war etwas unklar ausgedrückt...

1) Hmm, werd ich mal machen. Die Implementationen von reinjecten von Traffic beruhen jedenfalls auf einem anderen Konzept, aber es kann ja mehrere geben.....
2) -> Wireless Aber die hab ich gerade mal durchgeschaut. Nur altes blah blah......
3) Durchschnittlich würd ich sagen. Gerade in den letzten Wochen/Monaten wurden viele Optimierungen bei WEP brechen erzielt. Mir Airsnort hatte ich noch Tage gebraucht (ca. 12 GB Traffic bei meinem AP). Jetzt reichen mir ca. 500.000 Frames. (Tests beruhen auf weplab und airsnort - Stand Juli 2004).
4) Würde mich wirklich mal interessieren. Über http://www.i-eye.net...curity_misc.php konnte ich den Eintrag leider nicht finden. Vielleicht hast du die Möglichkeit nochmal danach zu suchen...
5) Welches? Quelle?
6) np

[Rika]

2. Nein, irgendwo anders. In einem paper war ein Link zu 'ner Webseite mit Links zu WLAN-Sniffing-Software, WEP-Crackern und auch Exploits für viele APs und Router.
4. Kein Wunder, das Ding respektiviert x-no-archive-Header.
5. sci.crypt-FAQ. Ist doch generell mit Stromciphern so... aber sorry für die 20, ich meinte 32. Bei 64 Bit Maximalbreite vom internen State hast du nach 2^32 Ciphertexten in deren Kombinationen von je zwei 64Bit-Blöcken im XOR eine Kollision, woraus man den State berechnen kann.