Come proteggersi dagli attacchi esterni V Parte
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.
V PARTE
--------------------------------------------------------------------------------
Bentornati a questa quinta parte di questo breve manuale.
Innanzitutto, è dovuta una piccola osservazione di ruolo: chi di voi stia leggendo questa guida nella speranza di poter apprendere come diventare un hacker, ha delle considerazioni da fare, ovvero:
- Penso davvero che per diventare un hacker basti leggere una guida?
- Sono sufficientemente curioso e pieno di me, da non fermarmi a ciò che apprenderò durante questo cammino?
- Sono sufficientemente motivato da rinunciare ad uscite con gli amici, in nome della mia sete di conoscenza?
Bhe, vedete, è importante sapere come risponderete a queste domande, perchè è da qui che potrete capire il perchè mi state leggendo.
Abbiamo detto che:
il punto di forza di un hacker è rappresentato dalle informazioni;
che le informazioni possono essere nascoste quasi sempre;
che non esiste un computer completamente sicuro, a meno che, non sia privo di collegamenti esterni;
che un S.O. ben amministrato, è sicuro come ogni altro;
che le password e le login possono essere rintracciate se lasciamo varchi aperti, tramite programmi (come scanner, sniffer ecc...)
Fatta questa premessa, ci sentiamo davvero pronti?
Se non pensate di possedere memoria sufficiente e pazienza e curiosità, lasciate perdere, troverete di meglio da leggere in edicola.
In caso contrario, potete sempre continuare a leggere.
COMINCIAMO
Dunque, parlavamo l'ultima volta, delle debolezze in genere, che si possono incontrare in un server, in particolare, parlavamo delle debolezze di WinNt.
Sebbene installando tutti i service pack e gli hotfix, si riesca a raggiungere un livello di sicurezza apprezzabile, potrebbe accadere, per incompetenza dell'amministratore o per incuria di alcuni all'interno dell'azienda, che un hacker riesca ad impossessarsi di login e password di qualcuno degli utenti.
Premesso che, per quanti di voi non conoscano a fondo le proprietà dei sistemi multiutente, esistono una serie di account che hanno libero accesso al server dall'esterno, pur senza avere diritti, mentre altri, che operando dalla sola macchina locale, possono avere diritti a volontà. In altre parole, un utente che possieda un account in locale, non è detto che lo possieda anche per accedere al server da remoto.
Premesso tutto ciò, si immagini di voler testare la sicurezza della propria rete.
Giusto per diritto di curiosità, date accesso a qualcuno alla vostra macchina, tramite telnet.
Se la vostra macchina è un Linux, potete avviare direttamente, un programmino che "di solito" viene installato automaticamente: lo SNIFFIT.
Quando darete accesso al vostro amico, vedrete contemporaneamente, all'interno dello SNIFFIT, tutto ciò che lui scriverà, in chiaro, sia login, che password.
Premesso che non stiamo parlando di "armi", ma di semplici utility, che possiedono praticamente tutti, adesso passiamo a vedere qualcosa di particolare.
Esistono, proprio per testare la sicurezza delle reti, diversi strumenti, che all'occorrenza possono essere utilizzati per scopi molto poco idilliaci.
Uno di questi strumenti, che nel corso del tempo ha subito notevoli variazioni e migliorie, è il L0phtcrac.
Questo strumento, che tuttavia necessita di una conoscenza di base di tutto ciò che gravita intorno alle reti ed ai protocolli, contiene al suo interno una serie di utility che potrete trovare alquanto interessanti, intercettati infatti alcuni dati, consente con una certa agilità, di de-criptare dati ed intercettare password di molti sistemi. Direte voi a questo punto: non di tutti? Bhe, il discorso è, che la sicurezza di ogni sistema dipende dal suo amministratore, oltre che dal sistema operativo in se stesso. Qualora fossero stati inseriti all'interno della password da amministratore, alcuni codici ascii, si potrebbe pensare, in buona sostanza, che non si potrebbe risalire a quella password (diciamo pure che l'impossibile non esiste, esistono comunque dei limiti, chi riesce a superarli, non fa certo parte della normale schiera di comuni mortali).
Dunque, per i sostenitori dei sistemi Unix Like, si ricordi che neanche un sistema Linux è perfetto, infatti, dando vita ad una sessione telnet, possiamo facilmente risalire a password e login. Ricordatelo sempre, la sicurezza non fa parte del solo sistema, ma di chi lo amministra!!!!
Un piccolo aiuto per chi voglia avere chiare le cose, su WINNT, è rappresentato dalla protezione del SAM. Il SAM (Security Account Manager) è infatti il potere assoluto per un hacker, che potrebbe tanto più essere avvantaggiato, quanto minori siano gli aggiornamenti fatti al sistema.
Il SAM contiene infatti tutte le password e le login degli utenti della macchina in questione.
Certo, dovrebbe avere avuto accesso come amministratore per poterlo prelevare, ma probabilmente voi non vorrete perdere tutti i vostri dati formattando, dunque avrà pensato di creare il suo dominio intorno a voi, prendendo possesso di tutto ciò che poteva.
Se un hacker riesce a prelevare il SAM, avrà una sorta di file criptato in mano, di cui noi probabilmente non sapremmo cosa fare... tuttavia, lui potrà avere accesso a tutte le risorse del vostro computer, impadronendosi delle chiavi necessarie a far ciò che vuole.
Lo strumento che potrà utilizzare per de-criptare il file SAM, sarà ovviamente il sopracitato L0phtcrac. Con questo mezzo, sfruttando alcune debolezze degli Hash (potremmo definirli "intestazioni" per i neofiti), di WinNt, avrà in mano, se non tutte, almeno buona parte delle chiavi che lo interessano.
L0phtcrac è soltanto un mezzo per accedere, non solo alle chiavi di decriptazione, ma anche alle informazioni tante volte citate, di cui necessita un hacker, prima di passare all'attacco.
È ovviamente un programma in vendita, ma il suo costo è assolutamente accessibile, in particolar modo, se volete testare degnamente la solidità della vostra rete e, il suo scopo non si esaurisce certo con la decriptazione di chiavi NT, ma come ovvio, si allarga a tutti i sistemi (pur se molti di questi daranno ai nostri attaccanti non poche difficoltà).
Il trucco per una buona protezione sta sempre nel mantenere aggiornato il nostro sistema, non aggiungendo fronzoli stupidi, né demoni che non abbiano utilità e che potrebbero tranquillamente essere sfruttati come punto debole da chiunque.
Tralasciando per un attimo i problemi relativi a WinNt, apriamo una parentesi parlando dei Sistemi Unix Like.
Una possibile falla, che potremmo trovare in tutti i sistemi basati su Unix, è costituita dal kernel stesso (il cuore del sistema operativo), infatti, per quanto assurdo possa apparire ad una prima analisi, vi è una piccola, microscopica, possibilità per un attaccante, di sfruttare un vostro errore.
Il kernel Linux (e *BSD) può essere monolitico (avendo incorporati tutti i moduli) o modulare (composto da moduli che verranno caricati dal kernel solo quando se ne porrà il bisogno).
Qualora aveste deciso di implementare un server web (per assurdo), con una componente modulare del kernel, sappiate che state creando una possibile via d'accesso.
Diciamo che il vostro kernel modulare, preveda (magari per noncuranza) il caricamento del modulo relativo alla scheda audio (non sempre, anzi, quasi mai presente su un server web), un attaccante (riuscito ad ottenere i necessari permessi) potrebbe caricare un modulo finto (scritto da lui) che contenga, invece delle informazioni necessarie al funzionamento della scheda audio, le impostazioni per l'accesso al sistema in maniera assolutamente proprietaria. A questo punto, per caricare il modulo, non dovrà far altro che eseguire in locale, un file midi (non ci vogliono abilità particolari, se è giunto a questo punto, l'esecuzione di musica all'interno della data cartella, infatti, è generalmente abilitato anche ad utenti senza particolari permessi). A questo punto, il kernel, credendo di aver caricato il modulo adatto, darà accesso al nostro attaccante, senza opporre resistenza alcuna.
So bene che agli occhi della maggior parte di voi, questa pratica risulterà assolutamente impossibile, se non, almeno improbabile, eppure, si riesce tranquillamente ad ottenere un accesso di questo tipo.
Dunque, non elogiate troppo i sistemi, che la maggior parte di voi non conoscono neanche, per il solo fatto, che un amico "esperto", gli ha garantito, che la sicurezza del Linux (o similari) è senza pari.
La sicurezza dipende sempre da voi e dagli errori che farete, consapevolmente o meno che sia.
Nelle prossime lezioni (purtroppo saranno poche altre) parleremo di come sfruttare i bug di buffer overflow, cosa sono e perchè.
Per ora, vi lascio a meditare su quanto abbiamo detto in questo capitolo.
A cura di:
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.
V PARTE
--------------------------------------------------------------------------------
Bentornati a questa quinta parte di questo breve manuale.
Innanzitutto, è dovuta una piccola osservazione di ruolo: chi di voi stia leggendo questa guida nella speranza di poter apprendere come diventare un hacker, ha delle considerazioni da fare, ovvero:
- Penso davvero che per diventare un hacker basti leggere una guida?
- Sono sufficientemente curioso e pieno di me, da non fermarmi a ciò che apprenderò durante questo cammino?
- Sono sufficientemente motivato da rinunciare ad uscite con gli amici, in nome della mia sete di conoscenza?
Bhe, vedete, è importante sapere come risponderete a queste domande, perchè è da qui che potrete capire il perchè mi state leggendo.
Abbiamo detto che:
il punto di forza di un hacker è rappresentato dalle informazioni;
che le informazioni possono essere nascoste quasi sempre;
che non esiste un computer completamente sicuro, a meno che, non sia privo di collegamenti esterni;
che un S.O. ben amministrato, è sicuro come ogni altro;
che le password e le login possono essere rintracciate se lasciamo varchi aperti, tramite programmi (come scanner, sniffer ecc...)
Fatta questa premessa, ci sentiamo davvero pronti?
Se non pensate di possedere memoria sufficiente e pazienza e curiosità, lasciate perdere, troverete di meglio da leggere in edicola.
In caso contrario, potete sempre continuare a leggere.
COMINCIAMO
Dunque, parlavamo l'ultima volta, delle debolezze in genere, che si possono incontrare in un server, in particolare, parlavamo delle debolezze di WinNt.
Sebbene installando tutti i service pack e gli hotfix, si riesca a raggiungere un livello di sicurezza apprezzabile, potrebbe accadere, per incompetenza dell'amministratore o per incuria di alcuni all'interno dell'azienda, che un hacker riesca ad impossessarsi di login e password di qualcuno degli utenti.
Premesso che, per quanti di voi non conoscano a fondo le proprietà dei sistemi multiutente, esistono una serie di account che hanno libero accesso al server dall'esterno, pur senza avere diritti, mentre altri, che operando dalla sola macchina locale, possono avere diritti a volontà. In altre parole, un utente che possieda un account in locale, non è detto che lo possieda anche per accedere al server da remoto.
Premesso tutto ciò, si immagini di voler testare la sicurezza della propria rete.
Giusto per diritto di curiosità, date accesso a qualcuno alla vostra macchina, tramite telnet.
Se la vostra macchina è un Linux, potete avviare direttamente, un programmino che "di solito" viene installato automaticamente: lo SNIFFIT.
Quando darete accesso al vostro amico, vedrete contemporaneamente, all'interno dello SNIFFIT, tutto ciò che lui scriverà, in chiaro, sia login, che password.
Premesso che non stiamo parlando di "armi", ma di semplici utility, che possiedono praticamente tutti, adesso passiamo a vedere qualcosa di particolare.
Esistono, proprio per testare la sicurezza delle reti, diversi strumenti, che all'occorrenza possono essere utilizzati per scopi molto poco idilliaci.
Uno di questi strumenti, che nel corso del tempo ha subito notevoli variazioni e migliorie, è il L0phtcrac.
Questo strumento, che tuttavia necessita di una conoscenza di base di tutto ciò che gravita intorno alle reti ed ai protocolli, contiene al suo interno una serie di utility che potrete trovare alquanto interessanti, intercettati infatti alcuni dati, consente con una certa agilità, di de-criptare dati ed intercettare password di molti sistemi. Direte voi a questo punto: non di tutti? Bhe, il discorso è, che la sicurezza di ogni sistema dipende dal suo amministratore, oltre che dal sistema operativo in se stesso. Qualora fossero stati inseriti all'interno della password da amministratore, alcuni codici ascii, si potrebbe pensare, in buona sostanza, che non si potrebbe risalire a quella password (diciamo pure che l'impossibile non esiste, esistono comunque dei limiti, chi riesce a superarli, non fa certo parte della normale schiera di comuni mortali).
Dunque, per i sostenitori dei sistemi Unix Like, si ricordi che neanche un sistema Linux è perfetto, infatti, dando vita ad una sessione telnet, possiamo facilmente risalire a password e login. Ricordatelo sempre, la sicurezza non fa parte del solo sistema, ma di chi lo amministra!!!!
Un piccolo aiuto per chi voglia avere chiare le cose, su WINNT, è rappresentato dalla protezione del SAM. Il SAM (Security Account Manager) è infatti il potere assoluto per un hacker, che potrebbe tanto più essere avvantaggiato, quanto minori siano gli aggiornamenti fatti al sistema.
Il SAM contiene infatti tutte le password e le login degli utenti della macchina in questione.
Certo, dovrebbe avere avuto accesso come amministratore per poterlo prelevare, ma probabilmente voi non vorrete perdere tutti i vostri dati formattando, dunque avrà pensato di creare il suo dominio intorno a voi, prendendo possesso di tutto ciò che poteva.
Se un hacker riesce a prelevare il SAM, avrà una sorta di file criptato in mano, di cui noi probabilmente non sapremmo cosa fare... tuttavia, lui potrà avere accesso a tutte le risorse del vostro computer, impadronendosi delle chiavi necessarie a far ciò che vuole.
Lo strumento che potrà utilizzare per de-criptare il file SAM, sarà ovviamente il sopracitato L0phtcrac. Con questo mezzo, sfruttando alcune debolezze degli Hash (potremmo definirli "intestazioni" per i neofiti), di WinNt, avrà in mano, se non tutte, almeno buona parte delle chiavi che lo interessano.
L0phtcrac è soltanto un mezzo per accedere, non solo alle chiavi di decriptazione, ma anche alle informazioni tante volte citate, di cui necessita un hacker, prima di passare all'attacco.
È ovviamente un programma in vendita, ma il suo costo è assolutamente accessibile, in particolar modo, se volete testare degnamente la solidità della vostra rete e, il suo scopo non si esaurisce certo con la decriptazione di chiavi NT, ma come ovvio, si allarga a tutti i sistemi (pur se molti di questi daranno ai nostri attaccanti non poche difficoltà).
Il trucco per una buona protezione sta sempre nel mantenere aggiornato il nostro sistema, non aggiungendo fronzoli stupidi, né demoni che non abbiano utilità e che potrebbero tranquillamente essere sfruttati come punto debole da chiunque.
Tralasciando per un attimo i problemi relativi a WinNt, apriamo una parentesi parlando dei Sistemi Unix Like.
Una possibile falla, che potremmo trovare in tutti i sistemi basati su Unix, è costituita dal kernel stesso (il cuore del sistema operativo), infatti, per quanto assurdo possa apparire ad una prima analisi, vi è una piccola, microscopica, possibilità per un attaccante, di sfruttare un vostro errore.
Il kernel Linux (e *BSD) può essere monolitico (avendo incorporati tutti i moduli) o modulare (composto da moduli che verranno caricati dal kernel solo quando se ne porrà il bisogno).
Qualora aveste deciso di implementare un server web (per assurdo), con una componente modulare del kernel, sappiate che state creando una possibile via d'accesso.
Diciamo che il vostro kernel modulare, preveda (magari per noncuranza) il caricamento del modulo relativo alla scheda audio (non sempre, anzi, quasi mai presente su un server web), un attaccante (riuscito ad ottenere i necessari permessi) potrebbe caricare un modulo finto (scritto da lui) che contenga, invece delle informazioni necessarie al funzionamento della scheda audio, le impostazioni per l'accesso al sistema in maniera assolutamente proprietaria. A questo punto, per caricare il modulo, non dovrà far altro che eseguire in locale, un file midi (non ci vogliono abilità particolari, se è giunto a questo punto, l'esecuzione di musica all'interno della data cartella, infatti, è generalmente abilitato anche ad utenti senza particolari permessi). A questo punto, il kernel, credendo di aver caricato il modulo adatto, darà accesso al nostro attaccante, senza opporre resistenza alcuna.
So bene che agli occhi della maggior parte di voi, questa pratica risulterà assolutamente impossibile, se non, almeno improbabile, eppure, si riesce tranquillamente ad ottenere un accesso di questo tipo.
Dunque, non elogiate troppo i sistemi, che la maggior parte di voi non conoscono neanche, per il solo fatto, che un amico "esperto", gli ha garantito, che la sicurezza del Linux (o similari) è senza pari.
La sicurezza dipende sempre da voi e dagli errori che farete, consapevolmente o meno che sia.
Nelle prossime lezioni (purtroppo saranno poche altre) parleremo di come sfruttare i bug di buffer overflow, cosa sono e perchè.
Per ora, vi lascio a meditare su quanto abbiamo detto in questo capitolo.
Ultima modifica: