Search the Community

Mai întâi de toate, vreau s? spun, c? acest tutorial, de fapt e r?spunsul unui mic Challenge, care a fost rezolvat doar de hari (lucru pentru care îl ?i felicit ?i m? bucur nespus c? a reu?it. Bravo!). Cât despre Challenge, a?a cum a spus ?i înving?torul, într-adev?r — a fost foarte simplu (desigur, dac? a?i auzit de func?ia ”preg_replace” ?i modificatorul ”e”)... ?i, dat fiind faptul c? nu doream, ca testul s? fie rezolvat prea u?or, în codul PHP, am folosit dou? mici ?iretlicuri: cu ajutorul semnului ”@”, am suprimat erorile (în caz c? cineva va testa scriptul pe serverul propriu); folosind func?ia Open_Page(), am l?sat s? se cread? c? este vorba de un LFI; Deci, dac? elimin?m liniile de cod care ne duc în eroare, din acel script va r?mâne doar o singur? linie: preg_replace( '#(<[a-z]+.*?>)(.*?)(</[a-z]+>)#isem', '\\2', $_POST['comment'] ); care, va extrage ?i va afi?a doar textul aflat în tag-urile HTML. De exemplu, din comentariul: Acesta este <a href='//site.com'>site-ul</a> meu , va fi extras? ?i afi?at? doar fraza ”Acesta este site-ul meu”. La prima vedere, aceasta nici pe departe nu pare a fi o vulnerabilitate, nemaivorbind despre PHP Shell, dar, v? rog s? atrage?i aten?ia la litera ”e” din lista modificatorilor: ”isem”. Deoarece anume acest modificator va trata parametrul ”\\2” ca fiind un cod PHP. Deci, pentru a primi detalii despre configurarea serverului, atacatorul trebuie s? posteze urm?torul comentariu: <i>phpinfo()</i> Astfel, preg_replace(),va extrage textul aflat în tag-ul ”<i>” ?i îl va trata ca pe un cod PHP, adic?, va afi?a rezultatul func?iei phpinfo(). ?i, cum v? da?i bine seama, mult mai periculos, este faptul c? atacatorul poate citi sau crea fi?iere pe server. De exemplu, pentru a citi datele din fi?ierul dbconfig.php, aflat în directorul inc/data se va folosi expresia: file_get_contents( base64_decode( aW5jL2RhdGEvZGJjb25maWcucGhw ) ) unde, func?ia file_get_contents() va citi informa?ia din fi?ierul inc/data/dbconfig.php, numele ?i adresa c?ruia a fost encodat? cu ajutorul func?iei base64_encode(). Exploatarea acestei vulnerabilit??i poate fi ob?inut? mult mai simplu, definind o noua variabil? dbconfig (apropo, aceasta poate fi atât de tip POST, cât ?i de tip GET). De exemplu, se ia pagina site-ului www.site.com, se adaug? parametrul dbconfig=inc/data/dbconfig.php ?i se acceseaz?: http://www.site.com/?dbconfig=inc/data/dbconfig.php în c?su?a comentariului se scrie: <i>file_get_contents($_GET[dbconfig])</i> astfel, dup? ce a se va posta comentariul, va fi afi?at? forma?ia din fi?ierul dbconfig.php. Vreau s? mai adaug, c? nu doar func?ia preg_replace(), ci ?i preg_filter() va executa ceea ce e descris mai sus. Not?: Ini?ial, credeam c? despre aceast? metod? nu a pomenit nimeni, dar cu mult timp în urm? (anul 2001) Shaun Clowes, în raportul Exploiting Common Vulnerabilities in PHP Applications, a aten?ionat ”publicul” despre func?iile care prezint? un mare pericol pentru aplica?iile PHP. B7ackAnge7z Special pentru RST