Flexibilitatea unui limbaj de programare se adaugă la comoditatea de dezvoltatori, dar, de asemenea, deschide noi vectori de atac. Dezvoltatorii PHP folosesc adesea așa-numitele wrapper'y și nu sunt chiar conștienți de faptul că acest lucru ar putea duce la eludarea securității construit în App și filtre, de exemplu, se lasă să se execute cod arbitrar pe server. Despre ambalaje, caracteristicile și riscurile asociate lor cu ei, și au discutat astăzi.
Vulnerabilitățile asociate cu mecanismul pus în aplicare în ambalaje PHP sunt discutate pentru o lungă perioadă de timp. Link-uri către ele sunt prezente în OWASP TOP 10 si WASC TCv2. Cu toate acestea, mai multe caracteristici ale punerii în aplicare a datelor de codificare rezultate în faptul că, chiar și aplicațiile dezvoltate cu securitate în minte, pot conține vulnerabilități (inclusiv critici). În această lucrare, vom examina mai întâi pe scurt ce sunt niște învelișuri PHP și modul în care acestea pot fi utile pentru programatori. Apoi analizează caracteristicile lor, care permit să ocolească filtrele de securitate încorporate pentru a pune în aplicare aplicare și de atac legate de accesul neautorizat la sistemul de fișiere și de a executa cod arbitrar.
Wrapper'y
în cazul în care ar fi numele fișierului $ poate fi folosit modul în care într-un fișier local. Este bine cunoscut faptul că pentru a obține conținutul fișierelor locale pot fi după cum urmează:
Dar așa-numitele înveli (înveliș) pot fi utilizate în plus față de calea banal la dosar. Cel mai bun mod de a explica ce este - câteva exemple. Deci, folosind ambalajele prin aceeași funcție fopen este posibilă:
Instalatii de ambalare (de asemenea, cunoscut sub numele de protocol sau înveliș stivuitoare) funcții indică modul de procesare a datelor din flux. Prin urmare, funcțiile care susțin învelișurile pot fi utilizate pentru a obține date din diferite surse. Împachetatoare permite flexibil și convenabil pentru a procesa datele care vin în program printr-un flux, și să le modifice, dacă este necesar.
În mod similar, se poate folosi funcția file_put_contents și orice altă funcție care acceptă înveliș în modul de scriere:
În versiunea de PHP 5.3.6 apărut înveliș php: // fd, care oferă acces direct la descriptorii de fișier. Dacă PHP este instalat ca modul de înfășurare php Apache: // IFD vă permite să scrie date arbitrare la access_log / error_log (de obicei, chiar pe aceste fișiere 644 și direct în ele se poate scrie doar de root).
Trebuie să spun că în PHP destul de o mulțime de built-in ambalaje, dar este posibil să se creeze și să înregistreze propriile ambalaje folosind funcția stream_wrapper_register. Mai multe informații puteți găsi pe site-ul oficial al PHP. O listă completă de ambalaje disponibile pot fi vizualizate cu secțiunea phpinfo - Curente PHP înregistrate.
Unele ambalaje au nedocumentat caracteristici care permit mai eficiente pentru a exploata vulnerabilitățile aplicațiilor Web. Este aceste caracteristici Reexaminăm astăzi.
Ce este ZIP plină?
ZIP - un format de compresie a datelor populare și fișiere de arhivare. Suport pentru acest format este implementat în toate sistemele de operare moderne și biblioteci de manipulare scrise pentru cele mai multe limbaje de programare. În PHP pentru a lucra cu acest format este modul zip util.
Linux-sistem de module zip devine disponibil, dacă PHP este compilat cu opțiunea -enable-Zip. Arhiva poate nu doar un singur fișier, ci directoare întregi; care păstrează structura de directoare, nume de fișiere care urmează să fie adăugate la arhivă, este permisă folosirea slash /. O altă caracteristică importantă a modulului este capabil să se ocupe de fișiere zip cu orice nume: principalul lucru pe care conținutul fișierului a fost format în mod corespunzător zip-arhiva.
După crearea zip-fișier, folosind zip înveliș: // puteți accesa fișierele din interiorul arhivei.
Posibilitatea de arhivare dosare în numele cărora există o bară oblică, permite să exploateze vulnerabilități, cum ar fi fișier de la distanță includ, în absența nul-byte. De exemplu, luați în considerare următorul script simplu:
Pentru a începe, să presupunem că este posibil de a crea fișiere de pe serverul destinație. Apoi, creând un zip-arhivă, așa cum se arată în exemplul de mai sus, este posibil să se execute PHP-cod pentru utilizarea înveliș zip: //.
Dacă nu puteți crea fișierul dorit folosind PHP-funcția, puteți utiliza fișierele temporare care creează un PHP atunci când descărcarea de conținut prin intermediul HTML-formular. Calea către fișierul temporar poate fi găsit în phpinfo (). Pentru mai multe informații despre modul de utilizare a fișierelor temporare în operarea tipurilor LFI / RFI de vulnerabilități pot fi găsite în rdot.org pe forum. Foarte important, directiva allow_url_fopen nu restricționează utilizarea de ambalaje zip: //.
Unde sunt datele mele: //?
date Wrapper: // de la începuturile sale a atras atenția specialiștilor în securitate web. În documentația oficială a învelișului de oferta utilizat într-un mod foarte limitat. Dar, în conformitate cu specificația RFC 2379, acest înveliș permite o sintaxă mai detaliată:
Astfel mediatype poate fie complet absente sau sa fie umplut cu valori arbitrare:
Această caracteristică a învelișului poate fi utilizat pentru a ocoli controalele și filtrele. De exemplu, în popularul v1.x script TimThumb au un astfel de filtru:
Pentru a ocoli această verificare după cum urmează:
În PHP există o funcție ca și stream_get_meta_data (). Conform documentelor oficiale, acesta preia metadatele din fluxul de fișiere și indicatoare:
În acest caz, matricea returnat conține elemente cu taste bine definite, iar sarcina de a adăuga la gama de elemente noi pare destul de problematic la prima vedere. Dar, cu ajutorul datelor de înveliș: // poate fi destul de ușor de manipulat matrice! Cum? Iată un exemplu:
Dacă fișierul $ variabila în loc de un nume de fișier local pentru a utiliza datele ambalaj,
compresă rece
Conform documentației, compress.zlib înveliș: // vă permite să decomprima GZ-fișiere. Dacă utilizați acest înveliș să se ocupe de date, non-zlib-arhivă, datele sunt returnate neschimbate.
De exemplu, citiți fișierul / etc / hosts poate fi după cum urmează:
„Foarte util!“ - crezi :). Cine va fi mai abruptă. Dacă ești chiar un pic de programare în PHP pentru web, probabil, sunteți familiarizați cu funcția prase_url (). Permiteți-mi să vă reamintesc, această funcție efectuează parsare URL. Și există un punct interesant: funcția de intrare, vă poate oferi nu numai URL-ul, și un șir de tip destul de general:
Având în vedere această caracteristică, puteți obține o varietate de controale și filtre bazate pe funcții parse_url folosind învelișurilor multifuncționale. De exemplu, luați în considerare următorul script, care, în conformitate cu dezvoltatorii conceput, poate încărca numai fișiere cu un img.youtube.com gazdă de încredere.
În timpul img.youtube.com previzualizare normale încărcate cu următorul text:
În acest caz, filtrul poate fi ocolită cu ajutorul compress.zlib înveliș: //.
În plus, pur și simplu ocolească filtrul pe numele gazdă și încărcați într-un fișier server cu un nume aleator și conținut folosind datele de contact înveliș discutat anterior: //:
În acest caz, fișierele locale sunt copiate într-un dosar cu previzualizare, în cazul în care dosarul este accesibil pentru acces direct din browser, devine posibil pentru a vizualiza fișierele de sistem. Acest exemplu demonstrează că utilizarea datelor ambalaje: // si compress.zlib: // poate fi util în script-uri pentru a descărca fișiere de la gazde de la distanță. Un astfel de script este TimThumb.
Exploatarea vulnerabilităților în v1.x TimThumb
linia de jos vulnerabilitate este că script-ul a verificat corect URL-ul din lista de gazde de încredere, din care a fost posibil pentru a descărca imaginile. Pentru a trece de filtru, de exemplu, pe un blogger.com gazdă de încredere, sunt încurajați să se înregistreze domeniul al patrulea nivel, care conține o adresă URL a unei gazde de încredere, de exemplu blogger.com.attacker.com, și descărca fișiere din acest domeniu.
În acest fel, a fost posibil să proekspluatirovat vulnerabilitate la versiunea 1.32 (revizuirea 142). Dar versiunile mai noi au fost, de asemenea, vulnerabile. Luați în considerare modul în care imaginile sunt de încărcare în versiunea 1,34 (revizie 145):
Este ușor de observat că un număr de greșeli logice au fost făcute în funcțiile de proiectare check_external:
- După efectuarea verificărilor în funcția cea mai parse_str obține date de utilizator nefiltrate. Astfel, puteți suprascrie variabilele care au fost testate: $ url_info $ local_filepath [ 'gazdă'], $ src,. Prin urmare, este posibil să se descarce fișiere de pe orice server.
- După descărcarea fișierului pe server bazat pe getimagesize verifica dacă fișierul de imagine. Dacă testul eșuează, fișierul este șters. Dar, așa cum este posibil să se influențeze $ local_filepath variabilă, este posibil să acceseze un fișier local folosind învelișurile php: // filtru, compress.zlib: //. Și în acest caz, funcția de deconectare nu va fi capabil de a șterge fișierul.
un pic sapat, am scris exploit pentru a descărca fișiere. Cu un nume aleator și un conținut aleatoriu într-o locație arbitrară a sistemului.
ramură 1.x se termină cu revizuirea 149, care are, de asemenea, o vulnerabilitate. Această revizuire a fost eliminat parse_str funcția și, prin urmare, nu există nici o posibilitate de a suprascrie variabile. Dar filtrele care verifica validitatea URL-ul, trebuie doar să verificați intrarea relevantă din subșir string $ src. În acest caz, dacă curl_init caracteristică nu este disponibilă pe serverul destinație, fișierul descărcat utilizând file_get_contents / file_put_contents. Este important de reținut că aceste funcții, spre deosebire de curl_init, suporta toate disponibile în ambalaje PHP.
Astfel, folosind datele de înveliș: //, puteți ocoli toate filtrele și de a crea un fișier în directorul cache-ul cu un conținut arbitrar:
Sau folosind compress.zlib înveliș: // copie în cache-ul este un fișier local:
Profit în acel fișier din cache-ul poate fi accesat direct, rezultând în BRM realizat printr-un cont shell folosind înveliș de date, precum și pentru a primi conținutul fișierelor locale folosind compress.zlib.
în loc de o concluzie
Evident, ambalajele construit în PHP oferă mari oportunități în exploatarea vulnerabilităților tip de manipulare a datelor. Dar este de remarcat faptul că, chiar și cele mai simple controale pe baza funcțiilor file_exists, is_file, Filesize nu va folosi ambalaje. De asemenea, atunci când Suhosin patch-uri instalate în mod implicit nu pot fi utilizate în ambalaje inkluda, chiar dacă allow_url_include directivă este setată la Activat. În acest moment eu nu închide subiectul utilizând ambalaje și următorul articol vă va spune despre posibilitatea de a php înveliș: // filtru pe exemplele de exploatare a vulnerabilitatilor in motoarele de web populare. Stay tuned!
Arată acest articol unui prieten: