Názory k článku K čemu lze zneužít FTP bounce-scanning
-
anonymníPan Haller, všetky vaše články sú "pecka". A kedže Vás považujem za odborníka, chcem sa opýtať:
"Existuje nejaký spôsob ako simulovať pripojenie z inej IP adresy ako v skutočnosti mám? Resp. je možné uskutočniť požiadavku na webový server Apache z inej IP a následne odchytiť odpoveď z webového serveru (SYN,ACK,FIN)? Nemám v úmysle hackovať, len potrebujem vyriešiť problém z Googlebotom a kedže nemám prístup k apache logom, chcel by som si overiť ako server odpovedá na požiadavky z IP adresy Googlebota." -
anonymníDík za tip. O tom viem, ale mne nejde o to čo konkrétne posiela Apache, ale či vôbec Googlebot dostáva odpoveď. V Google Webmaster Tools mi totiž pravidelne pri každom pokuse Googlebota o "crawl" ukazuje DNS chybu (opakuje sa to už tretí mesiac). Server pritom beží OK, ostatné roboty aj bežný surferi podľa awstat problém nemajú.
-
Martin Haller (neregistrovaný)Dekuji za pochvalu.
Ohledne problemu s Googlebotem vam asi prilis nepomuzu.
Ovsem na otazku "Existuje nejaký spôsob ako simulovať pripojenie z inej IP adresy ako v skutočnosti mám?", vam odpovedet muzu.
Pozadavek se zfalsovanou adresou odeslat muzete, ovsem problem je v tom ze server bude odpovidat na tuto zfalsovanou IP adresu a odpoved bude smerovana uplne nekam jinam, to tedy znamena ze k vam odpoved neprijde.
Tento problem by jste mohl vyresit pouze pokud by jste byl v s lokalni siti s danym serverem, nebo na trase, kterou je pripojen do internetu. V tom pripade by jste slysel komunikaci a mohl reagovat (data dale nepropustit a odpovedet na ne).Existuji i protokoly, kterymi se da menit smerovani v internetu a vlastne tak presouvat toky dat, ovsem do tehle oblasti nevidim.
Dalsi moznosti by mohlo byt pozmeneni routovacich pravidel na serveru. Ovsem to vyzaduje mit administratorska prava k serveru. Napriklad na Linuxu by jste toho mohl docili pomoci natovani (pres IPTABLES). Data by prichazela na server s vasi IP adresou, ovsem server by prepsal zdrojovou IP adresu a pak teprve predal data ke zpracovani a pri odchozich datech by se cilova adresa opet prepsala na vasi. -
anonymníĎakujem za odpoveď. Myslel som, že to nepôjde. Je to škoda, pretože aj môj ISP je z toho problému zúfalý. Na Apachi bežia viaceré "virtual hosts" domény a problém s DNS a Googlebotom mám ja a ešte jedna. Je to zaujímavý problém, pretože nefunguje ani napr. Site Overlay v Google Analytics. A hlavne ťažko sa hľadá chyba. Keby sa aspoň dal vykonať reverzný dotaz na nejaký z nameserverov Google. Ale už dosť, toto nijako nesúvisí s článkom.
Chcem sa, ale opýtať koľko pokračovaní plánujete? Dúfam, že veľa. Z vašich článkov napriek tomu, že (chvalabohu) neuverejňujete detailné postupy som sa veľa naučil. Sú to najlepšie, čo kedy lupa uverejnila.
A ešte jedna otázka. Existuje nejaká šanca nastaviť iptables aby "prepúšťali" pakety pre aktívne ftp serverom naväzované spojenie. Nie som nijaký expert, ale keď som to dobre pochopil, tak spojenie medzi klientom vzniká požiadavkou klienta na port 21 (20?) ftp servera. Potom sa server snaží vytvoriť spojenie s klientom na nejakom vysokom porte. Aj keď ide o "odchodzie" spojenie iptables to štandartne zablokujú. Nechápem prečo, keď spojenie začal klient na porte 21 (20?) a v úvodných pravidlách iptables mám nastavené "ESTABLISHED" spojenia na "ACCEPT". V SUSE to riešim, tak že otvorím všetky highports. -
Martin Haller (neregistrovaný)Vlastne to spojeni na portu 21 je spojeni pro vymenu prikazu a odpovedi.Vyhoda vytvareni noveho spojeni je v tom , ze muzete treba stahovat deset souboru najedno a pritom jeste dva uploadovat, vsechna komunikace probiha na jinych spojenich a to puvodni spojeni je volne, a diky nemu muzete navazovat dalsi spojeni (upload, download) aniz by jste se musel napriklad znovu prihlasovat.
Urcite to takto bylo udelano kvuli snadnejsi implementaci a prehlednosti. Protoze to nove datove spojeni je jakoby jednostrane (data proudi vzdy jenom jednim smerem), a uz v nem neproudi zadne prikazy, ale okamzite data. Jakmile jsou odeslana nebo prijata vsechna data je spojeni automaticky zavreno.
Jestli to bylo z jineho duvodu, tak me klidne kdokoliv opravte.
Planuju napsat jeste nejmene dva clanky a to RST Resetovaci utok a Unos TCP spojeni, potom se uvidi, ale se psanim bych nerad skoncil. -
Martin Haller (neregistrovaný)Pekne je o vysvetleno zde http://slacksite.com/other/ftp.html
-
Martin Haller (neregistrovaný)Jinak ohledne IPTABLES a odchoziho spojeni, tak si myslim ze na to je primo nejakej modul, zkusil bych google: "iptables aktivní ftp", nebo ja napriklad neco zde http://www.root.cz/clanky/linux-jako-internetova-gateway-4/
-
h4x0rr (neregistrovaný)krasny clanek, velmi jsem se pobavil.
ve spouste veci je totiz uplne mimo, ba primo zavadejici a zavani to spise pokusem o zamlzeni realnych informaci ;-)
FXP transfer jakozto utok na 2 ftp servery. pocitam ze kdyz je nejakej scene release tak jedna glftpd topsite dosuje druhou, ze?
je velka skoda ze prave diky "ftp utokum", jak leckteri 'odbornici' nazyvaji rfc chovani prikazu PORT (tj akceptovat jakekoukoliv ip, nejen tu ze ktere je control connection) FXP skoro nikde nefunguje, resp. lidi sou liny si to nastavit:
1) povolit FXP jen ne-anonymnim uzivatelum
2) povolit port pouze VYSSI nez 1024, toto je dulezite!
PORT sem nikdy nevidel v nasazeni typu DoS jaky autor zminuje - nejake halabala posilani dat. pravdepodobne si to spletl s popularnim PORT/RETR/POST utokem (uploadnem soubor s POST /script.php a hodne velkym contentem). staci 50-60 FTP serveru a sajta je mrtva. ne na traffic, ale umrtvenej apache kterej se rozswapuje.
ale dnes uz jsou na to mnohem vhodnejsi sluzby (napriklad rekurzivni DNS, kde je amplifikace lavinovita, nikoliv linearni jako u ftp)
daleko zajimavejsi nasazeni je posilani spamu.
priklad, ulozit soubor:
------------8< spam.txt
HELO brmbrm
MAIL FROM: spammer@company.com
RCPT TO: poor@user.cz
DATA
spamy spamy
.
QUIT
a pak:
PORT 1,2,3,4,0,25
RETR spam.txt
a voila, na smtp server podporujici pipelining muzeme vesele spamovat.
ditto pro irc:
----------------
USER h4x0rr +iw h4x0rr :spam bot
JOIN #loze
PRIVMSG #loze :you all suck!
QUIT :ftp rulz
existuje daleko vice sluzeb ktere nutne nevyzaduji interakci z druhe strany. a to nemluvim o tom ze nektere ftp servery (minimalne to vim o ncftpd) podporuji obousmerne data spojeni (tj. RETR a STOR najednou), viz rfc, kde se da zprovoznit kompletni protokolova interakce.
a ted trosku neco pro inspiraci, pro ty mladsi z nas kteri uz si urcite nudou okousaly nechty az na kost. autor popsal prikaz PASV, tak vas toho usetrim. vtip je totiz vtom ze drtiva vetsina serveru (jsou vyjimky, vsftpd) se zase tak moc nezajima o to kdo se na hlasenou ip/port pripoji. prave pro pripad ze by to byl FXP transfer. operacni systemy zpravidla alokuji listening sockety sekvencne, takze se trivialnim zpusobem predpovi pocatecni range a pak uz se jenom skript ve smycce snazi pripojit a predbehnout toho co nahodou spustil prikaz RETR/STOR. je to race condition, ale dost uspesna (obvzlaste velke virtual hostingy, .php skripty s hesly do databaze atp)
tohle vsechno jsou zalezitosti pomerne stare a v takovemto clanku by nemely chybet. pane hallere, obvykle vase prispevky z oblasti security jsou docela uchazejici, ale tentokrat se vam vase "how to hack for dummies" moc nevydarilo. prislo mi to takove krecovite. doufam ze se polepsite ;-)
stay bored, nothing to come -
Martin Haller (neregistrovaný)Diky za vas nazor. Jsem rad ze taky nekdo napise neco zajimaveho.Pokusim se na vsechno odpovedet, v kazdem pripade chci jeste zminit, ze nejsem zadny guru, ale jasem clovek a muzu se splest nebo zmilit.
Ad1) Ohledne prvniho odstavce muzete mi blize vysvetlit co jste napsal? Napriklad co pro vas znamena pojem scene release? Take co to je glftpd? Ja jsem myslel ze to je software (FTP server). Vubec ale nechapu co jste timto odstavcem zamyslel.
Ad2) V clanku byla rec o ftp bounce-scanningu jak by jste to nazval vy? Ohledne FXP, tak to at si resi kazdy sam a jestli je dobre to povolovat nebo ne je na veci spravce, preci jenom je to dost zneuzitelna vec.V kazdym pripade v tomto odstavci neni nic v rozporu s clankem.
Ad3) To ze jste to nevidel nic neznamena, sam jsem psal ze to nikde na internetu temer neni. Spise se zamyslete nad tim jestli takova technika muze fungovat a ja jsem presvedcen ze muze. Je to velice efektivni zesilujici zaplavovy DoS utok.
Ad4) Muzete mi prosim vysvetlit jak jste myslel lavinovitou amplifikaci. Podivejte se prosim jestli jestli ten utok, ktery myslite neni ten, ktery jsem popisoval u reflexnich DoS utoku.
Ad5) Ano spamovat je mozne, v clanku jsem se o tom zapomel zminit.
Ad6)O obousmernych spojenich zatim nic nevim. Takze se to v blizke dobe doucim ;).
Ad7) Ohledne toho race condition je to velice zajimave. Urcite bych ovsem o nem nepsal ze pravdepodobnost uspechu je dost velka.
Ano jsou to veci dost stare, a presto o nich spousta lidi nevi. To ze by takoveto informace nemeli v clanku chybet je vas nazor. Ted jsou tyto informace alespon v komentarich diky vam, takze vam dekuji za doplneni.
Ovsem nikde ve vasem komentari jsem nenarazil na neco co by bylo v rozporu s mim clankem, nebo by upozornovalo na chybu v nem. Proto vas prosim aby jste si prsite lepe rozmyslel titulek komentare.
Ja se na oplatku zase pokusim polepsit ;). -
anonymnízdravim,
1) glftpd je vec co pouzivaji warezaci na takovejch tech zrudnostech co maji 15-30 disku a gbit uplink. rika se tomu topsite. kdyz vyjde novy release (film,warez,prime time serial..) pomoci protokolu fxp se to behem nekolika minut roznese na ostatni servery po celem svete. popsat beznou feature (zminenou tusim v uplne prvnim rfc 765) jako "utok" je ponekud zcestne.
2) bounce scanning je zneuzivani FXP ke scanovani. nic vic, nic min. bounce scanning neni DoS/spam/fw/hijack utok, i kdyz ostatni techniky vychazeji ze stejneho principu, totiz PORT/PASV mechanismus. nazev bych asi ladil v duchu vice vypravnem, kuprikladu "netusene moznosti ftp protokolu", "alenka v risi ftp" nebo podobne.
3+4) to je sporne. pokud neposlete to spravne "intro" vetsina serveru zahodi spojeni uz po prvni radce, amplifikace je tedy sizeof("PORT <victim>\r\nRETR <junk>\r\n") versus pocatecni velikost mss (zpravidla 1500 bajtu). takze prinejlepsim 1:200 nezapominejte na to ze tcp zacina posilat data pomalu a postupne zrychluje. linearni amplifikace je ze se proste traffic nasobi nejakou konstantou, pri lavinovite je vyraz kvadraticky/exponencialni. neco jineho je samozrejme utok na protokol jako takovy (viz zmineny PORT/RETR/POST versus apache)
5) zalezi na tom jestli ma cil zapnutou ESMTP pipeline. diky rozsirenosti spamu tomu tak z vetsiny bohuzel neni, protoze jinak by slo spamovat i obycejnym javascriptem per page-view.
6) asynchronni abor/quit/retr atp. jsou dnes spise exotika, z duvodu komplexnosti implementace a nulove podpory ze strany novejsich ftp klientu.
a k te race condition. predpokladejme ze chceme zachytavat range 100 portu (bohate staci na odchyt vice jak 50% spojeni na busy serveru po dobu nekolika minut). klient potrebuje na PORT/RETR 2x round trip, rekneme 50ms.
pak tedy potrebujem na kazdy port poslat SYN probe kazdych 25ms, tzn 1000/25*100, pri velikosti 74 bajtu na paket to mame permanentni 2.3Mbit stream pri 4kpps, nerealne pro bezneho frantu dsl uzivatele ale na ethernetu zanedbatelne. lidi s 25ms rtt predbehneme v 99% pripadu, cim nizssi maji rtt, umerne tomu se nase sance zuzuje.
samozrejme spojeni musi byt passive, coz mnoho lidi splnuje kvuli rozbitym NAT a/nebo ssl+NAT.
stejne jak je snadne tento utok iniciovat je snadne ho rozpoznat: klient dostane 150 reply ze transfer byl iniciovan ale pritom se mu nikdy nepodari pripojit.
je mozne v takovem pripade control session okamzite zavrit a doufat ze server killne spojeni utocnikovi driv nez neco zajimaveho dostane (ABOR neni tak spolehlivy, jelikoz ho mnoho demonu asynchronne neumi). implementace teto ochrany u ftp klientu by stala za pruzkum.
jenom tak mimochodem, moderni demoni jako vsftpd generuji svuj PASV port nahodne, coz sance ponekud snizuje, ale utok je stale proveditelny (typ obtiznosty ekvivalentni dns cache poisoningu)
podobny utok lze teoreticky aplikovat i na active (tj PORT) spojeni ale zde je prilis mnoho promennych faktoru jako IP adresa obeti, implementace NATu, sekvence poslouchajicich portu...
...
mou "kritiku" si neberte moc k srdci, jsem proste takovy ;) ... nechal jsem se unest emocemi kdyz nekdo pise o takovych peknych vecech a vynecha to nejlepsi (+zavadejici informace ze FXP je implicitne "utok").
kdyz jsem byl jeste maly a programoval v Ccku, napsal jsem si par zajimavych toolu na "featury" ruznych protokolu, pokud nekdo bude mit oduvodneny (tzn ne "chci hacknout kamaradovi stranky na sweb.cz" :) zajem, piste na h4x0rr@hysteria.cz
ČLÁNKY DO MAILU