3.

Vulnerabilit i i amenin ri la adresa aplica iilor software

Limbajele Java i .Net care la ora actual sunt cele mai folosite platforme de dezvoltare de noi aplica ii informatice se folosesc de o ma in virtual care interpreteaz i execut cod la run-time. Codul executat de aceste ma ini virtuale nu este cod ma in ca la limbajele clasice, ci un cod intermediar foarte flexibil. n Java i .Net, prin compilare se ob ine acest cod intermediar ce con ine i foarte multe dintre informa iile existente n codul surs . Acest fapt face ca opera ia de decompilare s fie relativ u oar , n orice caz, mai u oar dect n cazul codului ma in . Firmele produc toare de aplica ii software trebuie s se confrunte acum cu riscul de a cheltui multe resurse pentru dezvoltarea unui proiect i de a accepta posibilitatea ca un competitor s fac reverseengineering i s ob in f r mare efort biblioteci, algoritmi sau ntregi aplica ii la care pot schimba doar interfa a. n acela i timp, utilizatori, sau alte persoane r u-voitoare pot folosi acelea i tehnici de reverse-engineering pentru a modifica aplica iile respective n sensul elimin rii protec iilor la copiere, verific rilor de licen e, etc. n ambele cazuri se ajunge la pierderi financiare mari i deci se impun m suri de protec ie. Vom examina cteva tehnici de protec ie care pot ngreuna opera iile de reverseengineering iar n capitolele din partea a doua a acestei lucr ri ne vom opri mai mult asupra tehnicii obfusc rii i a protej rii prin polimorfism.

3.1. Amenin ri la adresa programelor

Exist trei tipuri de amenin ri ce planeaz asupra unui program software: infectarea sa cu un virus informatic; dezactivarea p r ii din program care verific existen a unei licen e pentru folosirea legal a acestuia; furtul/copierea codului unor algoritmi, module sau a ntregului program cu scopul de a l folosi n aplica ii concurente. Prima amenin are (atacul unor viru i) a fost deja tratata n capitolele anterioare i are ca rezultat final imposibilitatea folosirii programului respectiv sau a datelor administrate cu ajutorul s u (problema aceasta este tratat pe larg i n lucrarea lui F. Cohen: Computer Viruses Theory and Experiments, Computer Security: A Global Challenge [9]). Tot n capitolele anterioare am v zut i cum ne putem proteja de aceast amenin are. Pagubele produse n acest caz sunt suportate de utilizatorul programului, de in torul licen ei de folosire a acestuia. Celelalte doua tipuri de amenin ri vor fi tratate n continuare. Ambele afecteaz compania produc toare a programului respectiv care va pierde sume de bani foarte importante. n cazul acestor ultime dou amenin ri, pentru a putea interveni asupra programelor int , atacatorii folosesc diverse tehnici de reverse-engineering. Reverse-engineeringul nseamn de fapt descompunerea unui produs software pentru a determina i studia modul de func ionare al acestuia. Mai multe detalii se pot g si i n Encyclopedia of Software Engineering a lui John Marciniak [68]. Mai 32

general, reverse-engineeringul urm re te analiza unui sistem existent (nu este important pentru tehnic cine este proprietarul acestui sistem). n sine, tehnicile de reverseengineering nu sunt ilegale sau imorale, ele fiind folosite pe scar larg pentru a mbun t ii produsele proprii. n urma folosirii acestor tehnici se pot descoperi gre eli n designul original al sistemului, se pot detecta redundan e sau se pot urm ri fluxuri de efectuare a unor opera ii. n domeniul ingineriei, reverse-engineeringul ia un produs finit i reconstituie cuno tin ele necesare pentru a re-crea acest produs. Procesele de fabrica ie i uneltele nu sunt deloc u or de reprodus, n contrast cu reproducerea unui program din domeniul software unde tot ce trebuie f cut este s se reproduc o secven de octe i ce alc tuiesc programul respectiv. Partea dificil a opera iei de reverse-engineering este ns crearea unei baze de cuno tin e despre programul analizat care s fie suficient pentru ca acesta s poat fi modificat, s se poat adapta p r i din el sau s poat fi interfa at cu diverse alte module. nsu i faptul c este mult mai u or s se copieze software dec t alte produse cu existen a fizic oblig produc torii din acest domeniu s pun un accent pe protejarea drepturilor legale de copyright asupra aplica iilor. Pentru a putea ncepe o analiza de reverse-engineering asupra unei aplica ii software trebuie ca nti acea aplica ie s fie accesibil fizic. Folosind dezasambloare i decompilatoare se poate ob ine codul surs i se poate analiza fluxul programului i structurile de date. Aceast analiz se poate face cu ajutorul unor unelte suplimentare. Una dintre cele mai importante utiliz ri legitime ale tehnicilor de reverseengineering este recuperarea informa iilor pierdute despre un sistem. Spre exemplu, multe companii folosesc nc programe foarte vechi pentru c respectivul sistem este func ional i ofer acces la un anumit volum de date importante. Este i cazul aplica iilor care au fost scrise n COBOL care uneori mai sunt p strate numai pentru c sunt singurele care pot accesa nregistr ri vechi. n multe cazuri, sursele acestor programe nu mai sunt disponibile ntr-o form utilizabil (n unele cazuri ele exist dar pot fi stocate pe un suport care azi este aproape imposibil de accesat: cartele perforate). Un efort important a fost f cut naintea anului 2000 cnd un mare num r de aplica ii vechi au fost supuse procesului de reverse-engineering pentru a putea ob ine codul surs i a-l modifica astfel nct s poat face fa a problemei anului 20001. Prin extragerea algoritmilor proprietari i a structurilor de date dintr-o aplica ie competitoare i prin incorporarea acestora n propria aplica ie se reduce n mod dramatic costul proiectului i timpul petrecut pentru faza de analiz , dezvoltare i chiar teste deoarece algoritmii prelua i sunt deja verifica i. n plus, dovedirea faptului c un algoritm sau anumite par i dintr-o aplica ie au fost furate este infinit mai dificil dect n cazul furtului ntregii aplica ii. Aceasta nseamn c ob inerea unor compensa ii pentru veniturile pierdute este foarte dificil n aceste cazuri iar micile companii sau dezvoltatorii independen i nu i vor permite s poarte procese lungi cu o companie puternica ce are n spate avoca i puternici. De la apari ia limbajului Java i, mai trziu, a limbajelor care func ioneaz pe platforma .Net amenin area asupra aplica iilor a devenit mult mai serioas . Aceste limbaje sunt proiectate s compileze codul surs ntr-un limbaj independent de platform care folose te bytecodes. Codul intermediar este un limbaj puternic, spre deosebire de codul ma ina i, din aceast cauz , o cantitate mare din informa ia care este prezent n codul surs trece n codul intermediar f cnd decompilarea mult mai facil . Se folosesc de asemenea foarte multe func ii de libr rie care fac programele s fie mici i u or de
1

Problema anului 2000 = bug al sistemelor informatice provenit din faptul ca pentru campuri ce stocau anul dintr-o dat calendaristic erau prevazute doar doua cifre.

33

urm rit. Aceasta pe lng faptul c limbajul intermediar fiind puternic deja necesit un num r redus de instruc iuni pentru implementarea unui program.

3.2. Metode de protec ie a programelor

Ideea de baz a folosirii unei protec ii tehnice a aplica iilor software este ajungerea la o situa ie n care opera iile de reverse-engineering s devin neviabile din punct de vedere economic sau chiar imposibile. Primele ncerc ri de a crea protec ii ale aplica iilor software au ap rut n anii 80. O tehnic foarte r spndit n acele vremuri era distribuirea programelor pe dischete cu o formatare special astfel nct utilitarele de copiere obi nuite s nu poat duplica informa ia con inut . Ideea din spatele apari iei limbajelor care genereaz cod independent de platform este c o singur versiune a acelui program trebuie creat i aceasta va rula pe orice sistem. Costurile de dezvoltare i suport vor fi reduse deoarece nu este necesar ntre inerea unor versiuni diferite ale aceleiasi aplica ii pentru fiecare platfrom pe care aceasta ruleaz . Schimb rile care fac ca aplica ia s se bazeze pe anumite particularita i hardware sau ale sistemului de operare fac inutil utilizarea unui limbaj portabil. Din aceast cauz , protec iile ncorporate n software trebuie s fie gndite n a a fel nct s fie independente de orice particularit i ale mediului n care ruleaz aplica ia. Vom discuta n continuare diverse tehnici de protejare a programelor precum modelul client-server, criptarea, codul nativ semnat i obfuscarea codului. Protec ia prin execu ia pe server (server-side execution). Primul pas pentru aplicarea unor tehnici de reverse-engineering asupra unei aplica ii este accesul fizic la acea aplica ie. Prin mpiedicarea accesului la aplica ie deja dejuc m orice ncercare de acest gen i problema este rezolvat nainte de a ncepe. S-au f cut multe studii referitoare la arhitecturile i mecanismele client-server (de exemplu cartea lui Sape Mullender Distributed systems). Ideea de baz a acestui mod de protec ie a aplica iilor este plasarea aplica iei care necesit protec ie pe un server iar serviciile acestei aplica ii vor fi oferite printr-o conexiune la distan (figura 3.2.1.). Folosind aceast arhitectur , accesul fizic la aplica ie este mpiedicat. Pe de alt parte exist i doua dezavantaje ale execut rii pe server fa de situa ia cnd ntreaga aplica ie este gazduita pe ma ina client: L imea de band a conexiunii la re eaua local sau la Internet este limitat , f cnd ca performan ele aplica iei respective s scad datorit constrngerilor legate de comunica ie; Dac re eaua n care este serverul nu func ioneaz corect atunci folosirea aplica iei va fi imposibil . Se pot prioritiza cerin ele aplica iei dezvoltate i se poate alege o arhitectur clientserver adecvat pentru fiecare caz practic. n acela i timp, numai anumite p r i (module) ale unei aplica ii pot fi considerate ca fiind critice din punct de vedere al protec iei, nefiind deci necesar protejarea ntregului program. Dac ne afl m n acest caz i anumite p r i nu sunt considerate de interes pentru competitorii firmei produc toare a aplica iei atunci executarea ntregii aplica ii pe server ne va aduce un grad de protec ie excesiv fa de necesit ile reale. Aplica ia va fi spart ntr-o parte privat ce va fi executat pe server i o parte public ce va rula local, pe ma ina client. n figura 3.2.1. 34

(b) este prezentat schematic i aceast configura ie cu execu ie par ial pe server a codului.

Figura 3.2.1. Protejarea aplica iilor prin execu ie server side (a) i par ial server-side (b) Executarea par ial pe server va avea acelea i beneficii ca i executarea total pe server, beneficii ce vin din faptul c partea ce se dore te a fi protejat nu este accesibil fizic. n plus se va beneficia i de performan e mai bune atunci cnd se vor executa p r ile din program care au r mas locale pe ma ina utilizatorului. n construirea arhitecturii acestui gen de aplica ii trebuie avut mereu n vedere volumul de informa ii ce va fi transferat ntre client i server. De asemenea trebuie considerat i frecven a comunica iilor efectuate ntre cele doua p r i ale aplica iei. Se fac de obicei compromisuri ntre nivelul de protec ie i viteza de excecu ie. n afar de protec ia aplica iilor, arhitecturile client-server mai au multe alte avantaje pe care ns nu le vom discuta aici nefiind relevante pentru domeniul nostru de studiu.

35

Protejarea prin criptare. Pentru a se elimina dezavantajele relative la performan ele aplica iilor care au fost sparte ntr-o arhitectur client-server din motive de protec ie a codului trebuiesc folosite metode care s protejeze codul direct accesibil unui utilizator pe ma ina pe care acesta ruleaz . Criptarea codului distribuit este una dintre aceste metode (n figura 3.2.2. este o reprezentare schematic ). Interceptarea i decriptarea codului compilat sunt posibile ns cu excep ia cazului n care decriptarea se face la nivel hardware. Sisteme hardware de decriptare exist i sunt descrise n diverse lucr ri precum cea a lui Amir Herzberg i Shlomit S. Pinter - Public Protection of Software [90] sau O. G. Wilhelm Criptographically Protected Objects [91]. Ideea este existen a unui procesor suplimentar (un cip dedicat) care s decripteze instruc iunile nainte ca acestea s fie executate de c tre procesorul principal al calculatorului pe care se execut aplica ia. Codul decriptat nu va fi niciodat p strat n memoria ce este accesibil utilizatorului sau altor programe ce ruleaz n paralel deci gradul de protec ie depinde de schema de criptare folosit pentru codul programului.

Figura 3.2.2. Protejarea prin criptare. Aplica iile protejate prin criptare pot fi programate s nu se execute dect dac cipul componenta hardware de decriptare este conectat la ma ina pe care se ncearc lansarea. n consecin , pentru a putea rula aplica ia pe orice ma in , cel ce va ncerca s o copieze i s o foloseasc va trebui s reu easc doua opera ii: S sparg schema de criptare; S modifice codul n a a fel nct verificarea existen ei cipului de decriptare s fie anulat . Problemele folosirii unui sistem de criptare care se bazeaz pe existen a unui cip de decriptare hardware vin din varietatea mare de procesoare folosite la ora actual pe pia a IT. Procesoarele acestea diferite vor avea nevoie de circuite de interfa are diferite pentru comunica ia cu cipul de decriptare. n consecin , acest mod de protec ie este aplicabil numai n cazul aplica iilor care sunt destinate s ruleze numai pe un set redus de procesoare sau pe un singur procesor pentru care exist deja interfa are cu cipul de decriptare folosit. De asemenea, ad ugarea unui cip de criptare oblig utilizatorii s pl teasc o sum suplimentar care nu le aduce nici o plus-valoare direct ci aduce beneficii numai produc torului aplica iei respective.

36

Protejarea cu ajutorul codului nativ semnat (Signed Native Code). Aplica iile Java i .Net sunt executate de c tre o ma in virtual care implementeaz un interpretor. Aceasta nseamn c aplica iile scrise folosind aceste tehnologii se vor executa ceva mai ncet dect aplica iile clasice scrise n limbaje ce se compileaz direct n cod ma in . Pe de alt parte vor avea avantajul portabilit ii. Pentru a mbun t ii viteza de execu ie n cazul aplica iilor Java au fost dezvoltate compilatoare just-in-time (JIT) ce traduc bytecodes Java n cod nativ exact la momentul rul rii aplica iei. Codul nativ ob inut este apoi executat n locul acelor bytecodes ce au fost tradu i. Exist un num r destul de mare de compilatoare just-in-time disponibile pentru o varietate de sisteme de operare. Anumite companii au inclus compilatorul JIT direct n kitul lor pentru platforma de dezvoltare, exemple fiind Borland Jbuilder [92] i Microsoft Visual J++ [93]. Pentru a evita consumarea de timp pentru compilare de fiecare dat cnd aceea i bucat de cod este executat pe aceea i ma in este posibil p strarea codului ma in deja compilat. Tehnologia care permite acest lucru este cunoscut sub numele de compilare way-ahead-of-time (WAT compilation). Exist deja pe pia mai multe compilatoare WAT pentru Java cum ar fi NET [94] i Toba [95]. Compilatoarele JIT i WAT pot fi folosite pentru a transforma codul intermediar (Java bytecodes) n cod ma in care este mult mai greu de decompilat i urm rit. Aplica ia ce este distribuit este astfel nti compilat cu un compilator standard de Java i nc rcat pe un server. Clien ii care cump r acea aplica ie identific o combina ie de arhitectur i sistem de operare n care se va lucra iar serverul despre care am vorbit le va furniza o versiune a acelei aplica ii direct n cod nativ pentru mediul respectiv. Faptul de a putea accesa numai codul nativ rezultat va ngreuna foarte mult dar n nici un caz nu va face imposibil o opera ie de reverse-engineering. Exist multe decompilatoare foarte performante care traduc cod ma in n cod surs C [96]. Ca nivel de protec ie oferit , distribuirea aplica iei n cod nativ nu ofer acela i nivel precum dispozitivele hardware de criptare. n plus, este necesar cte un compilator JIT sau WAT care s compileze aplica ia n cod nativ pentru fiecare arhitectur / sistem de operare ce pot fi ntlnite la clien ii poten iali. Deja portabilitatea aplica iei va fi redus la sistemele pentru care compilatoarele JIT sau WAT disponibile pot genera cod.

Figura 3.2.3. Protejarea prin distribuire de cod nativ semnat. n cazul aplica iilor scrise n limbajul Java mai exist o problem suplimentar legat de distribuirea direct a codului nativ. Spre deosebire de Java bytecodes, codul nativ nu mai este supus opera iei de bytecode verification care se efectueaz naintea execu iei. Deci n cazul codului nativ nu mai putem avea garan ia c acesta se va executa 37

f r s efectueze ac iuni ilegale precum coruperea unor fi iere utilizator. Aceasta nu este o problema n cazurile n care firma produc toare a aplica iei este o cas de software cunoscut i este evident c nu se vor a tepta ac iuni r u inten ionate de la codul distribuit de aceasta. Pentru a evita confuziile, companiile dezvoltatoare i semneaz digital [97] codul transmis, garantnd astfel clien ilor sau utilizatorilor autoriza i c respectiva aplica ie este cea original (figura 3.2.3.). Protejarea prin obfuscarea codului (code obfuscation). Am l sat ca ultim metod de protec ie prezentat n aceast sec iune obfuscarea codului. Ideea este transformarea unei aplica ii astfel nct aceasta s fie func ional identic relativ la original dar s fie mult mai greu de n eles. Companiile dezvoltatoare folosesc utilitare numite obfuscatoare pentru protejarea aplica iei (figura 3.2.4.). n orice caz, trebuie avut n vedere faptul c , spre deosebire de execu ia server-side, obfuscarea nu ofer o protec ie complet mpotriva atacurilor mali ioase de tip reverse-engineering. Cheltuind o cantitate suficient de timp i efort va fi posibil recuperarea algoritmilor i a structurilor de date importante din aplica ia avut n vedere. De data aceasta se va folosi un utilitar numit de-obfuscator care va ncerca s inverseze transform rile la care a fost supus aplica ia pentru a fi protejat .

Figura 3.2.4.Protejarea prin obfuscarea codului. Nivelul de securitate oferit de un obfuscator mpotriva opera iilor de reverseengineering depinde de: Complexitatea transform rilor folosite de obfuscator; Puterea algoritmilor de de-obfuscare; Cantitatea de resurse (n principal timp) care sunt disponibile pentru deobfuscator. Obfuscarea codului face codul respectiv mult mai greu de n eles p strnd n acela i timp i independen a de platform a acestuia. Este inutil modificarea aplica iilor transformate astfel nct acestea s depind de diverse particularit i ale unui sistem de operare sau ale unor componente hardware n cazurile cnd aceste aplica ii au fost scrise n limbaje create special pentru a facilita portabilitatea. Spre deosebire de execu ia server-side, o aplica ie obfuscat nu va suferi n plus din cauza limit rilor traficului de re ea i a disponibilit ii acesteia. Obfuscarea nu va necesita hardware suplimentar precum n cazul protec iei prin criptare iar verificatorul din cazul lui Java va putea s i 38

fac treaba i s previna executarea unor opera ii ilegale de c tre codul executat. Spre deosebire de codul nativ, n cazul obfusc rii nu este necesar nici un fel de semnare digital a aplica iilor pentru a dovedi c respectivul cod provine dintr-o surs de ncredere.

3.3. O concluzie n ce prive te metodele de protec ie

n cazul aplica iilor scrise n medii de dezvoltare care genereaz cod intermediar vom sus ine n aceast lucrare c obfuscarea combinat cu protejarea polimorfic este metoda de protec ie cea mai bun . Mai ales pentru cazul aplica iilor clasice vom intra n am nuntele cre rii de cod polimorfic n a doua parte a lucr rii. Exist situa ii n care o alt tehnic de protejare a aplica iilor este mai potrivit , de exemplu atunci cnd algoritmii implementa i sunt de o importan extrem sau cnd performan ele sunt critice. Transform rile folosite de un obfuscator ar putea s nu ofere un grad destul de bun de protec ie sau s afecteze n mode negativ performan ele. Trebuie avut n vedere faptul c tehnicile de protec ie a aplica iilor software nu sunt mutual exclusive. n exemplul din figura 3.3.1. obfuscarea codului este aplicat pe bytecodes iar codul rezultat este compilat way-ahead-of-time n cod nativ. De aici se aplic o criptare i apoi codul nativ este semnat digital.

Figura 3.3.1. Combinarea metodelor de protec ie. Aplicarea unui reverse-engineering asupra codului rezultat va fi considerabil mai dificil deoarece sunt mul i pa i care vor trebui inversa i pentru a ajunge la codul surs ini ial.

39