Come funziona davvero ottenere una shell remota sfruttando una vulnerabilità?

7

Posso capire cos'è un overflow del buffer e che ti permette di scrivere in posti della memoria che non dovresti essere in grado di scrivere. Posso anche cogliere l'idea che ci possano essere altre vulnerabilità del software che funzionano in un modo diverso che ti consente di inserire le cose che vuoi in memoria. Ho anche avuto accesso ad alcune mie vecchie macchine XP usando metasploit, che è stato divertente.

Ma non riesco a capire perfettamente come sia possibile accedere al sistema remoto avendo in mente (ad esempio) la vulnerabilità di buffer overflow.

Ci sono alcuni punti che non sono chiari per me:

  1. È necessario eseguire il programma che presenta la vulnerabilità e ascoltare una porta specifica sulla macchina vittima (come un mini-server o qualcosa del genere)? Un programma mal scritto può essere sfruttato da remoto se non ascolta una porta?
  2. Presumo che il programma leggerà qualche input da quella porta e poi lo scriverà in memoria in qualche variabile e forse lo elaborerà. Fornendo al programma più dati di quanti ne dovrebbe leggere, e a condizione che abbia la vulnerabilità, scriverà in una posizione nella memoria (in particolare, esattamente dopo la variabile) qualunque cosa vogliamo. In che modo questo non arresta il programma il 99,9% delle volte? Cosa succede se esattamente dopo il luogo in memoria in cui è memorizzata questa variabile c'è un puntatore a qualche funzione che non riesce ad eseguire e il programma si blocca?
  3. Se il programma non si arresta in modo anomalo, come possiamo eseguire il codice che abbiamo iniettato nella memoria? Abbiamo bisogno di inserire il codice che vogliamo in un posto all'interno della memoria che sappiamo che verrà eseguito? Come può essere eseguita una parte casuale della memoria? Quasi mai nei miei programmi eseguo alcune mie variabili, a meno che non voglia eseguire qualche altro programma, che è molto raro e non dovrebbe essere lo stesso dell'esecuzione diretta del codice dalla memoria (che mi ricorda eval ()).
  4. Se il punto 2 presuppone che la vulnerabilità di solito si verifica quando il programma vulnerabile legge input dannosi da una porta e che questo codice viene eseguito, in che modo il codice eseguito può tornare a me, l'utente malintenzionato? Devo inviare il codice dannoso il mio indirizzo IP in una variabile o qualcosa del genere?
  5. I programmi generalmente non possono leggere o scrivere nella memoria di un altro programma. Questo significa che quando il programma vulnerabile si chiude, perderò la connessione alla shell remota aperta? Oppure genera un sottoprocesso indipendente una volta eseguito e io sono effettivamente collegato ad esso?

Qualcuno può darmi un esempio semplice ma realistico e completo di come funziona l'intero sistema, dal programma ascoltando alcune porte fino a quando l'attaccante non acquisisce una shell?

    
posta hytromo 23.05.2015 - 00:00
fonte

2 risposte

7
  1. I programmi vulnerabili devono ascoltare le porte per poter accedere direttamente alla rete. Tuttavia, potresti ottenere l'accesso al sistema con altri mezzi, quindi sfruttare un programma vulnerabile che non accede alla rete (ad esempio malware e-mail che attiva una vulnerabilità in un lettore PDF)

  2. Sapere in che modo il programma vulnerabile si comporta in modo prevedibile è la chiave per trovare e sfruttare le vulnerabilità. In breve, devi sapere già cosa accadrà nello stack prima di inviare l'exploit. Ecco perché, proprio come tutte le programmazioni: test, test, test.

  3. Se capisci BO, allora sai di scrivere nello stack in un punto in cui il puntatore indirizzerà l'esecuzione. Ecco come possiamo eseguire il nostro codice.

  4. Proprio come nel mio n. 1, il programma vulnerabile non deve necessariamente essere un servizio di rete in esecuzione su una porta. Se si desidera una "shell inversa", il codice per la shell deve includere il codice di rete necessario per riconnettersi.

  5. Sì, e sì. Se non si esegue la migrazione a un altro processo (l'incorporamento in un processo in esecuzione o un nuovo processo attivato dal codice), una volta terminato il programma vulnerabile, anche la connessione. Quindi, migrare.

La mia risposta è una visione MOLTO semplicistica delle tue domande. C'è molto che puoi fare per approfondire ciò che ho fornito, e anche le tecniche che contraddicono ciò che ho detto, ma queste sono le basi.

Scenario semplicistico:

Un server FTP vulnerabile è in esecuzione su una porta. Si scopre che un determinato comando FTP non è adeguatamente vincolato, quindi è possibile inviare argomenti di comando eccessivamente grandi e scrivere in parti dello stack a cui accede il server FTP. Si progetta il codice (comprese le funzionalità di rete) che può adattarsi allo spazio di stack occupato dal programma FTP. Quindi ti connetti al server FTP e invii il comando con lo shellcode come payload. Quando il server FTP elabora il comando, colpisce il tuo codice ed elabora il carico utile. Il tuo shellcode viene eseguito e crea una connessione di rete sul tuo computer.

    
risposta data 23.05.2015 - 00:23
fonte
3

L'overflow del buffer consente a un utente malintenzionato di sovrascrivere gli indirizzi memorizzati nello stack utilizzati dall'applicazione quando si torna da una funzione. Una volta che l'attaccante controlla questo indirizzo, è possibile deviare l'esecuzione del programma ritornando a una parte diversa dell'applicazione o alle librerie che utilizza.

Nella sua forma più semplice l'attaccante può scrivere il codice shell nello stack oltre la sovrascrittura dell'indirizzo e imposterà l'indirizzo di ritorno a un'istruzione jmp esp che indicherà eip allo stack ed eseguirà i dati nello stack come codice.

Il codice shell può quindi creare una connessione in uscita o ascoltare su una porta.

Il termine "sfruttamento remoto" viene spesso applicato a nessun programma demone come un browser o invia via email a qualcuno un file che sfrutta una vulnerabilità nel programma di apertura, vale a dire: un file PDF.

    
risposta data 23.05.2015 - 00:25
fonte

Leggi altre domande sui tag