Hashcat 3.x rule nem működik WPA2 törésnél?

Előzmény:

Tanulás, feladat: Adott egy ‘baráti’ WPA2 hálózat, elmentett HCPX file. Mivel a feladat a hashcat (rule-ok) gyakorlása, az SSD jelszó páros ismert. A capture folyamán az előkészítés is megtörtént, a fájl tartalmaz minden szükséges adatot.

Ami adott:

  • Hashcat 3.6
  • HCPX capture fájl
  • A jelszó egy magyar keresztnév, két számjeggyel kiegészítve, első betű nagybetű.

Első próbálkozás:

Crunch-al létrehozott rule fájl ($%$%), illetve a magyar keresztnevek becézett alakjainak wordlistje.

Parancs:

hashcat -a 0 -m 2500  Becenevek-BP.txt -r 11.rule

Hashcat pörög, majd pár másodperc múlva végez, közli hogy nem talált megfelelő jelszót:

Semmi gond, valami rossz a rule-ban, vagy pedig a wordlist-ben…

Többszöri próbálkozás, és erős emlegetése az ismert (később ismeretlenek is) vallások fel és lemenőinek után eljutottam oda, hogy a megkérdezzük a jelszót.

Oké, jelszó megvan (Henike95). A wordlist tartalmazza a ‘Henike’ szót, a rule pedig a ’95’ szabályt, így működnie kellene… Mondom kell!

Még egyszer…

Persze, így se jó.

Gondolkozás… (+1 kadarka)

Hashcat –stdout paraméterével legeneráltam a használt jelszavakat, hátha… Persze tartalmazta, ezzel nincs gond…

Többszöri próbálkozás után eljutottam oda hogy a wordlist csak a ‘Henike’ szót tartalmazza, a rule pedig a ‘$9$5’ szabályt…

Így se találja…

Ha kézzel beírom, vagy pedig direktben megadom a wordlistben a jelszót, akkor persze kipörgeti…

Oké, akkor valahol mégiscsak a rule megadás környéken lehet a gond.

Kínlódás: -j paraméter, -k paraméter (Tudom, de hátha…)

Ugyanaz…. 😦

+1 kadarka

Jó, nincs más hátra, olvassuk el a readme-ket.

WP2 spec…

RC4 spec…

Semmi különös, nincs ötlet…

Mégegyszer…

Ötlet: a WPA2 jelszó minimum hossza 8 karater… A Henike95 meg 8 hosszú, akkor ez jó…. (másként nem is lehetett volna megcsinálni a WPA2 AP-t…)

+1 kadarka

Hashcat kimenet hosszas, hozzáértő (gyk.: pixeleket már külön látod) bámulása…

HOPPÁ!

Hát mi ez istentelen nagy szám a Rejected után ? Mit dobál ez el?

Hashcat doksi olvasása…

Aham, tehát ami nem tetszik neki az adott algoritmushoz (gyk.: -m 2500) azt eldobja…

De miért dob el ennyit?

Pár újabb rule és wordlist teszt után kiderült, hogyha a wordlist-ben csak a Henike van, a rule-ban pedig csak a $9$5, akkor is eldobja… Mind az egyet…

Pár extra wordlist/rule páros, meg 1 kadarka után a következő derült ki:

A hashcat veszi az algoritmus paramétereit, ebből előállít egy szűkítést (ebben az esetben azt, hogy a jelszó NEM lehet 8 karakternél rövidebb).

A probléma az, hogy  a jelszó hosszát nem a rule-al kiegészítve nézi, hanem a kiinduló wordlist-ben előforduló szó hosszát.

Mivel a wordlistben a Henike szerepelt, ezért eldobta, mivel csak 6 karakter hosszú…

Ennyi…

hashcat32 --stdout -r 11.rule Becenevek-BP.txt | hashcat64 -a 0 -m 2500 wpa0701-01.hcpx

Működik, jelszó kipörgetve.

A wordlistben kiegészítve a szavakat minimum 8 karakterre, majd a ] parancsot megfelelő számban használva a rule-ban, szintén megfelelő eredmény érhetünk el…

 

 

Másodfokon… (ARP és barátai)

Ebben a bejegyzésben a TCP/IP univerzum második rétegéről lesz pár szó. A pár szó szó szerinti (elég hülyén néz ki így leírva), a teljes leírás könyvet érdemelne… (ahogy van is ;)). A legtöbb felhasználó nem sok fogalommal rendelkezik erről a rétegről (miért is kellene tudnia?), és sajnos a rendszergazdák többségének is csak halvány, hozzávetőleges fogalma van az itt zajló dolgokról 😦 Ezt a tendenciát sajnos a nagy cégek is erősítik, igen kevés olyan komplex védelmi rendszer van ami ezen réteg védelmét látná el, koncentrálva a kliens forgalomra. Pedig igény is lenne rá, illetve a hasznosságát sem lehet elvitatni, ugyanis ezen a rétegen igen nagy problémákat lehet okozni, minimális tudással felfegyverkezve. A legtöbb, egyéb rétegben dolgozó alkalmazás ‘szentírásnak’ veszi az L2 által közölt adatokat, így igen érdekes dolgokat eredményezhet ezen réteg célzott támadása.

Per pillanat ebben a bejegyzésben csak a legfontosabb, legalapvetőbb protokollok szerepelnek. A részletes támadási formákról később, egyenlőre csak fedezzük fel, s ismerjük meg említés szintjén őket…

ARP (Address Resolution Protocol)
Legrégebbi, s egyben legfontosabb protokoll. Ezen protokoll segítségével tudják a hálózati eszközök a MAC címeket és az IP címeket egymáshoz kapcsolni. Korából adódóan (szokás szerint 😦 ) nem tartalmaz hitelesítést és titkosítást, a teljes bizalmon alapul. Ezt (és a gratuitous ARP funkciót: az ARP válasz broadcastra megy, akihez eljut a válaszban közölt információkat eltárolja) kihasználva a támadó úgynevezett ARP poisoning támadást tud kivitelezni. A támadás lényege, hogy két kommunikáló féllel elhiteti, hogy Ő a másik, s ezáltal a köztük futó kommunikáció rajta keresztül áramlik.

DTP (Dynamic Trunking Protocol)
A legérdekesebb állatfajta, és egyben a leghasznosabb is 🙂 A DTP szolgál arra, hogy a switchek egymást közt le tudják beszélni a trunk port(ok) paramétereit. Nemcsak globálisan, hanem port szinten is lehet/kell állitani. Ezáltal egy érdekes kiskapura lehet találni: kis unszolásra a támadó rá tudja beszélni a switchet, hogy a portot kapcsolja trunk üzemmódban. Ezek után, ha a portot megfelelő módon teggeli, a támadó egyéb VLAN-okba is bele tud hallgatni…

HSRP, VRRP (Hot Stand-by Redundancy Protocol, Virtual Router Redundancy Protocol)
Mindkét protokoll feladata hogy több router összekapcsolását végezzék el, transzparensen, redunáns módon a default gateway funkció számára. Ha az aktív router kiesik, feladatát átveszi a sorban következő, a felhasználó számára észrevehetetlenül. MiTM (és ebből adódóan DOS) támadásra is lehetőséget adnak, mivel egyik protokoll sem tartalmaz hitelesítést. Ezáltal könnyen kivitelezhető az a lehetőség, hogy a támadó behazudja magát a legnagyobb priorítású helyettesítő routernek, majd valamilyen technológiával kiüti az elsődleges routert. Így a teljes forgalom átkerül a támadóhoz…

RSTP (Rapid Spanning Tree Protocol)
Az ARP mellett a legfontosabb protokoll a rétegben. Ezen protokoll felelős, hogy a hálózatban lévő feszítőfa a lehető leggyorsabban, és a lehető legkisebb erőforrással felépíthető legyen. A protokoll a STP protokoll utódja, azzal visszafele kompatibilis. Ezen protokoll manipulálásával elvégezhető legegyszerűbb támadása forma, ha a már meglévő fát  összezavarjuk, helytelen access pontokat jelölünk ki. Ebben az esetben még a nagy fizikai redundanciával rendelkező hálózatok is összezavarodnak, s nem az elvárt működést produkálják. Kifinomultabb módja a támadásnak ha célzottan avatkozunk be a fa felépítésébe, s magunkat nevezzük ki, akár a fa gyökerének, akárcsak egy rész csúcspontjának. Ekkor minden (abban a fa-részben) forgalom a gépünkön fog áthaladni… Elméletben ennek helyes megvalósítása egyszerű, azonban a gyakorlatban gyorsan szembesülni fogunk azzal a problémával, hogy mit is kezdünk több gigabitnyi forgalommal… 😉