Wireless Risk Potential Scenario: WEP

Im Rahmen des IT Security Workshop 2006 haben wir uns mit der Sicherheit der WEP-Verschlüsselung befasst. Wir haben bestehende Schwachstellen analysiert und einen eigenen Angriff nach Vorlage von A.Bittau entwickelt.

Folien zur Presentation

Autoren: Moritz Grauel und Matthias Naber

Ziele

Ziel ist es verschiedene Angriffsszenarien auf WEP zu prüfen. Besonderer Schwerpunkt liegt dabei auf den "modernen" Angriffen, die auch bei Netzen ohne viel Traffic Erfolg versprechen.

Ansatzpunkt ist die Arbeit von A.Bittau

Als Ziel der Angriffe dient ein Netgear WGT634U Accesspoint in Standardkonfiguration.

Der Angreifer ist in unserem Szenario ebenfalls ein Netgear WGT634U, auf dem Linux (Hacking the Netgear wgt634u) läuft.

Funktionsweise von WEP

Eigenschaften von WEP

WEP (Wired Equivalent Privacy) ist ein Verschlüsselungsstandard, der von der IEEE herausgegeben wurde. Es findet ausschließlich eine Verschlüsselung auf dem drahtlosen Medium statt. WEP soll lediglich Sicher stellen, dass nur bestimmte Teilnehmer an der Kommunikation teilnehmen können. Das heißt, jeder, der den preshared key kennt, kann die Daten entschlüsseln - eine Verschlüsselung, der Teilnehmer gegeneinander findet nicht statt.

• Verschlüsselung auf OSI Layer 3
• symmetrischer Stromchiffre
• basiert auf RC4-Pseudozufallszahlengenerator
• offizielle Schlüssellängen 40 (64) Bit und 104 (128) Bit

Funktionsweise von Stromchiffre

• Verschlüsselung einer Nachricht der Länge $l$:

$E(x,k)=y\;\;\;\ y_{i}=x_{i}\oplus k_{i}\;\;\;\ i=1\dots l$

• Entschlüsselung einer Nachricht der Länge $l$:

$D(y,k)=x\;\;\;\ x_{i}=y_{i}\oplus k_{i}\;\;\;\ i=1\dots l$

Bildquelle Wikipedia

Verschlüsselung bei WEP

Mit dem Zufallszahlengenerator RC4 wird eine Zufallszahlenfolge gebildet, die so lang ist, wie der zu verschlüsselnde Text (plus 4 Byte). Der RC4-Algorithmus wird dabei mit dem Schlüssel (40 oder 104 Bit) und einem sogenannten Initialisierungsvektor (IV) initiiert. Der IV hat eine Länge von 24 Bit. Zusammen mit dem Schlüssel ergeben sich so die 64 bzw 128 Bit, für die WEP bekannt ist. Der Schlüssel muss a priori allen Teilnehmern bekannt sein, der IV wird jedesmal im Klartext mitverschickt. Über den Klartext wird vor der Verschlüsselung eine CRC32-Prüfsumme (Integrity Check Value - ICV) berechnet und hinten an den Klartext angehängt. Anschließend wird der Klartext (und die Prüfsumme) mit der RC4-Zufallszahl verschlüsselt. Vor den somit entstandenen Ciphertext wird der IV und ein Schlüsselindex (WEP unterstützt 4 verschiedene Schlüssel) geschrieben.

Bildquelle Wikipedia

Entschlüsselung bei WEP

Mit dem, im Klartext versendeten IV und dem preshared key wird der RC4-Schlüsselstrom erzeugt. Der erzeugte Strom ist der selbe, wie bei der Verschlüsselung. Aus dem Schlüsselstrom und dem Kryptotext wird der Klartext und dessen Prüfsumme errechnet. Anschliessend wird die errechnete Prüfsumme mit der übertragenen Prüfsumme verglichen - stimmen die beiden überein gilt das Paket als fehlerfrei entschlüsselt. Andernfalls wird die Entschlüsselung als gescheitert betrachtet und das Paket verworfen.

Bildquelle Wikipedia

Aufbau eines WEP-Pakets

+---------------+-----------+---------------+----------------+----------+
|    24 Byte    |  4 Byte   | 1 - 2308 Byte |    4 Byte      |  4 Byte  |
| 802.11 Header | IV Header |   Frame Body  |      ICV       |    FCS   |
|   Klartext    |  Klartext | verschlüsselt | verschluesselt | Klartext |
+---------------+-----------+---------------+----------------+----------+

Der FCS ist eine erneute CRC32-Prüfsumme, die vom Treiber vor dem Senden über die gesammte Nachricht generiert wird.

Theoretische Schwachstellen von WEP

Keystreamreuse

Eine, der größten Schwachstellen bei Stromchiffren ist es, den gleichen Schlüssel mehrfach zu verwenden. Wenn ein Angreifer zwei Nachrichten, die mit dem gleichen Schlüssel verschlüsselt wurden abfängt, besitzt er automatisch das XOR der beiden Klartexte. Sehr oft lassen sich daraus schon wichtige Informationen gewinnen. Bei WEP gibt es nur $2^{24}$ verschiedene IVs. Nach spätestens 16777216 versendeten Paketen wiederholen sich die IVs und somit die erzeugten Schlüsselströme. Viele Accesspoints beginnen zudem mit einem IV von 0 und inkrementieren diesen einfach. Zudem gibt es bestimmte IVs, die als Schwach gelten (Schwache IVs). Einige APs lassen diese einfach aus, was die Wahrscheinlichkeit des Keystreamreuse noch erhöht.

$C_{1}=P_{1}\oplus RC4(iv\|key)$

$C_{2}=P_{2}\oplus RC4(iv\|key)$

$C_{1}\oplus C_{2}=(P_{1}\oplus RC4(iv\|key))\oplus (P_{2}\oplus RC4(iv\|key))=P_{1}\oplus P_{2}$

Schwache IVs

Aufgrund einer Schwachstelle im RC4-Algorithmus lassen sich aus bestimmten IVs Rückschlüsse auf Bits im Schlüssel ziehen. Es ist daher möglich, mit relativ wenigen abgefangenen Paketen den presharedkey zu errechnen. Ein Programm, dass dieses Verfahren einsetzt, ist das bekannte aircrack. Mit nur ca 150.000 bis 300.000 Paketen kann man innerhalb von Sekunden (oft sogar schneller) den presharedkey errechnen. Durch die Verlängerung des Schlüssels wächst die Anzahl der schwachen IVs derart, dass die benötigte Menge abgefangener Pakete nur linear steigt. (Doppelte Schlüssellänge -> Doppelter Aufwand)

Fragmentierung

Der WEP-Standard lässt Fragmentierung auf der MAC-Ebene zu. Ein Paket kann in maximal 16 Fragmente zerlegt werden, die alle mit dem selben IV verschüsselt sein dürfen. Dies ist eine der größten Schwachstellen, da somit relativ einfach Pakete beliebigen Inhalts verschicken lassen.

Wörterbuchangriff

Da es eine überschaubare Menge IVs gibt, ist es möglich ein Wörterbuch zu erstellen, dass Paare von IV und dazugehörigem Schlüsselstrom enthält. Damit kann man bei Bedarf verschlüsselte Pakete entschlüsseln. Durch das generieren von Paketen mit bekantem Inhalt (z.b ARP-Request) kann man ein solches Wörterbuch gezielt aufbauen. Ein solches Wörterbuch hätte dann eine Größe von $2^{2}4*2312Byte=36GByte$. Ein solches Wörterbuch macht die Kenntnis des Presharedkey überflüssig, man kann sämtliche Pakte ver- und entschlüsseln.

Prüfsummenfunktion

Die im Standard vorgesehene Prüfsummenfunktion CRC32 ist keine kryptografische Hashfunktion. Es handelt sich um eine lineare Funktion, die im gewissen Maße vorhersagbar ist (Zip-Recovery nutzt dies zur Fehlerbehebung). Es ist daher eine geziehlte Manipulation möglich. Ein Tool, was dies ausnutzt ist chop-chop

schwache Passwörter

Häufig werden lediglich ASCII-Passwörter der Länge 5 oder 13 Zeichen verwendet. Der daraus resultierende Schlüsselraum für den Presharedkey ist so klein, dass damit bruteforce Angriffe realistisch werden.

Status

Wir haben uns für einen Angriff auf Basis der Fragmentierung entschieden.

Grundlage des Angriffs

Die ersten 8 Byte eines WEP-Pakets sind fast immer bekannt. Sie beinhalten den sogenannten LLC/SNAP, der den unter anderem den Typ des Protokolls definiert. Normalerweise handelt es sich dabei entweder um ARP oder IP. Ein ARP-Paket ist an seiner konstanten Länge von 36 Byte (+4 Byte ICV) zu erkennen. Ist das Paket länger kann man davon ausgehen, dass es sich um ein IP-Paket handelt.

+-------------------------+------------+--------+------+
|       LLC / SNAP        | ARP Header | Quelle | Ziel |
| AA AA 03 00 00 00 08 06 |            |        |      |
+-------------------------+------------+--------+------+

Framebody eines ARP-Requests

Da wir die ersten 8 Byte des Klartextes bekannt sind, können wir ohne weiteres auch die ersten 8 Byte des Schlüsselstroms errechnen, indem wir Klartext und Kryptotext verXORn.

Ablauf des Angriffs

Wir sniffen solange Pakete mit, bis wir ein WEP-verschlüsseltes Paket unseres Zielnetzes empfangen. Aus diesem Paket errechnen wir uns die ersten 8 Byte des Schlüsselstroms.

Im Speicher bauen wir uns daraufhin ein ARP-Request-Paket zusammen (feste Länge von 36 Byte). Diese Paket zerteilen wir daraufhin in 9 Fragmente zu je 4 Byte. Über diese Fragmente bilden wir eine CRC32-Prüfsumme und hängen diese an. Die Resultierenden 8 Byte werden dann mit dem uns bekannten Schlüsselstrom verschlüsselt und in einen 802.11-Frame eingebettet, der an die Broadcastadresse addressiert ist. Diesen übergeben wir dann dem Madwifitreiber, der es versendet.

Sobald der AP alle gültigen Fragmente empfangen hat, setzt er das Paket wieder zusammen, verschlüsselt es erneut (mit einem neuen IV) und forwarded es als Braodcast. Diesen Broadcast empfangen wir und können nun einfach (da wir den Klartext kennen) den Schlüsselstrom errechnen. Wir kennen nun 40 Byte (36 Byte ARP + Prüfsumme) eines Schlüsselstroms.

Dieses Vorgehen können wir nun mit größeren Paketen wiederholen und beliebig lange Schlüsselströme erhalten (maximal 16 Fragmente). Wir haben herausgefunden, dass der Netgear Router Pakete mit beliebigem (potentiell sinnlosem) Inhalt zusammensetzt und forwarded. Wir können nun also 16 Fragmente voller Nullen erstellen und an die Broadcast-Adresse schicken - daraus erhalten wir 580 Byte eines Schlüsselstroms.

Wir sind nun in der Lage beliebige Pakete, maximaler Länge, zu verschlüsseln und zu versenden. Damit können wir nun entweder zu weiteren IVs den Schlüsselstrom sammeln und ein IV-Wörterbuch aufbauen oder mittels ICMP-Echo-Requests beliebig viel Traffic verursachen um den Presharedkey zu knacken.

Probleme

Speicherplatz

Da der AP nur über 16 MB Speicher verfügt, haben wir uns entschieden, zusätzlichen Platz per NFS einzumounten. Das hat sich als etwas schwieriger erwiesen, als wir dachten. Die NFS-Module, die wir im Internet fanden, sind regelmäßig eingefroren und ließen sich dann auch nicht mehr (ohne Neustart) entfernen.

Das BRN-Projekt hat uns daraufhin die Module zur Verfügung gestellt, die sie benutzen -> Problem gelöst

Fake-Authentifizierung

Ohne Authentifizierung am AP waren wir keine berechtigten Teilnehmer und der Router hat unsere Pakete lediglich mit Deauthentifizierungsframes beantwortet. Die Aircrack-Suite bietet aber ein Tool, das sich beim AP anmeldet -> Problem gelöst

madwifi-Treiber

Um Pakete beliebigen Inhalts (sowie ungültige Pakete) verschicken zu können, benötigt man gepatchte Treiber, die das ath0raw-Device zur Verfügung stellen. Die Treiber, die wir vom BRN-Projekt erhalten haben waren bereits gepatcht -> Problem gelöst

Sequenznummer

Fragmentierte Pakete müssen alle die selbe Sequenznummer im 802.11-Header haben, damit sie wieder zusammengesetzt werden können. Der madwifi-Treiber hat aber auch beim Raw-Device die Sequenzummer selbst verwaltet und in der Regel inkrementiert. Dieser Mechanismus lässt sich nur umgehen, wenn man bei dem Paket das retransmit-Bit setzt -> Problem gelöst

Checksummen

Um gültige IP-Pakete (z.B. Pings) generieren zu können benötigt man einen Checksummenalgorithmus - wir haben uns leider zu doof angestellt, diesen korrekt zu implementieren (vermutlich aufgrund von Endian-Problemen). Daher können wir bisher keine beliebigen IP-Pakete erstellen, sondern nur bekannte Replizieren -> Problem bisher ungelöst, aber eigentlich leicht zu lösen

Antwort/Forward

Der AP hat auf unsere verschlüsselten Fragmentierten Pakete (Echo-Requests) nie geantwortet, sondern sie immer nur geforwarded. Für unsere Zwecke ist dies zwar ausreichend, aber es ist nicht befriedigend. Vermutlich liegt es daran, dass die Checksummen der IP-Pakete nicht stimmen (siehe oben) -> Problem ungelöst

Unbekannter SNAP

Aus uns völlig unbekannten Gründen hat der AP ständig WEP-verschlüsselte Pakete mit einem SNAP-Header von AA AA 03 00 00 00 00 27 verschickt (auch ohne angemeldete Teilnehmer). Dies hat unsere Annahme mit dem bekannten SNAP-Header zunächst durcheinander gebracht, später dann aber deutlich vereinfacht. Wir konnten praktisch immer davon ausgehen, dass es sich um ein solches Paket handelt. Vermutlich handelt es sich um Managementframes. Es handelt sich jedenfalls nicht um eines, der bekannten Protokolle -> kein Problem

viel noise

An unserem Standpunkt gab es eine Vielzahl verschiedener drahtloser Netze (Uninetz, BRN, VPNs, etc..). Dadurch flogen ständig irgendwelche Pakete durch die Luft, die wir immer erst ausfiltern mussten. Ein Arbteisplatz ohne weitere Netze wäre wünschenswert gewesen -> geringes Problem

Code

Unsere Implementation des Fragmentierungsangriffs: attack.c

Dazu notwendig:

• Als Verifikation unseres "erratenen" Schlüssels: rc4.h rc4.c (Quelle: Google-Groups)
• Implementation des crc32-Prüfsummenalgorithmus: crc32.c (Quelle: SAR)