A cura di:
Nota: E' permessa la pubblicazione di questa guida su altri siti lasciando intatto il contenuto, questa nota e il link al nostro sito.
VII PARTE
--------------------------------------------------------------------------------
Cari amici, quest'oggi parleremo di argomenti cari a molti di voi: specificheremo meglio il problema del buffer overflow, già citato la scorsa settimana e, ci dedicheremo all'hacking del sistema eccelso, da cui sono derivati i più famosi S.O. Multiutente ovvero Unix.
Innanzitutto, chiariamo una cosa, su cui abbiamo diverse volte insistito durante la lettura di questa guida: un hacker ha bisogno di informazioni precise circa il sistema obiettivo del suo lavoro!
Se qualcuno di voi nutre ancora dei dubbi in merito, potrà comunicarci, come sia possibile attaccare un sistema NT con exploit studiati per Unix o viceversa, come sia possibile sfruttare bug di un programma non installato su una data distribuzione di Linux o di BSD.
Innanzitutto quindi, dovremo andare a ricercare tutte le informazioni su quale sistema sia installato, quali demoni siano in ascolto (per demoni, si intendono alcuni programmini... ovvia citazione per i meno addentro la materia) ma soprattutto quale sia la piattaforma. Mi spiego meglio: un sistema i686 sarà diverso da uno SPARK, una versione di Apache datata, avrà dei bug risolti in una versione recente ecc....
Ecco che dunque si comincia a delineare un profilo da seguire ed ecco che finalmente, comincia anche ad essere chiaro il perchè sono state dette determinate cose.
Ma torniamo a noi: il buffer overflow, è stato già citato nelle scorse settimane, ma ne abbiamo dato soltanto una definizione spicciola, vediamo dunque di capire come fanno gli hackers a sfruttare questo punto debole di alcuni (ma forse troppi) programmi.
Cercherò di seguito di dare una definizione spicciola e non una enunciazione, dunque, qualora, alcuni di voi non si trovassero daccordo con quanto dirò, dovranno pensare che non mi sto rivolgendo ad esperti, infatti in quel caso, questa guida non avrebbe senso alcuno.
Innanzitutto bisogna aver presente il fatto che ogni programma avviato su un server (si, si lo so, non solo, ma un hacker penserebbe di attaccare la vostra workstation di casa con il buffer overflow????) ha a sua volta qualche processo avviato come utente root.
Un buffer non è altro che un array di dimensione fissa, che contiene una serie di dati e, che ogni programma sfrutta in misura diversa.
Nel momento in cui, un utente (o un processo) tenti di inserire all'interno di un buffer, una quantità di informazioni superiori al consentito, ecco che si verifica (bhe... diciamo alcune volte...) il buffer overflow.
Ora credo ovvio il sorgere di una domanda da parte vostra: - se è così semplice perchè non lo fanno tutti? -
La risposta è ovvia e scontata: - non è così semplice!!!!! -
Ecco spiegato il perchè, ogni qualvolta, ci troviamo ad analizzare un possibile obiettivo,dobbiamo necessariamente sapere tutto di lui e preferibilmente, anche di chi lo guida (qualche notizia sull'amministratore di sistema è sempre reperibile in giro per internet.
Andiamo dunque a tracciare, ogni qualvolta se ne ponga la necessità, una mappa dei possibili punti deboli del sistema.
Una vasta raccolta di informazioni circa i possibili exploit da applicare in determinate situazioni, si può reperire su bugtraq o dal sito del cert, ovvio che, ognuno di noi, deve innanzitutto avere una buona conoscenza dell'inglese nel momento in cui decide di darsi all'hackeraggio o comunque, dovrà conoscere buona parte dei linguaggi di programmazione prima di cominciare la sua carriera!
Per analizzare le risorse dei nostri avversari potremo utilizzare diverse utility già belle pronte, distribuite spesso anche gratuitamente.
Alcuni strumenti per la scansione dei punti deboli sono: Internet Scanner, distribuito dalla I.S.S. (
Utility che potrebbero invece servire a scopi ben più "profondi", nel senso che possono essere adoperati per molteplici scopi, possono essere: il netcat, da riga di comando, necessita di una certa dimestichezza, o l'nmap, che consente l'identificazione delle porte TCP e UDP.
Ogni strumento vi si presenterà sotto un diverso aspetto, nel senso che avrete modo di apprezzare o meno il suo uso, ma dipenderà unicamente da voi; ognuno dei programmi citati porta infatti con se una serie di vantaggi/svantaggi, che soltanto con la pratica noterete meno.
Tuttavia, sono tutti strumenti utilissimi ad un hacker, infatti, solo uno sciocco eviterebbe di tracciare i punti deboli del suo avversario, passando immediatamente all'attacco, si rischia di lasciare tracce, di non riuscire (cosa peggiore) ad aver ragione dell'obiettivo, ma soprattutto, si rischia di fare uan ben magra figura e di gettare via il tempo perso a cercare l'obiettivo in questione.
Dunque, a questo punto, per riassumere, abbiamo specificato meglio il problema del buffer overflow, abbiamo citato una serie di strumenti che vi torneranno utili (lo sono sempre e comunque), andiamo dunque ora, a parlare di qualche problema che incontrete anche su sistemi UNIX.
Innanzitutto, non esiste alcun sistema che sia invulnerabile, nel senso, che un attacco del tipo - forza bruta - ovvero una ricerca casuale e continua di combinazioni di login e password, da quasi sempre un esito positivo.
L'unica protezione da tentativi di questo tipo, possono essere dati dalle solite stantie raccomandazioni, già offerte in passato sempre nell'ambito di questa guida, ovvero:
- cambiare spesso la password dei vari utenti (dando una scadenza fissata ad es. in 15 gg)
- obbligare gli utenti ad inserire codici alfanumerici
- offrire password lunghe almeno 7 caratteri
in Unix e tutti i sistemi che su di esso si basano sono attivi da tempo immemore, diversi strumenti "sicuri" quale l'ssh, ma spesso, proprio tramite la scansione dei servizi attivi, possiamo trovare attivi dei demoni come l'ftp o il telnet, i quali, come già enunciato, trasmettono login e password in chiaro.
Questa attenzione, non è una debolezza di Unix, ma di tutti i S.O., cui neanche Unix si sottrae.
Altri punti deboli, sono basati ad es. su errori degli amministratori di sistema, i quali, potrebbero ad esempio non configurare correttamente il TFTP.
Il TFTP (Trivial File Transfer Protocol) viene usato per avviare postazioni prive di disco fisso o per avviare servizi di rete. Qualora non fosse correttamente configurato, consentirebbe ad un attaccante, di richiedere il file /etc/passwd, di trasferirlo sul proprio computer e di ottenere in tal modo, , se non sia stato attivato il file /etc/shadow, non solo le login, ma anche gli hash delle password, che potrà decidere di craccare in tutta tranquillità.
Nelle versioni più recent, il TFTP consente di accedere alla sola directory /tftpboot, ma anche in questo modo, darebbe accesso in ogni caso, ad informazioni preziosissime, come i dati relativi al router (nome, login e password).
Altro baco contenuto in sistemi Unix, è dovuto al popolarissimo sendmail, questo programma infatti, pur essendo uno dei più complessi e dunque corposi (circa 80.000 righe di codice) programmi relativi a Unix, è anche uno dei più bacati!
Si può risalire indietro nel tempo, ricordando periodi in cui si aveva notizia di problemi addirittura settimanalmente. Tuttavia, ad oggi il programma è stato nettamente migliorato, pur peccando ancora di bachi non immediatamente riconoscibili o non ancora scoperti.
È importantissimo dunque, qualora vogliate utilizzare il sendmail, che abbiate l'ultima versione disponibile e che abbiate installato alcune utility addizionali che vengono liberamente distribuite aumentando nettamente la sicurezza di sendmail: smap ed smapd, distribuite su
Debolezze ulteriori, sono state notate in RPC (remote procedure call)e nel popolarissimo NFS, il quale consente (come noto dalla maggioranza degli utenti di sistemi Unix Like) di montare in locale (per gli utenti windows, si potrebbe immaginare di collegarsi ad una risorsa di rete, anche se non rende decisamente l'idea) una risorsa remota, come se si stesse operando sulla stessa macchina.
Il primo soffre di alte probabilità di essere aggredibile tramite attacco da buffer overflow, mentre il secondo, basandosi sul primo, non solo ne offre alcune caratteristiche, a discapito della sicurezza globale del sistema. Inoltre gli attacchi più comuni ad NFS, si basano su un'errata configurazione del servizio, il quale consentirebbe di esportare il filesystem al gruppo everyone, in questo modo, l'aggressore avrebbe la possibilità di montare in locale una qualunque porzione del filesystem, senza bisogno di autenticazione.
Un'ultimo cenno riguardante un bug ricercatissimo da eventuali aggressori, riguarda un pacchetto che quasi sempre viene installato ed utilizzato: il BIND, ovvero il DNS.
Anni addietro, furono segnalati seri problemi circa l'esecuzione di buffer overflow con la concreta possibilità di accedere con privilegi di root.
Ora ragioniamo per un attimo: perchè abbiamo citato così tanti bug in sistemi Unix e abbiamo parlato molto meno di sistemi NT? Bhe, è presto detto: Unix e tutti i Sistemi basati su di esso, sono robustissimi e particolarmente difficili da attaccare, tuttavia, un vero hacker tenterà il difficile e non l'ovvio, inoltre, come avrete notato, i problemi riscontrati su questi sistemi, non sono relativi al kernel (il cuore del sistema operativo), ma piuttosto, riguardano applicazioni ad esso correlate.
Sistemi NT soffrono di bachi che vengono corretti lentamente e sono miriadi, relativi spesso al S. e non solo agli applicativi con esso forniti, mentre Unix, resta robustissimo, ma soffre delle aggiunte che comunque dovremo avere a bordo.
Sia chiaro dunque che non esiste il sistema per eccellenza. Dipende troppo spesso dagli amministratori di sistema e di rete e, S. NT possono essere robusti se correttamente configurati, esattamente come un S. Unix.
L'elenco di bug relativo ai sistemi Unix Like e Windows, non termina sicuramente qui, tuttavia, la complessità dell'argomento ci impone di interrompere qui lo studio delle "falle", rimandandovi a due testi di sicuro interesse per ognuno di voi, dalla lettura dei quali, è stato tratto in buona parte questo corso:
HACKER PROOF - edito dalla McGrawill (anche se risale ormai a qualche tempo addietro e si aspetta un'aggiornamento degli argomenti in esso contenuti)
HACKER! 2.0 NUOVE TECNICHE DI PROTEZIONE DEI SISTEMI - edito dalla Apogeo, la cui prefazione, curata da Bruce Schneier (riconosciuto coem massimo esperto di sicurezza a livello mondiale), ci consente di considerare affidabilissimo il libro ed il suo contenuto.
Detto questo, vi lascio alle vostre considerazioni, sperando di aver chiarito qualcosa di oscuro e di essere stato utile in qualche modo, a divertire (perchè no???) con questa guida, che non ha mai voluto tediarvi e vi aspetto all'interno del forum per parlare ancora di tutto quello che può interessarvi.
A presto.
Perfavore,
Entra
oppure
Registrati
per vedere i Link!
Nota: E' permessa la pubblicazione di questa guida su altri siti lasciando intatto il contenuto, questa nota e il link al nostro sito.
VII PARTE
--------------------------------------------------------------------------------
Cari amici, quest'oggi parleremo di argomenti cari a molti di voi: specificheremo meglio il problema del buffer overflow, già citato la scorsa settimana e, ci dedicheremo all'hacking del sistema eccelso, da cui sono derivati i più famosi S.O. Multiutente ovvero Unix.
Innanzitutto, chiariamo una cosa, su cui abbiamo diverse volte insistito durante la lettura di questa guida: un hacker ha bisogno di informazioni precise circa il sistema obiettivo del suo lavoro!
Se qualcuno di voi nutre ancora dei dubbi in merito, potrà comunicarci, come sia possibile attaccare un sistema NT con exploit studiati per Unix o viceversa, come sia possibile sfruttare bug di un programma non installato su una data distribuzione di Linux o di BSD.
Innanzitutto quindi, dovremo andare a ricercare tutte le informazioni su quale sistema sia installato, quali demoni siano in ascolto (per demoni, si intendono alcuni programmini... ovvia citazione per i meno addentro la materia) ma soprattutto quale sia la piattaforma. Mi spiego meglio: un sistema i686 sarà diverso da uno SPARK, una versione di Apache datata, avrà dei bug risolti in una versione recente ecc....
Ecco che dunque si comincia a delineare un profilo da seguire ed ecco che finalmente, comincia anche ad essere chiaro il perchè sono state dette determinate cose.
Ma torniamo a noi: il buffer overflow, è stato già citato nelle scorse settimane, ma ne abbiamo dato soltanto una definizione spicciola, vediamo dunque di capire come fanno gli hackers a sfruttare questo punto debole di alcuni (ma forse troppi) programmi.
Cercherò di seguito di dare una definizione spicciola e non una enunciazione, dunque, qualora, alcuni di voi non si trovassero daccordo con quanto dirò, dovranno pensare che non mi sto rivolgendo ad esperti, infatti in quel caso, questa guida non avrebbe senso alcuno.
Innanzitutto bisogna aver presente il fatto che ogni programma avviato su un server (si, si lo so, non solo, ma un hacker penserebbe di attaccare la vostra workstation di casa con il buffer overflow????) ha a sua volta qualche processo avviato come utente root.
Un buffer non è altro che un array di dimensione fissa, che contiene una serie di dati e, che ogni programma sfrutta in misura diversa.
Nel momento in cui, un utente (o un processo) tenti di inserire all'interno di un buffer, una quantità di informazioni superiori al consentito, ecco che si verifica (bhe... diciamo alcune volte...) il buffer overflow.
Ora credo ovvio il sorgere di una domanda da parte vostra: - se è così semplice perchè non lo fanno tutti? -
La risposta è ovvia e scontata: - non è così semplice!!!!! -
Ecco spiegato il perchè, ogni qualvolta, ci troviamo ad analizzare un possibile obiettivo,dobbiamo necessariamente sapere tutto di lui e preferibilmente, anche di chi lo guida (qualche notizia sull'amministratore di sistema è sempre reperibile in giro per internet.
Andiamo dunque a tracciare, ogni qualvolta se ne ponga la necessità, una mappa dei possibili punti deboli del sistema.
Una vasta raccolta di informazioni circa i possibili exploit da applicare in determinate situazioni, si può reperire su bugtraq o dal sito del cert, ovvio che, ognuno di noi, deve innanzitutto avere una buona conoscenza dell'inglese nel momento in cui decide di darsi all'hackeraggio o comunque, dovrà conoscere buona parte dei linguaggi di programmazione prima di cominciare la sua carriera!
Per analizzare le risorse dei nostri avversari potremo utilizzare diverse utility già belle pronte, distribuite spesso anche gratuitamente.
Alcuni strumenti per la scansione dei punti deboli sono: Internet Scanner, distribuito dalla I.S.S. (
Perfavore,
Entra
oppure
Registrati
per vedere i Link!
) o, il CyberCop, prodotto da Network Associated (Perfavore,
Entra
oppure
Registrati
per vedere i Link!
), mentre sono gratuitamente disponibili, il Nessus (Perfavore,
Entra
oppure
Registrati
per vedere i Link!
) o il SAINT (di cui però non ricordo l'url).Utility che potrebbero invece servire a scopi ben più "profondi", nel senso che possono essere adoperati per molteplici scopi, possono essere: il netcat, da riga di comando, necessita di una certa dimestichezza, o l'nmap, che consente l'identificazione delle porte TCP e UDP.
Ogni strumento vi si presenterà sotto un diverso aspetto, nel senso che avrete modo di apprezzare o meno il suo uso, ma dipenderà unicamente da voi; ognuno dei programmi citati porta infatti con se una serie di vantaggi/svantaggi, che soltanto con la pratica noterete meno.
Tuttavia, sono tutti strumenti utilissimi ad un hacker, infatti, solo uno sciocco eviterebbe di tracciare i punti deboli del suo avversario, passando immediatamente all'attacco, si rischia di lasciare tracce, di non riuscire (cosa peggiore) ad aver ragione dell'obiettivo, ma soprattutto, si rischia di fare uan ben magra figura e di gettare via il tempo perso a cercare l'obiettivo in questione.
Dunque, a questo punto, per riassumere, abbiamo specificato meglio il problema del buffer overflow, abbiamo citato una serie di strumenti che vi torneranno utili (lo sono sempre e comunque), andiamo dunque ora, a parlare di qualche problema che incontrete anche su sistemi UNIX.
Innanzitutto, non esiste alcun sistema che sia invulnerabile, nel senso, che un attacco del tipo - forza bruta - ovvero una ricerca casuale e continua di combinazioni di login e password, da quasi sempre un esito positivo.
L'unica protezione da tentativi di questo tipo, possono essere dati dalle solite stantie raccomandazioni, già offerte in passato sempre nell'ambito di questa guida, ovvero:
- cambiare spesso la password dei vari utenti (dando una scadenza fissata ad es. in 15 gg)
- obbligare gli utenti ad inserire codici alfanumerici
- offrire password lunghe almeno 7 caratteri
in Unix e tutti i sistemi che su di esso si basano sono attivi da tempo immemore, diversi strumenti "sicuri" quale l'ssh, ma spesso, proprio tramite la scansione dei servizi attivi, possiamo trovare attivi dei demoni come l'ftp o il telnet, i quali, come già enunciato, trasmettono login e password in chiaro.
Questa attenzione, non è una debolezza di Unix, ma di tutti i S.O., cui neanche Unix si sottrae.
Altri punti deboli, sono basati ad es. su errori degli amministratori di sistema, i quali, potrebbero ad esempio non configurare correttamente il TFTP.
Il TFTP (Trivial File Transfer Protocol) viene usato per avviare postazioni prive di disco fisso o per avviare servizi di rete. Qualora non fosse correttamente configurato, consentirebbe ad un attaccante, di richiedere il file /etc/passwd, di trasferirlo sul proprio computer e di ottenere in tal modo, , se non sia stato attivato il file /etc/shadow, non solo le login, ma anche gli hash delle password, che potrà decidere di craccare in tutta tranquillità.
Nelle versioni più recent, il TFTP consente di accedere alla sola directory /tftpboot, ma anche in questo modo, darebbe accesso in ogni caso, ad informazioni preziosissime, come i dati relativi al router (nome, login e password).
Altro baco contenuto in sistemi Unix, è dovuto al popolarissimo sendmail, questo programma infatti, pur essendo uno dei più complessi e dunque corposi (circa 80.000 righe di codice) programmi relativi a Unix, è anche uno dei più bacati!
Si può risalire indietro nel tempo, ricordando periodi in cui si aveva notizia di problemi addirittura settimanalmente. Tuttavia, ad oggi il programma è stato nettamente migliorato, pur peccando ancora di bachi non immediatamente riconoscibili o non ancora scoperti.
È importantissimo dunque, qualora vogliate utilizzare il sendmail, che abbiate l'ultima versione disponibile e che abbiate installato alcune utility addizionali che vengono liberamente distribuite aumentando nettamente la sicurezza di sendmail: smap ed smapd, distribuite su
Perfavore,
Entra
oppure
Registrati
per vedere i Link!
Debolezze ulteriori, sono state notate in RPC (remote procedure call)e nel popolarissimo NFS, il quale consente (come noto dalla maggioranza degli utenti di sistemi Unix Like) di montare in locale (per gli utenti windows, si potrebbe immaginare di collegarsi ad una risorsa di rete, anche se non rende decisamente l'idea) una risorsa remota, come se si stesse operando sulla stessa macchina.
Il primo soffre di alte probabilità di essere aggredibile tramite attacco da buffer overflow, mentre il secondo, basandosi sul primo, non solo ne offre alcune caratteristiche, a discapito della sicurezza globale del sistema. Inoltre gli attacchi più comuni ad NFS, si basano su un'errata configurazione del servizio, il quale consentirebbe di esportare il filesystem al gruppo everyone, in questo modo, l'aggressore avrebbe la possibilità di montare in locale una qualunque porzione del filesystem, senza bisogno di autenticazione.
Un'ultimo cenno riguardante un bug ricercatissimo da eventuali aggressori, riguarda un pacchetto che quasi sempre viene installato ed utilizzato: il BIND, ovvero il DNS.
Anni addietro, furono segnalati seri problemi circa l'esecuzione di buffer overflow con la concreta possibilità di accedere con privilegi di root.
Ora ragioniamo per un attimo: perchè abbiamo citato così tanti bug in sistemi Unix e abbiamo parlato molto meno di sistemi NT? Bhe, è presto detto: Unix e tutti i Sistemi basati su di esso, sono robustissimi e particolarmente difficili da attaccare, tuttavia, un vero hacker tenterà il difficile e non l'ovvio, inoltre, come avrete notato, i problemi riscontrati su questi sistemi, non sono relativi al kernel (il cuore del sistema operativo), ma piuttosto, riguardano applicazioni ad esso correlate.
Sistemi NT soffrono di bachi che vengono corretti lentamente e sono miriadi, relativi spesso al S. e non solo agli applicativi con esso forniti, mentre Unix, resta robustissimo, ma soffre delle aggiunte che comunque dovremo avere a bordo.
Sia chiaro dunque che non esiste il sistema per eccellenza. Dipende troppo spesso dagli amministratori di sistema e di rete e, S. NT possono essere robusti se correttamente configurati, esattamente come un S. Unix.
L'elenco di bug relativo ai sistemi Unix Like e Windows, non termina sicuramente qui, tuttavia, la complessità dell'argomento ci impone di interrompere qui lo studio delle "falle", rimandandovi a due testi di sicuro interesse per ognuno di voi, dalla lettura dei quali, è stato tratto in buona parte questo corso:
HACKER PROOF - edito dalla McGrawill (anche se risale ormai a qualche tempo addietro e si aspetta un'aggiornamento degli argomenti in esso contenuti)
HACKER! 2.0 NUOVE TECNICHE DI PROTEZIONE DEI SISTEMI - edito dalla Apogeo, la cui prefazione, curata da Bruce Schneier (riconosciuto coem massimo esperto di sicurezza a livello mondiale), ci consente di considerare affidabilissimo il libro ed il suo contenuto.
Detto questo, vi lascio alle vostre considerazioni, sperando di aver chiarito qualcosa di oscuro e di essere stato utile in qualche modo, a divertire (perchè no???) con questa guida, che non ha mai voluto tediarvi e vi aspetto all'interno del forum per parlare ancora di tutto quello che può interessarvi.
A presto.