La nostra formula antivirus

Ogni sistema si basa su un algoritmo unico, senza l’algoritmo il sistema non esiste. Non importa realmente quale tipo di algoritmo segua il sistema (lineare, gerarchico, deterministico, stocastico); ciò che importa è che si ottenga il miglior risultato affinché il sistema segua determinare regole.

Ci è stato spesso chiesto degli algoritmi che utilizziamo per i nostri prodotti, e soprattutto ci chiedono in che modo ci aiutano a individuare le future minacce in maniera più efficiente rispetto alla concorrenza.

Beh, per ovvie ragioni non posso darvi molti dettagli sulla nostra formula magica; in ogni caso, con questo post piuttosto tecnico (oserei dire il più tecnico che abbia scritto su questo blog) voglio farvi dare una sbirciatina a ciò che succede nella nostra officina tecnologica, ma vi faccio dare un’occhiata giusto per un attimo.

Noi di Kaspersky Lab utilizziamo un approccio deduttivo per individuare i malware, ovvero andiamo dal generale al particolare. Tutti i malware effettuano, facciamo un’ipotesi, le operazioni x, y e z. Un determinato file esegue le operazioni x, y e z. Possiamo dedurne che questo file potrebbe essere dannoso perché compie le stesse operazioni di un malware. Purtroppo, però, le cose nella pratica non sono così semplici.

Innanzitutto, è impossibile stabilire che una determinata azione indichi in maniera inequivocabile la presenza di un oggetto dannoso. Un classico esempio riguarda l’accesso al Master Boot Record (MBR): non possiamo affermare che tutto ciò che utilizza questo comando sia dannoso, dal momento che esistono diverse applicazioni che lo utilizzano per scopi legittimi. Lo stesso vale per le altre operazioni: dopotutto, se ci pensiamo bene, ogni comando è stato creato per eseguire delle operazioni utili.

In altre parole, non è sufficiente separare il grano dal loglio. Ciò che sì serve è capire quanto ci sia di buono, quanto di cattivo e in che termini. Ed è proprio quello che facciamo: scoprire ciò che succede all’interno del nostro granaio e nei granai vicini, analizzare i risultati e prendere delle decisioni importanti sulla situazione in generale, capire quanti “nemici” o “amici” abbiamo e poi seguirne i movimenti.

Per fare tutto ciò impieghiamo una tecnologia che abbiamo chiamato SR, acronimo di Security Rating. Si tratta di un sistema in continua evoluzione che ci aiuta a comprendere la natura di un oggetto durante le fasi di valutazione ed emulazione.

La formula magica di Kaspersky: un sistema in continua evoluzione che aiuta a comprendere la natura di un oggetto durante le fasi di valutazione ed emulazione.Tweet

L’SR analizza la composizione e la densità degli eventi generati da un oggetto e anche le sue caratteristiche più superficiali (nome, dimensione, ubicazione, compressione ecc.). Seguendo una complessa serie di regole, si ottiene una percentuale (da 0 al 100%). La prima serie di regole (che sono oltre 500) sono derivate da uno studio manuale di oltre 80 mila programmi dannosi unici appartenenti a diverse famiglie. Le nuove regole sono state sviluppate quasi in maniera automatica, lasciando agli esperti l’unico compito di raffinare gli algoritmi.

Per effettuare i test e gestire meglio il tutto, le regole sono state suddivise in gruppi (ad esempio, “Internet”, “Password”, “Registro” ecc.)  e se un oggetto si scontra con una di queste regole, vengono applicate le sanzioni corrispondenti.

Ecco un esempio delle regole più semplici:

‘Loading driver via low level API ntdll.dll’ rule

API function: NtLoadDriver
Argument 1: *
Argument 2: *
Argument 3…N: *
Assessment: Single operation – 40%, 2-3 operations – 50%, >3 operations – 60%
Harmful: No

‘Analysis of kernel machine code (taking hooks)’ rule

API function: CreateFile
Argument 1: Contains ‘ntoskrnl.exe’ entry
Argument 2: *
Argument 3…N: *
Assessment: Single operation – 100%, 2-3 operations – 100%, >3 operations – 100%
Harmful: Yes 

Il rating totale di un oggetto è la somma di tutti i singoli rating dopo aver applicato l’intero database delle regole. In altre parole, si tratta di una tipica rete neurale artificiale, che raccoglie i segnali da una moltitudine di sensori, ne analizza le caratteristiche qualitative e quantitative, esplora le connessioni ed emette il verdetto.

Questo era il meccanismo iniziale di SR nel  2007 (brevetto US7530106). Da allora, ci sono stati miglioramenti in questa tecnologia, come potete ben immaginare!

Problema numero uno: nel momento in cui viene analizzato, il file può generare un elevato numero di eventi insignificanti, e questi eventi possono erroneamente far pensare che si tratti di un file dannoso. Ad esempio, al suo avvio un’applicazione Deplhi crea fino a 500 eventi.  Ci possono essere eventi identici per qualsiasi applicazione scritta in una determinata lingua e questi eventi possono non contenere informazioni utili circa le vere intenzioni di un file. Questo “rumore” non solo consuma le risorse del computer ma rende più difficile il compito di analizzare i file.

Per ovviare a questo problema, abbiamo creato un filtro per sbarazzarci di questo “rumore”. Inoltre, a differenza delle normali regole, è sufficiente un attributo booleano; in questo modo, si può semplificare e velocizzare il lavoro. Di conseguenza, il risultato contiene il nome della funzione API e le maschere per i suoi argomenti.

SysAllocString (*,-NULL-,-NULL-)

In questo caso, se il primo argomento della funzione ha un significato mentre il resto no, l’evento sarà considerato non significativo.

Per la generazione automatica delle regole di filtro per eventi non importanti abbiamo adottato tre metodi.

Il primo è il drosophilae method. Prepariamo un’applicazione semplice che mostra il messaggio “Hello World” utilizzando lo strumento X e, finché possibile, le sue DLL più popolari. Inseriamo l’applicazione nell’emulatore assieme a tutti gli eventi che rientrano nel campo “non signficativo” (insignificant).

Il secondo è il packed drosophilae method. È simile alla prima metodologia tranne per il fatto che ci concentriamo sul comportamento dei packer/protector. Per fare ciò eseguiamo il messaggio nell’Assembler con diversi tipi di packer e protector, impieghiamo l’emultatore e… il resto lo potete immaginare. In caso contrario… filtriamo gli eventi non significativi.

Come il drosophilae method aiuta KL a contrastare le nuove minacce?Tweet

Il terzo metodo appartiene più al campo della statistica. Analizziamo una grande quantità di file sia legittimi che dannosi e segniamo le chiamate alle API che si osservano con maggiore frequenza in entrambe le tipologie di file. Questo metodo accompagna gli altri due e dà i suoi risultati se non c’è possibilità di impiegare gli altri due metodi sopra citati. Un esempio dell’impiego di questa metodologia è quando segnaliamo gli eventi non significativ dell’interfaccia grafica e delle funzioni di allocazione della memoria.

Tuttavia, questa generazione automatica di filtri per eventi non importanti era solo una delle sfide più facili da affrontare. Man mano le cose si sono fatte più interessanti…

La prima versione di SR funzionava su un solo computer tenuto praticamente in isolamento. Ai tempi non avevamo un’idea generale della situazione, non avevamo capito quali regole venissero impiegate (con quale frequenza e con quanta precisione) e non riuscivamo a modificare velocemente il rating. Di conseguenza, c’erano ancora tante possibilità da esplorare…

… e qui che è entrato in gioco KSN, il nostro servizio su cloud che ai tempi si stava sviluppando a tutta velocità e al quale abbiamo aggiunto il sistema Astraea (per poter analizzare importanti volumi di segnali dai computer protetti dai nostri prodotti e raggiungere così delle conclusioni ragionevoli circa la diffusione nel mondo delle minacce cibernetiche).

Nel 2009 abbiamo pubblicato con orgoglio la nuova versione di SR, ovvero SR2 (US8640245), che vede la presenza di KSN e Astraea.

Ciò ci ha consentio di gesitre i big data in maniera approfondita ed è questa la ricetta del successo nell’industria della sicurezza informatica!

In sostanza, siamo riusciti a: (i) ridurre in maniera consistente le regole non efficaci, (ii) disattivare temporaneamente o a testare certe regole e (iii) a correggere praticamente in real time i rating utilizzando dei coefficienti specifici. Inoltre, i database dei coefficienti erano piuttosto ridotti (in kilobyte) e il loro aggiornamento non ha avuto praticamente conseguenze sulla connessione Internet dei computer protetti, incluso nel lontano 2009.

Astraea, inoltre, ha ampliato la struttura statistica per il calcolo dei rating: non solo sono stati utilizzati i segnali provenienti da vari emulatori, ma anche altri sensori connessi a KSN. Tra l’altro, il prodotto poteva avvalersi delle considerazioni offerte da KSN, saltando il passaggio dell’emulazione. E c’era un altro aspetto positivo: potevamo prendere dei campioni affidabili di “esemplari” sconosciuti per i quali non disponevamo di dati sufficienti (ma il cui comportamento era sospetto) per un’analisi manuale.

Ciò che conta di più è che Astraea corregge automaticamente le regole: un esperto informatico deve solo valutare periodicamente l’efficacia del modello applicato e ottimizzarlo (pratica del brevetto US20140096184).

La tecnologia intelligente può fare tutto in maniera autonoma. Ad esempio: #Kaspersky combatte le future minacce con o senza l’intervento umano.Tweet

La disponibilità di big data ci ha fatto venire nuove idee per risolvere vecchi problemi, il primo fra tutti quello dei falsi positivi.

Sin dall’inizio abbiamo sperimentato con SR per avanzare nella nostra lotta ai falsi positivi. Ma è stato nel 2011 che abbiamo avuto la svolta: abbiamo ideato una serie di nuove funzionalità per minimizzare i falsi positivi di un colpo.

Ci sono molte operazioni eseguite da un software legittimo con le più innocenti intenzioni. Ad esempio, gli installer cancellano i file nella cartella System32. L’autoregolazione del rating di queste operazioni porta a una degradazione inutile e così non riusciamo a identificare i veri malware. Bisogna trovare un compromesso e, per fare ciò, abbiamo deciso di dividere il meccanismo di calcolo dei rating in tre parti:

Prima parte: il calcolo sopra descritto –  più il comportamento è pericoloso, più facilmente viene individuato, e più il rating è alto;

Seconda parte: definizione di regole di whitelist, che revocano o correggono le azioni delle regole comuni che si si applicano a situazioni o file concreti;

Terza parte: definizione di regole per le applicazioni legittime, che abbassano il rating di pericolo quando viene individuato un comportamento tipico e che consente anche di creare un rating di sicurezza.

Ad esempio:

‘Creation of registry key of autorun’ rule 

API function: Registry: establishing the meaning of the parameter (RegSetValueEx)
Argument 1: Contains entry
‘RegistryMachineSoftwareClasses*shellexContextMenuHandlersNotepad++’
Argument 2: *
Argument 3…N: *
Evaluation: Single operation – 1%, 2-3 operations – 1%, >3 operations – 1%
Harmfulness: None

Come possiamo vedere, si accede al registro di sistema; in ogni caso, si tratta solo di Notepad++ con la sua DLL. L’argomento della regola rimuove i falsi, mentre la regola principale  rimane fissa; tra i vari tentativi di cambiare il registro di sistema, la regola funzionerà come dovuto.

Successivamente, nel 2011, abbiamo introdotto un’altra funzionalità molto utile (nulla è lasciato al caso). Come detto in precedenza, su SR le regole funzionano in maniera indipendente l’una dall’altra; perciò, non possiamo studiare interdipendenze complesse come “carica file”, “salva file su disco” o “aggiungi all’autorun”. Ma se fossimo riusciti a rintracciare queste interdipendenze, avremmo ottenuto dei rating che non sono semplicemtne la somma dei rating dei vari eventi (o addirittura meno). Per questo, abbiamo deciso di abilitare il collegamento tra eventi su SR2 per individuare in maniera più precisa i malware sconosciuti.

E lo abbiamo fatto in due modi.

Innanzitutto abbiamo creato le bit mask, che determinano gruppi di regole o regole separate da OR e AND. La descrizione principale è il bit index delle classificazioni dei comportamenti. All’inizio si è pensato al clustering del malware basato sulle specifiche del proprio comportamento, ma un approccio simile può essere applicato per ridefinire i rating. Con l’aiuto delle mask, possiamo implementare funzioni come (RULE 76 o RULE151) e (RULE270 o RULE540). L’aspetto positivo è che le mask sono compatte e veloci, il difetto è che non sono flessibili.

In secondo luogo, abbiamo sviluppato script speciali per effettuare analisi globali dopo i calcoli di SR (brevetto US8607349). Si possono avviare gli script in maniera indipendente o quando viene stabilita una regola. Ogni script ha accesso al database delle statistiche riguardanti le regole o i gruppi di regole precedenti. Di conseguenza, abbiamo la possibilità di (i) utilizzare una logica complessa (condizioni, calcoli, cicli e attivazione di sottoprogrammi), (ii) sfruttare al massimo le reti neutrali e (iii) utilizzare gli script non solo per ottenere rating più precisi su SR, ma anche per ottenere maggiori conoscenze da applicare agli script successivi.

Ad esempio, basandoci sull’analisi di una dozzina di regole, il primo script decide che “l’applicazione cerca di ottenere la password da altri programmi”. Un secondo script decide che “l’applicazione trasferisce qualcosa su Internet”, mentre un terzo script decide che “se l’applicazione mostra un interesse per le password E trasferisce qualcosa su Internet, allora il rating è del +100%”.

Inoltre, gli script possono essere usati per qualsiasi regola, e la regola finale diventa un trigger per un qualche algoritmo.

Un esempio di script:

VarS : string;begin
if copy(ExtractFilePath(APIArg[1]), 2, 100)=’:’ then begin
AddSR(20);
s := LowerCase(ExtractFileExt(APIArg[1]));if S = ‘.exe’ then AddSR(40);
if S = ‘.com’ then AddSR(50);
if S = ‘.pif’ then AddSR(60);
if S = ‘.zip’ then AddSR(-20);
end;
end.

In questo esempio, lo script valuta l’operazione di creare un file. Verifichiamo che il file sia stato creato su disco e per questo motivo diamo a SR un 20%. Inoltre, in base alla dimensione del file, aggiungiamo un rating extra con “+” o “-“. Questo esempio dimostra quale sia il vero vantaggio offerto dagli script, ovvero la possibilità di valutare argomenti di funzione assegnando un rating SR individuale basato sui risultati delle varie prove. Inoltre, alcune prove possono far crescere il rating, altre diminuirlo e questa analisi complessa su più punti porta all’eliminazione dei falsi negativi.

E ora parliamo un po’ del futuro…

Abbiamo già iniziato a sviluppare la nostra linea di prodotti per il 2015, che usciranno tra poco. Ci abbiamo pensato e lungo e… alla fine abbiamo deciso di mettere da parte l’SR locale e trasferire i rating su cloud.

Questo nuovo approccio ci offre subito nuovi vantaggi. La qualità dell’analisi non ne risentirà, e le risorse necessarie saranno minori, dal momento che tutti i calcoli avverranno su cloud. Ridurranno anche i tempi di attesa delle valutazioni a… frazioni di millisecondi, che solo un software speciale può misurare; ovviamente i nostri utenti nemmeno se ne renderanno conto!

Ebbene, ora conoscete la nostra ricetta segreta (come quella della Coca Cola) e in 2.500 parole. In realtà è solo la punta dell’iceberg, ci vorrebbero giorni per spiegare tutto in dettaglio…

Il post più tecnico di @e_kaspersky sulle minacce future! Vale la pena leggerlo.Tweet