Antivirus & Rootkits

Moderators: forart, Davy Bartoloni, gabrielilardi

Post Reply
PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Antivirus & Rootkits

Post by PUOjACKz »

Ultimamente, da quanto si legge, i rootkit e gli spyware vanno alquanto di moda. Addirittura, alcuni produttori di AV famosi (es. Kaspersky e McAfee), ne fanno uso.
Le cause principali, dell'adozione di tale prassi, sono, principalmente, 2:

- Impedire che i malware causino attacchi DoS contro AV/Firewall, disattivandoli ed esponendo il sistema alla vulnerabilità di sicurezza che ne deriva
- Impedire, ai malware, il libero accesso ai database o altri files critici, al fine di arginare la possibilità, a questi, di effettuare vari tipi di injection maligni (per corrompere, ad esempio, i databases degli AV)

A questo punto, mi vedo costretto nel ri-sottolineare l'importanza, in ReactOS, d'implementare le Capabilities (progettandole in modo da renderle sia enormemente configurabili, sia al fine di bloccare le azioni maligne più comuni, che potrebbero avvenire nell'ambiente operativo, a discapito della sua sicurezza).
Con opzioni quali:

Code: Select all

- Bypass del permesso nel spedire il comando di Kill Task
- Possibilità/Impossibilità d'uso del RAW e Packet Socketing ecc...
Ben sviluppate, es. configurabili da MMC, è possibile circoscrivere l'attività maligna dei malware, diretta alla disattivazione dei dispositivi di sicurezza e alla generazione di traffico spoofato (usato, in particolar modo, durante gli attacchi DDoS, da botnet).
Rendendo un programma, predefinitamente, impossibilitato nel generare, ad esempio, le funzioni legate a queste due opzioni delle Capabilities, l'attaccante necessita, come minimo, di un account che permetta l'impostazione o la disattivazione di tali sbarramenti, per poter apportare un certo tipo di operazioni maligne, tramite il box compromesso.
Linux, ad esempio, nonostante goda, già di per sè, di una robusta sicurezza fornita da tutto il sistema di privilegi ecc., implementa nativamente tali "estensioni" di configurazione, sebbene, non ne abbia bisogno (almeno non ora). Questo a dimostrare che se addirittura i coders di un OS alquanto "stabile", a livello di sicurezza, giungono ad implementare più stratagemmi quali, ad es., PaX, Exec Shield, StackGuard ed GrSecurity, significa che il problema è ben più serio di quanto si potesse lontanamente immaginare, per garantire una piattaforma mission-critical.

Riguardo il problema dovuto dal pericolo d'injection, anche in questo caso, ripropongo l'implementazione dell'identità "Programma", oltre che "Utente" e "Computer", nell'engine dei privilegi assegnabili via sistema. In questo modo, è possibile creare un finto gruppo, ove sono inseriti tutti i singoli programmi installati nel sistema, oppure, specificare solo una cerchia ristretta di eseguibili, creando un gruppo secondario. In questo modo, ad esempio, è possibile permettere degli accessi maggiormente protetti, a certe cartelle.

Es.

Solitamente, quando viene creata una cartella, in XP, vengono introdotti i seguenti gruppi:

- Administrators
- Users
- "Utente" ov'è stata creata la cartella

e poi, vengono introdotti alcuni gruppi particolari, creati con funzioni specifiche:

- Creator Owner, che non è un gruppo normale, che contiene degli utenti, bensì, è una versione speciale, che introduce, in maniera dinamica, il creatore della cartella, permettendogli dei privilegi superiori, rispetto alla norma, per quella cartella
- SYSTEM, che è, anch'esso, un gruppo speciale, il quale sta a significare le funzioni di sistema; rimuovendo questo gruppo, la cartella non è più accessibile

Implementando anche un pseudo-gruppo speciale "PROGRAMS", è possibile specificare l'accesso o l'interazione, con una cartella o una risorsa, solo a certi programmi, impedendone l'azione ad altri. In questo modo, un eventuale malware o attaccante, deve, o effettuare una Priviledge Escalation, raggiungendo un utente, in tutto l'ambiente operativo, che abbia diritto di accesso, oppure, è necessario agire effettuando un Code Injection o sfruttando un Buffer Overflow, entrambi colpendo i programmi dotati dei privilegi sufficienti. Ovviamente, in questo caso, entra in gioco l'azione congiunta del DEP e del Behavior Blocker, rendendo, il tutto, molto più difficile.
E' possibile, per un utente, blindare una cartella in modo più specifico, limitando, ad esempio, l'accesso, all'area ove son presenti i databases dell'AV, solo all'eseguibile stesso e al sistema (che ovviamente, deve poter aver sempre accesso, oppure niente funziona).

Riguardo i RootKits, l'unica è quella d'implementare, nel sistema, una versione standard di Integrity Checker, la quale, dovrebbe essere più che sufficiente nel garantire un
certo margine di monitoraggio, per l'amministratore, riguardo certi files di sistema.

Nei confronti delle email a pagamento, contro lo spam, direi che è una sciocchezza assurda, quella che stan adottando Yahoo! e amici di merende. Ho potuto notare che la presenza di un filter engine di spam, nei client email, non è molto comune.
Qualora i coders di ReactOS, abbiano intenzione d'introdurre una loro versione di OutLook Express, è bene:

1) Implementare, ASSOLUTAMENTE, un dispositivo di filtraggio, nel client, che permetta il riconoscimento e la cancellazione delle email, considerate come spam, direttamente da server, senza il bisogno di scaricare la posta (risparmiando banda e scocciature)
2) Interfaccia per il controllo, via scanner euristico/bayesiano e/o AV, delle email e degli allegati

folle_invasato
Posts: 134
Joined: Thu Jan 13, 2005 9:11 pm
Location: Pordenone, Italy

Post by folle_invasato »

Con la premessa che se ti sei preso una rootkit decente da un sistema live non puoi farci niente, te la tieni e basta. E' già tanto se ti accorgi di averla, credimi...

Cmq una cusriosità, anche i programmi che cercano di aggirare i software di protezione dei CD/DVD fanno uso di rootkit...

...ma anche nel mondo del DRM non si scherza. Vedi l'ormai famosissimo caso della Sony...

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

folle_invasato wrote:Con la premessa che se ti sei preso una rootkit decente da un sistema live non puoi farci niente, te la tieni e basta. E' già tanto se ti accorgi di averla, credimi...

Cmq una cusriosità, anche i programmi che cercano di aggirare i software di protezione dei CD/DVD fanno uso di rootkit...

...ma anche nel mondo del DRM non si scherza. Vedi l'ormai famosissimo caso della Sony...
Non dico che simili sistemi rimuovano, del tutto, il rischio. Semplicemente, servono ad arginarlo. Riguardo la storia del DRM e dei rootkit autoinstallanti, direi che è giunto il momento di arginare questo problema. Le major possono utilizzare dei sistemi di sicurezza meno invasivi e con il fritz chip hanno il tutto su un piatto d'argento. Ma questa corsa al cracking dei sistemi degli utenti, è, di per sè, una cosa vergognosa, che và bloccata. Poi facciano quel che vogliono, ma legalmente. Combattere l'illegalità, con l'illegalità, è come fottere per la verginità, un assurdo.

Post Reply

Who is online

Users browsing this forum: Yeti [Bot] and 0 guests