ARP Reinjekce

ARP rámce sú ľahko identifikovateľné aj v zašifrovanej forme, pretože sú krátke,

a ARP request (požiadavka) má cieľovú MAC adresu broadcast (FF:FF:FF:FF:FF:FF).

AP takýto rámec prepošle ostatným STA; niektoré AP ho najprv dešifrujú a následne

zašifrujú s novým IV. Pri zvyšovaní prevádzky sú dobré aj v tom, že cieľový adresát na

ne promptne odpovie, čím vygeneruje nový rámec, s novým IV.

Program aireplay-ng z balíka Aircrack-ng umožňuje v režime monitor

reinjekciu rámcov podľa zadaných pravidiel. Pre zvýšenie ARP prevádzky ho spustíme

ako root s parametrom -3 takto:

# ./aireplay-ng -3 -b 00:11:3b:07:00:14 -h 00:11:3b:0b:22:0c rausb0

The interface MAC (00:11:09:29:62:38) doesn't match the specified MAC (-h).

ifconfig rausb0 hw ether 00:11:3B:0B:22:0C

Saving ARP requests in replay_arp-0502-004658.cap

You should also start airodump-ng to capture replies.

Read 51729 packets (got 49845 ARP requests), sent 51017 packets...(277 pps)

-3 určuje typ útoku: ARP reinjekcia,

-b ... určuje BSSID (MAC adresa AP),

-h ... určuje zdrojovú MAC adresu, ktorá sa má pre vyslané rámce použiť,

rausb0 je zariadenie použité na vyslanie rámca (musí byť v monitor mode).

Po zachytení rámca, o ktorom sa predpokladá, že je to ARP request, sa tento so

zmenenou hlavičkou pošle, generujúc tak od adresáta skoro 300 ARP response (odpoveď)

rámcov za sekundu, s novými IV. Ak žiadne ARP rámce nezachytíme, môžeme si ich

skúsiť vynútiť pomocou deautentifikácie (bližšie k tomuto v 6.4).

4.2.2 Ochrana voči reinjekcii

Podľa IEEE štandardu nie je pre WEP zadefinovaná ochrana voči reinjekcii

paketov. Niektoré zariadenia reinjekcii čiastočne zabraňujú tým, že IV prijatých rámcov

si ukladajú do cache (vyrovnávacia pamäť) a ignorujú všetky rámce s rovnakým IV,

akonáhle ich počet presiahne istú hranicu (napríklad 64).

Použitie RSN (Robust Security Network, sieť s robustnou bezpečnosťou) (WPA/WPA2)

zabráni reinjekcii, pretože neumožňuje znovupoužitie IV a pomocou MIC je

zabezpečená aj hlavička rámca. Alternatívou môže byť Wireless IDS (viď. 9.4).

Generovaniu ARP prevádzky na sieti je možné zabrániť statickými ARP

tabuľkami na všetkých staniciach. To je však ťažko manažovateľné a zle škálovateľné

riešenie.

Príklad úspešnej Shared-Key autentifikácie je na obr. 4-2. Štandard určuje, že

challenge text (výzva) má mať dĺžku 128 znakov. Formát challenge elementu v druhom

autentifikačnom rámci je {Element ID, Length, Challenge Text}, kde Element ID je 10h,

Length 80h (128). Po odchytení druhého rámca a výpočte ICV teda poznáme celý

plaintext (otvorený text), ktorý sa posiela zašifrovaný (ciphertext) v treťom rámci ako

response (odpoveď), konkrétne 6+2+128+4 = 140 bajtov. Po odchytení tretieho rámca

máme teda „úplne zadarmo“ pseudonáhodnú sekvenciu (ciphertext Å plaintext) dĺžky

140 pre dané IV (zvolí STA).

Autentifikácia prebieha len pri nadväzovaní konektivity, môžeme si ju ale vynútiť

sfalšovanou deautentifikáciou (viď. 3.1.1 a tiež 6.4) a vytvoriť si tak slovník takej

veľkosti, ako na konkrétny účel potrebujeme.