Vlákno názorů k článku K čemu lze zneužít FTP bounce-scanning od h4x0rr - krasny clanek, velmi jsem se pobavil. ve spouste veci...
-
Článek je starý, nové názory již nelze přidávat.
- Podle hodnocení
- Podle vláken
- Nejnovější
-
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
