Tak, po nejakom období som napísal ďalšiu časť nášho malého seriálu.
V tejto časti si ukážeme ako správne spravovať relácie užívateľov, ukradnutie
identity a maskovanie identity cez proxy.
11.4.2012 00:00 | Marek Beleščiak | read 6792×
DISCUSSION
Session Management
Session Management je spôsob akým sa spravujú relácie užívateľov. Kedže
vďaka http protokolu server nevie identifikovať klienta, ten musí odoslať cookies,
aby sa identifikoval. Pokiaľ vám to stále nič nehovorí, zamyslite sa, čo sa asi
stane keď sa na nejakej stránke prihlasíte - ako server ďalej vie, že ste to práve VY ?
Pri prihlásení vám server poslal identifikátor, ktorý mu pri každej požiadavke posielate naspäť.
Čo ak ale identifikátor, ktorý dostanete je slabý, spätne ľahko vygenerovaľný, popr. zmeniteľný
tak aby sa za vás mohol hocikto prihlásiť bez toho aby vedel údaje ?
Ako vždy najlepšie je si uviesť príklad takéhoto zistenia, hacknutia a zmenenia identity.
Frank a Sony boli kamárati. Jedného dňa sa ale strašne pohádali. Frankov koníček bola
bola webová bezpečnosť tak sa rozhodol, že sa Sonymu pomstí. Vedel, že Sony
najradšej navštevuje stránku example.com a takže tam mal aj veľa osobných a citlivých informácií.
Frank tam nikdy nebol, zato však vedel, že Sonyho meno je Sony225.
Frank neváhal ani sekundu. Zaregistroval sa na example.com ako Frank001 a keď sa prihlásil,
pozrel si identifikátor:
==wMyEjMEJDM2IkMyITRzMjMGJjNzIkMFBjR3U0NFdTNyAjMGJzQzgDM
Tvar mu veľmi pripomínal base64, vedel ale, že bude najskôr obrátený pretože base64 má rovnítka na konci.
Preto ho obrátil a skúsil dešifrovať ako base64, jeho výsledok bol nasledujúci:
083C2F20257E7E7F0E2B362F233E222B602D2123
Vyzeralo to ako hash, a veľa mu to nevravelo. Keď prehodil hex na znaky na nič nové neprišiel.
Vytvoril si preto ešte dva nové účty Frank002 a Frank003. Porovnal si hashe všetkých troch účtov:
Frank001: 083C2F20257E7E7F0E2B362F233E222B602D2123
Frank002: 083C2F20257E7E7C0E2B362F233E222B602D2123
Frank003: 083C2F20257E7E7D0E2B362F233E222B602D2123
Hashe boli skoro rovnaké. Nezhodovali sa len v ôsmom byte:
Frank001: 083C2F20257E7E7F0E2B362F233E222B602D2123
Frank002: 083C2F20257E7E7C0E2B362F233E222B602D2123
Frank003: 083C2F20257E7E7D0E2B362F233E222B602D2123
Frankovy bolo hneď jasné, že ten rozdiel robia práve číslice 1,2,3. Vyzeralo
to na XOR-ovú šifru, bolo mu hneď jasné, že ten hash je vlastne užívateľské
meno prehodené do hexu a každý byte nejak zašifrovaný. Preto si zostavil malý skript, ktorý vyskúšal všetky
možné kombinácie šifry (nebolo ich tak veľa je to v rozmedzí 0-255) na znak 0x7F, pokiaľ by daná šifra fungovala
aj na ostatné byty, má vyhrané.
Skript ho nesklamal. Vrátil mu hodnotu 0x4E. Keď celý ten hash rozxoroval číslom 0x4E vysledok bol nasledovný:
Frank001@example.com
Teraz už Frank vedel, že je veľmi blízko. Zaxoroval si reťazec "Sony225@example.com", zakódoval do base64 a obrátil.
Výsledok bol:
=MjMxIDRyAjNCJjMyU0MzIjRyYzMCJTRwI0NDdzQ3czMwITMyQUM
Keď si potom vo svojom prehliadači zmenil cookie na túto hodnotu a navštívil example.com, bol už prihlasený za Sonyho a pomsta mohla
začať.
Záver
Session hijack není zrovna najľahší typ útoku ale jeho následky sú drvivé.
Identifikátory by mali byť jedinečné, rozhodne by sa nemali zakladať na údajoch používateľa. Ak
by sa nejaký užívateľ prihlásil aj viac krát, vždy by mal dostať rozdielny identifikátor. Pokiaľ
je to možné, relácia by sa mala zamykať na IP adresu. Takže ak by ste boli prihlasený
pod 192.168.1.100 a niekto z adresy 192.168.1.101 by poslal presne váš identifikátor, tak by jednoducho neprešiel.
Proxy a maskovanie identity
Proxy je server ktorý stojí medzi koncovým užívateľom a serverom.
Podstata je v tom, že užívateľ pošle požiadavku proxy serveru, ten koncovému serveru,
koncový server vráti údaje proxy serveru a ten pôvodnému užívateľovi. Takto
sa dá pomerne ľahko "schovať", pretože vy ako užívateľ nekomunikujete so serverom,
ten nevie vašu IP ale vie len IP proxy servera. Na internete môžte nájsť tisícky takýchto servrov,
dávajte si ale pozor na súkromie. Ľahký postup ako si zapnúť proxy je spustiť terminál nastaviť si http_proxy premennú. Napr.
export http_proxy="http://127.0.0.1:8080/" potom si môžte spustiť cez terminál svoj prehliadač a ten už bude bežať cez proxy (overený len chrome).
O čo vlastne ide
Klient pri posielaní požiadavky môže uviesť hlavičku "X-Forwarded-For" kde sú IP adresy počítaču/ov pre ktoré
danú požiadavku posiela. Vlastne o sebe tvrdí, že je proxy a posiela adresu originálneho klienta.
Táto hlavička sa dá ale veľmi ľahko zmeniť. To znamená, že pokiaľ web používa na zistenie reálnej ip adresy
spôsob podobný tomuto, robí veľmi zle. Nemôžete totižto slepo dôverovať dátam ktoré môžu byť fiktívne. V praxi, ale niektoré
proxy servery robia to, že adresu v hlavičke X-Forwarded-For si úplne vymýšlajú resp. posielajú náhodne vygenerovanú.
Anonymné proxy túto hlavičku vôbec neposielajú.
Keby ste tejto hlavičke dôverovali a brali ju tak ako skript hore, všetky opatrenia ktoré máte
napr. 'zablokovanie ip po 100 neúspešných pokusoch o prihlásenie' alebo 'hlasovanie je možné jednej ip adresy!' strácajú zmysel, navyše všetko,
kde dáte túto ip môže byť mylné. Veď, čo môže byť lahšie ako si napísať skript, ktorý automatický bude náhodne generovať túto hlavičku a robiť za
vás špinavú robotu ? Niekedy však táto hlavička môže byť užitočná. Rozhodne je ale lepšie dôverovať len tej pravej ip adrese, aj ked niekedy
je možno lepšie vedieť čo najviac informácií, ak je to tak, osobne by som navrhol ukladať
aj ip klienta aj ip v tejto hlavičke - najlepšie čo najkratšie, čize v 4roch bytoch.
Dúfam, že som vám stručne a jasne objasnil problematiku s generovaním uživateľských relacií a taktiež
problematiku okolo pracovania, používania a vydávania sa za proxy
komunikovanie s proxy servermi.