






Studia grazie alle numerose risorse presenti su Docsity
Guadagna punti aiutando altri studenti oppure acquistali con un piano Premium
Prepara i tuoi esami
Studia grazie alle numerose risorse presenti su Docsity
Prepara i tuoi esami con i documenti condivisi da studenti come te su Docsity
Trova i documenti specifici per gli esami della tua università
Preparati con lezioni e prove svolte basate sui programmi universitari!
Rispondi a reali domande d’esame e scopri la tua preparazione
Riassumi i tuoi documenti, fagli domande, convertili in quiz e mappe concettuali
Studia con prove svolte, tesine e consigli utili
Togliti ogni dubbio leggendo le risposte alle domande fatte da altri studenti come te
Esplora i documenti più scaricati per gli argomenti di studio più popolari
Ottieni i punti per scaricare
Guadagna punti aiutando altri studenti oppure acquistali con un piano Premium
Traduzione delle slide del corso di Sicurezza delle Reti dell'Università di Pisa, con eventuali approfondimenti
Tipologia: Traduzioni
1 / 12
Questa pagina non è visibile nell’anteprima
Non perderti parti importanti!







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:
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.
◦ Sovrascrittura di un indirizzo di gestione di eccezioni nello stack frame.
◦ Overflow del buffer sovrascriverà la funzione del puntatore.
Controllo del dirottamento (hijacking) Difesa piattaforme → contromisure.contromisure. Prevenire attacchi di dirottamento.
▪ Difficile per codice esistente (legacy)
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
Combinazione di ProPolice and Random Canary I canarini sono un importante strumento di difesa, ma non impediscono tutti gli attacchi di controllo del dirottamento:
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.