FSCK Everything Goes!

Netcat proxy második nekifutás

Írta: Kerekes Attila

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