Docsity
Docsity

Prepara i tuoi esami
Prepara i tuoi esami

Studia grazie alle numerose risorse presenti su Docsity


Ottieni i punti per scaricare
Ottieni i punti per scaricare

Guadagna punti aiutando altri studenti oppure acquistali con un piano Premium


Guide e consigli
Guide e consigli


Vulnerabilità attacchi e contromisure, Traduzioni di Sicurezza delle reti

Traduzione delle slide del corso di Sicurezza delle Reti dell'Università di Pisa, con eventuali approfondimenti

Tipologia: Traduzioni

2018/2019

Caricato il 28/02/2019

maurizius7
maurizius7 🇮🇹

5

(1)

21 documenti

1 / 12

Toggle sidebar

Questa pagina non è visibile nell’anteprima

Non perderti parti importanti!

bg1
Dirottamento di controllo (control hijacking)
Attacchi di controllo di base di hijacking
L’obiettivo dell’attaccante è quello di prendere il controllo della macchina bersagliata,
attraverso l’esecuzione di codice arbitrario su un obiettivo con applicazioni di
dirottamento del flusso di controllo.
Alcuni tipi di attacchi possono essere il Buffer/Integer overflow attack e il format
string vulnerabilities control flow.
Uno dei bug più ricorrenti nei programmi C/C++ è il Buffer Overflow. Questo tipo di
vulnerabilità riguarda circa il 20% del totale, e circa il 10% delle vulnerabilità tra il
2005 e il 2007.
E’ necessario conoscere le funzioni in C, lo stack e lo heap; inoltre è necessario
conoscere come vengono fatte le chiamate di sistema.
Per la chiamata di sistema exec(), è necessario conoscere la CPU e l’OS utilizzato nella
macchina bersaglio: gli esempi andranno fatti su macchine con architettura x86 e OS
Windows o Linux. I dettagli variano leggermente in base alla CPU e all’OS. (Little
endian vs Big endian per la memorizzazione del dato; Differenza di struttura nello
Stack Frame tra Unix e Windows.
Supponiamo che *str è tale che dopo aver lanciato
strcpy, lo stack assomiglia a
----------------------------------------------->
Lanciando il programma P: exec(“/bin/sh”)
Quando func() esce, l’utente ottiene la shell!
Nota: il codice maligno P viene eseguito nella Pila
THE NOP SLIDE CHIARIMENTI.→ CHIARIMENTI.
Dettagli ed esempi.
Alcune complicazioni:
Il programma P non dovrebbe contenere il carattere\0\’; L'overflow non dovrebbe
arrestare il programma prima che func () esista.
Esempio di stack in eccesso che distruggono gli overflow:
- (2007) Windows animated cursors (ANI), LoadAniIcon()
– (2005) Symantec Virus Detection
Alcune funzioni di libc poco sicure
strcpy (char *dest, const char *src)
strcat (char *dest, const char *src)
pf3
pf4
pf5
pf8
pf9
pfa

Anteprima parziale del testo

Scarica Vulnerabilità attacchi e contromisure e più Traduzioni in PDF di Sicurezza delle reti solo su Docsity!

Dirottamento di controllo (control hijacking) Attacchi di controllo di base di hijacking L’obiettivo dell’attaccante è quello di prendere il controllo della macchina bersagliata, attraverso l’esecuzione di codice arbitrario su un obiettivo con applicazioni di dirottamento del flusso di controllo. Alcuni tipi di attacchi possono essere il Buffer/Integer overflow attack e il format string vulnerabilities control flow. Uno dei bug più ricorrenti nei programmi C/C++ è il Buffer Overflow. Questo tipo di vulnerabilità riguarda circa il 20% del totale, e circa il 10% delle vulnerabilità tra il 2005 e il 2007. E’ necessario conoscere le funzioni in C, lo stack e lo heap; inoltre è necessario conoscere come vengono fatte le chiamate di sistema. Per la chiamata di sistema exec(), è necessario conoscere la CPU e l’OS utilizzato nella macchina bersaglio: gli esempi andranno fatti su macchine con architettura x86 e OS Windows o Linux. I dettagli variano leggermente in base alla CPU e all’OS. (Little endian vs Big endian per la memorizzazione del dato; Differenza di struttura nello Stack Frame tra Unix e Windows. Supponiamo che *str è tale che dopo aver lanciato strcpy, lo stack assomiglia a -----------------------------------------------> Lanciando il programma P: exec(“/bin/sh”) Quando func() esce, l’utente ottiene la shell! Nota: il codice maligno P viene eseguito nella Pila THE NOP SLIDE → CHIARIMENTI.CHIARIMENTI. Dettagli ed esempi. Alcune complicazioni: Il programma P non dovrebbe contenere il carattere ‘\0\’; L'overflow non dovrebbe arrestare il programma prima che func () esista. Esempio di stack in eccesso che distruggono gli overflow:

  • (2007) Windows animated cursors (ANI), LoadAniIcon()
  • (2005) Symantec Virus Detection Alcune funzioni di libc poco sicure strcpy (char *dest, const char *src) strcat (char *dest, const char *src)

gets (char *s) scanf ( const char format, … ) and many more Le versioni "sicure" della libc strncpy (), strncat () sono fuorvianti per esempio. strncpy () può lasciare la stringa non terminata Con Windows C run time (CRT), l’esecuzione di strcpy_s ( dest, DestSize, * src): assicura la terminazione corretta. Opportunità di buffer overflow.

• Gestore di eccezioni. (Attacchi su Windows SEH, Structured Exception Handling)

◦ Sovrascrittura di un indirizzo di gestione di eccezioni nello stack frame.

• Funzione puntatori (per esempio PHP 4.0.2, MS Media Player Bitmaps)

◦ Overflow del buffer sovrascriverà la funzione del puntatore.

  • Longjmp buffer: longjmp(pos) → CHIARIMENTI.perl 5. ◦ Overflow del buffer vicino a pos sovrascrive il valore di Pos. Attacco SEH
  • Esegue codice arbitrario abusando dei servizi di spedizione delle eccezioni di Windows a 32 bit.
  • Uno stack overflow sovrascrive un record di registrazione delle eccezioni (ERR) sullo stack di un thread.
  • Un ERR include un puntatore successivo e un gestore di eccezioni puntatore di funzione. Il puntatore successivo si collega al prossimo record in l'elenco dei gestori di eccezioni registrati. L'eccezione il puntatore della funzione di gestione viene utilizzato quando si verifica un'eccezione.
  • Dopo che un record di registrazione delle eccezioni è stato sovrascritto, è necessario generare un'eccezione in modo che il dispatcher delle eccezioni tenterà di gestirlo Trovare un buffer overflow. Per trovare l'overflow in un server Web:
  • Esegui il server sul computer locale
  • Emettere richieste non corrette (che terminano con "$$$$$")
  • Esistono molti strumenti automatici (chiamati fuzzers - modulo successivo)

• Scrivere su memoria arbitraria.

Controllo del dirottamento (hijacking) Difesa piattaforme → contromisure.contromisure. Prevenire attacchi di dirottamento.

  • Fissare bug: ◦ Revisione dei software, utilizzando tool automatizzati

◦ Riscrivere il software in un linguaggio sicuro, tipo Java o ML

▪ Difficile per codice esistente (legacy)

  • Permettere l’overflow, ma impedire l’esecuzione del codice
  • Aggiungere codice runtime per rilevare gli exploit degli overflow. ◦ Interrompe il processo quando viene rilevato l’exploit di overflow. Esistono software per fare ciò come Stackguard e LibSafe. Marcatura di stack e heap come non eseguibili NX-bit su AMD Athlon 64,
  • XD-bit su Intel P4 Prescott
  • Bit NX in ogni voce della tabella delle pagine (PTE) Distribuzione: Linux (tramite progetto PaX);
  • OpenBSDWindows: dal XP SP2 (DEP)
  • Visual Studio: / NXCompat [: NO] limitazioni:
  • Alcune app richiedono un heap eseguibile (ad esempio JIT).
  • Non difende contro la programmazione Return Oriented Attacco: Programmazione orientata al ritorno. Controllare l'hijacking senza eseguire il codice Esempi: controlli DEP in windows

Risposta: ASLR = randomizzazione del layout dello spazio indirizzo Sono librerie condivise in posizioni casuali nella memoria di processo  L'attaccante non può saltare direttamente alla funzione exec L'attaccante non può saltare direttamente alla funzione exec

  • Distribuzione: (/ DynamicBase)
  • Windows Vista: 8 bit di casualità per le DLL
  • allineato alla pagina 64K in una regione da 16 MB  L'attaccante non può saltare direttamente alla funzione exec256 scelte
  • Windows 8: 24 bit di casualità su processori a 64 bit
  • Altri metodi di randomizzazione:
  • Sys-call randomization: randomize sys-call id
  • Instruction Set Randomization (ISR) Esempio: l’avvio carica due volte le librerie in posizioni diverse. Nota: tutto nella memoria di processo deve essere randomizzato stack, heap, librerie condivise, immagine
  • Win 8 Force ASLR: assicura che tutti i moduli caricati utilizzino ASLR Altri attacchi: irrorazione. Nella sicurezza del computer, l'irrorazione dell'heap è una tecnica utilizzata negli exploit per facilitare l'esecuzione arbitraria di codice. La parte del codice sorgente di un exploit che implementa questa tecnica è chiamata spray di heap. In generale, il codice che spruzza l'heap tenta di mettere una certa sequenza di byte in una posizione predeterminata nella memoria di un processo di destinazione facendolo allocare (grandi) blocchi sull'heap del processo e riempire i byte in questi blocchi con i giusti valori. Non è possibile utilizzare un heap spray per interrompere qualsiasi sicurezza: è necessaria una vulnerabilità separata. Sfruttare i problemi di sicurezza è spesso difficile perché vari fattori possono influenzare questi processi. Gli allineamenti casuali di memoria e temporizzazione introducono molta casualità (dal punto di vista dell'attaccante). Si può usare uno spruzzo di heap per introdurre una grande quantità di ordine per compensare questo e aumentare le possibilità di successo dello sfruttamento. Gli spray di heap sfruttano il fatto che la posizione iniziale delle allocazioni di heap di grandi dimensioni è
  • Protegge i puntatori e i buffer di crittografia
  • Chiave generata quando il programma inizia
  • Mai condiviso, quindi è sicuro
  • Meno efficace, più evidente effetti sulle prestazioni Miglioramenti StackGuard: Riorganizzare il layout dello stack per evitare l'overflow di ptr Crescita della stringa Crescita della pila ProPolice IBM. Preordinare le variabili locali per posizionare i buffer dopo i puntatori per evitare il danneggiamento dei puntatori
  • copia dei puntatori negli argomenti delle funzioni su un'area che precede i buffer delle variabili locali per impedire il danneggiamento dei puntatori
  • omissione del codice di strumentazione da alcune funzioni per ridurre il sovraccarico delle prestazioni. Visual Studio /GS (dal 2003) https://msdn.microsoft.com/it-it/library/8dbf701c.aspx Protegge gli argomenti del puntatore e i puntatori locali da un overflow del buffer Puntatori, ma non array

Combinazione di ProPolice and Random Canary I canarini sono un importante strumento di difesa, ma non impediscono tutti gli attacchi di controllo del dirottamento:

  • Gli attacchi basati su heap sono ancora possibili
  • Gli attacchi di overflow su interi sono ancora possibili
  • / GS di per sé non impedisce l'attacco di Exception Handling Minacce su Web Application (spiegazione) Injection Flaws Le Injection Flaws sono vulnerabilità relative all’invio da parte di un agente di minaccia di input non validato e inviato ad un interprete come comandi di sistema o query SQL. Injection significa fare in modo che un’applicazione includa dati ulteriori rispetto a queli previsti nei flussi diretti ad un interprete. Gli interpreti accettano stringhe dati come input e li interpretano come comandi: SQL, OS Shell, LDAP, Xpath, ecc.

Il Canary protegge ret addr

e il frame gestore di

eccezioni.

Puntatori, ma non array

Con gli attacchi XSS basati su DOM, il codice e le variabili JavaScript del sito vengono manipolati piuttosto che gli elementi HTML. In alternativa, gli attacchi possono essere una miscela o un ibrido di tutti e tre i tipi. Il pericolo con lo scripting cross-site non è il tipo di attacco, ma è possibile. Gli attacchi sono solitamente implementati in Javascript, che è un potente linguaggio di scripting. L'uso di Javascript consente agli aggressori di manipolare qualsiasi aspetto della pagina visualizzata, inclusa l'aggiunta di nuovi elementi (come l'aggiunta di un riquadro di accesso che inoltra le credenziali a un sito ostile), la manipolazione di qualsiasi aspetto dell'albero DOM interno e l'eliminazione o la modifica del modo in cui la pagina aspetto e tatto, JavaScript consente l'uso di XmlHttpRequest, che viene in genere utilizzato dai siti che utilizzano le tecnologie AJAX, anche se il sito della vittima non utilizza AJAX oggi. Usando XmlHTTPRequest, a volte è possibile ottenere uno stesso criterio di origine dell'origine del browser, cioè trasmettere i dati delle vittime ai siti ostili e creare worm complessi e zombi dannosi che durino finché il browser rimane aperto. Gli attacchi AJAX non devono essere visibili o richiedono l'interazione dell'utente per eseguire pericolosi attacchi di violazione della richiesta del sito (CSRF). Come si risolve il Cross Site Scripting: Limitazione dei caratteri di input inviati dall’utente; e la sanitizzazione dei caratteri di input provenienti dai client con procedura di HTML encoding. CSRF – Cross Site Request Forgery. Un attacco CSRF forza il browser della vittima ad inviare una richiesta HTTP opportunamente forgiata – includendo i cookie di sessione della vittima ed ogni altra informazione di autenticazione – ad una applicazione web vulnerabile. Questo permette all’attaccante di forzare il browser della vittima a generare una richiesta che l’applicazione vulnerabile crede legittimamente inviata dall’utente. Un attacco di tipo Cross Site Request Forgery è mirato a forzare il browser di una vittima ad eseguire operazioni da lui non espressamente richieste, sfruttando vulnerabilità applicative come una non corretta implementazione delle sessioni ed un passaggio dei parametri e dei rispettivi valori di una richiesta attraverso l’uso del metodo GET. La differenza con XSS è che nel CSRF è la vittima che viene forzata a compiere un’azione; con XSS è l’attaccante che si impadronisce dell’identità della vittima e richiede javascript. Inoltre: XSS richiede che un sito accetti codice malevolo, mentre con CSRF il codice malevolo è un sito di terze parti. Perchè esiste questo problema? Per una errata progettazione dell’applicativo (parametri inviati tramite il metodo GET). Cosa permette? La manipolazione dei parametri passati nell’URL tramite metodo GET in mod oda forzare il browser della vittima ad eseguire operazioni appositamente forgiate dall’agente di minaccia. L’impatto è una esecuzione di operazioni non espressamente richieste. Come si risolve? Attraverso il passaggio di parametri all’interno dell’applicazione tramite metodo POST; implementando un ID di sessione non prevedibile (meglio se prevedono anche una scadenza su base temporale). Infine, implementando meccanismi che non consentano l’esecuzione di richieste dirette.

Supponiamo che l’utente Alice stia navigando su un forum, o un blog, o stia visualizzando una mail in formato HTML dove l’utente Bob ha postato una immagine malevola così forgiata: <img src=”link di reindirizzamento” alt=”Errore nella visualizzazione dell’immagine”> Supponiamo ora che Alice sia autenticata in quel momento sul sito della sua banca, quindi sul suo computer sia presente un cookie che testimonia l’avvenuta autenticazione. In tal caso la richiesta effettuata sarà perfettamente valida, l’URL in questione eseguito da Alice con ovvie conseguenze. In genere questo tipo di attacchi vengono perpetrati attraverso immagino o iframe “abusivi” nel codice.