vulnerabilità di sistema (Windows)

[Delmak_O]

che cosa s'intende per "sfruttare una vulnerabilità"?
da quello che ho capito, sono errori logici di scrittura di un programma, cose che solo un programmatore potrebbe capire...ma come fa un 'hacker', ad esempio, a scrivere programmi che sfruttino 'buchi' di Windows, se il codice sorgente di Windows (mi pare che si giri lì la differenza con l'open source) è protetto?! mi sono posto questa domanda dopo che ho sentito della diffusione del pezzo di codice Windows in rete e di come ci si sono avventati gli 'hacker', ma, altrimenti, come fanno a trovare gli errori logici dei programmi se questi sono protetti? ovvero come fanno a leggere un codice sorgente che è inaccessibile?
la domanda è un po' così...

[Mercuzi0]

Non è necessario conoscere il codice sorgente di un programma per creare un "exploit", basta conoscere la logica del suo funzionamento e...provare ! .
A volte sono "bug" banali che possono essere sfuttati anche a danno dei S.O. (es. il "buffer overflow" non è prettamente un "bug" di Windows ..).
Una volta che il bug è conosciuto è testato si incomincia a "lavorarci su"........

[Habanero]

Quando non si possiede il sorgente i buffer overflow vengono spesso trovati per tentativi.... fornendo input "strano" o particolarmente lungo si possono notare malfunzionamenti... indice che qualcosa non va. Da qui si parte per ulteriori investigazioni.

Un Buffer Overflow (BOF) consiste nello sfruttare il fatto che il programma si dimentica di controllare la lunghezza dei dati in ingresso prima di memorizzarli in un buffer. Se il buffer è lungo 100 byte e noi forniamo 200 byte c'è il rischio che si vadano a sovvrascrivere zone di memoria adibite ad altro senza che il programma se ne accorga.

Le variabili passate dal programma alle soubroutine (procedure, funzioni come le volete chiamare) vengono memorizzate in una zona chiamata STACK. Nello stack viene anche memorizzato l'indirizzo di ritorno al programma affinche al termine della procedura l'esecuzione riparta del punto corretto.

Lo sfruttamento del BOF consiste proprio nella sovvrascrittura di tale indirizzo. Se riusciamo a modificare, sfruttando l'extra lunghezza dei dati in input, tale indirizzo con uno che punta ad una nostra funzione personalizzata al termine della procedura sarà la nostra funzione ad essere eseguita e non ci sarà un ritorno al programma chiamante. Il codice della nostra funzione sarà fornito ancora tramite i dati di input..

Per fare tutto ciò è essenziale avere un debugger (un programma che ci mostri l'immagine della memoria, dello stack e del codice in un determinato istante) e conoscere l'assembly... oltre ad un po' d'ingenio e parecchie conoscenze sul sistema.

[Delmak_O]

non so se ho capito bene...lasciando stare l'andare 'per tentativi ed errori', un hacker che volesse analizzare le vulnerabilità di un sistema dovrebbe recuperare non tanto il codice sorgente magari scritto in C ma il codice-macchina o meglio l'assembler di un programma che ne descriverebbe allora la logica di funzionamento?
io pensavo che l'assembler fosse un linguaggio di programmazione come, ad es., il C, per cui un programma era scritto o in C o in assembler, invece forse è uno strato più vicino all'eseguibile, dietro cui starebbe all'origine magari un linguaggio C? in questo caso un hacker smontando un programma ne coglierebbe gli errori logici magari non attingendo al codice sorgente del programma stesso?
l'analisi è fatta sull'assembler quindi? per un hacker allora è importante conoscere l'assembler, non riuscirebbe a stare solo sui linguaggi di programmazione 'alta'?
non so se riesco a spiegarmi, è chiaro che non ci sono molto dentro queste cose...

[Habanero]

Un po' di chiarezza sull'Assembly:

Il microprocessore (uP) interpreta solo dati binari, uni e zeri raggruppati in byte o suoi multipli. Alcuni di questi valori rappresentano istruzioni del uP (es caricamento di una valore da/verso un registro o memoria, confronto tra valori, salti verso altri indirizzi di memoria etc) altri i dati delle istruzioni. Nell'insieme tali valori rappresentano il LINGUAGGIO MACCHINA (LM) del uP. L'essere umano difficilmente riesce ad interpretare dati puramente numerici.
L'Assembly è quanto di più vicino esiste al LM ma tale da essere compreso più facilmente dalle persone. In sostanza i valori che costituiscono le istruzioni sono sostituite con dei codici mnemonici, cioè nomi brevi che le descrivono. Per esempio JMP (JuMP) permette un salto incondizionato verso un certo indirizzo, MOVE permette il trasferimento di dati da/verso registri e memoria, CMP (CoMPare) esegue confronti tra valori etc...
L'assembly descrive esattamente il codice macchina ma semplicemente in una forma più umana. Si puo' dire che l'assembly è un modo di rappresentare il LM.


Detto questo è possibile attraverso programmi Disassemblatori vedere il codice macchina interpretato in assembly di un qualsiasi programma.
In linea teorica è quindi possibile la ricostruzione del suo funzionamento.
Questo però è decisamente scomodo, lungo, impegnativo e spesso inutile per l'argomento che stiamo trattando... l'assembly non è certo un linguaggio ad alto livello!!!! Per eseguire una normale istruzione ad alto livello sono spesso necessarie decine e decine di istruzioni assembly...

Tutti i linguaggi ad alto livello che sono compilati (C, C++, Pascal per esempio) vengono tradotti dal compilatore in LM per formare l'eseguibile. Ricorda che il linguaggio macchina è l'unico comprensibile al uP!!!!!

[Habanero]

Torniamo alle nostre vulnerabilità.
Possono essere di vari tipi ma la più sfruttata è il Buffer Overflow (BOF).
Per prima cosa bisogna individuare la presenza di un BOF cioè di un buffer riempito senza controllare la lunghezza dei dati in ingresso.
Analizzare direttamente il codice assembly alla sua ricerca sarebbe da suicidio! In teoria e' possibile ma sarebbe un lavoro mostruoso e probabilmente infruttuoso.
Provando invece a mandare input particolarmente lunghi o malformati è possibile rendersi conto che qualcosa non funziona correttamente. Se cio' succede abbiamo probabilmente scoperto un BOF. Ovviamente ci vuole esperienza e volte anche un po' di fortuna.

La cosa più difficile è far si che il BOF possa essere utile per l'hacker e quindi trovare il metodo per sfruttarlo per eseguire codice remoto. Questa è tutto una altra faccenda..

Oviamente stiamo supponendo che l'hacker stia facendo dei test preliminari sul suo sistema.

Uno strumento utile a questo punto è il Debugger. Questo tipo di software permette di disassemblare in tempo reale un programma in memoria e simulare passo passo la sua esecuzione. Immagina di dire tu al programma quando avanzare di una istruzione, quando fermarsi etc. Per tutto il tempo il debugger ti da la possibilità di analizzare la memoria e il codice assembly attualmente eseguito.

Tutto questo permette di individuare la posizione esatta nel codice in cui si verifica l'errore, cioè il blocco del programma.

In base alle informazione del mio primo post l'errore avviene in genere quando nello stack si trova un errato indirizzo di ritorno per la funzione poichè questa è stata sovvrascritta dall'eccesso di dati forniti al buffer. Questo indirizzo errato sarà in generale casuale poichè tali erano i dati in ingresso e in tale punto in memoria non saranno presenti istruzioni valide. Sia ha quindi il blocco del programma o la segnalazione da parte del sistema operativo... (il programma XXX ha eseguito una operazione illegale.... ti dice qualcosa?)

Attraverso il debugger è possibile individuare dove si verifica l'errore e quindi dove è memorizzato l'indirizzo di ritorno.

Ora possiamo forgiare i dati in ingresso in modo che nella posizione che sovvrascriverà l'indirizzo incriminato ce ne sia uno che punta ad una nostra funzione.

Come vedi una volta indviduato il BOF non è stata necessaria l'analisi di tutto il codice... solo un po' di ingegno.

In generale comunque le cose possono essere molto più complicate di quanto ti ho detto ma le linee guida sono queste.

[maiosyet]

Originariamente inviato da Habanero
Quando non si possiede il sorgente i buffer overflow vengono spesso trovati per tentativi.... fornendo input "strano" o particolarmente lungo si possono notare malfunzionamenti... indice che qualcosa non va. Da qui si parte per ulteriori investigazioni.

Un Buffer Overflow (BOF) consiste nello sfruttare il fatto che il programma si dimentica di controllare la lunghezza dei dati in ingresso prima di memorizzarli in un buffer. Se il buffer è lungo 100 byte e noi forniamo 200 byte c'è il rischio che si vadano a sovvrascrivere zone di memoria adibite ad altro senza che il programma se ne accorga.

Ma ad esempio (sperando non sia un es cretino) se in C indicizzo un array con 9 elementi e gli fornisco un input di 10 elementi va in BOF?

[Habanero]

Diciamo che va in BOF nel senso che sicuramente sovvrascivi una zona di memoria che non è stata allocata per l'array. E' possibile che per un solo elemento in più non succeda nulla di particolare.
Puoi fare delle prove. Dichiara l'array dentro al main() e non come variabile globale in modo da assicurarti che venga allocato nello stack. Utilizza sempre lo stesso codice e prova a vedere dopo quanti byte oltre la giusta dimensione il programma va in crash... in quel caso hai probabilmente sovvrascritto l'indirizzo di ritorno...
Ancora meglio sarebbe fare delle prove leggendo i dati da un file e memorizzandoli nell'array, in questo modo il codice rimane sempre uguale.