TESTAREA SECURITII -19 Atacuri asupra programelor

1.INTRODUCERE
Vom prezenta n acest Capitol tehnicile de testare ale furnizorului de securitate software
Security Innovation []. Este vorba de 19 atacuri posibile (Tabelul ), care sunt practice,
eficiente, i se bazeaz pe ani de studiu i cercetare n domeniul defectelor de securitate
software. Ele sunt utile oricrui tip de aplicaie, oricrei platforme i oricrui limbaj de
dezvoltare i sunt deja folosite de mii de testeri i dezvoltatori din ntreaga lume.
Tipul de atac
I. Atacarea dependenelor programului

II. Spargerea securitii prin interfaa

utilizator

III. Atacarea Design-ului

Atacuri posibile
Atac1:
Blocarea accesului la biblioteci
Atac 2: Manipularea valorilor din registrul
aplicaiei.
Atac 3: Forarea aplicaiei s foloseasc
fiiere corupte
Atac 4: Manipularea i nlocuirea fiierelor pe
care aplicaia le creeaz, citete, scrie i
execut
Atac 5: Forarea aplicaiei s opereze n
condiii de prea puin memorie, prea puin
spaiu pe disc i disponibilitate prea redus a
reelei
Atac 6: Suprancrcarea bufferelor de intrare
Atac 7: Examinarea tuturor opiunilor i
variantelor comune
Atac 8: Explorarea caracterelor de escape
(ieire), a mulimilor de caractere, i a
comenzilor
Atac 9: Verificarea valorilor implicite i
testarea numelor de conturi i a parolelor
Atac 10: Folosirea programului Holodeck1
pentru a expune API-urile neprotejate
Atac 11: Conectarea la toate porturile
Atac 12: Falsificarea sursei de date
Atac 13: Crearea de cicluri care s
interpreteze scriptul, codul, sau alt logic
furnizat de utilizator
Atac 14: Folosirea de ci alternative pentru o
sarcin
Atac 15: Forarea sistemului s reseteze valori
1. https://www.securityinnovation.com/securitylab/holodeck/

IV. Atacarea Implementrii

Atac 16: Intervenia ntre momentul

verificrii i momentul utilizrii
Atac 17: Crearea de fiiere cu acelai nume ca
fiierele protejate de rang mai nalt
Atac 18: Forarea tuturor mesajelor de eroare
Atac 19: Folosirea Holodeck pentru a cuta

fiiere temporare i cutarea de informaii

sensibile n coninutul lor
Tabel .O vedere de ansamblu asupra atacurilor

2. ATACAREA DEPENDENELOR PROGRAMULUI (atacurile 1 - 5)

Aplicaiile sunt strns dependente de mediul lor pentru a funciona corect. Ele depind de
sistemul de operare s le furnizeze resurse de genul spaiu pe disc i n memorie, depind de
sistemul de fiiere pentru a citi i a scrie date, folosesc structuri ca regitrii pentru a stoca i
regsi informaiile i lista poate continua. Toate aceste resurse furnizeaz intrri programului
(nu n modul direct n care o face un utilizator uman, dar sunt, totui, intrri). Ca orice intrare,
dac programul primete o valoare n afara limitelor ateptate, poate eua. Inducerea de
scenarii de eec ne permite s observm o aplicaie ntr-un mediu pentru care nu a fost
adaptat i n care i expune vulnerabilitile.
Atacul 1: Blocarea accesului la biblioteci
Programele depind de biblioteci ale sistemului de operare, ale unor furnizori teri, i ale
componentelor integrate n aplicaie. Tipurile de biblioteci ce trebuie urmrite depind de
aplicaie. Uneori DLL-urile au nume obscure din care este greu de neles la ce folosesc. Alte
nume pot fi ns un indiciu asupra serviciilor pe care le fac n cadrul aplicaiei. Acest atac e
construit pentru a ne asigura c aplicaia testat nu se comport nesigur atunci cnd
bibliotecile nu se ncarc. Cnd apar cderi ale mediului, se execut acele pri din aplicaie
care trateaz erorile. Totui, uneori, aceste situaii nu sunt luate n considerare n timpul
design-ului aplicaiei, rezultatul fiind o excepie netratat. Chiar dac exist cod pentru a trata
aceste tipuri de erori, acest cod este un teren propice pentru tot felul de probleme, deoarece
este probabil c nu a fost testat la fel de bine ca restul aplicaiei.
Atacul 2: Manipularea valorilor din registrul aplicaiei
Registrul Windows conine informaii cruciale pentru operarea normal a sistemului de
operare i a aplicatiilor instalate. Pentru SO, registrul ine evidena informaiilor de genul
locaia fiierelor cheie, structura de directoare, cile de execuie, i versiunile bibliotecilor.
Aplicaiile se bazeaz pe aceste informaii (i altele stocate n registru) pentru a funciona
corect. Totui, nu toat informaia din registru este securizat fa de utilizatori sau alte
aplicaii instalate. Acest atac testeaz dac aplicaiile stocheaz informaii sensibile n registru
sau dac presupun c registrul se comport ntotdeauna ntr-un mod predictibil.
Atacul 3: Forarea aplicaiei s foloseasc fiiere corupte
Programele pot face foarte multe lucruri nainte de a avea nevoie s stocheze i s citeasc
datele persistente. Datele sunt combustibilul care conduce o aplicaie, astfel c mai devreme
sau mai trziu toate aplicaiile trebuie s interacioneze cu sistemul de fiiere. Fiierele sau
numele de fiiere corupte sunt ca i cum ai pune zahar n rezervorul de benzin al mainii:
dac nu i dai seama nainte de a porni maina, distrugerile sunt de neevitat. Acest atac
determin dac aplicaiile pot trata cu succes datele greite, fr a expune informaiile
sensibile i fr s permit un comportament nesigur. O aplicaie mare poate citi i scrie din/
n sute de fiiere n timp ce-i efectueaz sarcinile. Fiecare fiier pe care o aplicaie l citete
furnizeaz intrri, i poate deveni un punct de cdere, deci un punct de start al unui atac.
Fiierele cel mai interesant de verificat sunt cele folosite exclusiv de aplicaie, i care nu sunt

destinate citirii/ modificrii de ctre utilizator; n aceste fiiere este cel mai probabil c
verificrile de integritate a datelor nu au fost implementate complet i corect.
Atacul 4: Manipularea i nlocuirea fiierelor create, citite, scrise sau executate de
aplicaie
Similar Atacului 3, acest atac implic dependenele de fiiere-sistem. n atacurile precedente,
s-a ncercat s se determine aplicaia s proceseze date corupte. n Atacul 4 se manevreaz
date, executabile, sau biblioteci n moduri ce foreaz aplicaia s se comporte nesigur. Acest
atac se poate aplica de fiecare dat cnd o aplicaie citete/ scrie n sistemul de fiiere,
lanseaz alt executabil sau acceseaz funcionaliti dintr-o bibliotec. Scopul su este de a
testa dac aplicaia ne permite s facem lucruri pe care ar trebui s nu le putem face.
Atacul 5: Forarea aplicaiei s opereze cu memorie puin, spaiu redus pe disc i acces
redus la retea
O aplicaie este o mulime de instruciuni pe care hardware-ul calculatorului trebuie s le
execute. Iniial, calculatorul ncarc aplicaia n memorie i apoi i furnizeaz aplicaiei
memorie suplimentar n care s i stocheze i manevreze datele interne. Memoria este totui
temporar; pentru a fi cu adevrat util, aplicaia trebuie s poat stoca i date permanente.
Aici intervine sistemul de fiiere, i mpreun cu el, i necesitatea de spaiu pe disc. Fr
suficient memorie pe disc, majoritatea aplicaiilor nu i vor putea ndeplini funciile.
Obiectivul acestui atac este s priveze aplicaia de toate aceste resurse astfel nct testerii pot
nelege ct de robust i sigur este aplicaia lor sub stres. Decizia alegerii scenariilor de
cdere se determin de la caz la caz. n general, se ncearc blocarea unei resurse la momentul
n care aplicaia pare s aib cel mai mult nevoie de ea. .
3. ATACAREA INTERFEEI UTILIZATOR (atacurile 6-8)
n cadrul interfeei utilizator este de obicei cel mai uor de cutat defecte pentru testarea
securitii. Interfaa este modul n care dezvoltatorii se ateapt c vom utiliza programul.
Atacurile descrise n continuare se refer la intrri transmise programului prin intermediul
interfeei. Cele mai multe probleme de securitate rezult din comportamente suplimentare,
neintenionate i nedocumentate ale utilizatorilor. Din IU, aceasta presupune tratarea de intrri
neateptate de la utilizator, ntr-un mod ce compromite aplicaia, sistemul pe care aceasta
ruleaz sau datele sale. Rezultatul poate fi nclcarea drepturilor (un utilizator obinuit
dobndete drepturi de administrare) sau expunerea de informaii secrete ctre un utilizator
neautorizat.
Atacul 6: Suprancrcarea buferelor de intrare
Suprancrcarea bufferelor este cea mai cunoscut problem de securitate a programelor, ce
apare atunci cnd o aplicaie nu reuete s constrng dimensiunea intrrilor. Unele
suprancrcri nu reprezint un pericol real pentru securitate, dar altele permit hackerilor s
preia controlul unui sistem prin trimiterea unui ir bine meteugit (exploatabil) ctre aplicaie
(pri din ir ajung s se execute fiind interpretate drept cod). Ceea ce se ntmpl uneori este
c se aloc o dimensiune fixat de memorie pentru intrrile utilizatorului. Dac dezvoltatorii
nu constrng lungimea stringurilor de intrare introduse de utilizatori, datele pot suprascrie
instruciuni ale aplicaiei, permind utilizatorului s execute cod arbitrar i s ctige
controlul asupra mainii.
Atacul 7: Examinarea tuturor opiunilor i variantelor comune

Unele aplicaii sunt tolerante cu varierea intrrilor utilizatorilor sub o configuraie implicit.
Majoritatea configuraiilor implicite sunt alese de ctre dezvoltatorii aplicaiei, i majoritatea
testelor se execut n aceste condiii (mai ales dac opiunile sunt obscure sau sunt introduse
folosind switch-uri din linia de comand). Cnd aceste configuraii se modific, programul
este adesea nevoit s utilizeze ci sub-testate prin cod, i deci cu rezultate imprevizibile.
Desigur, este imposibil de testat pentru aplicaiile mari un spectru larg de intrri sub fiecare
mulime posibil de configuraii; acest atac se concentreaz pe unele din cele mai obscure
configuraii n care opiunile sunt setate n linia de comand sau la pornire.
Atacul 8: Explorarea caracterelor de escape (ieire), a mulimilor de caractere, i a
comenzilor
Unele aplicaii trateaz anumite caractere ca echivalente atunci cnd fac parte dintr-un ir.
Pentru majoritatea scopurilor, un ir cu litera a ntr-o anumit poziie e probabil c va fi
procesat la fel cu un ir cu litera z n aceeai poziie. De aici, urmeaz firesc ntrebarea Ce
caractere sau combinaii de caractere sunt tratate diferit?, care ghideaz acest tip de atac.
Fornd aplicaia s proceseze caractere i comenzi speciale, putem uneori s o form s se
comporte n moduri pe care designerii si care nu le-au prevzut. Factorii care afecteaz ce
caractere i comenzi pot fi interpretate diferit includ limbajul aplicaiei, bibliotecile prin care
trec datele utilizatorilor, i cuvintele i irurile rezervate ale sistemului de operare.
4. ATACAREA DESIGN-ULUI (atacurile 9-15)
Este foarte dificil s parcurgi 300 de pagini de documentaie a design-ului i s determini dac
produsul final va fi sigur, aadar, o parte din vulnerabilitile de securitate se strecoar n
aceast etap a dezvoltrii. Problema este c decizii de design subtile pot duce la interaciuni
ntre componente i defecte inerente care produc vulnerabiliti produsului final. Atacurile 915 ajut la expunerea acestor insecuriti de design din software: presupuneri implicite
nesigure, testarea conturilor, testarea instrumentaiei, a porturilor deschise, i a constrngerilor
nesatisfctoare asupra logicii de program furnizate de utilizator.
Atacul 9: Verificarea valorilor implicite i a numelor de conturi i de parole
n aplicaiile cu restricii asupra datelor i a funcionalitilor utilizatorii sunt tratai diferit.
Aciunile utilizatorului sunt controlate de nivelul asociat de acces. De cele mai multe ori,
utilizatorii sunt identificai i autentificai pe baza unor nume de utilizatori i parole. Totui,
multe aplicaii au incorporate nite conturi de utilizatori speciale (contul Administrator,
root etc.) Aceste conturi bine documentate nu prezint, de obicei, probleme, i utilizatorii
sunt invitai s le modifice/ iniializeze parola la instalare. Problema apare odat cu existena
unor conturi invizibile, nedocumentate sau neconfigurabile. Pentru acestea trebuie neles bine
pe ce baz se acord ncredere unui utilizator, cum este acesta verificat i dac sunt stocate n
cache sau nu. Atacul are destinaia de a depista conturile ascunse nainte de livrarea
aplicaiei.
Atacul 10: Folosirea programului Holodeck pentru a expune API-urile neprotejate
Aplicaiile complexe, pe scar larg, sunt dificil de testat eficient bazndu-ne doar pe APIurile destinate utilizatorilor normali. Uneori se fac mai multe asamblri ale programului n
aceeai sptmn, i fiecare dintre acestea parcurge o suit de teste de verificare. Din aceast
cauz, muli dezvoltatori folosesc nite ancore folosite de testare. Aceste ancore i APIurile de testare corespunztoare ocolesc adesea verificrile obinuite de securitate (pentru a
face aplicaia eficient i uor de folosit). Dezvoltatorii le adaug pentru a uura munca

testerilor, i apoi le elimin la livrarea programului. Problema este c aceste API-uri de testare
sunt integrate programului i testrii att de bine nct la livrare muli manageri nu le mai
elimin de teama de a nu destabiliza codul i a nu ntrzia livrarea. Este aadar important ca
aceste pri de program s fie gsite i s se verifice c ele nu pot fi folosite de hackeri pentru
a compromite aplicaia, sistemul su gazd sau datele utilizatorului. Prin urmrirea aplicaiei
cu Holodeck n timpul rulrii suitelor de test automate, se pot identifica DLL-urile ncrcate i
folosite, i se poate evalua impactul lor asupra securitii. Atacul ncearc s expun API-urile
de test.
Atacul 11: Conectarea la toate porturile
Un port este o metod de a organiza traficul din reea trimis sau recepionat ntr-o/dintr-o
main anume, astfel ca tipuri diferite de date s poat fi transmise simultan. Cnd un port
este deschis, sistemul de operare ascult datele ce trec prin interfaa respectiv. Aplicaiile
deschid n mod obinuit porturi pentru a transmite datele prin reea. Totui, un port deschis nu
este n mod automat o variant sigur de comunicare. Dac dezvoltatorii nu iau msuri
adecvate, un port deschis poate fi folosit de un hacker care ncearc s obin accesul
neautorizat la sistem. Acest atac descoper aceste pori deschise.
Atacul 12: Falsificarea sursei de date
Unele date nu sunt deloc verificate, pe baza ncrederii n sursa care le-a produs/ furnizat; spre
exemplu, aplicaiile tind s accepte valori din surse ca SO cu o minim examinare. Unele
surse trebuie crezute pentru buna funcionare a aplicaiei (cum ar fi comenzile de
configurare de la un administrator autentificat). Problema apare atunci cnd ncrederea pe care
o aplicaie o are ntr-o surs nu este dublat de verificarea c datele provin cu adevrat de la
sursa respectiv. Acest atac se concentreaz pe asigurarea c aplicaia este precaut i verific
sursa datelor, atribuind acestei surse un nivel de ncredere corespunztor.
Atacul 13: Crearea de bucle n orice aplicaie care interpreteaz script, cod, sau alt
logic furnizat de utilizator
Unele comenzi, executate izolat sunt inofensive (de exemplu, deschiderea unui browser Web
i navigarea ctre un Website care lanseaz o alt fereastr). Aceast aciune n sine nu
reprezint o ameninare pentru utilizator (dei poate deveni enervant). S ne imaginm acum
o fereastr lansnd o alt fereastr care lanseaz o alt fereastr i aa mai departe: dac
browser-ul nu face nite verificri de raionalitate, sistemul se blocheaz. Atacul 13
investigheaz aciunile repetate: preluarea de comenzi relativ benigne i executarea lor
repetat pentru a limita sau bloca funcionalitatea destinat utilizatorilor sau proceselor n
drept.
Atacul 14: Folosirea de ci alternative pentru a ndeplini o sarcin
Iat mai multe ci alternative de deschidere a unui fiier Microsoft Word n Windows:
Scrierea cii n caseta de dialog Run
Dublu-clic pe iconul fiierului ntr-o fereastr Explorer
Tastarea cii i numelui fiierului ntr-o fereastr Explorer
Tastarea cii i numelui fiierului ntr-o fereastr Internet Explorer
Selectarea sa din My Recent Documents din meniul de Start
Tastarea numelui fiierului n caseta de dialog Open din interiorul Word
Etc.
Exist multe modaliti de a realiza acest lucru, dar ne ateptm ca pe oricare am alege-o s
obinem acelai rezultat: documentul nostru s fie afiat i gata pentru editare. Dac dorim s

implementm un control de securitate asupra documentului, trebuie s anticipm fiecare

scenariu posibil i s ne asigurm c trece rutina de validare; -ceea ce uneori este descurajant
chiar pentrru dezvoltatorii cu experien. Multe cazuri sunt pur i simplu omise, rezultatul
fiind o rut care se sustrage controalelor de securitate. Atacul presupune regndirea aplicaiei
i explorarea tuturor modalitilor de executare a unei sarcini (nu doar scenariile tipice ale
utilizatorilor).
Atacul 15: Forarea sistemului s reseteze valori
n acest atac nu trebuie practic s faci nimic: cmpurile sunt lsate goale, se alege Finish n
loc de Next sau pur i simplu se terg valori. Aceste aciuni oblig aplicaia s furnizeze o
valoare acolo unde utilizatorul nu a fcut-o. Stabilirea de valori implicite este o sarcin de
programare complex. Dezvoltatorii trebuie s se asigure c variabilele sunt iniializate
nainte de intrarea ntr-un ciclu sau nainte de apelul unei funcii, altfel se poate folosi o
valoare intern, cu efecte deseori catastrofice. O bun practic n programare este ca fiecare
variabil s primeasc o valoare legitim imediat dup declarare, pentru a evita acest tip de
cderi. Pentru securitate, cea mai mare preocupare este ca valorile i configuraiile implicite
s nu lase programul ntr-o stare instabil. Acest atac foreaz aplicaia s foloseasc valorile
implicite, pentru a observa eventualele vulnerabiliti ale acestei situaii.
5. ATACAREA IMPLEMENTRII (atacurile 16 -19)
Un design perfect poate deveni imperfect din cauza implementrii sale. Spre exemplu, schema
de autentificare Kerberos este recunoscut pentru sigurana sa, i totui implementarea sa de
ctre MIT a avut multe vulnerabiliti majore n implementare, - cel mai notabil, depirea
bufferelor. Un design sigur poate construi un produs nesigur atunci cnd problemele de
securitate nu sunt bine explicate de-a lungul ierarhiei: dezvoltatorii primesc de obicei o list
de cerine ce pun accentul pe interfeele pe care componenta lor trebuie s le extind ctre
restul aplicaiei, pe formatul datelor primite de component i pe calculele asupra acestor date.
Totui, adesea nu se specific n cerine modul n care trebuie efectuate calculele pentru a
pstra securitatea datelor.
Atacul 16: Interpunerea ntre momentul verificrii i momentul folosirii
Datele sunt supuse riscului de cte ori un atacator poate separa funciile ce verific securitatea
din jurul unei caracteristici sau date de funciile care acceseaz i folosesc efectiv aceste
caracteristici sau date. Situaia ideal ar fi s ne asigurm c de cte ori se execut operaii
sensibile, se fac verificri c ele se vor desfura n siguran. Dac trece prea mult timp de la
verificare pn la folosire, exist posibilitatea infiltrrii unui atacator n tranzacie: acesta
momete aplicaia cu informaii legitime, pe care le schimb ns nainte ca aplicaia s i
dea seama. Atacul de fa este construit astfel nct s exploateze aceast ntrziere i s
ptrund n proces ntre aceste dou funcii, cu scopul de a fora aplicaia s execute o aciune
neautorizat.
Atacul 17: Crearea de fiiere cu acelai nume ca fisierele protejate de rang mai nalt
Anumite fiiere se bucur de privilegii speciale datorit localizrii lor. Spre exemplu,
bibliotecile de legturi dinamice (dynamic link libraries- dll) sunt folosite pentru sarcini
specifice i sunt ncrcate de aplicaie fie la pornire, fie la momentul n care devin necesare. n
funcie de localizarea lor n structura de directoare, e posibil ca un utilizator cu privilegii
restricionate s nu le poat modifica, i s nu poat scrie n directorul lor. Atacatorii pot
profita de faptul c aceste biblioteci sunt ncrcate de obicei dup nume, fr alte verificri de

asigurare c sunt ntr-adevr fiierele dorite. Aceasta se poate face prin crearea unui fiier cu
acelai nume i plasarea sa ntr-un director n care utilizatorul are acces i n care aplicaia
caut mai nti. O problem de acelai tip este cea n care unele fiiere capt privilegii
speciale numai pe baza numelui lor. Acesta e un fenomen comun, mai ales cu programele
antivirus care opereaz folosind o plas complex de reguli de filtrare bazate pe nume de
fiiere i extensiile lor. Atacul este aplicabil de cte ori o aplicaie ia decizii de execuie sau de
privilegii pe baza numelui unui fiier.
Atacul 18: Forarea tuturor mesajelor de eroare
Mesajele de eroare sunt folosite pentru a furniza informaii utilizatorului, scopul lor fiind de a
alerta un utilizator asupra unei aciuni incorecte sau nepermise care s-ar fi ncercat. Scopul
acestui atac este s form domeniul mesajelor de eroare ce pot fi afiate de o aplicaie. Spre
exemplu, putem s cutm toate valorile ilegale posibile ce pot fi introduse ntr-un cmp. Prin
ncercarea de a declana mesaje de eroare, practic se acoper domeniul de intrri greite ctre
aplicaie i se testeaz robusteea acesteia la datele respective (s zicem, introducei un numr
negativ n cmpul numrul frailor dintr-un formular Web). Scopul acestui atac este gsirea
situaiilor tratate inadecvat- adic, n locul unui mesaj de eroare, aplicaia ncearc s
proceseze date greite.
Atacul 19: Folosirea Holodeck pentru cutarea de fiiere temporare i de informaii
sensibile n coninutul acestora
Aplicaiile scriu deseori date n sistemul de fiiere, care poate stoca att date permanente ct i
temporare. Fiierele temporare pot fi create pentru a transfera date ntre componente sau
pentru a pstra date prea mari/ prea ineficiente pentru pstrarea n memorie. Dac aceste date
(chei de CD-uri, chei de criptare, parole sau alte date personale) sunt sensibile, atunci
mecanismul de a le stoca i punctele de acces la ele trebuie verificate. Testerii de securitate
trebuie s fie contieni de momentul, locul i modalitatea n care o aplicaie acceseaz datele
din fiierele sistemului. Pentru eficien, trebuie identificate ce date nu ar trebui expuse altor
utilizatori poteniali ai sistemului. Dup identificarea datelor sensibile, atacul trebuie s
gseasc modaliti creative de a ctiga acces nepermis la ele. Programul triete ntr-o
reea cu mai muli utilizatori, i faptul c a creat un fiier i apoi l-a ters nu nseamn c
operaia a trecut neobservat de curioi. Un instrument de observaie util acestui atac este tot
Holodeck, care poate monitoriza aplicaia pentru scrierile n fiiere i construiete un log al
acestor comportamente, pentru a fi analizate. Holodeck ne poate spune cnd, cum i unde a
avut loc fiecare acces la un fiier al aplicaiei noastre, rmnnd n sarcina noastr s
investigm ce anume s-a scris i dac ar trebui s rmn secret.