Il software moderno vive sempre più online, utilizzando interfacce di programmazione dell’applicazione o API, per importare ed esporre dati, rimanere aggiornati e in generale lavorare in modo più efficace. Le API sono grandi acceleratori di attività con migliaia di usi, dal disegno di un file di ricette per un sito Web di cucina, al collegamento di un sistema di pagamento sicuro a un rivenditore online, all’aggiunta di funzionalità all’infrastruttura IT esistente.

Man mano che crescono in popolarità, tuttavia, si spostano anche nel mirino dei cattivi attori, diventando un nuovo obiettivo per le minacce alla sicurezza.

Non è un problema quando sono gestiti e configurati correttamente (in realtà, sono una parte importante di un solido livello di sicurezza aziendale). Il problema è proprio che quasi tutte le aziende ora devono vivere online, utilizzando le API esistenti all’interno e all’esterno del firewall aziendale. Ciò significa che i vecchi tempi di mettere un perimetro sicuro attorno alle risorse IT sono finiti. Agire come se non lo fossero è la vera minaccia.

In che modo le organizzazioni possono utilizzare moderne tecniche di sviluppo basate su API per alimentare le proprie attività mantenendo al sicuro l’ambiente? Passando da un modello perimetrale di rete a qualcosa che applica sicurezza e protezione in ogni punto di interazione. Ecco cinque importanti tecniche per aiutare.

1. Equilibrare la protezione con facilità di accesso 

La migliore sicurezza è bloccare tutto senza dare alcun accesso. Tuttavia, affinché le API forniscano valore aziendale, devono accedere a informazioni e funzionalità utili, come i dati dei clienti, le informazioni di inventario e le applicazioni legacy. Ciò significa che ogni API è un potenziale punto di accesso che deve essere protetto.

Il trucco è mantenere le API sicure lasciando che le persone che costruiscono esperienze digitali con loro si muovano il più rapidamente possibile, evitando politiche pesanti e un accesso altamente restrittivo che possa far deragliare l’innovazione.

La risposta sono gli strumenti di gestione delle API, che possono mediare l’accesso alle API, monitorarne l’utilizzo e automatizzare l’iscrizione, l’onboarding, l’autenticazione e l’istruzione degli sviluppatori. Tuttavia, è ancora troppo comune per le aziende applicare queste precauzioni solo ad alcune delle loro API. Ciò può essere dovuto a una serie di motivi, tra cui la governance irregolare delle API, le scorciatoie adottate per raggiungere scadenze di sprint aggressive, la convinzione che le API su misura non destinate al riutilizzo non richiedano la gestione o una combinazione di molti altri scenari possibili. Sebbene comprensibile, è come mettere delle serrature su alcune finestre, lasciando le porte spalancate. Tutte le API dovrebbero essere protette, il che significa che tutte le API dovrebbero essere gestite.

2. Autenticare gli utenti giusti 

Le API adeguatamente protette dovrebbero fornire l’autenticazione sia per gli utenti finali che per le applicazioni. Lo standard aperto di fatto per la sicurezza API, chiamato OAuth, consente l’autenticazione e l’autorizzazione basate su token. Ciò consente agli utenti finali e alle applicazioni di ottenere il giusto livello di accesso a una risorsa protetta senza richiedere all’utente di rivelare le proprie credenziali di accesso. OAuth consente a un client che effettua una chiamata API di scambiare alcune credenziali per un token, il che consente al client di accedere all’API.

OAuth utilizza un token che identifica in modo univoco una singola applicazione o utente su un singolo dispositivo, mantenendo segrete le password. I token hanno portata; sono un meccanismo per limitare l’accesso di un’applicazione all’account di un utente. È molto meglio che usare una password con ampio accesso. Inoltre, l’ambito e la durata del token stesso possono essere facilmente limitati. È un’ottima soluzione, ma per essere sicuri, i team API devono avere familiarità con le capacità di OAuth e le migliori pratiche di autenticazione correnti.

Il monitoraggio delle API e altre funzionalità di gestione aiutano anche a proteggere le API. Ad esempio, alcune aziende applicano funzionalità come il controllo degli accessi in base al ruolo (RBAC), che assegna diversi livelli di accesso API e privilegi in base ai tipi di utenti integrati.

3. Mantenere il controllo con un’efficace gestione del traffico

Qualsiasi API potrebbe essere soggetta ad un attacco di brute force in qualsiasi momento. I cattivi potrebbero utilizzare un software automatizzato per generare un gran numero di ipotesi consecutive nel tentativo di ottenere l’accesso ai dati protetti o mettere a dura prova i back-end invocando le API a un throughput oltre a quello per cui sono state distribuite. Tali attacchi sono probabilmente inevitabili per le imprese digitali di successo: in un certo senso, sono i costi per fare affari. Pertanto, i team API dovrebbero sempre considerare l’utilizzo di limiti e quote per ulteriore sicurezza API.

Quando si verificano questi attacchi, i limiti di accesso e le quote ti aiutano a mantenere il controllo delle risorse digitali della tua organizzazione e proteggere le esperienze e la privacy dei tuoi clienti. Le piattaforme di gestione API che supportano i limiti di velocità consentono ai team API di stabilire soglie alle quali vengono attivati ​​gli spike arresti, contribuendo a evitare che i back-end vengano colpiti da attività impreviste. Ad esempio, un team API potrebbe stabilire che nessuno dovrebbe chiamare un’API più di 500 volte al secondo o che a un’applicazione è assegnato solo un determinato numero di chiamate API al giorno.

4. Generare approfondimenti tramite analisi e monitoraggio

Le esperienze connesse uniscono risorse digitali che potrebbero essere effettivamente distribuite in una vasta gamma di aree geografiche, cloud pubblici e privati ​​e provider di API. Un obiettivo di un’efficace gestione e sicurezza delle API è controllare questa architettura distribuita in modo unificato.

L’integrità di un programma API si basa spesso su effettivi handoff tra team di sicurezza e operativi. Se le capacità di reporting non possono essere chiaramente dimostrate quando una situazione richiede una squadra rispetto all’altra, può essere difficile facilitare un’efficace collaborazione di sicurezza.

Ciò rende importante valutare non solo se una piattaforma di gestione API fornisce funzionalità di monitoraggio e analisi, ma anche se l’integrazione di queste funzionalità acceleri effettivamente le soluzioni ai problemi aziendali.

A livello di funzionalità, ciò significa che report e dashboard efficaci dovrebbero fornire informazioni a colpo d’occhio, nonché la possibilità di eseguire il drill down per dettagli più dettagliati. Dovrebbe essere semplice vedere i cambiamenti nel traffico, anche di giorno in giorno, di settimana in settimana e così via; visualizzare gli schemi nei periodi di tempo scelti; accedere alle informazioni sulla gestione dei cambiamenti e sui dati di governance; e visualizzare i dati di configurazione dei criteri su base per API e per proxy.

5. Non dimenticare le basi

Proprio come nei giorni di sicurezza del firewall, condurre codice e revisioni della sicurezza aumenta la probabilità di trovare vulnerabilità prima che colpiscano i clienti. Aiuta anche a garantire che i difetti di sicurezza prodotti in una parte di un programma API siano documentati e non vengano ripetuti altrove. 

I professionisti IT dovrebbero anche essere consapevoli del fatto che molti utili utenti API hanno riscontrato molti problemi di sicurezza. Un’altra best practice, quindi, è quella di stabilire canali per gli utenti per segnalare problemi, disporre di un programma per sviluppare correzioni e portarle in produzione e verificare con la persona che ha presentato il bug per confermare che il problema è stato veramente risolto.

Andando avanti

Nel mondo complesso di oggi, i perimetri di rete non contengono più tutte le esperienze e le interazioni che guidano il business. Per tenere conto di questo cambiamento fondamentale, le aziende dovrebbero considerare ogni API come un potenziale punto di leva aziendale e un possibile punto di vulnerabilità. Fatto bene, un’azienda può diventare ancora più sicura di quanto non fosse quando si nascondeva dietro un firewall e sperava nel meglio. 

Il fatto che i criminali possano attaccare la tua rete aziendale attraverso le tue stampanti è sia noto che ben documentato. Ciò che è meno certo è quanto attivamente i dipartimenti IT si proteggano dalla minaccia, specialmente nelle piccole imprese. Ecco perché vale sempre la pena verificare di aver messo in atto le misure giuste.

Alcuni di questi passaggi saranno comuni a tutte le stampanti, mentre altri potrebbero essere rilevanti solo per le stampanti per gruppi di lavoro. Alcuni potrebbero essere supportati solo da stampanti e dispositivi multifunzione specifici, mentre altri potrebbero richiedere software o hardware aggiuntivo.

Passaggio 1: applicare gli ultimi aggiornamenti del firmware

Ogni produttore di stampanti aggiorna il suo firmware sulle stampanti a seguito di qualsiasi vulnerabilità rilevata, quindi assicurati di scaricare l’ultima versione dal sito Web del produttore. Può contenere correzioni per gravi problemi di sicurezza o nuove funzionalità che potrebbero rendere le tue stampanti più sicure.

Naturalmente, se hai molte stampanti, questo diventa una spesa, motivo per cui il passaggio 2 può essere utile.

Passaggio 2: strumenti di amministrazione per semplificare la sicurezza della stampante

Uno dei motivi per cui gli amministratori IT non aggiornano frequentemente i dati delle loro stampanti è che per ognuna va fatta una installazione a parte. Ma c’è una soluzione a tutto. Esistono molti tool, tra cui quello della Hp, che aiutano le imprese a gestire aggiornamenti di massa. E’ un ottimo punto di partenza.

Passaggio 3: controllare gli indirizzi IP delle stampanti

Per impostazione predefinita, è possibile che la stampante disponga di un indirizzo IP esterno; a meno che non ci sia un ottimo motivo per mantenerlo in questo modo, passa a un indirizzo IP interno. Per maggiore sicurezza, considerare la possibilità di limitare l’accesso a una LAN o sottorete specifica.

Passaggio 4: utilizzare il PIN o il badge

Molte moderne stampanti aziendali includono un sistema PIN e ti consigliamo di applicarlo. Consentendo ai dipendenti di inserire fisicamente un PIN sulla stampante per iniziare il loro lavoro di stampa, ti assicurerai immediatamente che i documenti riservati non vengano lasciati sul vassoio di uscita. Significa anche molte meno pagine sprecate, poiché gli utenti dimenticano di aver stampato qualcosa e lo hanno lasciato lì, oppure lo stampano una seconda volta per errore.

Se i tuoi dipendenti usano già i badge di sicurezza, allora una politica “solo badge” ha molto senso. È esattamente la stessa idea di richiedere un PIN, ma un utente deve scorrere il proprio badge su un pad dedicato situato sulla stampante per autorizzare il lavoro di stampa.

Passaggio 5: assicurarsi che il disco rigido della stampante sia crittografato

Questo è semplice ma spesso dimenticato. Significa che anche se qualcuno prende il disco, i tuoi dati sono al sicuro, ma è anche una buona protezione a lungo termine, nel caso in cui la stampante venga passata a un rivenditore e lasci accidentalmente informazioni riservate sull’unità. Il modo più semplice per mettere al sicuro il disco rigido della stampante? Semplice: verificare che sia crittografato al momento dell’acquisto. Come ultimo passo, assicurati di cancellare professionalmente il tuo disco rigido se vendi o rottami la stampante.

Passaggio 6: assicurarsi che la stampa remota sia sicura

È possibile che per impostazione predefinita siano attivi protocolli e servizi di accesso remoto poco sicuri. In tal caso, vanno disabilitati. Tutti desideriamo che i dipendenti o collaboratori possano stampare da telefoni, tablet e laptop, ma utilizzando formati sicuri come la stampa diretta wireless o il touch-to-print NFC. 

Passaggio 7: crittografare le linee di comunicazione

Se si desidera amministrare una stampante via Web, abilitare SSL per assicurarsi che tutte le comunicazioni avvengano tramite https. È anche una precauzione ragionevole evitare che ficcanaso intercettino lavori di stampa riservati crittografando i dati in transito. 

VUOI UN CONSIGLIO SU COME METTERE IN
SICUREZZA LE TUE STAMPANTI?

CONTATTACI

Passaggio 8: sostituire le stampanti meno recenti

Le stampanti hanno comunicazioni wireless ormai da tanti anni. Ma le prime versioni di ogni stampante esistente non aveva dentro di se nemmeno le possibilità tecniche di assicurare la riservatezza dei dati. Per questo motivo, aggiornare il parco stampanti di un ufficio è una cosa da non sottovalutare.

Nel frattempo, il rilevamento delle intrusioni in fase di runtime aiuta a proteggere le stampanti dagli attacchi quando vengono accese, cercando le anomalie nella memoria o nel firmware che sono le caratteristiche di una minaccia. In breve, più vecchia è la tua stampante, meno è probabile che sia sicura. Inoltre beneficerai di una stampante più silenziosa, più veloce e di migliore qualità se esegui l’aggiornamento.

Passaggio 9: applicare un criterio “svuota vassoio”

È incredibile quanti documenti stampati siano abbandonati sul vassoio di uscita a volte con informazioni riservate, spesso sui propri dipendenti. Sottolineando una politica in base alla quale se lo stampi, lo raccogli, ridurrai questo rischio.

Un modo per farlo è abilitare la stampa pull, in questo modo i lavori di stampa vengono eseguiti solo se autenticati nella stampante. L’autenticazione potrebbe comportare solo la digitazione di un codice PIN (vedere il passaggio 4) o potrebbe implicare la sicurezza biometrica, una smart card o altri token fisici. Ciò garantisce che solo coloro che avviano e quindi autenticano un lavoro di stampa possano ritirarlo dal vassoio di uscita.

Passaggio 10: semplificare la distruzione dei documenti

Se è molto più facile per le persone mettere documenti sensibili nel cestino piuttosto che nel distruggi documenti, lo faranno. Anche se potresti non desiderare un distruggi documenti accanto a ogni stampante, assicurati che i dipendenti sappiano dove trovare la trinciatrice più vicina. E sappiamo poi che il fatto che ci sia una distruggi documenti non da come conseguenza il fatto che la usino, anzi. Quindi è possibile anche pensare di togliere fisicamente i cestini oppure di arrivare a creare delle sanzioni per chi butta documenti stampati nei cestini.

Passaggio 11: proteggere le porte

Molte stampanti consentono di inoltrare i lavori alla coda di stampa tramite porte SMTP, FTP, Telenet e USB. Sfortunatamente, gli stessi protocolli e le porte di rete utilizzate possono essere utilizzati dagli aggressori come mezzo per recuperare documenti e informazioni. Se non sono necessari, disabilitarli utilizzando l’interfaccia di gestione Web per ridurre il potenziale di attacco. 

VUOI UN CONSIGLIO SU COME METTERE IN
SICUREZZA LE TUE STAMPANTI?

CONTATTACI

Quando si accetta un input esterno, un’applicazione deve allocare memoria per archiviare tale input. Molti linguaggi di programmazione di alto livello lo faranno dietro le quinte, ma alcuni linguaggi (come C / C ++) consentono al programmatore di allocare memoria direttamente tramite funzioni come malloc.

Si verifica una vulnerabilità di buffer overflow quando l’applicazione tenta di archiviare più dati nella memoria allocata di quanto non vi sia spazio disponibile. Ciò può verificarsi per vari motivi, tra cui:

• Impossibilità a controllare la lunghezza dell’input durante la lettura
• Essersi dimenticati di allocare spazio per il terminatore null
• Lunghezze di input che causano un overflow di numeri interi

Indipendentemente dal motivo, se un’applicazione tenta di scrivere nella memoria oltre l’intervallo del buffer allocato significa che sta scrivendo nella memoria allocata per altri scopi all’interno dell’applicazione. A causa della struttura di come la memoria viene allocata all’interno di un computer, questo può essere estremamente utile per un utente malintenzionato poiché consente di controllare l’esecuzione del programma.

Sfruttamento del buffer overflow

Lo sfruttamento di una vulnerabilità di overflow del buffer è abbastanza semplice. Se un programma alloca in modo errato la memoria per l’input dell’utente o legge in modo non sicuro i dati in quello spazio di memoria, esiste una vulnerabilità. Questa vulnerabilità può essere sfruttata da un hacker semplicemente fornendo un input all’applicazione più grande di quanto il buffer allocato sia in grado di contenere.

Il travaso di un buffer con input insignificanti o casuali può causare semplicemente un errore di segmentazione o un errore nel programma. Tuttavia, la struttura dello stack porta a che un exploit buffer ben progettato può fare molto di più, consentendo a un utente malintenzionato di controllare il flusso di esecuzione ed eseguire codice dannoso sul sistema.

Lo stack

Un’applicazione può allocare memoria nello stack o nell’heap. Lo stack viene comunemente utilizzato per argomenti di funzione e variabili locali e l’heap memorizza la memoria dinamica (allocata utilizzando il nuovo comando in C ++). Sia lo stack che l’heap possono essere sfruttati da un attacco di buffer overflow, ma la struttura dello stack lo rende estremamente delicato.

Come suggerisce il nome, lo stack è organizzato come uno stack di memoria. Lo stack cresce da indirizzi di memoria elevati a indirizzi inferiori. La posizione corrente nello stack è indicata da una variabile (il puntatore dello stack) che punta alla parte superiore dello stack corrente. Man mano che i dati vengono aggiunti o rimossi dallo stack, anche il puntatore dello stack viene aggiornato.

Quando una funzione viene chiamata da un’altra funzione, le informazioni vengono inviate nello stack per fornire a quella funzione i dati che deve eseguire. Questi dati vengono inseriti nello stack nel seguente ordine:

1. Argomenti della funzione chiamata (in ordine inverso)
2. L’indirizzo dell’istruzione successiva dopo la funzione chiamata ritorna
3. Variabili locali della funzione chiamata

In genere, l’input dell’utente a una funzione verrà archiviato in una variabile locale, il che significa che verrà inserito nello spazio di memoria direttamente sopra l’indirizzo di ritorno nello stack. Ciò è utile per un utente malintenzionato che esegue un buffer overflow, poiché la memoria che verrà sovrascritta da un buffer overflow è il puntatore all’istruzione successiva da eseguire.

Programmazione orientata al ritorno (ROP)

Il fatto che un utente malintenzionato possa sovrascrivere l’indirizzo di ritorno di una funzione nello stack è la base per la programmazione orientata al ritorno (ROP). In ROP, un utente malintenzionato tenta di sfruttare un overflow del buffer che causa il ritorno della funzione vulnerabile in un’area del programma sotto il controllo dell’attaccante.

Quest’area può essere lo stesso buffer riempito durante l’attacco o un’altra area controllata dall’utente. Se ha esito positivo, l’utente malintenzionato potrebbe essere in grado di guidare l’applicazione a interpretare l’input fornito come istruzioni del programma, consentendo all’utente malintenzionato di eseguire codice dannoso.

Una delle principali sfide di ROP è lo sviluppo di codice che fa ciò che l’attaccante vuole in uno spazio limitato. Per questo motivo, il codice generalmente cerca di chiamare funzioni di libreria che sono già all’interno dello spazio di memoria del processo per abbreviare il codice necessario. Alcune mitigazioni contro ROP si concentrano sul rendere questa funzionalità più difficile da localizzare ed eseguire per lo shellcode.

Mitigazioni del buffer overflow

Lo sfruttamento del buffer overflow può rappresentare una grave minaccia per la sicurezza poiché il codice ROP inserito ed eseguito dall’attaccante viene eseguito con gli stessi privilegi dell’applicazione sfruttata. Tuttavia, esistono diversi mezzi per prevenire o mitigare gli attacchi di buffer overflow.

Protezioni dello stack

L’obiettivo primario di un exploit buffer overflow è consentire all’attaccante di eseguire codice arbitrario tramite una programmazione orientata al ritorno. Diverse soluzioni sono state implementate per aiutare a proteggere contro il POR.

Stack canaries

Affinché ROP sia possibile nello stack, l’utente malintenzionato deve essere in grado di riscrivere un indirizzo di ritorno della funzione per puntare a una regione di memoria sotto il loro controllo. Il concetto è stato inventato per aiutare a rilevare e prevenire questo. 

Uno stack canary è un valore noto al programma che viene inserito prima dell’indirizzo di ritorno nello stack. Prima che ritorni una funzione, viene verificato il valore del canary e viene generato un errore se non è corretto (indicando che si è verificato un attacco di overflow del buffer).

Prevenzione dell’esecuzione dei dati

La programmazione orientata al ritorno si basa sull’input dell’utente interpretato dal programma per essere interpretato come dati da interpretare come codice. Ciò è possibile perché i dati e le informazioni di controllo sono spesso intrecciati nello stack senza confini chiari.

Data Execution Prevention (DEP) contrassegna alcune aree della memoria come non eseguibili. Questo aiuta a proteggere dal buffer overflow poiché, anche se l’attaccante può modificare un indirizzo di ritorno per puntare al proprio shellcode, non verrà eseguito dal programma. Tuttavia, DEP può essere aggirato da un attacco return-to-libc, rendendo necessaria la randomizzazione del layout dello spazio degli indirizzi (ALSR).

Randomizzazione del layout dello spazio degli indirizzi

La maggior parte delle applicazioni sono progettate per essere orientate agli oggetti, con applicazioni che fanno un uso pesante di librerie condivise che importano nel loro spazio di memoria. Mentre le funzioni di queste librerie condivise sono utili per legittimare il codice, sono utili anche per ROP.

La randomizzazione del layout dello spazio degli indirizzi (ASLR) è progettata per rendere più difficile per un utente malintenzionato trovare le funzioni di libreria di cui ha bisogno. Invece di importare le funzioni di libreria per impostare gli indirizzi in ogni applicazione, ASLR randomizza dove verrà importata una particolare libreria. Ciò rende il POR più difficile, poiché l’aggressore deve trovare una libreria in memoria prima di poter utilizzare le sue funzioni.

Convalida dell’input

Gli attacchi di buffer overflow sono causati quando un utente malintenzionato scrive più dati su un blocco di memoria rispetto allo spazio allocato dall’applicazione per tali dati. Ciò è possibile per una serie di motivi, ma il più comune è l’uso di letture illimitate che leggono fino a quando non viene trovato un terminatore nullo sull’input. Utilizzando letture a lunghezza fissa progettate per adattarsi allo spazio buffer allocato, un’applicazione può essere resa immune dagli attacchi di buffer overflow.

Controllo di overflow dell’intero

I buffer overflow possono anche essere abilitati da vulnerabilità di overflow dei numeri interi. Ciò si verifica quando la lunghezza del valore memorizzato in una variabile è maggiore di quella che la variabile può contenere, causando la caduta dei bit più significativi che non si adattano. Di conseguenza, un input molto grande può essere interpretato come avente una lunghezza più breve a causa di un overflow, causando il dimensionamento del buffer allocato. 

Il controllo degli overflow dei numeri interi nelle lunghezze di input è importante per la protezione dagli attacchi del buffer overflow.

Librerie standard

Mentre C ++ consente a uno sviluppatore di allocare manualmente la memoria per l’input dell’utente, ciò non significa che sia sempre una buona idea farlo. La libreria di modelli standard C ++ (STL) ha funzioni (come le stringhe) che gestiscono correttamente la gestione della memoria dietro le quinte. Il passaggio è un modo semplice per mitigare la minaccia di vulnerabilità di buffer overflow.

Buffer overflow per l’hacking etico

I buffer overflow sono una semplice vulnerabilità che può essere facilmente sfruttata ma anche risolta facilmente. Tuttavia, anche oggi, il software contiene vulnerabilità sfruttabili di buffer overflow. Nell’ottobre 2018, in Whatsapp è stata scoperta una vulnerabilità di buffer overflow che ha consentito l’uso della vulnerabilità se un utente aveva appena risposto a una chiamata o una videochiamata. 

Queste vulnerabilità meritano sicuramente una verifica quando si esegue un hack etico e devono essere corrette nel codice il più rapidamente possibile.

Un rootkit è semplicemente un insieme di strumenti in grado di procurare e mantenere l’accesso privilegiato di root a un sistema operativo. Un rootkit malware di solito trasporta un codice/software dannoso che viene distribuito segretamente nel sistema di destinazione.

Per mantenere l’accesso backdoor per il malware, i rootkit possono sfruttare i processi del sistema in background a vari livelli di privilegi. In un sistema Windows, questo di solito significa attaccare in modalità utente o kernel.

L’importanza di comprendere il vettore di attacco

Contrariamente alla percezione popolare, un rootkit non compromette la sicurezza del sistema da solo. La penetrazione delle difese di un sistema operativo è gestita dal metodo impiegato per infettare il sistema. Ci sono molti modi per farlo oggi:

• Invio di un file infetto / Trojan come allegati di posta elettronica
• Creazione di app malware mascherate da banner / pop-up innocui sui siti Web
• L’uso di attacchi di phishing e altri malware come i keylogger offrono agli attacker l’accesso root, che può quindi essere utilizzato per iniettare il rootkit

Un rootkit inizia il suo lavoro una volta che il vettore ha compromesso con successo il sistema, dandogli la possibilità di entrare in modalità privilegiate di root all’interno del sistema operativo. Una volta ottenuto l’accesso, a seconda del luogo del suo attacco, un rootkit può cambiare il software installato o anche parti del sistema operativo stesso. Ciò può rendere difficile da rilevare un’infezione da rootkit o persino praticamente invisibile.

Comprensione della posizione di un rootkit nel sistema operativo

Windows ha due modalità per l’esecuzione del codice: la modalità utente e la modalità kernel. Di questi, la modalità kernel è la più importante, in quanto funge da collegamento diretto tra il codice hardware e software. Questa è la modalità con privilegi più alti , o “root” in un sistema Windows.

Ma non tutti i programmi e i processi richiedono l’accesso all’intera gamma di potenza di elaborazione e hardware di sistema. Queste funzioni di livello inferiore sono gestite in una modalità con privilegi inferiori: la modalità utente.

In modalità kernel, il sistema operativo esegue i codici direttamente per eseguire tutte le attività di alto livello di gestione del sistema. Al contrario, la modalità utente utilizza un’API (Application Programming Interface) per eseguire indirettamente i codici. Durante il normale funzionamento del sistema, l’API esegue chiamate di funzione al kernel e riceve informazioni in cambio.

Un rootkit di solito dirotta queste chiamate di funzione, sia in modalità utente che in modalità kernel, a seconda del suo design.

Rootkit in modalità utente e iniezione DLL

In Windows, l’aggancio delle API è una tecnica comunemente utilizzata per modificare o cambiare il flusso delle chiamate API. Un rootkit in modalità utente sfrutta questa tecnica per iniettare codice dannoso nella memoria di un programma rimanendo nascosto. 

Perché questo funzioni, il rootkit deve inserire il suo codice in un processo comunemente usato. In Windows, le librerie Dynamic Link (DLL) sono perfette per questo, poiché sono chiamate da molti programmi diversi installati nel sistema operativo. 

L’iniezione DLL è il metodo utilizzato dall’utente rootkit (hacker) per inserire codice dannoso in vari programmi che eseguono chiamate API nel sistema operativo. Esistono diversi modi per raggiungere questo obiettivo:

• Modifica dei valori di registro per aggiungere una nuova DLL dannosa al sistema Windows
• Utilizzo dell’aggancio globale in Windows per influire su tutte le chiamate API del programma
• Creando un thread remoto per il processo di destinazione per aggiungere ad esso DLL infetta

Aggancio IAT contro aggancio in linea

Il principale punto debole di un rootkit a livello di utente è che manca l’accesso diretto al kernel del sistema operativo. Quindi usano API che aggancia un exploit. Ci sono due diverse tecniche spesso utilizzate qui: l’aggancio IAT e l’aggancio in linea.

In Windows, una IAT (Import Address Table) viene utilizzata per semplificare l’accesso alle DLL con i loro indirizzi di funzioni variabili. Lo IAT ospita i puntatori a funzione delle DLL quando vengono caricati dal caricatore di Windows durante una chiamata API.

Utilizzando l’aggancio IAT, un rootkit può apportare modifiche all’elenco delle chiamate delle funzioni DLL, sostituendo le funzioni esistenti con il proprio indirizzo. Quando un’applicazione effettua una chiamata API per quella funzione, il codice rootkit viene caricato invece nello spazio di memoria del programma vittima.

Al contrario, l’aggancio in linea modifica direttamente i codici funzione di programmi specifici. Questo è un approccio più mirato e ristretto rispetto all’aggancio IAT. Ma come l’aggancio IAT, l’obiettivo qui è quello di far caricare le chiamate API del programma dal codice dannoso dall’indirizzo rootkit.

Rootkit in modalità kernel e tecniche di aggancio

L’uso dell’iniezione DLL rende relativamente più facile rilevare un’infezione da rootkit in modalità utente. Ma i rootkit in modalità kernel sono del tutto diversi. Si trova allo stesso livello della maggior parte dei software di rilevamento malware e può eludere il rilevamento alterando parti del codice del kernel stesso.

Un rootkit in modalità kernel può apportare modifiche al sistema usando diverse tecniche di aggancio. Questi includono:

Aggancio SSDT

In Windows, le chiamate di sistema al kernel sono gestite secondo la tabella di invio del servizio di sistema o SSDT. Questa tabella contiene gli indirizzi di memoria importanti delle funzioni principali chiamate. Se un rootkit ottiene l’accesso al kernel, può apportare modifiche all’SSDT, con risultati simili a quelli dell’aggancio IAT. 

Aggancio IDT

La modalità kernel di Windows contiene anche una tabella descrittore di interrupt (IDT) per gestire eventuali interruzioni causate da un software o hardware. Un semplice esempio potrebbe essere un interrupt di processo causato dalla tastiera. Un rootkit può utilizzare l’hook IDT per raccogliere informazioni importanti, compresi i dati della tastiera. 

Aggancio della funzione in linea

I rootkit del kernel possono anche usare hook non correlati alle tabelle di sistema. Nell’aggancio in linea, il codice dannoso attacca parti specifiche di una funzione di destinazione nel kernel, costringendolo a passare a un’area specifica nella memoria di sistema contenente il codice rootkit. 

Key takeaway

• I rootkit usano molti diversi vettori e tecniche di attacco per compromettere la sicurezza di un sistema e infettarlo
• I rootkit funzionano dirottando o collegando le chiamate di funzione API in un sistema operativo
• In Windows, possono farlo a Ring-3 (livello utente) e Ring-0 (livello kernel)
• I rootkit a livello di utente spesso usano l’iniezione DLL per aggiungere codice dannoso alle applicazioni
• A livello di kernel, abusano delle chiamate di funzione SSDT e IDT per apportare modifiche

Meccanismi di rilevazione

Il rilevamento di rootkit è considerato un problema complicato nella sicurezza dei computer, ma dipende anche dal livello di programmazione in ciascun caso particolare. Come in altri meccanismi di rilevamento del malware, vengono utilizzate tecniche basate su firma e comportamento. Altre tecniche utilizzate per il rilevamento dei rootkit sono l’analisi basata sulla diff e i controlli di integrità. Non esiste un’unica applicazione in grado di rilevare e rimuovere tutti i tipi di rootkit in quanto l’area in cui potrebbero risiedere potrebbe essere completamente diversa, software o hardware. Nella maggior parte dei casi, un rootkit può essere rimosso solo ricostruendo il sistema compromesso.

• Basato su firma

Questa è la tecnica più comune per il rilevamento di malware. Tuttavia, è il meno efficiente in quanto è efficace solo per rootkit già rilevati e diffusi. Le firme dei rootkit noti vengono utilizzate per rilevare se ne esiste una su un sistema.

• Basato sul comportamento

Questi rilevatori identificano un comportamento anomalo su un sistema informatico basato su euristica e schemi comportamentali. Questi schemi sono derivati ​​da alcune attività che si trovano tipicamente nei rootkit. Il vantaggio della tecnica basata sul comportamento rispetto alla precedente è che può rilevare rootkit precedentemente sconosciuti.

• Visualizzazione basata su diff / croce

L’approccio Diff-Based o Cross view viene utilizzato principalmente per rilevare rootkit in modalità kernel confrontando due diverse visualizzazioni del sistema per le stesse informazioni attraversando le strutture di dati. In questo caso, il rilevatore di rootkit otterrà una vista del sistema e una vista ottenuta dalle utilità di sistema e quindi li confronterà. Una differenza nei risultati restituiti dai due approcci segnala la presenza di un rootkit.

• Verifica dell’integrità

I controlli di integrità possono essere eseguiti in un sistema per verificare l’alterazione del codice non autorizzata nei file di sistema. Innanzitutto, è necessario eseguire una funzione unidirezionale per calcolare un hash per ogni file di sistema quando il sistema è ancora pulito e quindi utilizzarlo come base. Quando sorge la necessità, viene eseguito un confronto hash tra gli hash di base e gli hash della versione corrente.

Il cloud computing si sta evolvendo da un’opzione praticabile per fornire servizi IT allo standard di fatto. Secondo il rapporto “Public Cloud Trends” del 2019 , dell’Enterprise Strategy Group (ESG), l’utilizzo di ambienti infrastrutturali come servizio è aumentato negli ultimi otto anni, dal 17% delle organizzazioni al 58%, e il 39% delle organizzazioni afferma di avere una mentalità cloud-first per tutte le loro implementazioni tecnologiche.

È sicuramente un vantaggio per l’innovazione, ma le organizzazioni di sicurezza continuano a lottare per stare al passo con i costanti cambiamenti nella tecnologia cloud, nell’architettura e nei casi d’uso. Molte delle maggiori sfide che devono affrontare hanno a che fare con la visibilità. In un recente rapporto di Cloud Security Alliance, tre quarti delle aziende con risorse nel cloud pubblico hanno indicato la mancanza di visibilità come una grande sfida.

Ecco alcuni dei più grandi punti critici di sicurezza del cloud.

Servizi IT gestito dall’azienda

Dimentica “shadow IT” o “rogue IT”. I modelli di acquisto di tecnologia che hanno parti interessate della linea di business che acquistano e gestiscono risorse cloud sono ora indicati in modo incondizionato come “IT gestito dal business” da molte organizzazioni che lo vedono come un motore per l’innovazione. Otre i due terzi delle aziende incoraggiano o consentono l’IT gestito dall’azienda. Questo perché le aziende che lo fanno hanno il 52% in più di probabilità di battere i concorrenti sul mercato e il 38% in più di fornire un’esperienza positiva ai dipendenti.

Il problema è che senza la collaborazione dei professionisti IT e della sicurezza informatica, questi silos di tecnologia cloud possono diventare enormi punti ciechi di sicurezza per le organizzazioni. Queste stesse organizzazioni innovano più rapidamente, ma hanno il doppio delle probabilità di avere più aree di esposizione al rischio di sicurezza.

Errata configurazione del cloud

La configurazione errata di Internet-as-a-service (IaaS) e degli archivi di dati cloud è la causa principale di alcune delle violazioni del cloud e dei furti di dati più dannose. Che si tratti di disattivare le impostazioni di sicurezza predefinite standardizzate dai provider cloud, utilizzare password predefinite, consentire l’accesso illimitato a determinati servizi o qualcos’altro, i problemi di configurazione errata introducono una serie di rischi nascosti che vengono spesso scoperti solo dopo aver subito un furto. Circa il 40% delle organizzazioni afferma che l’errata configurazione delle piattaforme cloud è la principale preoccupazione per la sicurezza informatica.

Architettura ibrida

Secondo un recente rapporto della Cloud Security Alliance, circa il 55% delle organizzazioni gestisce ambienti di cloud computing complessi che operano con un’architettura ibrida. Tale configurazione offre un ottimo modo per le grandi organizzazioni di passare gradualmente al cloud, ma introduce sfide di sicurezza proprio mentre le aziende lottano per tenere traccia delle risorse nell’intera architettura e monitorare l’attività attraverso una complessa miriade di connessioni cloud ibride. In effetti, un rapporto pubblicato all’inizio di quest’anno da Firemon mostra che l’80% delle organizzazioni ha gravi problemi data la complessità degli strumenti utilizzati per monitorare e gestire la sicurezza in ambienti ibridi.

Acquisti multicloud

Le aziende sono impegnate in acquisti multicloud, utilizzando ambienti cloud da numerosi fornitori. Circa il 66% delle organizzazioni ha un ambiente multicloud e circa il 36% fa affidamento su una combinazione di tecnologie multicloud e ibride.

Ciò confonde ulteriormente le cose per i professionisti della sicurezza. “Il problema per i professionisti della sicurezza è che i modelli e i controlli di sicurezza variano ampiamente tra i fornitori, sono spesso scarsamente documentati e sono completamente incompatibili“, ha scritto Rich Mogull, analista di Securosis e vicepresidente di cloud DisruptOps. “Chiunque ti dica di poter cogliere queste sfumature in poche settimane o mesi con un paio di lezioni di formazione sta mentendo o ignorando. Ci vogliono anni di esperienza pratica per capire davvero i dettagli della sicurezza di un fornitore di cloud. “

Dark Data

I dati non classificati e non gestiti – noti anche come “dati oscuri” – rappresentano oggi un grosso problema per la maggior parte delle aziende, che si tratti di dati locali o nel cloud. Le aziende fanno fatica a proteggere i dati non classificati a causa del fatto che non possono proteggere risorse di cui non sono a conoscenza. Secondo un recente sondaggio condotto da Vanson Bourne per Veritas, i dark data sono particolarmente pericolosi negli ambienti di cloud pubblico, in cui tre aziende su cinque affermano di aver classificato meno della metà dei loro dati di cloud pubblico.

Telemetria forense e ricerca delle minacce

Alcuni dei più grandi punti ciechi che i team di sicurezza stanno combattendo oggi sono legati alla telemetria forense e la ricerca delle minacce. Le organizzazioni non solo lottano per ottenere le giuste informazioni da tutte le loro diverse risorse cloud, ma anche quando riescono a farlo affrontano una dura battaglia. Il solo consolidamento di tali dati e la correlazione con la telemetria locale diventa il suo incubo, una forma di cecità multidashboard per la risposta agli incidenti e alle minacce.

Secondo il SANS Institute, oltre la metà delle pmi ha riscontrato problemi nel reperire registri e informazioni di sistema di basso livello per i servizi forensi dai propri fornitori di servizi cloud e meno di una organizzazione su tre è stata in grado di integrare gli strumenti forensi e di risposta agli incidenti che usano all’interno con i loro ambienti cloud pubblici.