Aircrack-ng és Intel PRO/Wireless 3945ABG
Írta: Kerekes Attila
Jun/091
Végre sikerült egy kis időt találnom a blogra is. Reményeim szerint ez lesz az első része egy komolyabb cikk sorozatnak, amelyekben vezeték nélküli hálózatok támadásával szeretnék foglalkozni. Az ilyen támadásokhoz általában egy speciális drivert kell használnunk a wifi kártyánkhoz, hogy nem egészen szabványos csomagokat is tudjunk küldeni, illetve a nem nekünk címzett csomagokat is fogadhassuk. Kezdésnek egy ilyen driver beszerzéséről és beüzemeléséről lesz szó, méghozzá az Intel PRO/Wireless 3945ABG kártyákhoz, ismertebb nevén az ipw3945-höz. A környezet továbbra is Debian.
Feltételezzük, hogy a sima ipw3945 drivert alapból sikerült felinstallálnunk. Azért egy-két tipp: /etc/apt/sources.list -be szükséges lesz berakni a non-free csomagokat is. Például így kéne, hogy kinézzen egy sor:
deb http://ftp.hu.debian.org/debian/ lenny main contrib non-free
Egy apt-get update után már látnunk kéne a firmware-iwlwifi csomagot. Ezt kell installálnunk (apt-get install firmware-iwlwifi), ezek után már gond nélkül kéne, hogy működjön minden.
Ezzel a driverrel ha elindítjuk a kismetet vagy akár az airodump-ng-t sajnos nem fogunk látni mindent, amire kíváncsiak lehetünk, illetve az aireplay-ng is felejtős még. Emiatt van szükség egy másik driverre, méghozzá az “ipwraw“-ra, amit innen lehet beszerezni: http://homepages.tu-darmstadt.de/~p_larbig/wlan/. A driver forrásának letöltése után még szükségünk lesz a kernel headerekre az aktuális kernelünkhöz. Mivel nálam épp a gyári 2.6.26-2-686 -os Debian kernel fut, ezért ezt a következő paranccsal tehetem meg:
apt-get install linux-headers-2.6.26-2-686
Ha ez is megvolt lépjünk az ipwraw forrás könyvtárába és jöhet a make, make install, make install_ucode. Arra figyeljünk, hogy ugyanahhoz a hardverhez két driverünk lesz a gépen, ezzel nem árt, ha tisztában vagyunk. Sajnos nem túl kényelmes, de ha netezni akarunk, akkor a gyári driverre lesz szükségünk, míg egyéb felhasználáshoz az ipwraw driverre. A gyári driver neve iwl3945, míg a másiknak ipwraw (meglepő?). Átállás a hackelt driverre így történik:
modprobe -r iwl3945 modprobe ipwraw
Ha minden sikeresen ment akkor az airodump-ng is egészen új képet mutat majd nekünk a vezeték nélküli világról. Az előbbi driver betöltéshez jár egy script is az ipwraw forrással, az Intel_files könyvtárban a load nevezetű fájl. Bár nagyon gyönyörű script, valamiért mégis írtam egy sajátot is, kiegészítve egy wpa_supplicant killel az ipwraw driver betöltésekor, nekem ez jól szokott jönni:
#!/bin/bash
startit() {
echo -n "Killing wpa_supplicant if present: "
(killall -9 wpa_supplicant) 2> /dev/null
echo "done."
echo -n "Unloading ipw3945 driver: "
modprobe -r iwl3945
echo "done."
echo -n "Loading ipwraw driver: "
modprobe ipwraw
echo "done."
sleep 4
iwconfig wifi0 rate 1M
iwconfig wifi0 txpower 16
iwconfig
}
stopit() {
echo -n "Unloading ipwraw driver: "
modprobe -r ipwraw
echo "done."
echo -n "Loading ipw3945 driver: "
modprobe iwl3945
echo "done."
sleep 2
iwconfig
}
case $1 in
start) startit ;;
stop) stopit ;;
*) echo "Usage: ipwchange <start|stop>";;
esac
Nagyrészt sajnos emlékezetből írtam le mindent, ha valami nem megy, csak szóljatok, és jobban utána nézek, javítok. A következőkben szépen végig sétálunk majd remélem a wep és wpa psk -t használó hálózatok “biztonsági tesztelésén” az ipwraw driverrel ellátott Intel PRO/Wireless 3945ABG kártyánk segítségével.
Ajánlott irodalom:
http://homepages.tu-darmstadt.de/~p_larbig/wlan/
http://www.aircrack-ng.org/doku.php?id=ipw3945
#eof
Rainbowcrack meg a Debian
Írta: Kerekes Attila
Jun/091
Mivel egyre aktívabban foglalkozom szivárványtáblás kódvisszafejtésekkel, gondoltam beszerzem a RainbowCrack programcsomagot is. Leginkább nem is az rcrack hanem az rtgen miatt. Linuxra ahogy néztem az 1.2-es verzió érhető el a hivatalos honlapról. Letöltöttem, kicsomagoltam, majd a readme alapján nekifutottam egy make -f makefile.linux paranccsal. Az eredmény lenyűgöző volt:
rogue:~/tools/rainbowcrack-1.2-src/src# make -f makefile.linux
g++ Public.cpp ChainWalkContext.cpp HashAlgorithm.cpp HashRoutine.cpp RainbowTableGenerate.cpp -lssl -O3 -o rtgen
In file included from Public.cpp:11:
Public.h:25: error: u_int64_t does not name a type
Public.h:26: error: u_int64_t does not name a type
Public.h:37: error: u_int64_t was not declared in this scope
Public.h:38: error: u_int64_t was not declared in this scope
Public.cpp:113: error: redefinition of std::string uint64tostr
Public.h:37: error: std::string uint64tostr previously declared here
Public.cpp:113: error: u_int64_t was not declared in this scope
Public.cpp:126: error: redefinition of std::string uint64tohexstr
Public.h:38: error: std::string uint64tohexstr previously declared here
Public.cpp:126: error: u_int64_t was not declared in this scope
In file included from ChainWalkContext.h:11,
from ChainWalkContext.cpp:11:
Public.h:25: error: u_int64_t does not name a type
Public.h:26: error: u_int64_t does not name a type
Public.h:37: error: u_int64_t was not declared in this scope
Public.h:38: error: u_int64_t was not declared in this scope
In file included from ChainWalkContext.cpp:11:
ChainWalkContext.h:30: error: u_int64_t does not name a type
ChainWalkContext.h:31: error: u_int64_t does not name a type
ChainWalkContext.h:34: error: u_int64_t does not name a type
ChainWalkContext.h:37: error: u_int64_t does not name a type
ChainWalkContext.h:56: error: u_int64_t does not name a type
ChainWalkContext.h:61: error: u_int64_t has not been declared
ChainWalkContext.h:68: error: u_int64_t does not name a type
ChainWalkContext.cpp:31: error: u_int64_t CChainWalkContext::m_nPlainSpaceUpToX [257] is not a static member of class CChainWalkContext
ChainWalkContext.cpp:32: error: u_int64_t CChainWalkContext::m_nPlainSpaceTotal is not a static member of class CChainWalkContext
ChainWalkContext.cpp:35: error: u_int64_t CChainWalkContext::m_nReduceOffset is not a static member of class CChainWalkContext
ChainWalkContext.cpp: In static member function static bool CChainWalkContext::LoadCharset(std::string):
ChainWalkContext.cpp:119: error: memcpy was not declared in this scope
ChainWalkContext.cpp: In static member function static bool CChainWalkContext::SetPlainCharset(std::string, int, int):
ChainWalkContext.cpp:165: error: m_nPlainSpaceUpToX was not declared in this scope
ChainWalkContext.cpp:178: error: m_nPlainSpaceTotal was not declared in this scope
ChainWalkContext.cpp: In static member function static bool CChainWalkContext::SetRainbowTableIndex(int):
ChainWalkContext.cpp:188: error: m_nReduceOffset was not declared in this scope
ChainWalkContext.cpp: At global scope:
ChainWalkContext.cpp:303: error: no u_int64_t CChainWalkContext::GetPlainSpaceTotal() member function declared in class CChainWalkContext
ChainWalkContext.cpp: In static member function static void CChainWalkContext::Dump():
ChainWalkContext.cpp:339: error: m_nPlainSpaceTotal was not declared in this scope
ChainWalkContext.cpp:342: error: m_nReduceOffset was not declared in this scope
ChainWalkContext.cpp: In member function void CChainWalkContext::GenerateRandomIndex():
ChainWalkContext.cpp:348: error: m_nIndex was not declared in this scope
ChainWalkContext.cpp:349: error: m_nPlainSpaceTotal was not declared in this scope
ChainWalkContext.cpp: At global scope:
ChainWalkContext.cpp:352: error: prototype for void CChainWalkContext::SetIndex(u_int64_t) does not match any in class CChainWalkContext
ChainWalkContext.h:61: error: candidate is: void CChainWalkContext::SetIndex(int)
ChainWalkContext.cpp: In member function void CChainWalkContext::SetHash(unsigned char*):
ChainWalkContext.cpp:359: error: memcpy was not declared in this scope
ChainWalkContext.cpp: In member function void CChainWalkContext::IndexToPlain():
ChainWalkContext.cpp:367: error: m_nIndex was not declared in this scope
ChainWalkContext.cpp:367: error: m_nPlainSpaceUpToX was not declared in this scope
ChainWalkContext.cpp:374: error: m_nIndex was not declared in this scope
ChainWalkContext.cpp:374: error: m_nPlainSpaceUpToX was not declared in this scope
ChainWalkContext.cpp: In member function void CChainWalkContext::HashToIndex(int):
ChainWalkContext.cpp:438: error: m_nIndex was not declared in this scope
ChainWalkContext.cpp:438: error: m_nReduceOffset was not declared in this scope
ChainWalkContext.cpp:438: error: m_nPlainSpaceTotal was not declared in this scope
ChainWalkContext.cpp: At global scope:
ChainWalkContext.cpp:441: error: no u_int64_t CChainWalkContext::GetIndex() member function declared in class CChainWalkContext
ChainWalkContext.cpp: In member function bool CChainWalkContext::CheckHash(unsigned char*):
ChainWalkContext.cpp:491: error: memcmp was not declared in this scope
In file included from ChainWalkContext.h:11,
from RainbowTableGenerate.cpp:18:
Public.h:25: error: u_int64_t does not name a type
Public.h:26: error: u_int64_t does not name a type
Public.h:37: error: u_int64_t was not declared in this scope
Public.h:38: error: u_int64_t was not declared in this scope
In file included from RainbowTableGenerate.cpp:18:
ChainWalkContext.h:30: error: u_int64_t does not name a type
ChainWalkContext.h:31: error: u_int64_t does not name a type
ChainWalkContext.h:34: error: u_int64_t does not name a type
ChainWalkContext.h:37: error: u_int64_t does not name a type
ChainWalkContext.h:56: error: u_int64_t does not name a type
ChainWalkContext.h:61: error: u_int64_t has not been declared
ChainWalkContext.h:68: error: u_int64_t does not name a type
RainbowTableGenerate.cpp: In function int main(int, char**):
RainbowTableGenerate.cpp:113: error: strcmp was not declared in this scope
RainbowTableGenerate.cpp:115: error: atoi was not declared in this scope
RainbowTableGenerate.cpp:128: error: atoi was not declared in this scope
RainbowTableGenerate.cpp:207: error: u_int64_t was not declared in this scope
RainbowTableGenerate.cpp:207: error: expected `;' before nIndex
RainbowTableGenerate.cpp:208: error: nIndex was not declared in this scope
RainbowTableGenerate.cpp:222: error: nIndex was not declared in this scope
RainbowTableGenerate.cpp:222: error: class CChainWalkContext has no member named GetIndex
make: *** [rtgen] Error 1
Vajon az idő járt el a forrás felett, vagy sose fordult csak úgy Debianon? Mindenesetre kicsit komolyabban átnézve a logot, egyértelmű volt, hogy a Public.h -ban nem stimmel valami, amihez bizony az u_int64_t -nek is köze van. Azonnal elő is kaptam kedvenc vim editorom, és néztem vajon mik hiányoznak. A fájl elején az #include-k között kell keresni a hibát:
rogue:~/tools/rainbowcrack-1.2-src/src# vi Public.h ... #include <stdio.h> #include <string> #include <vector> #include <list> ...
Ami innét hiányzik nekünk az a cstdlib és a cstring. Orvosoljuk a hibát, a header fájl eleje így nézzen ki:
rogue:~/tools/rainbowcrack-1.2-src/src# vi Public.h ... #include <stdio.h> #include <string> #include <vector> #include <list> #include <cstring> #include <cstdlib> ...
Ezek után nekifutva a fordításnak ezt kapjuk:
rogue:~/tools/rainbowcrack-1.2-src/src# make -f makefile.linux g++ Public.cpp ChainWalkContext.cpp HashAlgorithm.cpp HashRoutine.cpp RainbowTableGenerate.cpp -lssl -O3 -o rtgen g++ Public.cpp ChainWalkContext.cpp HashAlgorithm.cpp HashRoutine.cpp RainbowTableDump.cpp -lssl -o rtdump g++ Public.cpp RainbowTableSort.cpp -o rtsort RainbowTableSort.cpp: In function ‘int QuickSortPartition(RainbowChain*, int, int)’: RainbowTableSort.cpp:37: warning: integer overflow in expression g++ Public.cpp ChainWalkContext.cpp HashAlgorithm.cpp HashRoutine.cpp HashSet.cpp MemoryPool.cpp ChainWalkSet.cpp CrackEngine.cpp RainbowCrack.cpp -lssl -O3 -o rcrack
És már működik is minden, nyugodtan generálhatjuk a szivárvány táblázatainkat a nagyvilágnak :)
#eof
Rogue GNU/Linux 0.1
Írta: Kerekes Attila
Jun/090
Egyre többet dolgozgatok a saját linux rendszeremen. Kiindulási alapnak egy Debian lenny-t vettem, minimális telepítéssel. Majd telepakoltam svn-ből összeszedett biztonságtechnikával kapcsolatos programokkal. Eddig egész jól haladok vele, talán egy szép napon sikerül egy Backtrack klónt összehoznom, amiben kicsit kevesebb a cenzúra. Ha már kialakult egy stabil köre a programcsomagoknak, amiket szeretnék benne látni, megpróbálom átrakni az egészet LFS alapra. De azthiszem ez még odébb van. Nézzük eddig mi került bele, nagy vonalakban:
- Grafikai felület: Fluxbox, urxvt, firefox + több plugin, rdesktop… (Bár sokat gondolkodtam, hogy legyen e egyáltalán xorg a rendszeren, több program kezelhetőségéhez létfontosságúnak bizonyult. pl: rdekstop.)
- Exploitokhoz pár tool: metasploit, w3af, evilgrade…
- Hálózati támadásokhoz: ettercap, dsniff csomag, sslstrip, wireshark, nmap, Nkiller2 (lol!)
- Wifi támadásokhoz: aircrack-ng, cowpatty, mdk3, kismet, módosított driverek.
- Jelszavak támadásához: john, Ophcrack, Hydra, Medusa (utóbbi kettő még mindig lehet efektív nagyon sok helyen, bár nem túl finom.)
- Windowsos programok jelszavak könnyű kifejtésére.
- Szivárvány táblák, hash táblák, szólisták. (Sajnos ezek már most rengeteg helyet foglalnak…)
- Rootkitek, logfile tisztítók, backdoor programok
- Postgresql szerver.
- Saját programok, scriptek.
Kitudja, talán egyszer egy komoly security related disztribúció lesz az egészből, vagy csak megmarad örökre nekem. :) Mindezek mellett egy Rogue GNU/BSD sem lenne rossz…
#eof
Netcat proxy második nekifutás
Írta: Kerekes Attila
May/090
Előző gondolatmenetet kicsit tovább vittem. Tegyük fel, hogy állandóan proxyzni szeretnénk egy porton. Ha az alábbi parancsot használjuk:
nc -l -p 31337 0<backstream | nc google.hu 80 1>backstream
akkor ha csatlakozunk a böngészőnkkel, bejön a google.hu, de a program ki is lép a routeren, így ha másodikra is próbálkozunk, nem fog már bejönni a honlap. Mit tehetünk ilyenkor? Erre találták ki a inetd-t vagy Xinetd-t. Én most a Xinetd-s megoldást fogom vázolni. Elsőre is az /etc/services fájlban létre kéne hozni az új szolgáltatásunkat. Ezt az alábbi sorral tehetjük meg:
duckroll 31337/tcp # duckrolling nc
Létre is hoztuk a duckroll servicet, ami bizony a 31337-es tcp portot használja. Ezekután jöhet a Xinetd bejegyzés. Hozzunk létre egy filet az /etc/xinetd.d/-ben:
touch /etc/xinetd.d/duckroll
És másoljuk bele a következőt:
service duckroll
{
flags = Reuse
socket_type = stream
wait = no
user = root
protocol = tcp
server = /root/duckroll.sh
only_from = localhost 10.0.0.0/8
disable = no
}
Az only_from mezőt értelemszerűen töltsük ki, hogy a saját hálónkról is be tudjunk lépni (pl 192.168.0.0/24). Nézzük mi is kerüljön a /root/duckroll.sh-ba:
#!/bin/bash /bin/nc google.hu 80
Ezekután már akárhányszor csatlakozunk a 31337-es portunkra, mindig a google.hu fog bejönni.
Oké, de mi az értelme ennek az egésznek. Elmélkedjünk rajt egy kicsit. Lényegében az adatforgalmat átdobtuk egy shell scripten, amiben össze vissza loggolhatjuk és átírhatjuk az egészet. Nézzünk egy példát:
#!/bin/bash /bin/tee -a forgalom.log | /bin/nc google.hu 80
Most a forgalom.log-ba már láthatjuk is a böngészőnk által küldött kérést. Nézzük tovább:
#!/bin/bash /bin/sed -u s/duckroll/rickroll/ | /bin/nc google.hu 80
Lehet tippelni. Ha esetleg valaki a hálón rákeresne a duckrollra, akkor rickroll eredményét fogja megkapni. Persze miért írná be bárki is a google.hu cím helyett a routerünk címét, ráadásul a 31337-es porttal utána. Ez így elég furcsa… De egy iptables szabály segíthet a problémán:
iptables -t nat -A PREROUTING -p tcp --dport 80 -d google.hu -j REDIRECT --to-port 31337
A REDIRECT mindig a routernek a –to-port-ban megadott portjára küldi a csomagokat tovább. Így már ha simán a google.hu-ra vagyunk kiváncsiak is a proxyzott, shell scripten átfuttatott oldalt kapjuk.
Ez szép és jó, de most már igazán nézhetnénk valami hasznos példát az egészre… Tegyük fel, hogy egy adott torrent oldalon például az arányunkkal akarunk játszani. Mi minden kéne:
- iptables-ben egy szabály ami a torrent oldal felé haladó kapcsolatokat beszipkázza.
- egy script ami az adatokat megfelelően módosítja
Az iptables szabály valahogy így nézne ki:
iptables -t nat -A PREROUTING -p tcp --dport PORT -d HOST -j REDIRECT --to-port 31337
PORT: a torrent tracker portja (pl 11337)
HOST: a torrent tracker címe (pl … :)
A duckroll.sh scriptünk valami ilyesmi is lehetne, ha mondjuk az általunk letöltött mennyiséget szeretnénk kinullázni (freeleech):
#!/bin/bash /bin/sed -u 's/downloaded=.*\&left/downloaded=0\&left/' | /bin/nc HOST PORT
És kész is vagyunk. Innéttől ha a torrent kliensünk kapcsolódni akar a trackerhez, a kapcsolatot elkapja a routerünk, átírja benne az általunk letöltött mennyiséget nullára, majd továbbítja az adatokat. Persze a trackerek nagyrésze az ilyen ügyeskedéseket figyeli, és bannolja a csalókat. Egy bonyolultabb scripttel akár ésszerű feltöltést is lehet szimulálni.
Gondoljuk csak végig, milyen könnyen és milyen kevés alap unix eszközzel sikerült ezt elérnünk. Hasonló módszerrel különböző adatfolyamokat manipulálhat bárki, ezt kombinálva mitm támadásokkal könnyedén lehet rosszindulatú kódot bejuttatni egyes adatfolyamokba…
Ajánlott irodalom:
http://www.linuxfocus.org/English/November2000/article175.shtml
http://www.stearns.org/doc/nc-intro.v0.80.html
#eof
Netcat proxy
Írta: Kerekes Attila
May/090
Sok helyen olvastam, hogy ez lehetséges, de valahogy igazi élő példát nem találtam rá. Viszont amit találtam:
mkfifo backstream nc -l -p 31337 0<backstream | nc google.hu 80 1>backstream
Ezek után ha csatlakozunk a gépünk 31337-es portjára egy böngészővel, jó eséllyel a google.hu fog bejönni. Oké, ez frankó, de mire megyünk vele? Ebben a formában tényleg nem sokra. De tegyük fel, hogy valahol egy tűzfal mögött ücsörgünk, és szeretnénk ircezni, de csak a 80as port van engedélyezve kifele (suli, meló, stb).
mkfifo backstream nc -l -p 31337 0<backstream | nc irc.atw.hu 6667 1>backstream
Most ha kívülről csatlakoznánk az otthoni gépünk 80as portjára egy irc klienssel mondjuk, akkor az továbbküldene minket az atw.irc.hu 6667es portjára. Persze erre sok más és talán egyszerűbb megoldás is létezik. Mégis miért lenne érdemes ezt így megvalósítani? Itt lényegében akármilyen egyéb shellscriptet közbe szúrhatunk, pl:
mkfifo backstream nc -l -p 31337 0<backstream | sed -u s/rick/duck/g | nc irc.atw.hu 6667 1>backstream
Ezt használva ezentúl ircen akárhányszor azt írjuk be a kliensünkbe, hogy rick, a többiek duck-ot fognak látni. Magyarul megváltoztattuk az áthaladó adatfolyamot. És ezt kombinálva pár egyéb technikával igen komoly eredményeket érhetünk el…
#eof