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.