Malicious behavior monitoring system

Malicious Behavior Monitoring SYSTEM

Lucrarea iși propune realizarea unei aplicații ce monitorizeaza in timp real starea unui sistem de operare, cu scopul de a detecta și bloca acțiunile unei aplicații malware sau a unui atac din internet. Punctul de plecare il constituie studiul atacurilor cunoscute pana in momentul de fața, incercandu-se sa se stabileasca un tipar al unui atac, cu scopul de a reuși identificarea atacurilor noi, pentru care nu au aparut inca soluții. Testarea se va desfașura pe doua mașini virtuale: atacatorul și victima, care trebuie sa depisteze și sa faca fața  atacurilor inițiate de atacator asupra sa.

This paper has as purpose of developing an application that monitors in real time the state of a operating system, with the aim of detecting and blocking the actions of a malware application or an attack from the Internet. The departure point is being represented by the studies of the known attacks up until now, by trying to set a pattern of the attack, with the purpose of succeeding to identify new attacks, for which no solutions were yet found. The testing will be realised on two virtual machines: the attacker and the victim, that should be able to detect and deal with the initial attacks launched upon it.

Cuvinte cheie: malware, analiza dinamica, monitorizare in timp real, securitate

1. Introducere

O aplicație malware reprezinta definiția generica pentru orice tip de program nedorit ce poate rula pe un calculator (viruși, viermi, troieni etc.). Pentru recunoașterea și indepartarea acestor programe, un antivirus folosește de obicei o baza de date cu semnaturile tipurilor de aplicații malware cunoscute pana in prezent. Aceasta baza de date trebuie actualizata cat mai des posibil pentru a permite depistarea atacurilor noi aparute. Pentru asigurarea stabilitații unui sistem, este totuși vital ca antivirusul sa aiba capacitatea de a depista un conportament daunator chiar daca acesta nu corespunde unei intrari din baza sa de date.

Procesul de analiza a aplicațiilor malware are ca scop determinarea unui tipar in comportamentul acestora: scopul general și mijloacele prin care incearca atingerea acestui scop. Acest proces este un pas necesar in dezvoltarea unei aplicații capabile sa detecteze noi tipuri de atacuri (asa-numitele "zero day attacks"[1]). Analiza manuala a unei astfel de aplicații este un proces indelungat și anost. Din acest motiv, automatizarea procesului reprezinta o necesitate.

Exista doua moduri de abordare a analizei comportamentului unui program: Primul, analiza statica, presupune analiza codului aplicației, instrucțiune cu instrucțiune. Totuși, aceasta metoda nu poate fi aplicata in timp real și este ineficienta in cazul ofuscarii codului aplicației respective. Celalalt mod de analiza, cea dinamica, presupune rularea executabilului intr-un mediu izolat și observarea acțiunilor sale (de exemplu interacțiunea cu sitemul de operare, prin monitorizarea secvenței de apeluri de sistem invocate).

Proiectul presupune realizarea unei aplicații de monitorizare in timp real a unui sistem Linux, aceasta urmand sa ruleze intr-un mediu ușor de controlat (in cadrul unei mașini virtuale). Aplicația va realizeaza analiza dinamica a unor aplicații malware și a unor atacuri de rețea (testele folosind atacuri existente in lumea reala), prin monitorizarea rețelei, a sistemului de fișiere și a proceselor existente pe mașina respectiva. Fiind o aplicație de monitorizare, va necesita o interfața grafica, unde se pot vizualiza toate activitațile monitorizate. Va construi log-uri cu diferite formate pentru a putea vizualiza efectele aplicației malware intr-un mod catitativ:

tabele cu evoluția in timp a parametrilor vizualizați;

grafice cu ecoluția in timp a parametrilor vizualizați;

Va fi implementata și o interfața separata, care permite incarcarea unor astfel de fișiere de log pentru mai multe aplicații malware și realizarea unei comparații. O astfel de comparație poate fi utila, de exemplu, pentru compararea mai multor versiuni ale aceluiași tip de malware.

2. Soluții existente

Exista in momentul de fața diverse implementari de sisteme de analiza dinamica a comportamentului unui software. Ideea principala din spatele unui astfel de sistem este de a genera rapoarte automate și cat mai detaliate despre comportamentul unui program, precum interacțiunea programului cu sistemul de fișiere (deschidere, creare, inchidere fișier), monitorizarea modificarii regiștrilor și serviciilor (precum pornirea sau oprirea unui serviciu) in cazul sistemelor Windows sau a fișierelor de configurare in cazul Linux, precum și  ascultarea activitații proceselor și a comunicației inter-procese și a activitații pe rețea.

Norman SandBox [1] simuleaza un computer și o rețea conectata la acesta prin reimplementarea nucleului sistemului Windows și ruland executabilul programului presupus malware in acest mediu. Exista de asemenea și posibilitatea de a rula executabilul și cu o conexiune la rețea reala. Astfel de medii simulate sunt de regula total transparente aplicației malware, aceasta din urma nefiind capabila sa realizeze ca ruleaza intr-un mediu controlat. Totuși, astfel de simulari nu permit proceselor aplicației malware sa interfereze, sa infecteze sau sa modifice in vreun fel celelalte procese active de obicei in orice sistem de operare din simplul motiv ca in implementarea mediului simulat nu ruleaza și alte procese in afara de cele ale aplicației malware. Fara monitorizarea acestei interferențe, informație foarte valoroasa analizei poate fi pierduta. Proiectul nostru presupune folosirea unui sistem de operare linux, in cadrul unei mașini virtuale, singura modificare adusa nucleului fiind hook-urile pe rețea și pe apelurile de sistem , permițand astfel aplicației malware sa interfereze cu sistemul.

O alta implementare existenta este TTAnalyze [2], care de asemenea folosește hook-uri insa difera de proiectul nostru prin faptul ca folosește ca și emulator QEMU2, in loc de mașini virtuale, ceea ce ar face mai dificila detecția de catre aplicația malware a faptului ca ruleaza intr-un mediu controlat.

O abordare diferita a unei astfel de soluții este a lui Chas Tomlin, denumita Litterbox [3], in care aplicația malware este rulata intr-un sistem de operare real (Windows) și nu intr-unul simulat. Dupa 60 de secunde de execuție, computerul pe care ruleaza este restartat și forțat sa booteze de pe o imagine Linux. Dupa pornirea Linuxului, aceasta soluție propusa monteaza partiția cu sistemul Windows și extrage regiștrii Windows și fisierele de pe partiție, dupa care reface sistemul Windows la starea anterioara execuției malware-ului. Litterbox  pune accentul pe monitorizarea activitații de rețea, pentru aceasta simuleaza in sistemul Windows o conexiune la internet cu un server de IRC in funcțiune, ce raspunde pozitiv la toate cererile de conexiune. Scopul este de a captura toate pachetele primite și a le trimite spre analiza ulterior. Aceasta abordare are un inconvenient major, acela ca sistemul este restartat dupa 60 de secunde și deci analiza se face pe o stare intermediara a sistemului infectat, nemonitorizand și acțiuni dinamice precum crearea de procese noi.

Mecanismele de baza din spatele unui IDS (Intrusion Detection System) sunt hook-urile pe rețea sau pe apelurile de sistem, precum și ordinea apelarii acestora. O implementare a unui astfel de sistem presupune o faza de pregatire, in care se monitorizeaza apelurile de sistem sau procesele și se creaza un profil al sistemului considerat comportament "normal". In timpul rularii, IDS-ul compara secvența de apeluri de sistem cu acest profil și in cazul in care distinge o deviere genereaza o alarma. In proiectul nostru ne propunem sa introducem un astfel de mecanism, partea cea mai dificila fiind logica de creere a profilului considerat normal și scaderea ratei de alarme false.

Referat: Contabilitatea tertilor Referat: Structurarea elementelor de activ si pasiv dupa criterii financiare

3. Scenariul unui atac

Scenariul unui atac asupra unui sistem consta in primul rand intr-o metoda de tranziție de la nivelul de privilegii inițial al atacatorului, la un alt nivel de privilegii, și folosirea noilor drepturi pentru a realiza o anumita acțiune.

Acțiunea executata de un atac dupa folosirea unei metode de tranziție  se poate incadra in una din urmatoarele categorii:

Probe - Atac ce este cunoscut și sub numele de "scanare a porturilor", este folosit pentru descoperirea mașinilor existente intr-o rețea, respectiv a serviciilor și utilizatorilor existenți pe o mașina.

Denial of Service

Intercept - de exemplu interceptarea traficului de rețea

Alter - modificarea datelor, a log-urilor

Use - atacuri cu scop recreativ

Nivelurile de privilegii ale unui utilizator se impart in cinci categorii generale:

R (Remote network access) - utilizator care se afla undeva in internet, in afara rețelei locale din care face parte stația victima;

L (Local network access) - utilizator din rețeaua locala a victimei;

U (User access) - cont de utilizator neprivilegiat pe stația victima;

S (Super-user access) - cont de utilizator cu drepturi depline (root);

P (Physical access to host) - acces fizic la stația victima;

Pentru a putea efectua acțiunea dorita asupra unui sistem, atacatorul va folosi una dintre urmatoarele metode de tranziție:

M (Masquerading) - falsificarea identitații; atacatorul pretinde a fi un utilizator ce poseda drepturile necesare pentru a executa acțiunea dorita;

A (Abuse of feature) - folosirea in exces a unui privilegiu deja caștigat; intalnita in atacurile de tip Denial of Service (de exemplu: umplerea cu fisiere a unei partiții de pe disc, sau inițierea a sute de conexiuni telnet pentru a umple tabela de procese a stației victima);

B (implementation Bug) - folosirea unei vulnerabilitați a unei aplicații sigure petru a iniția un atac (cele mai multe exemple de atacuri folosesc buffer overflow);

C (system misConfig) - configurarea greșita a politicilor de securitate;

S (Social Engineering) - atacatorul poate convinge un utilizator uman sa ii acorde accesul;

Pe baza acestor reguli se va incerca stabilirea unei baze de date cu scenarii ce pot fi daunatoare sistemului. La intalnirea unei situații ce se incadreaza in baza de date, aplicația va scrie in fisierele de log și va incerca, prin execuarea unor acțiuni predefinite, minimizarea daunelor.

4. Prezentarea arhitecturii

Aplicația va avea doua componente:

o parte in user space, care va conține și interfața grafica și baza de date cu reguli;

o parte in kernel space, care se ocupa de monitorizarea starii rețelei, a sistemului de fișiere cat și a proceselor deschise

Cele doua componente comunica una cu cealalta, pentru luarea unor decizii de acțiune in cazul unui posibil atac, pentru scrierea in fisierele de log, sau pentru crearea de noi reguli, specificate de utilizator.

Fig. 1. Arhitectura aplicației

a)     Monitorizarea rețelei

Pentru a nu ingreuna traficul de pachete, analiza unui pachet se realizeaza in doua etape, conform diagramei de mai jos:

Fig. 2. Analizarea unui pachet de rețea

Fiecare pachet este analizat inițial cu iptables (implementat cu ajutorul librariei libiptc [5]), care consulta lista de reguli, extagand din pachet headerele pana la nivelul transport al stivei OSI. Apoi, daca este necesara o verificare amanunțita, headerele de nivel sesiune-aplicație vor fi analizate cu ajutorul librariei libnetfilter_queue [6] (aceasta functioneaza asemenea netfilter, dar pastreaza pachetele intr-o coada, din care vor fi extrase ulterior pentru analiza). Daca pachetul nu se potrivește niciunei intrari din tabela de reguli, acesta va fi lasat sa treaca și se va analiza pachetul urmator. Daca pachetul corespunde unei reguli, atunci aplicația va lua o decizie (de DROP/ACCEPT) pentru pachetul respectiv și va rula o acțiune corespunzatoare (de exemplu blocarea temporara sau definitiva a unui port, respectiv a adresei sursa a pachetului, sau contorizarea pachetelor de acel tip interceptate - pentru detectarea atacurilor ce presupun trimiterea mai multor pachete).

b)     Monitorizarea sistemului de fișiere

Folosește un hook pe sistemul de fișiere cu ajutorul caruia se monitorizeaza fiecare acțiune de deschidere, inchidere sau creare a unui fișier. Se verifica daca cel ce manipuleaza fisierul respectiv are drepturile necesare și se testeaza integritatea fișierelor de configurare prin verificarea hash-urilor.

c)      Monitorizarea proceselor

Sunt introduse limitari cu privire la numarul maxim de procese ce pot fi create de un utilizator pentru a se evita atacuri de tipul "fork bomb" [7]. De asemenea, urmeaza a fi implementat un nivel minim de protecție proprie al aplicației. Astfel, daca este atacat chiar sistemul de monitorizare, acesta va trebui sa reziste unor atacuri de baza cum ar fi:

sa previna inchiderea sa prin rularea mai multor procese care ruleaza simultan și se monitorizeaza reciproc. In momentul in care antivirusul inchide aplicația, unul dintre procesele de monitorizare o va reporni (se merge pe ideea ca virusul nu are cum sa inchida toate procesele simultan, in mod atomic);

sa previna ștergerea și/sau modificarea fișierelor de log create;

5. Prezentarea scenariilor de test

Analiza malware trebuie intotdeauna sa se desfașoare intr-un mediu controlat, iar in cazul de fața, folosirea unei mașini virtuale s-a considerat ca fiind soluția optima. Mediul de testare este format din doua mașini virtuale amplasata folosind VMware Workstation 7.0, pe ambele ruland un sistem de operare Debian 5.0.

Una dintre aceste doua stații, stația victima, este cea pe care s-a instalat aplicația de monitorizare, iar in cadrul testarilor se verifica gradul de stabilitate al sistemului in urma unor atacuri inițiate de pe cealalta mașina virtuala, atacatorul.

Cu toate ca folosirea unei mașini victima virtuale ofera un anumit nivel de control asupra comportamentului aplicațiilor malware rulate pe aceasta, exista și unele riscuri in rularea de aplicații malware pe o mașina virtuala:

Software-ul de virtualizare nu este perfect și poate permite scurgeri neașteptate de informații de la mașina virtuala catre mașina gazda;

Codul analizat poate detecta faptul ca ruleaza intr-un mediu virtual și iși poate schimba comportamentul;

Un vierme zero day care poate exploata un serviciu care asculta pe sistemul de operare al mașinii gazda, va scapa din mașina virtuala.

O soluție in acest sens ar fi folosirea unui mediu de analiza malware dedicat, dar, din motive financiare ne-am limitat pentru inceput la folosirea unui mediu virtual.

In tabelul de mai jos sunt prezentate sumar caracteristicile mașinilor ce vor participa la analiza malware:

Tabelul 1

Mediul de testare

Atacurile folosite pentru testare vor fi cele ce au participat la crearea bazei de date cu reguli, folosita de aplicație pentru identificarea unui atac. Principala sursa de inspirație in care am gasit descrierile mai multor tipuri de atacuri adunate in același loc a fost teza de doctorat a lui Kristopher Kendall [8]. In continuare vor fi prezentate cateva dintre aceste atacuri și acțiunea rulata de aplicația noastra in cazul depistarii lor.

Tabelul 2

Exemple de atacuri

Exemplu de comportament: Apache2

Este un atac de tip Denial of Service administrativ (necesita intervenția administratorului). Atacatorul trimite server-ului Apache2 cereri http GET cu mai multe headere http. De exemplu: Header-ul "User-Agent: siouxrn' repetat de 10 000 de ori in fiecare cerere. Daca atacul reusește, server-ul este suprasolicitat și nu mai raspunde, necesitand restartarea daemon-ului httpd pentru a iși reveni.

La primirea unui astfel de pachet, partea de libiptc verifica portul destinație (in cazul de fața este portul 80, cel pe care asculta server-ul Apache), apoi inspecteaza segmentul de date din pachet folosind libnetfilter_queue și observa ca pachetul reprezinta o cerere GET http, cu un numar de headere mai mare de 10 000 (este identificat atacul din baza de date).

Dupa identificarea atacului, este rulata acțiunea corespunzatoare acestuia: DROP pachet, adresa sursa este blocata pentru 24 de ore și adaugata intr-o lista neagra (la 3 atacuri inițiate de la aceasta adresa, ip-ul este blocat definitiv).

6. Concluzii

Majoritatea antivirușilor folosesc baze de date cu semnaturi ale atacurilor cunoscute, dar sunt vulnerabile la atacurile nedescoperite pana la momentul atacului, sau daca baza de date nu este actualizata destul de frecvent.

Analiza aplicațiilor malware este un pas necesar in dezvoltarea unei aplicații capabile sa detecteze noi tipuri de atacuri.

Monitorizarea in timp real a aplicațiilor rulate pe sistem folosește analiza dinamica a aplicației. Spre deosebire de analiza statica, cea dinamica nu urmareste codul sursa al programului analizat, ci secvența de apeluri de sistem invocate pe parcursul execuției. Aceasta permite detectarea atacurilor de tip "zero-day" și este imuna la ofuscarea codului.

Un mecanism de analiza dinamica a starii sistemului se bazeaza pe stabilirea unui profil considerat "normal", orice deviere de la acesta generand o alarma. Un defect al acestei metode il constituie faptul ca profilul va trebui ajustat la fiecare modificare a sistemului pe care este instalat; se poate ajunge astfel la alarme false ce pot duce chiar ele la instabilitatea sistemului.

Analiza malware trebuie intotdeauna sa se desfașoare intr-un mediu controlat, pentru a nu permite raspindirea unei eventualei infecții.

In dezvoltarea unei aplicații de identificare a atacurilor asupra unui sistem trebuie avuta in vedere implementarea unei soluții de protecție proprie.

Folosirea unei mașini virtuale ca mediu de testare a unei aplicații malware ofera un anumit nivel de control asupra comportamentului aplicației malware, dar poate duce la infectarea mașinii gazda sau la schimbarea comportamenului aplicației analizate, daca aceasta detecteaza faptul ca ruleaza intr-o mașina virtuala. O soluție pentru evitarea acestor riscuri este folosirea unui mediu de analiza malware dedicat.

O direcție practica de extindere a aplicației ar fi portarea acesteia pe alte sisteme de operare sau adaptarea pentru dispozitive mobile (atacurile asupra telefoanelor mobile inteligente sau a PDA-urilor s-au inmulțit deja considerabil).

Bibliografie

K. Kendall, "A Database of Computer Attacks for the Evaluation of Intrusion Detection Systems" (1999), Thesis (S.B. and M.Eng.), Massachusetts Institute of Technology, Dept of Electrical Engineering and Computer Science