Aplicațiile web care facilitează încărcarea fișierelor au devenit esențiale pentru numeroase organizații, acționând ca portaluri pentru clienți, parteneri și angajați pentru a partaja diverse tipuri de documente și fișiere. De exemplu, o firmă de resurse umane ar putea permite utilizatorilor să încarce CV-uri sau o companie ar putea facilita partenerilor partajarea fișierelor prin intermediul unei platforme web specializate.
Chiar și cu măsuri de securitate îmbunătățite și procese de validare mai stricte, atacatorii continuă să exploateze vulnerabilitățile folosind metode sofisticate. Fișierele care par benigne, cum ar fi imaginile, pot fi manipulate pentru a compromite securitatea unui server web.
Fișierele poliglot sunt fișiere care pot fi validate ca mai multe tipuri simultan, permițând atacatorilor să ocolească măsurile de securitate bazate pe tipul de fișier. Exemplele includ GIFAR, care funcționează atât ca GIF, cât și ca fișier RAR, poligloți JavaScript/JPEG care sunt interpretați atât ca JavaScript, cât și ca JPEG și fișiere Phar-JPEG, recunoscute atât ca arhivă Phar, cât și ca imagine JPEG. Aceste fișiere poliglote pot trece neobservate cu extensii înșelătoare sau goale care "păcălesc" sistemele să creadă că sunt un tip de fișier benign (cum ar fi o imagine sau un PDF), conținând în același timp un cod malițios nedetectat.
Validarea încărcării fișierelor
Permiterea încărcării fișierelor de către utilizatori fără o validare adecvată sau completă reprezintă o amenințare semnificativă pentru aplicațiile web. În cazul în care un atacator reușește să încarce un fișier rău intenționat, cum ar fi un web shell, acesta poate obține controlul asupra serverului, compromițând atât sistemul, cât și datele sensibile. Pentru a reduce aceste riscuri, au fost stabilite cele mai bune practici pentru a ghida dezvoltatorii în aplicarea unor măsuri eficiente de validare. Aceste practici contribuie la asigurarea prelucrării sigure a încărcărilor de fișiere, minimizând astfel riscul de exploatare.
Domeniile cheie de interes pentru securizarea încărcărilor de fișiere includ:
- Validarea extensiilor: Implementați o listă de blocuri sau o listă de extensii de fișiere permise pentru a vă asigura că sunt acceptate numai tipurile de fișiere permise.
- Sanitizarea numelui fișierului: Generați șiruri aleatorii pentru numele fișierelor la încărcare.
- Validarea tipului de conținut: Verificați tipul MIME al fișierului încărcat pentru a vă asigura că acesta corespunde formatului așteptat.
- Validarea antetului imaginii: Pentru încărcarea imaginilor, funcții precum getimagesize() în PHP pot fi utilizate pentru a confirma validitatea fișierului prin verificarea antetului acestuia.
Ocolirea filtrului de încărcare a fișierelor
În ciuda punerii în aplicare a acestor măsuri de protecție, atacatorii își perfecționează continuu metodele de a ocoli mecanismele de validare. Tehnici precum injectarea de caractere nule, extensii duble și extensii goale pot submina validarea extensiilor: un fișier poate apărea cu un nume precum "file.php.jpg", "file.php%00.jpg", "file.PhP" sau "file.php/" pentru a evita detectarea . Validarea tipului MIME poate fi eludată prin modificarea octeților magici inițiali ai fișierului, cum ar fi schimbarea lor în GIF89a, antetul asociat fișierelor GIF, care poate păcăli sistemul să identifice fișierul ca fiind un format legitim. În plus, un fișier .htaccess malițios poate fi încărcat pentru a manipula configurațiile serverului, permițând executarea de fișiere cu extensii neautorizate.
Atacuri asupra fișierelor poliglote
Chiar și cu punerea în aplicare a unor procese de validare riguroase care combină mai multe măsuri de securitate pentru a preveni tehnica de ocolire a filtrului de încărcare a fișierelor, atacurile sofisticate care vizează fișiere poliglot sau imagini poliglot rămân o amenințare semnificativă la adresa securității. Această metodă permite atacatorilor să creeze fișiere - cum ar fi imaginile - care respectă structura binară așteptată pentru fișierele imagine, dar care pot executa simultan coduri rău intenționate atunci când sunt interpretate într-un context diferit. Natura dublă a acestor fișiere le permite să ocolească mecanismele tradiționale de validare și să exploateze vulnerabilitățile în scenarii specifice.
Fișier poliglot simplu cu ExifTool
O tehnică simplă pentru generarea unei imagini poliglot este utilizarea ExifTool. Această aplicație puternică este concepută pentru a citi, scrie și modifica diverse formate de metadate, precum EXIF, XMP, JFIF și Photoshop IRB. Cu toate acestea, persoanele rău intenționate pot profita de ExifTool pentru a executa acțiuni dăunătoare, inclusiv crearea unei imagini poliglot cu intenții rău intenționate. Prin utilizarea ExifTool pentru a încorpora cod rău intenționat în metadatele EXIF ale unei imagini - în special în câmpuri precum UserComment și ImageDescription - atacatorii pot genera o imagine poliglot și își pot crește șansele de exploatare cu succes.
În continuare sunt prezentate metadatele EXIF ale imaginii, care oferă informații complete referitoare la aceasta.
Prin utilizarea ExifTool, un actor amenințător poate încorpora cod rău intenționat în metadatele EXIF ale unei imagini, creând astfel un fișier poliglot care poate eluda mecanismele de validare.
Deși validarea tipului MIME poate restricționa încărcarea de fișiere web shell de bază, această imagine poliglot poate ocoli aceste restricții, permițând unui atacator să încarce un web shell poliglot.
Atacatorul poate exploata ulterior shell-ul web poliglot pentru a prelua controlul asupra serverului web.
Fișier poliglot Javascript/JPEG
Un fișier poliglot JavaScript/JPEG este structurat astfel încât să fie valid atât ca imagine JPEG, cât și ca script JavaScript. Pentru a realiza acest lucru, un actor rău intenționat trebuie să aibă o înțelegere cuprinzătoare a structurii interne a unui fișier JPEG. Această cunoaștere permite încorporarea precisă a datelor binare malițioase în cadrul imaginii, asigurându-se că acestea pot fi prelucrate de un motor JavaScript fără a-i afecta validitatea ca imagine JPEG.
O imagine JPEG are următoarea structură:
| Bytes | Nume |
| 0xFF, 0xD8 | Începutul imaginii |
| 0xFF, 0xE0, 0x00, 0x10, ... | Antet implicit |
| 0XFF, 0XFE, ... | Comentariu imagine |
| 0xFF, 0xDB, ... | Tabelul de cuantificare |
| 0xFF, 0xC0, ... | Începutul cadrului |
| 0xFF, 0xC4, ... | Tabelul Huffman |
| 0xFF, 0xDA, ... | Începutul scanării |
| 0xFF, 0xD9 | Sfârșitul imaginii |
Formatul JPEG - sursa: https://github.com/corkami/formats/blob/master/image/JPEGRGB_dissected.png
În structura unei imagini JPEG, antetul este urmat de informații privind lungimea. După cum se arată în exemplul anterior, antetul începe cu secvența 0xFF 0xE0 0x00 0x10, unde 0x00 0x10 reprezintă în mod specific lungimea segmentului, indicând 16 octeți. Marcajul 0xFF 0xD9 marchează sfârșitul imaginii.
Pentru a crea un fișier poliglot JavaScript/JPEG, este necesar să modificați valorile hexazecimale ale imaginii pentru a vă asigura că motorul JavaScript le poate recunoaște și procesa.
În primul rând, în JavaScript, secvența 0xFF 0xD8 0xFF 0xE0 poate fi interpretată ca valori non-ASCII, dar 0x00 0x10 este invalidă și trebuie modificată. Înlocuitorul adecvat pentru aceste valori hexazecimale este 0x2F 0x2A, care este reprezentarea hexazecimală a /*, o sintaxă utilizată pentru a deschide un comentariu în JavaScript. Această înlocuire permite ca datele binare rămase să fie ignorate ca parte a comentariului.
Cu toate acestea, deoarece 0x00 0x10 reprezintă inițial lungimea antetului JPEG, modificarea acestuia în 0x2F 0x2A, care în zecimală este egal cu 12074, necesită redefinirea antetului JPEG pentru a-i menține valabilitatea. Pentru a realiza acest lucru, trebuie adăugați octeți nule, iar sarcina utilă JavaScript trebuie plasată după markerul 0xFF 0xFE, care indică un comentariu de imagine în structura JPEG.
De exemplu, dacă sarcina utilă este */=alert(document.domain);/*, care are o lungime de 28 de octeți, octeții nule necesari vor fi calculați după cum urmează: 12074 (noua lungime) - 16 (lungimea antetului original) - 2 (pentru markerul 0xFF 0xFE ) - 28 (lungimea sarcinii utile) = 12 028 octeți nule.
În consecință, codul JavaScript din cadrul imaginii JPEG va semăna cu următorul:
În cele din urmă, secvența 0x2A 0x2F 0x2F 0x2F (corespunzătoare *///) trebuie plasată chiar înainte de marcajul de sfârșit JPEG 0xFF 0xD9. Acest pas închide comentariul JavaScript și asigură că sarcina utilă este executată corect, fără a perturba structura fișierului JPEG.
După această modificare, imaginea poate fi în continuare interpretată ca o imagine validă, conținând în același timp cod JavaScript executabil.
Atunci când un fișier HTML încarcă această imagine ca un cod sursă JavaScript, acesta rămâne valid și poate executa codul JavaScript încorporat:
Fișierele de imagine poliglotă prezintă riscuri nu numai pentru exploatarea din partea clientului, ci și pentru atacurile din partea serverului în anumite circumstanțe. Un exemplu în acest sens este fișierul poliglot Phar/JPEG, care poate fi interpretat atât ca o arhivă PHP (Phar), cât și ca o imagine JPEG. Structura fișierului Phar permite încorporarea datelor serializate în metadate, ceea ce prezintă un risc potențial pentru vulnerabilitățile de deserializare, în special în anumite versiuni PHP. Ca urmare, fișierele poliglote Phar/JPEG pot fi utilizate pentru a ocoli validarea încărcării fișierelor și pentru a exploata serverele vulnerabile.
Formatul de fișier Phar este structurat ca stub/manifest/contents/signature și stochează informațiile esențiale despre ceea ce este inclus în arhiva Phar în manifestul său:
- Stub: Stub este o bucată de cod PHP care este executată atunci când fișierul este accesat într-un context executabil. Nu există restricții privind conținutul stub-ului, cu excepția cerinței ca acesta să se încheie cu __HALT_COMPILER();.
- Manifest: Această secțiune conține metadate despre arhivă și conținutul acesteia, care pot include metadate Phar serializate stocate în formatul serialize().
- Conținutul fișierelor: Fișierele originale care sunt incluse în arhivă.
- Semnătură (opțional): Conține informații privind semnătura pentru verificarea integrității.
Deoarece stub-ul nu impune nicio restricție de conținut în afara celor stipulate de __HALT_COMPILER(), un actor amenințător poate injecta valorile hexazecimale ale unei imagini în stub. Prin plasarea acestor valori la începutul fișierului PHAR, acesta poate fi identificat ca fiind o imagine validă. În consecință, un poliglot PHAR/JPEG poate fi ușor construit prin adăugarea la început a octeților hexazecimali ai unei imagini JPEG, după cum se demonstrează în exemplul următor:
Prin această metodă, fișierul poliglot generat funcționează atât ca o imagine validă, cât și ca un fișier PHAR legitim și, prin urmare, poate fi utilizat pentru a ocoli anumite mecanisme de validare a încărcării fișierelor.
Deși acest fișier poliglot poate ocoli filtrele de încărcare a fișierelor, el nu este în prezent capabil să exploateze serverul web. Pentru a exploata și compromite cu succes un server web utilizând un fișier PHAR sau un fișier poliglot PHAR, este esențial să se injecteze metadate serializate malițioase în manifestul fișierului.
Atunci când fișierul PHAR este accesat prin intermediul wrapper-ului PHAR (phar://) în anumite funcții PHP (PHP ≤7.x) asociate operațiunilor cu fișiere - precum file(), file_exists(), file_get_contents(), fopen(), rename() sau unlink() - funcția unserialize() este declanșată pentru metadatele serializate. În cele din urmă, prin utilizarea PHPGGC, un instrument utilizat pe scară largă pentru construirea lanțurilor de gadget-uri PHP, actorii amenințători pot exploata vulnerabilitatea de deserializare prin intermediul unui fișier poliglot PHAR, compromițând astfel serverul de aplicații web.
Combinația dintre fișierele poliglote PHAR/JPEG și vulnerabilitățile de deserializare permite atacatorilor să se infiltreze într-un server de aplicații web, chiar și atunci când sunt implementate filtre de încărcare a fișierelor. În special, această compromitere poate avea loc chiar și în timpul prelucrării unui fișier imagine.
Prin utilizarea fișierelor poliglot pentru a ocoli filtrele de încărcare a fișierelor și prin adăugarea wrapper-ului PHAR (phar://) la locația fișierului, atacatorii pot manipula serverul web pentru a trata fișierul ca pe o arhivă PHAR. Această manipulare poate declanșa ulterior o vulnerabilitate de deserializare, ducând la executarea de cod de la distanță prin intermediul funcțiilor de operare a fișierelor.
Pentru a transmite riscurile asociate fișierelor poliglot în aplicația dvs., am simulat un mediu în care aplicația utilizează filtre stricte de încărcare a fișierelor pentru a preveni încărcarea de fișiere rău intenționate sau shell-uri web. În ciuda acestor măsuri de protecție, o imagine poliglot poate ocoli procesul de validare și, în anumite contexte, poate duce la executarea codului de la distanță, compromițând în cele din urmă serverul de aplicații web vulnerabil.
Acest exemplu ilustrează o aplicație web convențională care permite partajarea fișierelor între clienți, parteneri și organizații:
MetaDefender Core și MetaDefender ICAP Server vă protejează aplicațiile web de aceste amenințări și sporesc securitatea rețelei și a infrastructurii dvs.
MetaDefender ICAP Server și MetaDefender Core lucrează împreună pentru a proteja serverul dvs. web împotriva atacurilor sofisticate care implică fișiere poliglot PHAR/JPEG malițioase în următoarele moduri:
Atunci când un fișier poliglot PHAR/JPEG este încărcat în aplicația web, acesta este mai întâi transmis către MetaDefender Core prin MetaDefender ICAP Server pentru un proces complet de igienizare folosind tehnologia noastră Deep CDR ™. Spre deosebire de verificatoarele simple de tip de fișier, Deep CDR analizează în profunzime structura fișierului încărcat, eliminând scripturile, macro-urile și conținutul în afara politicii, reconstruind fișierul JPEG pentru a include numai datele necesare.
Acest proces elimină conținutul PHAR dăunător adăugat după markerul de sfârșit JPEG(0xFF 0xD9), asigurându-se că fișierul igienizat este strict un fișier JPEG. Ca urmare, aplicația web este protejată de atacurile poliglote PHAR/JPEG; chiar dacă un atacator poate modifica schema de procesare a fișierelor pentru a injecta un wrapper PHAR, acesta nu poate exploata serverul web.
Organizațiile care dispun de o infrastructură de securitate a rețelei - fie că utilizează WAF (firewall-uri pentru aplicații web), proxy-uri sau controlori de intrare - își pot îmbunătăți acum mecanismele de apărare prin MetaDefender ICAP Server .Această soluție creează o interfață între serverele web existente și MetaDefender Core , stabilind un punct de control de securitate transparent pentru toate fișierele primite. Orice conținut direcționat prin interfața ICAP va fi scanat și procesat înainte de a ajunge la serverul dvs. web, asigurându-se că numai conținutul sigur și legitim intră în rețeaua dvs. și ajunge la utilizatorii finali.
Această abordare înseamnă că organizațiile își pot valorifica investițiile existente în securitate, adăugând în același timp un nivel suplimentar și puternic de protecție. Organizațiile care utilizează NGINX ingress controller pot integra MetaDefender ICAP Server cu infrastructura lor existentă prin intermediul configurației proxy.
OPSWATmerge dincolo de detectarea tradițională a amenințărilor. În loc să semnalizeze pur și simplu fișierele suspecte, MetaDefender Core neutralizează în mod activ potențialele amenințări, transformând fișierele periculoase în conținut sigur, utilizabil. Atunci când este integrat cu serverul dvs. web, MetaDefender ICAP Server oferă protecție completă împotriva amenințărilor de tip zero-day și a atacurilor poliglot.
Împuternicit de principiul "Trust no file. Trust no device. ™", OPSWAT rezolvă provocările clienților din întreaga lume cu tehnologii patentate la fiecare nivel al infrastructurii, securizând rețelele, datele și dispozitivele și prevenind amenințările cunoscute și necunoscute, atacurile de tip zero-day și programele malware.
