Fuzzing - Fuzzing

Parte dintr-o serie pe
Securitatea informațiilor
Incidente de securitate a informațiilor pe categorii, anul fiscal 2014.svg
Categorii de securitate conexe
Amenințări
Apărări

Fuzzing-ul sau testarea fuzz-ului este o tehnică automată de testare software care implică furnizarea de date invalide, neașteptate sau aleatorii ca intrări într-un program de computer . Programul este apoi monitorizat pentru a găsi excepții, cum ar fi blocări , aserțiuni de cod încorporate nereușite sau eventuale scurgeri de memorie . De obicei, fuzzerele sunt utilizate pentru a testa programe care iau intrări structurate. Această structură este specificată, de exemplu, într-un format de fișier sau protocol și distinge intrarea validă de cea nevalidă. Un fuzzer eficient generează intrări semi-valide care sunt „suficient de valide” în sensul că nu sunt respinse direct de analizor, dar creează comportamente neașteptate mai adânc în program și sunt „suficient de invalide” pentru a expune cazuri de colț care nu au fost tratate corect cu.

În scopul securității, intrarea care trece o graniță de încredere este adesea cea mai utilă. De exemplu, este mai important să codificați codul care gestionează încărcarea unui fișier de către orice utilizator decât să codificați codul care analizează un fișier de configurare care este accesibil numai unui utilizator privilegiat.

Istorie

Termenul „fuzz” provine dintr-un proiect de clasă din toamna anului 1988 în clasa absolventă Advanced Operating Systems (CS736), predat de prof. Barton Miller de la Universitatea din Wisconsin, ale cărui rezultate au fost publicate ulterior în 1990. Pentru a testa fuzz un utilitar UNIX însemna pentru a genera automat parametri de intrare și linie de comandă aleatorii pentru utilitate. Proiectul a fost conceput pentru a testa fiabilitatea programelor de linie de comandă UNIX executând un număr mare de intrări aleatorii în succesiune rapidă până când acestea s-au prăbușit. Echipa lui Miller a reușit să coboare între 25 și 33% din utilitățile testate. Apoi au depanat fiecare dintre blocări pentru a determina cauza și au clasificat fiecare eșec detectat. Pentru a permite altor cercetători să efectueze experimente similare cu alte programe, codul sursă al instrumentelor, procedurile de testare și datele brute ale rezultatelor au fost puse la dispoziția publicului. Acest fuzzing timpuriu s-ar numi acum cutie neagră, fuzzing generațional, nestructurat (prost).

Această lucrare fuzz din 1990 a remarcat, de asemenea, relația fiabilității cu securitatea: „În al doilea rând, una dintre erorile pe care le-am găsit a fost cauzată de aceeași practică de programare care a oferit una dintre găurile de securitate pentru viermele Internet (eroarea„ primește degetul ”). Am găsit erori suplimentare care ar putea indica viitoare găuri de securitate. " (Cu referire la viermele Morris din noiembrie 1988.)

Proiectul original fuzz a continuat să contribuie în 1995, 2000, 2006 și cel mai recent în 2020:

  • 1995: Hârtia „fuzz revisited” constă din patru părți. (1) A reprodus studiul inițial pe linia de comandă, incluzând o varietate mai largă de sisteme UNIX și mai multe utilitare. Studiul a arătat că, în orice caz, fiabilitatea se înrăutățise. Acesta a fost primul studiu care a inclus utilități open source GNU și Linux care, interesant, au fost semnificativ mai fiabile decât cele din sistemele UNIX comerciale. (2) A introdus testarea fuzz a aplicațiilor GUI (bazate pe ferestre) în X-Windows. Acest studiu a utilizat date de intrare atât structurate, cât și structurate (secvențe valide de evenimente de la mouse și tastatură). Au reușit să blocheze 25% din aplicațiile X-Windows. În plus, au testat serverul X-Windows și au arătat că este rezistent la blocări. (3) A introdus testarea fuzz a serviciilor de rețea, din nou pe baza intrărilor de test structurate. Niciunul dintre aceste servicii nu a fost prăbușit. (4) A introdus testarea aleatorie a valorilor de returnare a apelului bibliotecii de sistem, în mod specific returnând zero aleator din familia de funcții malloc. Aproape jumătate din programele standard UNIX nu au reușit să verifice în mod corespunzător aceste valori de returnare.
  • 2000: S-a aplicat testarea fuzz la sistemul de operare Windows NT lansat recent , testând aplicațiile care rulează sub sistemul de ferestre Win32 . Au reușit să blocheze 21% din aplicații și să atârne încă 24% din cele testate. Din nou, aplicațiile au fost testate atât cu intrare nestructurată, cât și structurată (evenimente valide de la tastatură și mouse), blocând aproape jumătate din acele aplicații pe care le-au testat. Ei au identificat cauzele eșecurilor și au constatat că sunt similare cu studiile anterioare.
  • 2006: Aplicarea testării fuzz pe Mac OS X , atât pentru aplicații bazate pe linie de comandă, cât și pentru ferestre. Au testat 135 de programe utilitare de linie de comandă, blocând 7% din cele testate. În plus, au testat 30 de aplicații care rulau sub sistemul de ferestre MacOS Aqua , prăbușind 73% dintre cele testate.
  • 2020: Cel mai recent, au aplicat clasica generație, cutie neagră, testare nestructurată la sistemele UNIX actuale, în special Linux, FreeBSD și MacOS, pentru a vedea dacă tehnicile originale erau încă relevante și dacă programele utilitare actuale erau rezistente la acest tip de testare. Au testat aproximativ 75 de utilități pe fiecare platformă, cu rate de eșec de 12% pe Linux, 16% pe MacOS și 19% pe FreeBSD. (Rețineți că aceste rate de eșec au fost mai slabe decât rezultatele testelor anterioare ale acelorași sisteme.) Când au analizat fiecare eșec și le-au clasificat, au constatat că categoriile clasice de eșecuri, cum ar fi erorile indicatorului și matricei și nu verificarea codurilor de returnare, au fost încă pe larg prezente în noile rezultate. În plus, noile erori cauzate de starea complexă a programului și algoritmi care nu s-au scalat cu dimensiunea sau complexitatea intrării. De asemenea, au testat utilitățile UNIX scrise mai recent în Rust și au descoperit că au o fiabilitate similară cu cele scrise în C, deși (așa cum era de așteptat) au mai puține șanse de a avea erori de memorie.

În aprilie 2012, Google a anunțat ClusterFuzz, o infrastructură de fuzzing bazată pe cloud pentru componentele critice de securitate ale browserului web Chromium . Cercetătorii în materie de securitate își pot încărca propriile fuzzere și pot colecta recompense de erori dacă ClusterFuzz găsește un accident cu fuzzer-ul încărcat.

În septembrie 2014, Shellshock a fost dezvăluit ca o familie de bug-uri de securitate în shell- ul UNIX Bash utilizat pe scară largă ; cele mai multe vulnerabilități ale Shellshock au fost găsite folosind fuzzer-ul AFL . (Multe servicii orientate spre internet, cum ar fi unele implementări de server web, folosesc Bash pentru a procesa anumite solicitări, permițând unui atacator să provoace versiuni vulnerabile ale Bash să execute comenzi arbitrare . Acest lucru poate permite unui atacator să obțină acces neautorizat la un sistem informatic.)

În aprilie 2015, Hanno Böck a arătat cum fuzzer-ul AFL ar fi putut găsi vulnerabilitatea Heartbleed din 2014. ( Vulnerabilitatea Heartbleed a fost dezvăluită în aprilie 2014. Este o vulnerabilitate gravă care permite adversarilor să descifreze comunicarea altfel criptată . Vulnerabilitatea a fost introdusă accidental în OpenSSL care implementează TLS și este utilizată de majoritatea serverelor de pe internet. Shodan a raportat 238.000 mașini încă vulnerabile în aprilie 2016; 200.000 în ianuarie 2017.)

În august 2016, Defense Advanced Research Projects Agency (DARPA) a organizat finala primei Cyber ​​Grand Challenge , o competiție complet automată de capturare a steagului , care a durat 11 ore. Obiectivul a fost dezvoltarea sistemelor automate de apărare care să poată descoperi, exploata și corecta defectele software în timp real . Fuzzing-ul a fost folosit ca o strategie eficientă de infracțiune pentru a descoperi defecte în software-ul adversarilor. A arătat un potențial extraordinar în automatizarea detectării vulnerabilităților. Câștigătorul a fost un sistem numit „Mayhem” dezvoltat de echipa ForAllSecure condusă de David Brumley .

În septembrie 2016, Microsoft a anunțat Project Springfield, un serviciu de testare fuzz bazat pe cloud pentru a găsi erori critice de securitate în software.

În decembrie 2016, Google a anunțat OSS-Fuzz, care permite difuzarea continuă a mai multor proiecte open-source critice de securitate.

La Black Hat 2018, Christopher Domas a demonstrat utilizarea fuzzing-ului pentru a expune existența unui nucleu RISC ascuns într-un procesor. Acest nucleu a reușit să ocolească verificările de securitate existente pentru a executa comenzile Ring 0 din Ring 3.

În septembrie 2020, Microsoft a lansat OneFuzz , o platformă auto-găzduită de fuzzing ca serviciu care automatizează detectarea erorilor software . Suportă Windows și Linux.

Testarea aleatorie timpurie

Programele de testare cu intrări aleatorii datează din anii 1950, când datele erau încă stocate pe carduri perforate . Programatorii ar folosi carduri perforate care au fost scoase din coșul de gunoi sau de pe punțile de cărți ale numerelor aleatorii ca intrare în programele de computer. Dacă o execuție a dezvăluit un comportament nedorit, a fost detectată o eroare .

Executarea intrărilor aleatorii se mai numește testarea aleatorie sau testarea maimuțelor .

În 1981, Duran și Ntafos au investigat oficial eficacitatea testării unui program cu intrări aleatorii. În timp ce testarea aleatorie a fost percepută pe scară largă ca fiind cel mai prost mijloc de testare a unui program, autorii ar putea arăta că este o alternativă rentabilă la tehnici de testare mai sistematice.

În 1983, Steve Capps de la Apple a dezvoltat „The Monkey”, un instrument care ar genera intrări aleatorii pentru aplicațiile clasice Mac OS , cum ar fi MacPaint . „Maimuța” figurativă se referă la teorema maimuței infinite care afirmă că o maimuță care lovește tastele la întâmplare pe o tastatură de mașină de scris pentru o perioadă infinită de timp va tasta în cele din urmă toate lucrările lui Shakespeare. În cazul testării, maimuța ar scrie secvența particulară de intrări care ar declanșa un accident.

În 1991, instrumentul crashme a fost lansat, care a fost destinat pentru a testa robustețea Unix si Unix- ului sistemele de operare prin executarea în mod aleatoriu apeluri sisteme cu parametri aleși în mod aleatoriu.

Tipuri

Un fuzzer poate fi clasificat în mai multe moduri:

  1. Un fuzzer poate fi bazat pe generație sau pe bază de mutație, în funcție de dacă intrările sunt generate de la zero sau modificând intrările existente.
  2. Un fuzzer poate fi prost (nestructurat) sau inteligent (structurat), în funcție de conștientizarea structurii de intrare.
  3. Un fuzzer poate fi alb, gri sau negru, în funcție de conștientizarea structurii programului.

Reutilizarea semințelor de intrare existente

Un fuzzer bazat pe mutație utilizează un corp existent de intrări de semințe în timpul fuzzing-ului. Acesta generează intrări modificând (sau mai degrabă mutând ) semințele furnizate. De exemplu, atunci când fuzzează biblioteca de imagini libpng , utilizatorul ar furniza un set de fișiere de imagini PNG valide ca semințe, în timp ce un fuzzer bazat pe mutație ar modifica aceste semințe pentru a produce variante semi-valide ale fiecărei semințe. Corpusul fișierelor semințe poate conține mii de intrări potențial similare. Selecția automată a semințelor (sau reducerea suitei de testare) permite utilizatorilor să aleagă cele mai bune semințe pentru a maximiza numărul total de erori găsite în timpul unei campanii fuzz.

Un fuzzer bazat pe generație generează intrări de la zero. De exemplu, un fuzzer inteligent bazat pe generație ia modelul de intrare furnizat de utilizator pentru a genera noi intrări. Spre deosebire de fuzzere bazate pe mutații, un fuzzer bazat pe generație nu depinde de existența sau calitatea unui corpus de intrări de semințe.

Unele fuzzere au capacitatea de a face ambele, de a genera intrări de la zero și de a genera intrări prin mutația semințelor existente.

Conștient de structura de intrare

De obicei, fuzzerele sunt folosite pentru a genera intrări pentru programe care acceptă intrări structurate, cum ar fi un fișier , o secvență de evenimente de la tastatură sau mouse sau o secvență de mesaje . Această structură distinge intrările valide care sunt acceptate și procesate de program de intrările nevalide care sunt respinse rapid de program. Ceea ce constituie o intrare validă poate fi specificat în mod explicit într-un model de intrare. Exemple de modele de intrare sunt gramaticile formale , formatele de fișiere , modelele GUI și protocoalele de rețea . Chiar și elementele care nu sunt considerate în mod normal ca intrare pot fi difuzate, cum ar fi conținutul bazelor de date , memoria partajată , variabilele de mediu sau intercalarea precisă a firelor . Un fuzzer eficient generează intrări semi-valide care sunt „suficient de valide”, astfel încât să nu fie respinse direct de la analizor și „suficient de invalide”, astfel încât să poată stresa cazuri de colț și să exercite comportamente interesante ale programului.

Un fuzzer inteligent (bazat pe model, bazat pe gramatică sau bazat pe protocol) utilizează modelul de intrare pentru a genera o proporție mai mare de intrări valide. De exemplu, dacă intrarea poate fi modelată ca un arbore de sintaxă abstract , atunci un fuzzer inteligent bazat pe mutație ar folosi transformări aleatorii pentru a muta subarborii complet de la un nod la altul. Dacă intrarea poate fi modelată printr-o gramatică formală , un fuzzer bazat pe generație inteligentă ar instanția regulile de producție pentru a genera intrări care sunt valabile în ceea ce privește gramatica. Cu toate acestea, în general, trebuie furnizat în mod explicit modelul de intrare, lucru dificil de realizat atunci când modelul este proprietar, necunoscut sau foarte complex. Dacă este disponibil un corpus mare de intrări valide și nevalide, o tehnică de inducție gramaticală , cum ar fi algoritmul L * al lui Angluin , ar putea genera un model de intrare.

Un fuzzer prost nu necesită modelul de intrare și poate fi astfel utilizat pentru a estompa o varietate mai largă de programe. De exemplu, AFL este un fuzzer mut, bazat pe mutații, care modifică un fișier seed prin răsucirea biților aleatori , prin înlocuirea octeților aleatori cu valori „interesante” și prin mutarea sau ștergerea blocurilor de date. Cu toate acestea, un fuzzer prost poate genera o proporție mai mică de intrări valide și poate accentua codul parserului, mai degrabă decât componentele principale ale unui program. Dezavantajul fuzzerelor stupide poate fi ilustrat prin construirea unei sume de control valide pentru o verificare a redundanței ciclice (CRC). Un CRC este un cod de detectare a erorilor care asigură păstrarea integrității datelor conținute în fișierul de intrare în timpul transmiterii . O sumă de control este calculată peste datele de intrare și înregistrată în fișier. Când programul procesează fișierul primit și suma de control înregistrată nu se potrivește cu suma de control recalculată, atunci fișierul este respins ca nevalid. Acum, un fuzzer care nu știe CRC este puțin probabil să genereze suma de control corectă. Cu toate acestea, există încercări de a identifica și re-calcula o sumă de control potențială în intrarea mutată, odată ce un fuzzer bazat pe mutație mut a modificat datele protejate.

Conștient de structura programului

De obicei, un fuzzer este considerat mai eficient dacă atinge un grad mai mare de acoperire a codului . Rațiunea este că, dacă un fuzzer nu exercită anumite elemente structurale în program, atunci nici nu poate dezvălui erori care se ascund în aceste elemente. Unele elemente ale programului sunt considerate mai critice decât altele. De exemplu, un operator de diviziune poate provoca o divizare prin eroare zero sau un apel de sistem poate bloca programul.

Un fuzzer cu cutie neagră tratează programul ca pe o cutie neagră și nu este conștient de structura internă a programului. De exemplu, un instrument de testare aleatorie care generează intrări la întâmplare este considerat un fuzzer de cutie neagră. Prin urmare, un fuzzer de cutie neagră poate executa câteva sute de intrări pe secundă, poate fi ușor paralelizat și poate scala la programe de dimensiuni arbitrare. Cu toate acestea, fuzzer-urile din caseta neagră pot zgâria doar suprafața și pot expune erori „superficiale”. Prin urmare, există încercări de a dezvolta fuzzere de cutie neagră care pot învăța în mod incremental despre structura internă (și comportamentul) unui program în timpul fuzzingului, observând ieșirea programului având o intrare. De exemplu, LearnLib folosește învățarea activă pentru a genera un automat care reprezintă comportamentul unei aplicații web.

Un fuzzer cu cutie albă utilizează analiza programului pentru a crește în mod sistematic acoperirea codului sau pentru a ajunge la anumite locații critice ale programului. De exemplu, SAGE utilizează execuția simbolică pentru a explora sistematic diferite căi din program. Dacă specificația programului este disponibilă, un fuzzer cu cutie albă poate utiliza tehnici din testarea bazată pe model pentru a genera intrări și a verifica ieșirile programului în raport cu specificațiile programului. Un fuzzer de cutie albă poate fi foarte eficient la expunerea erorilor care se ascund adânc în program. Cu toate acestea, timpul folosit pentru analiză (al programului sau al specificațiilor acestuia) poate deveni prohibitiv. Dacă fuzzerul pentru casetă albă durează relativ mult timp pentru a genera o intrare, un fuzzer pentru casetă neagră va fi mai eficient. Prin urmare, există încercări de a combina eficiența fuzzerelor blackbox și eficiența fuzzerelor whitebox.

Un fuzzer cu cutie gri utilizează instrumentele mai degrabă decât analiza programului pentru a culege informații despre program. De exemplu, AFL și libFuzzer utilizează instrumente ușoare pentru a urmări tranzițiile de bază de bloc exercitate de o intrare. Acest lucru duce la o cheltuieli de performanță rezonabile, dar informează fuzzer-ul despre creșterea acoperirii codului în timpul fuzzing-ului, ceea ce face ca fuzzer-urile cu cutie gri să fie instrumente de detectare a vulnerabilităților extrem de eficiente.

Utilizări

Fuzzing-ul este utilizat mai ales ca o tehnică automată pentru a expune vulnerabilitățile în programele critice de securitate care ar putea fi exploatate cu intenție rău intenționată. Mai general, fuzzing-ul este folosit pentru a demonstra prezența bug-urilor, mai degrabă decât absența lor. Desfășurarea unei campanii de difuzare timp de câteva săptămâni fără a găsi o eroare nu demonstrează că programul este corect. La urma urmei, programul poate eșua în continuare pentru o intrare care nu a fost încă executată; executarea unui program pentru toate intrările este prohibitiv de costisitoare. Dacă obiectivul este de a dovedi un program corect pentru toate intrările, trebuie să existe o specificație formală și trebuie utilizate tehnici din metode formale .

Expunerea erorilor

Pentru a expune bug-uri, un fuzzer trebuie să fie capabil să distingă comportamentul programului așteptat (normal) de neașteptat (buggy). Cu toate acestea, o mașină nu poate distinge întotdeauna o eroare de o caracteristică. În testarea automată a software-ului , aceasta se mai numește și problema oracle de testare .

De obicei, un fuzzer face distincție între intrările care se prăbușesc și cele care nu se prăbușesc în absența specificațiilor și pentru a utiliza o măsură simplă și obiectivă. Blocările pot fi ușor identificate și ar putea indica vulnerabilități potențiale (de exemplu, refuzul de serviciu sau executarea arbitrară a codului ). Cu toate acestea, absența unui accident nu indică absența unei vulnerabilități. De exemplu, un program scris în C poate sau nu să se blocheze atunci când o intrare provoacă o depășire a bufferului . Mai degrabă comportamentul programului este nedefinit .

Pentru a face un fuzzer mai sensibil la alte defecțiuni decât la blocări, pot fi folosite produse de dezinfectare pentru a injecta afirmații care blochează programul atunci când este detectată o defecțiune. Există diferite produse de dezinfectare pentru diferite tipuri de bug-uri:

Fuzzing-ul poate fi folosit și pentru a detecta erori „diferențiale” dacă este disponibilă o implementare de referință . Pentru testarea automată de regresie , intrările generate sunt executate pe două versiuni ale aceluiași program. Pentru testarea diferențială automată , intrările generate sunt executate pe două implementări ale aceluiași program (de exemplu, lighttpd și httpd sunt ambele implementări ale unui server web). Dacă cele două variante produc ieșiri diferite pentru aceeași intrare, atunci una poate fi buggy și ar trebui examinată mai atent.

Validarea rapoartelor de analiză statică

Analiza statică a programului analizează un program fără a-l executa efectiv. Acest lucru ar putea duce la falsuri pozitive în cazul în care instrumentul raportează probleme cu programul care nu există de fapt. Fuzzingul în combinație cu analiza dinamică a programului poate fi folosit pentru a încerca să genereze o intrare care să asiste la problema raportată.

Securitatea browserului

Browserele web moderne sunt supuse unei fuzzing extinse. Chromium Codul de Google Chrome este fuzzed continuu de echipa Chrome de securitate cu 15.000 de nuclee. Pentru Microsoft Edge și Internet Explorer , Microsoft a efectuat teste fuzzed cu 670 de ani-mașină în timpul dezvoltării produsului, generând peste 400 de miliarde de manipulări DOM din 1 miliard de fișiere HTML.

Toolchain

Un fuzzer produce un număr mare de intrări într-un timp relativ scurt. De exemplu, în 2016, proiectul Google OSS-fuzz a produs aproximativ 4 trilioane de intrări pe săptămână. Prin urmare, multe fuzzere oferă un lanț de instrumente care automatizează sarcinile manuale și plictisitoare care urmează generației automate de intrări care induc eșecuri.

Triaj automat de erori

Articol principal: Triajul erorilor

Triajul automat de erori este utilizat pentru a grupa un număr mare de intrări care provoacă eșecuri în funcție de cauza principală și pentru a prioritiza fiecare eroare individuală în funcție de severitate. Un fuzzer produce un număr mare de intrări, iar multe dintre cele care provoacă eșecuri pot expune în mod eficient aceeași eroare software . Doar unele dintre aceste erori sunt critice în materie de securitate și ar trebui corecționate cu prioritate mai mare. De exemplu, Centrul de coordonare CERT oferă instrumentele de triaj Linux care grupează intrările care se blochează prin urmărirea stivei produse și listează fiecare grup în funcție de probabilitatea lor de a fi exploatabile . Centrul de cercetare a securității Microsoft (MSEC) a dezvoltat instrumentul! Exploatabil care creează mai întâi un hash pentru o intrare care se blochează pentru a determina unicitatea acestuia și apoi atribuie o evaluare de exploatabilitate:

  • Exploatabil
  • Probabil exploatabil
  • Probabil că nu este exploatabil sau
  • Necunoscut.

Bug-urile triată anterior neraportate ar putea fi raportate automat unui sistem de urmărire a bug-urilor . De exemplu, OSS-Fuzz desfășoară campanii de difuzare pe scară largă și de lungă durată pentru mai multe proiecte software de securitate critice în care fiecare eroare distinctă neraportată anterior este raportată direct unui tracker de erori. Sistemul de urmărire a erorilor OSS-Fuzz îl informează automat pe administratorul software-ului vulnerabil și verifică la intervale regulate dacă eroarea a fost remediată în cea mai recentă revizuire utilizând intrarea minimizată încărcată care induce eșecul.

Minimizare automată a intrărilor

Minimizarea automată a intrărilor (sau reducerea cazurilor de testare) este o tehnică de depanare automată pentru a izola acea parte a intrării care induce eșecul care de fapt provoacă eșecul. Dacă intrarea care provoacă eșecuri este mare și este în mare parte malformată, ar putea fi dificil pentru un dezvoltator să înțeleagă exact ce cauzează eroarea. Având în vedere intrarea care provoacă eșecuri, un instrument automat de minimizare ar elimina cât mai mulți octeți de intrare posibil în timp ce ar reproduce încă eroarea originală. De exemplu, Delta Debugging este o tehnică automată de minimizare a intrărilor care folosește un algoritm de căutare binar extins pentru a găsi o intrare atât de mică.

Vezi si

Referințe

Lecturi suplimentare

linkuri externe