Guida all'Hacking v. 0.5
2001-09-17
When I was 16, I used to write articles under the nicknames Esorcista and XpTerminator.
The following is a "hacking" manual that got published on the 4th issue of OndaQuadra, an Italian e-zine.
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [HACKiNG] #03 - 17/09/2001 |
| GUiDA ALL'HACKiNG v. 0.5 [Xp Terminator] 0x09/0x29 |
+-------------------------------------------------------------------------------+
Powered by vi rulez ;)
Voglio premettere innanzi tutto che questa guida, non spiega
ne come entrare nel server del Pentagono, ne in quello della
NASA, da solo un'idea generale dei vari scenari che si possono
presentare durante un hackaggio. Spiega le varie e più diffuse
tecniche di occultamento e falsificazione dell'IP ed insieme
spiega trucchi su come compiere attacchi sia ad alto livello,
sia a basso livello come l'hijacking del protocollo TCP.
Ricordo inoltre che in questa guida vengono sorvolati argomenti
pur importanti come le shell, i comandi unix, il cracking delle password,
che si intendono come "conoscenza base" per poter continuare.
Quindi un consiglio per chi legge è che abbia già letto un'altra
guida base all'hacking...nonostante questo però la prima parte
della guida può essere letta anche da un newbie, magari saltando
le parti che sembrano più complesse.
DISCLAIMER
==========
Questo documento è stato sviluppato solo per scopo educativo, per
aiutare a capire le reti, ed aiutare i sysadmin a difendersi da eventuali
attacchi descritti in questo documento. Di conseguenza l'autore del
testo non si assume nessuna responsabilità su ciò che venga fatto
tramite queste informazioni, e non ne incita l'utilizzo per scopi fraudolenti.
Ok?
Iniziamo...
Dedicated to: La fantastica Delilah, tutti gli amici di #hack e quelli che mi conoscono!
Fuck to: oggi mi sento buono :)
INDICE DELLA GUIDA
==================
Capitolo 1°
- Introduzione
- Argomenti trattati
PARTE PRIMA DELLA GUIDA
- TCP/IP
- TECNICHE DI ANONIMIZZAZIONE "SEMPLICI"
Capitolo 2°
- Caller line identification
- Account internet
Capitolo 3°
- TCP/IP
- Introduzione al protocollo TCP e al protocollo IP
- Three-way-handshake
Capitolo 4°
- Tecniche elementari di anonimizzazione
- Tramiti web
- Proxy
- Connessioni concatenate tramite telnet
- "Passerelle ad hoc"
- Inviare email quasi anonime
- Inviare email anonime al 100% (solo con linux)
PARTE SECONDA DELLA GUIDA
- TECNICHE DI ANONIMIZZAZIONE COMPLESSE
- ARP/RARP/MAC
- HIJACK CON ATTACCHI ARP
- CONCLUSIONI DELLA GUIDA
Capitolo 5°
- Tecniche avanzate di anonimizzazione
- IP spoofing
- Spoofing cieco e non
- Hijacking (la mia tecnica preferita ;)
(consiglio di leggere attentamente i prossimi due capitoli, i più ricchi di
info interessanti :)
Capitolo 6°
- ARP , RARP , MAC
- Proxy ARP
Capitolo 7°
- Hijack al protocollo TCP tramite attacco ARP
- Vulnerabilità ed attacchi
- Hijack ad una connessione TCP
- Attacchi DoS
- Dimostrazione pratica di un attacco hijack
- Attacco
- Protezioni e contromisure
- Protezione
- Detenzione
- Conseguenze e perdite
- Perdite per le vittime
- Motivazioni per un attacco ARP - hijack
- Conclusioni
Capitolo 8°
- Conclusioni della guida
- Fonti
CAPITOLO PRIMO
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
INTRODUZIONE E ARGOMENTI TRATTATI
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
La preoccupazione principale di chiunque entra illecitamente in un
sistema è quella di nascondere le proprie tracce, al fine di mantenere
nascosta la propria posizione reale, o almeno di rendere la propria
localizzazione la più difficoltosa possibile. Per l'importanza di questo
argomento ho cercato di rendere questo testo il più completo possibile
in ambito di tecniche di anonimizzazione, cercando di renderlo semplice
ma allo stesso tempo trattando argomenti più o meno complessi.
Tratterò le "basi di internet", prima ad alto livello descrivendo TCP/IP
e poi più a basso livello descrivendo ARP/RARP/MAC, utili per comprendere
come funzionano le tecniche di anonimizzazione. Descriverò le maggiori
tecniche di anonimizzazione, dalle più semplici, come la concatenazione
di connessioni, alle più complesse, come l'ip spoofing ed i vari derivati,
e tratterò nella parte finale della guida, tecniche di attacco a basso
livello utilizzando l'hijacking sul protocollo TCP tramite attacco ARP.
La prima parte della guida è scritta per i newbie, quindi se non siete
tali, vi consiglierei di passare direttamente alla seconda, per non
rischiare di annoiarvi, dato che avrete letto queste cose almeno un
milione di volte :).
PARTE PRIMA DELLA GUIDA
CAPITOLO SECONDO
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Caller line identification & Account internet falso
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Per essere sicuri di avere il massimo dell'anonimità possibile bisogna
analizzare il nostro "percorso" fin dall'inizio, per cercare di rimanere
il numero minore di tracce "per la strada" che possano far ricondurre a noi,
quindi partiremo dal nostro dial-in verso l'ISP (in parole povere, la nostra
chiamata telefonica verso il fornitore del servizio internet
(ISP = internet service provider)).
Quando chiamiamo qualcuno il CLI (caller line identification) invia il
nostro numero telefonico a colui che chiamiamo, che quindi può vedere il
nostro numero in tempo reale. Naturalmente ciò avviene anche quando chiamiamo
il nostro ISP. Per evitare quindi che l'ISP possa vedere il nostro numero,
ci viene in aiuto il BIC (blocco identificazione chiamante), il quale
disabilita in parte il CLI (dico in parte, perchè il nostro numero telefonico
rimarrà sempre sui tabulati della telecom). Per utilizzare il BIC basta
inserire il numero 1793 oppure *67# davanti al numero da chiamare, ed in questo
caso davanti al numero del nostro ISP.
Il secondo passo da compiere, è connettersi tramite un account falso. Infatti,
se per esempio stiamo hackando un sistema, e non prendiamo le giuste
precauzioni, il sysadmin tramite il nostro ip potrebbe risalire al nostro
account, e se non abbiamo un account falso, verrebbe subito a conoscenza della
nostra vera identità, di dove abitiamo, ecc...
Quindi, cosa importante, è registrarsi un account falso, ed ancora più
importante è essere anonimi quando lo registriamo, quindi utilizziamo il BIC ed
un proxy o un anonimizzatore per raggiungere la pagina di registrazione
(guarda il cap. successivo).
Per quanto riguarda i dati falsi da inserire, si potrebbero mettere dati senza
senso, ma visto che spesso i provider richiedono anche il codice fiscale,
è utile utilizzatore un generatore di identità come quello di
Cavallo De Cavallis.
CAPITOLO TERZO
=====================================================
Questo capitolo in alcune parti può risultare
di difficile comprensione, soprattutto se si è
alle prime armi; naturalmente non preoccupatevi,
molte delle informazioni sono state aggiunte solo
per i più "curiosi" (il three-way-handshake), e
quindi, se volete, leggetevi velocemente l'inizio
e saltate direttamente al cap. successivo :))
=====================================================
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
TCP/IP
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Per poter iniziare a descrivere le prime semplici tecniche per anonimizzarsi,
è giusto sapere prima su cosa si basano, come funzionano, e quindi bisogna
prima conoscere il protocollo TCP ed il protocollo IP, cose fondamentali
da sapere per avere una idea di cosa sia la rete almeno ad alto livello.
Il TCP (transfer control protocol) è il protocollo di trasferimento dati più
utilizzato in rete, insieme al UDP (user datagram protocol). La differenza tra
i due è fondamentale, infatti, mentre l'UDP invia i dati e basta, il TCP
si accerta che questi arrivino a destinazione, e quindi è un protocollo
maggiormente affidabile.
Qualunque operazione facciamo in rete, il protocollo TCP non fa altro che
inviare pacchetti contenenti dati diversi a seconda della situazione. Tutto
ciò però è possibile grazie ad un altro protocollo, l'IP (internet protocol)
ovvero il vero pilastro della "grande rete" internet.
L'indirizzo IP (composto da 4 numeri da 8 bit) serve ad identificare una
macchina univocamente in una rete TCP/IP, ed è quindi in parole povere come
la carta d'identità di una macchina all'interno di internet e di conseguenza
è ciò che dobbiamo nascondere per renderci anonimi.
Per capire l'importanza dell'IP e la difficoltà nel nasconderlo o falsificarlo
faccio subito un semplice esempio:
Immaginiamo le poste. Quando vogliamo inviare una lettera a qualcuno, bisogna
indicare sulla busta l'indirizzo a cui dovrà essere recapitata, e se si vuole
che il destinatario ci possa anche rispondere dobbiamo anche indicare
l'indirizzo a cui si desidera ricevere la risposta. Se non si indica un
recapito ne sulla busta, ne all'interno delle lettera, il ricevente non avrà
possibilità di risponderci e quindi avremo inviato una lettera anonima.
Questo succede anche col protocollo TCP, nel quale però gli indirizzi sono
rappresentati dagli indirizzi IP. Se non usiamo nessuna precauzione ci penserà
il nostro programma gestore del protocollo TCP a riempire il campo del source
IP col nostro ip. Naturalmente noi possiamo facilmente modificare questo
campo utilizzando diversi metodi (come per es. sockets raw),ma purtroppo come
nell'esempio non saremo più in grado di ricevere alcuna risposta dalla
macchina che abbiamo contattato, e quindi non sarà servito a nulla, l'unico
aiuto che ci può dare modificare l'indirizzo del mittente è essere anonimi
quando effettuiamo "manovre" in cui non avremo bisogno di risposte dal server
(per esempio attacchi DoS (denial of service) (vedi capitolo settimo, sezione
Attacchi DoS)) o quando utilizzeremo tecniche come l'ip spoofing (vedi capitoli
successivi).
Per capire cosa contengono questi pacchetti inviati dal protocollo TCP, ecco
uno schema che rappresenta un tipico pacchetto:
__________________________________________________________
| SOURCE IP | TARGET IP |
|_______________________________|__________________________|
| TCP LENGTH | SOURCE PORT |TARGET PORT | SEQ | ACK|
|______________|________________|_____________|_______|____|
| FLAGS | WINDOW |TCP CHECKSUM | UrgPtr |
|______________|________________|_____________|____________|
| CONTENUTO DATI DEL PACCHETTO |
|__________________________________________________________|
Tutti i dati all'interno del pacchetto sono in formato esadecimale.
Ecco cosa contiene ognuno di questi campi:
- Source ip : indirizzo ip del "mittente"
- Target ip : indirizzo ip del "destinatario"
- Target port : porta del server alla quale inviare il pacchetto
- Tcp checksum : campo per il controllo dell'integrità dei dati
- Dati : i dati da inviare
- Flags : guarda gli esempi del three-way-handshake
- Seq : il numero di serie che il protocollo TCP assegna ad ogni
pacchetto, ovvero il numero che identifica univocamente il pacchetto,
in modo da poter, ad esempio, scartare duplicati e correggere certi
errori che potrebbero prodursi durante la connessione.
(come vedremo più avanti con le tecniche di ip spoofing, questo
aspetto dei pacchetti rende assai più difficile l'attuamento della
falsificazione dei pacchetti...)
- Gli altri campi possono essere sorvolati per non scendere troppo
nei particolari
Per avere una propria "esperienza", vi consiglio di utilizzare un qualunque
tcp sniffer, e di sniffarvi la vostra connessione, per poi vedere i pacchetti
che il vostro pc ha inviato e ricevuto durante lo sniffing.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
THREE WAY HANDSHAKE
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Prima di poter comunicare con un server o un pc in rete, i due host hanno
bisogno di scambiarsi delle informazioni per poi iniziare il vero dialogo
(Naturalmente anche queste informazioni sono dei pacchetti).
Questa operazione pre-dialogo col server è chiamata three-way-handshake,
infatti si compone di tre fasi, ovvero le seguenti:
================================================================
[Questa seguente parte sul three-way-handshake è stata tratta da
"Tecniche di scanning" articolo del grande Tritemius, pubblicato
su Onda Quadra 0]
================================================================
1) il client invia un pacchetto con il solo flag SYN attivo nel campo FLAGS
(vedi tabella sopra)
2) il server risponde; la risposta può essere di 2 tipi:
porta aperta o porta chiusa, se la porta è chiusa il server risponderà
con un pacchetto con i flag ACK RST, se invece è aperta, risponderà
con un pacchetto con i flag SYN e ACK.
3) il client invia un pacchetto ACK al server e può avere inizio il vero
dialogo tra client e server (sempre se la porta era aperta...)
Questo in modo molto semplificato, senza considerare i valori di ISN
(initial sequence number) e ack.
Un esempio pratico di pacchetti inviati durante il three-way-handshake:
(pacchetti sniffati da butsniffer, ottimo sniffer per Windows)
Il client invia SYN, questo lo vediamo nel campo "Flags":
la "S" sta appunto per SYN.
Source IP: 192.168.0.1 Target IP: 192.168.0.2
TCP Length: 0 Source Port: 1032 Target Port: 1080
Seq: 1E8734B7 Ack: 00000000
Flags: S Window: 32120 TCP ChkSum: 11901 UrgPtr: 0
il server risponde con SYN ACK: la porta e' aperta.
Source IP: 192.168.0.2 Target IP: 192.168.0.1
TCP Length: 0 Source Port: 1080 Target Port: 1032
Seq: 00116211 Ack: 1E8734B8
Flags: SA Window: 8760 TCP ChkSum: 54467 UrgPtr: 0
il client invia ACK: il three-way-handshake e' concluso con successo,
inizia la trasmissione di dati.
Source IP: 192.168.0.1 Target IP: 192.168.0.2
TCP Length: 0 Source Port: 1032 Target Port: 1080
Seq: 1E8734B8 Ack: 00116212
Flags: A Window: 32120 TCP ChkSum: 64270 UrgPtr: 0
In questo caso la porta era aperta...
CAPITOLO QUARTO
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
TECNICHE ELEMENTARI DI ANONIMIZZAZIONE
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Come visto nel capitolo precedente, prima di poter comunicare con un
server, bisogna connettercisi, e ciò tramite il three-way-handshake.
Quindi se per esempio vorremmo tramite il nostro browser web visitare
un sito (per esempio http://xpterminator.cjb.net ;) e modifichiamo
il campo del source ip per essere anonimi, questa connessione non potrà
mai avvenire, poichè il server non risponderà a noi, ma all'ip che abbiamo
inserito...
Ciò complica l'anonimità in rete, e non di poco, ed uno dei primi metodi
che potrebbe venire in mente per poter essere anonimi è quello di stabilire
la connessione da un'altra macchina, ovvero utilizzare una macchina
intermedia per mezzo della quale stabilire la connessione. Il vantaggio
di questo tipo di tecnica consiste nel poter usare i soliti client di
rete per connettersi ai vari servizi (browser web, client ftp, client di
posta elettronica, ecc..).
Esistono diversi metodi per stabilire connessioni verso un server da una
macchina non nostra..ecco i principali:
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
TRAMITI WEB
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Con l'aumento di popolarità del web come servizio internet, sono nati tanti
servizi ad esso dedicati. Uno di questi è quello che ci permette di
raggiungere una pagina web tramite un'altra senza mostrare il nostro indirizzo
reale, ma bensì quello della macchina dalla quale abbiamo effettuato la
connessione; ciò è possibile tramite script CGI o applet java.
Ecco un esempio di ciò che avviene:
______________ _______________ ___________
| 123.45.67.89 | ---> | 222.111.12.21 | --> |111.111.1.2|
-------------- --------------- -----------
IL NOSTRO PC TRAMITE WEB NOSTRO OBIETTIVO
ed ecco cosa avviene:
1)contattiamo il tramite web, e ci connettiamo ad esso
2)inviamo al tramite web, ciò che "deve fare"
3)il tramite web si connette al nostro obiettivo
4)il tramite web "fa quello che deve fare" ovvero preleva la pagina web da noi
richiesta
5)il nostro obiettivo invia la pagina web al tramite web
6)il tramite web invia la pagina ottenuta dall'obiettivo a noi
7)il nostro browser web visualizza la pagina ricevuta
Quindi tra i log del nostro obiettivo rimarrà l'ip 222.111.12.21 (naturalmente
in questo esempio) invece che 123.45.67.89. Purtroppo il nostro ip però
rimarrà sempre nei log del tramite web....
La forma più solita che assume un tramite web è: http://www.server.com/-_-
Dopo -_- noi dobbiamo inserire il nostro obiettivo, esempio:
http://www.server.com/-_-http://www.microsoft.com
Spesso un tramite web può assumere anche la seguente forma:
http://www.server.com/cgi-bin/nomecgi?
(dove nomecgi può assumere qualunque nome)
esempio:
http://www.server.com/cgi-bin/nomecgi?http://www.microsoft.com
Come sicuramente avrete intuito per ottenere ancora una maggiore anonimità è
un ottimo metodo concatenare i tramiti web (per un ottimo livello di anonimità
bisogna concatenare almeno 4 tramiti web, ma ricordate che più se ne
concatenano più diventa lenta la connessione!).
Esempio:
http://www.server.com/-_-http://www.server2.com/-_-http://www.server3.com/cgi-bin/anony?http://www.microsoft.com
Concettualmente il tramite web agisce ugualmente al proxy.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
PROXY
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Come già detto i proxy funzionano ugualmente ai tramiti web.
Ecco un semplice esempio che fa capire cos'è un proxy e come funziona:
Supponiamo che un'università possegga una rete locale comprendente cinquanta
macchine, e desidera dotarle tutte di accesso internet. L'università avrà
bisogno di contrattare cinquanta indirizzi ip perchè queste macchine possano
accedere alla rete, cosa che in molti casi risulta infattibile e poco pratico.
Esiste una soluzione molto più semplice, cioè utilizzare un proxy.
Quindi l'università otterrà un solo indirizzo ip per accedere ad internet,
il quale verrà assegnato ad una sola macchina che esegue un programma speciale
generalmente conosciuto con il nome di proxy. Questa macchina proxy sarà la
rappresentante in internet di tutte le macchine della rete interna. Quando una
di queste richiederà un dato ad un server di internet, in realtà lo richiederà
al proxy. Quest'ultimo si occuperà di fare la richiesta reale e convoglierà la
risposta alla macchina della rete interna. Con questa configurazione il server
internet riceverà richieste da un solo indirizzo ip, quello assegnato al
proxy, anche se queste richieste hanno origine in macchine della rete interna,
ma non hanno un indirizzo ip valido.
Da ciò ci si può fare già una idea di come occultare il proprio indirizzo ip;
infatti, molto spesso i proxy non vengono configurati bene, ed invece di
permettere l'accesso tramite di esso alle sole macchine della rete interna,
permettono il loro utilizzo da parte di qualunque macchina (spesso alcuni
proxy sono creati apposta per essere utilizzati da qualunque macchina).
Quindi, basta che inviamo la richiesta al proxy e lui farà ciò che vogliamo
per noi, proprio come i tramiti web. A differenza dei tramiti web però non
dovremo inserire un url aggiuntivo davanti quello da raggiungere, ma dovremo
settare il nostro browser per mandare le nostre richieste al server proxy ad
una determinata porta che può cambiare da proxy a proxy.
Ciò però non è semplice come può sembrare infatti spesso i proxy manterranno
un registro di tutte le connessioni stabilite, in modo che se dovesse
risultare tramite di un attacco, l'amministratore del sistema colpito possa
contattare l'amministratore del proxy che esaminando il registro gli possa
fornire l'indirizzo ip reale dell'attaccante.
Raramente i proxy vengono installati da soli, è consuetudine infatti
utilizzarli in simbiosi con un firewall. La macchina contenente il firewall
(spesso la stessa in cui è installato il proxy) disporrà di due adattatori di
rete. Com'è logico, anche il proxy deve possedere due adattatori di rete per
assolvere alle sue funzioni. Un adattatore sarà connesso alla rete interna che
s'intende proteggere, che riferendoci al nostro esempio è la rete di cinquanta
computer, mentre l'altro sarà connesso ad internet.
Il firewall verrà configurato con una serie di regole che scarteranno alcuni
pacchetti con contenuti anomali. Verranno scartati anche pacchetti che
arrivino dall'adattatore connesso alla rete interna con destinazione esterna,
facendo così che le macchine della rete non possano essere utilizzate con la
tecnica dello spoofing (guarda cap. successivi). Verrà scartato inoltre
qualunque pacchetto proveniente dall'adattatore esterno e diretto ad una
macchina esterna. Questo è il caso dell'intruso che tenta di utilizzare il
proxy per occultare il proprio indirizzo ip. La configurazione corretta dei
firewall è in generale abbastanza complicata ed esistono in commercio testi di
considerevole mole che trattano il tema.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
CONNESSIONI CONCATENATE TRAMITE TELNET
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Un altro metodo per utilizzare un computer intermedio è quello di concatenare
più connessioni utilizzando telnet, ovvero "telnettandosi". In parole povere
tramite telnet ci si connette ad una propria shell, dalla quale poi è
possibile connettersi ad un altra, e così via, finchè non ci si telnetta
direttamente nel server da attaccare. Quindi la macchina attaccata vedrà il
numero ip del server del nostro ultimo shell account utilizzato e non il
nostro. Anche questo metodo però ha i suoi problemi...infatti oltre ad essere
complesso da attuare, (bisogna trovarsi degli account shell in rete che diano
la possibilità di utilizzare servizi come telnet, ftp, rlogin, irc, ecc..e di
gratuiti non credo che ne esistano (ma si possono sempre hackare ;) ), ha il
difetto che la localizzazione dell'origine della connessione è relativamente
semplice...almeno chè... :) almeno che non facciamo in modo di "compromettere"
almeno una delle macchine utilizzate. Ecco spiegato un pò il concetto....
Quando il sysadmin del server attaccato vedrà l'ip (falso) dell'attaccante,
gli basterà collegarcisi e guardare il syslogd di questo, dal quale otterrà
un'altro indirizzo ip (la penultima macchina utilizzata), e ripetendo la stessa
operazione più volte giungerà fino a noi, ovvero fino al nostro reale indirizzo ip.
Come ho detto in precedenza, questo è possibile solo se non abbiamo
compromesso almeno una delle macchine utilizzate. Ma noi siamo in gamba e lo
faremo :). Ciò che dobbiamo fare e riuscire ad hackare una delle macchine
tramite la quale ci colleghiamo, in modo da poter essere root. Il fattore più
importante qui è la velocità. Infatti finito l'attacco, dovremmo uscire dalla
sessione telnet aperta, poi uscire anche dall'altra fino a rimanere a quella
della quale abbiamo la # (root! ;). Qui dobbiamo eliminare tutte le nostre
tracce dai log di sistema (non dimenticate niente!), di cui in questa guida
non parlo, e subito dopo uscire anche da questa sessione telnet. Dico di
fare subito, perchè se il sysadmin è un tipo in gamba, ed è veloce, può
darsi che arrivi prima che noi cancelliamo i log, o ancora peggio può darsi
che noi abbiamo già cancellato i log ma siamo ancora connessi su quel server,
quindi al sysadmin basterà fare un semplice netstat per vedere la nostra
connessione (un consiglio è quello, se è possibile, di compromettere i log
su più di una sola macchina).
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
"PASSERELLE AD HOC"
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Passerelle ad hoc, ovvero, dei "passaggi segreti" che ci creiamo noi stessi.
Questo metodo di anonimizzazione è uguale ai precedenti visti, infatti si
utilizza una macchina intermedia per effettuare la connessione al server
finale. La differenza tra le altre tecniche è che questi passaggi segreti ce
li costruiamo noi. Per esempio, riusciamo ad hackare un server divenendo il
root? Allora ci installiamo un programma proxy su una porta a nostra scelta
e cerchiamo di non dirlo a nessuno. Quindi poi utilizzeremo questo server
hackato come un qualunque proxy. Naturalmente se ci abbiamo installato il
programma proxy significa che abbiamo ottenuto la root shell e quindi è buona
abitudine inserire delle backdoor per poter rientrare in futuro, anche se il
sysadmin cambia la propria password; ciò ci sarà utile per poter ripulire i
log del sistema utilizzato da proxy, dopo aver effettuato le nostre
connessioni. Ricordatevi sempre di usare una concatenazione di connessioni
quando vi collegate al server manomesso, come visto precedentemente, e
prendete sempre le giuste precauzioni. Se fate tutto per bene, e quindi
ripulite tutti i log per bene, avrete una anonimità del 100%, rimarrà solo
l'ip dell'host manomesso nei log del server al quale ci siamo collegati.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
INVIARE E-MAIL QUASI ANONIME
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Fin qui abbiamo visto le tecniche per collegarsi anonimamente a siti web, o a
shell, e di conseguenza a tutti i suoi servizi. Ho inserito l'argomento delle email
anonime dopo di essi, non perchè è più difficile ma perchè possiamo attuare anche
qui la tecnica sopradetta della concatenazione delle connessioni tramite telnet.
Descrivo ora una semplice tecnica per inviare email semi-anonime;
per farlo bisogna collegarsi alla porta 25, dove solitamente è installato il
demone smtp, di un mail server. Per l'esempio utilizzeremo mail.libero.it
Cliccate su start --> esegui e digitate telnet, dopodichè premete ok.
(per inviare email anonime potete anche utilizzare il telnet realizzato da me:
Xp Tel 'n chat downloadabile dal mio sito http://xpterminator.cjb.net :)
Si avvierà telnet, se non lo avete mai configurato fatelo ora dal menu della
configurazione mettete il segno di spunta a tutte le opzioni a sinistra.
Ora connettetevi al server mail.libero.it sulla porta 25.
Il server ci dirà di essere pronto, digitiamo:
helo anonimo.it
mail from: <anonimo@anonimo.it>
rcpt to: <destinatario@provider.it>
mail
Received: from smtp5.libero.it (111.111.111.111) by ims3b.libero.it (5.5.042)
id 3B73CBD4000235F5 for anonimo@anonimo.itit; Sun, 12 Aug 2001 00:02:49 +0200
Received: from be3a.com (222.222.222.222) by smtp5.libero.it (5.5.025)
id 3B2B228203D0507F for anonimo@anonimo.it; Sun, 12 Aug 2001 00:02:49 +0200
Message-ID: <3B2C22820DD0507F@smtp5.libero.it> (added by postmaster@iol.it)
Date: Sun, 12 Aug 2001 00:00:00
From: <anonimo@anonimo.it>
To: <destinatario@provider.it>
Subject: prova
Messaggio di prova
.
quit
In questo "dialogo" che abbiamo effettuato col server, ho eliminato le sue
risposte. Ecco il significato di ogni riga inviata:
helo anonimo.it ---> salutiamo il server, anonimo può essere sostituito con
qualunque altra parola
mail from: <anonimo@anonimo.it> ---> diciamo al server il mittente della mail
(cambiate anonimo@anonimo.it con un'email falsa)
rcpt to: <destinatario@provider.it> ---> diciamo al server colui che dovrà
ricevere l'email
mail ---> indichiamo al server che iniziamo il messaggio dell'email
Received: from smtp5.libero.it (111.111.111.111) by ims3b.libero.it (5.5.042)
id 3B73CBD4000235F5 for anonimo@anonimo.itit; Sun, 12 Aug 2001 00:02:49 +0200
Received: from be3a.com (222.222.222.222) by smtp5.libero.it (5.5.025)
id 3B2B228203D0507F for anonimo@anonimo.it; Sun, 12 Aug 2001 00:02:49 +0200
Message-ID: <3B2C22820DD0507F@smtp5.libero.it> (added by postmaster@iol.it)
Date: Sun, 12 Aug 2001 00:00:00
Queste righe servono a confondere la mail, per rendere più difficile capire
quale sia il nostro vero ip fra quelli qui detti. Sostituite gli ip
111.111.111.111 e 222.222.222.222 con ip più credibili, e cambiate gli id (ma
non di troppo (sono codici esadecimali, quindi con numeri da 0 a 9 e lettere A
B C D E F). Sostituite inoltre anonimo@anonimo.it con l'email falsa che avete
inserito più sopra
From: <anonimo@anonimo.it> ---> inseriamo nelle intestazioni dell'email chi è
il destinatario (naturalmente email falsa)
To: <destinatario@provider.it> ---> inseriamo nelle intestazioni dell'email
chi sarà colui che dovrà ricevere la mail
Subject: prova ---> inseriamo nelle intestazioni l'oggetto della mail, in
questo esempio prova
---> lasciamo una riga vuota
Messaggio di prova ---> scriviamo il messaggio che vogliamo inviare (anche su
più righe)
. ---> digitiamo un punto su una riga vuota
quit ---> inviamo la mail e chiudiamo la sessione telnet
Questo è lo schema che dovremo prendere di esempio ogni volta che vogliamo
inviare email tramite questo metodo.
Questa è la tecnica più semplice di inviare email anonime (a parte i programmi
apposta fatti per questo, ma quelli li usano i lamah, voi non siete lamer
vero? :P ).
Per ottenere una anonimità quasi assoluta è possibile fare la stessa cosa,
però lanciando il telnet dopo essersi telnettato su qualche shell
(ricordandovi per ancora maggiore sicurezza di comprometterne una). In questo
caso non dovrete scrivere i vari received from falsi, il message-id ed il date,
perchè quelli che saranno messi di standard non conterranno il vostro ip ma bensì quello
della macchina dalla quale avete lanciato telnet.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
INVIARE E-MAIL ANONIME AL 100% (solo con linux)
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Un altro metodo per inviare email con anonimità a dir quasi assoluta, è lo
stesso descritto sopra, l'unica differenza è che è moooolto più semplice,
infatti non dovremo ne telnettarci tra le varie shell, ne compromettere i log
di una di esse. Ciò che dovremo fare è aver installato sendmail sul nostro pc
(bisogna avere linux!), e seguire queste istruzioni.
Per poter inviare email col nostro sendmail dobbiamo configurare il file:
/etc/sendmail.cf
All'interno di questo file cerchiamo due righe consecutive simili a queste:
#"Smart" relay host....
DSmail.server.it
l'importante è che ci sia un # davanti la prima riga, ed un DS davanti la
seconda. Modifichiamole per farle diventare così:
#"Smart" relay host (may be null)
DSmail.server.it
in cui mail.server.it va sostituito con il vostro provider(es:mail.libero.it)
Ora salvate ed uscite. Ecco spiegato il significato delle righe:
#"Smart" relay host (may be null) ---> con questa riga abbiamo obbligato il
demone MTA a mandare la posta al
server sotto scritto, sarà poi compito
suo occuparsi del resto
Ora per attuare le modifiche dovete uccidere il demone e farlo ripartire,
quindi digitate:
killall -HUP sendmail
Se tutto è andato bene non succederà nulla, se invece c'è stato qualche
problema apparirà l'errore. Per verificare che sia in funzione digitare:
ps aux | grep sendmail
e se non funziona, ovvero non è in funzione il sendmail, digitare come root:
/usr/sbin/sendmail -bd -q 15m
Fatto questo ci manca ancora un'ultima cosa...
Editate il file /etc/hosts e aggiungete in fondo al file la riga:
127.0.0.1 server.it
dove server.it è il vostro provider (es.: libero.it).
Ciò vi permetterà di inviare email anche quando non siete connessi ovvero appena saremo
connessi ci basterà digitare il comando: "sendmail -q" per inviare le mail.
Ora siamo pronti per inviare una email moolto anonima :). Telnettiamoci sulla
porta 25 del nostro pc (dov'è installato sendmail), digitando:
telnet localhost 25
Ed eseguiamo i passi sopra detti, senza prendere però alcuna precauzione,
riassumendo:
helo anonimo.it
mail from: <anonimo@anonimo.it>
rcpt to: <destinatario@provider.it>
data
From: <anonimo@anonimo.it>
To: <destinatario@provider.it>
Subject: Questa è una email anonima al 100%
Questa email è anonima al 100% !!
.
quit
Ora avremo inviato una email totalmente anonima perchè nelle intestazioni del
messaggio non apparirà nemmeno un indirizzo IP!
Ciò è possibile farlo anche quando non ci si è connessi, per esempio da
disconnessi si eseguono gli stessi passi qui detti, e poi appena connessi si
digita il comando: sendmail -q , come già detto sopra.
Oltre ad inviare queste mail anonime tramite telnet, è possibile farlo anche
normalmente tramite il nostro client mail preferito, basta configurarlo per
utilizzare come mail server il nostro sendmail (nella maggior parte dei casi
si trova in /usr/sbin/sendmail) ed inviando utilizzando un account falso,
specificando una mail diversa, ecc..
PARTE SECONDA DELLA GUIDA
CAPITOLO QUINTO
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
TECNICHE AVANZATE DI ANONIMIZZAZIONE
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Tutte le tecniche per anonimizzarsi fin qui descritte, non sono le più
raffinate, ciò perchè il nostro indirizzo ip non rimane nel server nostro
obiettivo, però rimane in qualche punto della rete, come nel nostro "tramite"
utilizzato per raggiungerlo.
Qui di seguito, analizziamo tecniche più complesse che ci permettono di non
lasciare alcuna traccia in rete del nostro indirizzo ip, ovvero l'ip spoofing
ed i suoi "derivati" (spoofing non cieco, spoofing cieco, hijacking).
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
IP SPOOFING
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
L'ip spoofing (utilizzato per la prima volta dal grande Kevin David Mitnick) è
una tecnica di occultazione o falsificazione dell'ip che si basa sulla
modifica di uno o più di uno dei campi di un pacchetto (vedi tabella al
capitolo terzo, sezione TCP/IP).
Esistono diversi tipi di tecniche di spoofing conosciuti come blind spoofing
(spoofing cieco), non blind spoofing (spoofing non cieco) e hijacking.
Per poter capire la complessità dell'applicazione di queste tecniche dobbiamo
tornare a ciò di cui abbiamo parlato nel capitolo sul TCP/IP ovvero i numeri
di serie contenuti nei pacchetti inviati in rete. Infatti per poter comunicare
con un server modificando il campo del source ip, dobbiamo essere in grado di
predire questi numeri di serie. Questo accade perchè il server, come visto in
precedenza, non sarà in grado di risponderci (invierà la risposta
all'indirizzo falso che abbiamo inserito nell'ip-source) e quindi noi non
potremo vedere quale numero di serie sta adottando il server per questa
specifica connessione, almeno che non adottiamo la tecnica non cieca o
l'hijacking, e se lo sbagliamo i nostri pacchetti saranno ignorati,
o al massimo intralceremo la connesione a qualche altro utente.
Esistono vari metodi di generare questi numeri di serie, tutti con
l'obbiettivo di rendere la predizione di questi numeri la più difficile
possibile, chiaramente per motivi di sicurezza. Le ultime versioni del kernel
GNU/Linux utilizzano un sistema che rende praticamente inutile l'applicazione
delle tecniche dette qui di seguito. Concludendo, è un grande problema quello
dei numeri di serie con lo spoofing.
Però ho detto che questo è il problema dello spoofing cieco, ma non di quello
non cieco (che lo stesso risulta molto difficile da attuare) o dell'hijacking!
Per questo l'hijacking è la mia tecnica preferita! ;))
Le prossime due tecniche trattano lo spoofing non cieco e cieco solo in modo
molto generalizzato, per una comprensione basilare, poi passeremo
direttamente all'hijacking, entrando maggiormente nei particolari :)).
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
SPOOFING NON CIECO
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Lo spoofing non cieco si basa sul fatto che la macchina attaccante dispone di
un qualche meccanismo che le permette di osservare le risposte che la
macchina attaccata trasmette, in modo che non sia necessario indovinare i
numeri di serie.
Perchè si possa usare questa tecnica si ha bisogno di un qualcosa di
aggiuntivo che permette di leggere le risposte della macchina remota, funzione
tipicamente svolta da uno sniffer (in parole povere, ciò che avreste dovuto
utilizzare su di voi, nel capitolo sul TCP per imparare
la "forma" dei pacchetti).
Si aprono quindi due scenari d'utilizzo della tecnica del non blind spoofing.
Il primo sarà una rete locale nella quale una macchina starà facendo un
attacco utilizzando l'indirizzo ip di un'altra macchina connessa alla stessa
rete locale. In questo caso lo sniffer ci permetterà di leggere qualunque dato
inviato dalla macchina che si intende soppiantare a quella con lo sniffer (di
cui avremo messo l'ip nel campo ip-source dei pacchetti che inviamo, come
detto poco sopra) e quindi l'attaccante può ottenere i numeri di serie
necessari per stabilire una comunicazione con la macchina.
Il secondo scenario è più generale ed anche molto più complesso. Dovrebbe
essere utilizzato un cacciatore di pacchetti generico che trasmetta i dati
dalla macchina soppiantata, (quella sulla quale avremo installato il
cacciatore, e della quale avremo inserito l'indirizzo ip nell'ip source), o
da un qualsiasi punto della rotta seguita dai pacchetti dalla macchina vittima
del nostro attacco alla macchina soppiantata, verso di noi, in modo che i
numeri di serie ci siano accessibili (questo periodo potrebbe sembrare più
complesso di quanto sia, rileggetelo ;).
Questa scelta è molto complessa ed insicura per l'attaccante dato che lo
sniffer cessa di essere un elemento passivo di cattura per convertirsi in un
elemento attivo di trasmissione dati, trasferendo i pacchetti di risposta
dalla macchina attaccata alla macchina attaccante. In questo modo l'indirizzo
ip reale dell'attaccante appare nella rete rendendo più facile la
localizzazione.
Questo modo di operare presenta ulteriori complicazioni, derivanti dal fatto
che la macchina soppiantata riceverà pacchetti dalla macchina vittima e
cercherà di rispondervi, con l'unico risultato di produrre errori nella
comunicazione (pacchetti RTS, FIN, duplicati, ecc.) che normalmente
determineranno la fine della connessione.
Il modo abituale di risolvere questo problema è fare un attacco DoS alla
macchina che s'intende soppiantare perchè sia resa incapace di rispondere ai
pacchetti che riceverà dalla macchina vittima e non causi i problemi derivanti
da una possibile risposta.
Come si può immaginare, questo attacco DoS, finalizzato ad utilizzare un
cacciatore di pacchetti invece che uno sniffer, è molto più complesso di quel
che sembra perchè il cacciatore di pacchetti deve trasmettere dati verso la
macchina attaccante, cioè non è sufficiente bloccare la macchina, è necessario
farlo in maniera controllata, in modo che le risposte verso la macchina
vittima non vengano inviate, mentre i pacchetti del cacciatore verso di noi
vengano inviati. La scelta di installare il cacciatore di pacchetti in una
macchina sulla rotta macchina vittima-macchina soppiantata, è generalmente più
complessa, anche se in questo caso un attacco DoS classico sarà sufficiente.
L'obbiettivo è quindi bloccare la macchina che si desidera soppiantare
mantenendo al contempo la possibilità di osservare le risposte della macchina
vittima, cosa che non è affatto banale.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
SPOOFING CIECO
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
In questa tecnica la macchina attaccante non ha la possibilità di osservare i
pacchetti che la macchina vittima invia come risposta. L'unica possibilità che
avrà sarà quella di investigare sui numeri della sequenza che la macchina
vittima utilizza e dedurre i valori necessari da inserire in testa ai
pacchetti che permetteranno di stabilire la connessione.
Logicamente, indovinare semplicemente non è buona scelta. Per ottenere le
informazioni necessarie allo spoofing, l'attaccante dovrà rivelare il suo vero
indirizzo ip prima di soppiantare un'altra macchina, cioè l'attaccante
trasmetterà un certo numero di pacchetti alla macchina vittima in modo da poter
analizzare le sue risposte e, sulla loro base, dedurre il metodo di
generazione dei numeri di serie, così come il numero di serie appropriato per
stabilire la comunicazione. Questi pacchetti contengono l'indirizzo ip reale
dell'attaccante, visto che in questo caso si ha bisogno della risposta diretta
della macchina vittima.
Una volta seguita questa procedura, la macchina attaccante avrà qualche
possibilità di dedurre il contenuto dei pacchetti che dovrebbe ricevere dalla
macchina vittima e quindi rispondere adeguatamente perchè la connessione non
decada. A seconda del metodo utilizzato per la generazione dei numeri di serie
iniziali della connessione, l'attaccante potrà comunicare con un ip falso con
la macchina vittima, tenendo conto del fatto che attualmente vengono
utilizzati algoritmi che rendono tali predizioni praticamente impossibili.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
HIJACKING
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
L'hijacking è sicuramente la tecnica più interessante ed affascinante dello
spoofing, e consiste nel rubare una connessione già stabilita e sostituirsi ad
uno dei due estremi della connessione. Prima di poter scendere però nei particolari
dell'hijacking (capitolo settimo) con vere dimostrazioni di attacchi, è giusto
capire cosa sia ARP, RARP e MAC, come discusso in questo successivo capitolo.
CAPITOLO SESTO
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
ARP , RARP e MAC
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Passiamo dunque a capire cosa siano ARP, RARP e MAC...
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
ARP e MAC
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
L' ARP (adress resolution protocol) è un protocollo per convertire gli
indirizzi ip a 32 bit (ricordate? quattro numeri da 8 bit...) in indirizzi
ethernet (MAC (media access control) ) a 48 bit.
Le schede ethernet hanno normalmente un indirizzo MAC fisso, mentre
l'indirizzo ip di un computer che sta usando una scheda ethernet cambia
spesso. Esso può essere spostato da un luogo ad un altro o configurato per
utilizzare un altro indirizzo ip. Questo causa la necessità, per le reti
basate sull'ip (internet protocol), di conoscere a quale indirizzo MAC inviare
i pacchetti. Questo è ciò a cui serve l'ARP.
Quando una macchina in una rete deve inviare un pacchetto ad un altra macchina
o ad un router, deve conoscere l'indirizzo MAC di quest'ultima. Se l'indirizzo
MAC non viene trovato nella senders cache dell'ARP, questo inoltra una
richiesta nella rete (ARP request). La richiesta (anch'esso un pacchetto)
contiene l'indirizzo IP del computer del quale si vuole sapere l'indirizzo
MAC. Quando il computer riceverà il pacchetto di ARP request, esso risponderà
con un altro pacchetto (ARP reply) che conterrà gli indirizzi IP e MAC del
computer. Per evitare di dover domandare l'indirizzo MAC per ogni volta che si
voglia inviare un pacchetto verso la macchina, l'indirizzo ip e MAC della
macchina vengono salvati nella senders cache dell'ARP, in modo tale che i
seguenti pacchetti possano essere inviati al giusto indirizzo MAC senza inviare
ogni volta pacchetti di ARP request.
I pacchetti inviati dall'ARP seguono questo formato:
______________________________________________________________
| HARDWARE TYPE | PROTOCOL TYPE |
|--------------------------------------------------------------|
| HLEN | PLEN | OPERAZIONE |
|--------------------------------------------------------------|
| SENDER HA (ottetti 0-3) |
|--------------------------------------------------------------|
| SENDER HA (ottetti 4-5) | SENDER IP (ottetti 0-1) |
|------------------------------|-------------------------------|
| SENDER IP (ottetti 2-3) | TARGET HA (ottetti 0-1) |
|--------------------------------------------------------------|
| TARGET HA (ottetti 2-5) |
|--------------------------------------------------------------|
| TARGET IP (ottetti 0-3) |
|______________________________________________________________|
Gli indirizzi hardware type e protocol type identificano il tipo di
indirizzo dell'hardware e il tipo del protocollo per l'indirizzo.
Nel caso della scheda ethernet come tipo hardware il valore è 1 e nel caso
dell'ip come protocollo di indirizzo il valore è 0x800.
HLen e PLen indicano la lunghezza dell'indirizzo hardware e del protocollo
degli indirizzi. Questi valori sono 48 bit nel caso della scheda ethernet come
hardware e 32 bit nel caso del protocollo ip.
Il campo operazione contiene il tipo di servizio al quale il pacchetto
appartiene. Esso può contenere uno dei seguenti valori:
1. ARP request
2. ARP reply
3. RARP request
4. RARP reply
Una ARP request è simile a questa:
00:00:2b:04:a9:11 ff:ff:ff:ff:ff:ff arp 60:
arp who-has 123.231.1.2 tell 123.45.67.89
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
RARP
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Il RARP (reverse adress resolution protocol) è un protocollo per chiedere
l'indirizzo ip di un computer. Esso è usato dai computer per domandare il
proprio indirizzo ip da altri computer sulla rete.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
PROXY ARP
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Il proxy ARP è una situazione che si viene a verificare quando un computer
invia una ARP request tramite un altro computer localizzato in un'altra rete,
proprio come accade con i proxy.
Credo che la via migliore per capire questo concetto sia un semplice esempio:
Supponi di avere due computer in una rete a casa e vuoi fare un dial-in per
accedere alla rete del tuo ufficio. Il modem al tuo ufficio risponde alla
chiamata, e ti da un indirizzo ip. Il router in ufficio è configurato per
inviare messaggi ai computer di quella rete tramite la linea telefonica.
Però gli altri computer non sanno che tu non appartieni a quella rete, quindi
quando ti devono inviare qualcosa controllano il tuo indirizzo ip, vedono che
è della stessa rete (perchè assegnato dal router della rete) e provano ad
inviare un ARP request per ottenere il tuo indirizzo MAC. Ma poichè tu sei
sulla linea telefonica non puoi ascoltare la richiesta. Qui avviene il Proxy
ARP, infatti, il router, tramite il quale tu sei connesso alla rete, risponde
a queste richieste inviando il proprio indirizzo MAC in un ARP reply.
Dopodichè quando i computer della rete lan ti vorranno inviare qualcosa, lo
invieranno all'indirizzo MAC del router, il quale lo inoltrerà verso di te
tramite la linea telefonica.
Ecco praticamente cosa avviene:
1.2.3.4 5.6.7.8 9.10.10.10
| | |
| | |
-------------------RETE LAN-------------------
|
|
|
|
|
90.80.70.60 (ROUTER)
|
|
|
|
|
-----------------11.22.33.44------------------
(MIO PC)
Quindi il router, si interpone tra me ed i computer della rete.
CAPITOLO SETTIMO
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
HIJACK AL PROTOCOLLO TCP TRAMITE ATTACCO ARP
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
VULNERABILITA' ED ATTACCHI
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
L'attacco ARP si basa sul fatto che, in una rete locale, l'attaccante può
inviare ARP reply forgiati a piacimento ad un qualunque pc della stessa rete,
il quale salverà i dati contenuti in questo ARP reply nel proprio ARP senders
cache, dopodichè invierà verso il pc dell'attaccante pacchetti che dovrebbero
essere inviati ad altri pc. Se l'attaccante invia simultaneamente al computer
A un ARP reply che gli dice di essere il computer B, ed al computer B un ARP
reply che gli dice che l'attaccante è il computer A, tutta la comunicazione
sarà dirottata tramite il computer dell'attaccante. Questo gli permetterà di
controllare tutte le comunicazioni fra i computer A e B.
L'attacco ARP è semplice ed allo stesso tempo potente, però ha un difetto:
esso è limitato alla rete locale. Quindi per effettuare un attacco ARP,
l'attaccante ha bisogno di avere accesso ad un computer che si trova sullo
stesso segmento di rete del computer da attaccare.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
HIJACK AD UNA CONNESSIONE TCP
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Useremo una macchina Linux come nostro pc attaccante. Il primo passo è quello
di fare in modo che i due computer inviino i loro pacchetti a noi. Dopo aver
scelto i nostri obiettivi (il computer vittima, ed il computer "manovrato"), e
trovato i loro indirizzi MAC, dovremo creare due interfacce alias, i quali
indirizzi ip corrispondono agli indirizzi dei pc nostri obiettivi.
Settiamo le entrate ARP delle nostre nuove interfacce in modo che esse inviino
i pacchetti ai veri destinatari. Fatto questo, disabilitiamo le risposte ARP
automatiche, in modo da non inviare il nostro indirizzo MAC a computer
"sbagliati". Passo successivo: iniziamo l'attacco! Inviamo un ARP reply ad
entrambi i computer in modo che loro inviino a noi tutti i pacchetti che
vogliono inviare all'altra macchina (come visto precedentemente).
Per evitare errori, inviamo tutti i pacchetti che riceviamo ai computer ai
quali erano destinati originariamente.
Dobbiamo continuare però ad inviare anche ARP reply ad entrambi i computer
perchè altrimenti la loro ARP cache scaderà, e ciò comporterà che i computer
inviano un ARP request al computer giusto! Per evitare questo quindi
aggiorniamo periodicamente la cache ARP di entrambi i computer.
Ora possiamo controllare tutto il traffico tra i due computer.
Ora inizia il vero divertimento!
Visto che tutti i pacchetti attraversano la nostra macchina, noi possiamo
naturalmente vederli tramite uno sniffer!
Ma non c'è niente di nuovo con questo!
Noi possiamo fare qualunque cosa vogliamo con essi!
Possiamo modificare i loro contenuti, ed aggiungere o rimuovere pacchetti se
vogliamo! Ecco alcune cose carine che potremmo fare:
- Possiamo fare il nostro attacco normalmente senza che la
vittima si accorga di niente. Potremmo aggiungere un
comando telnet durante una sessione (come per esempio "rm -Rf *" o
qualcos'altro come leggere il file /etc/passwd) tutto ciò senza che
l'utente del computer attaccato si accorga di niente, poichè noi
controllando l'interno traffico faremo in modo che lui non veda gli
output dei comandi, e quindi non si accorga di operazioni
"extra-ordinarie" :).
- Possiamo fare anche l'hijack della connessione, "tagliando fuori" il
pc di cui non abbiamo bisogno e continuando a "parlare" all'altra
macchina facendo finta di essere ancora il vecchio pc ;) (il fatto
negativo di ciò e che l'utente vittima visualizzerà un messaggio di
errore di persa connessione, ma la cosa buona è che sarà troppo tardi
e noi avremo già fatto tutto quello di cui avevamo bisogno ;) )
- Giocando con la vittima, possiamo anche inserire nella sessione
telnet qualche parola extra, tramite il comando echo e facendo sì
che venga visualizzato l'output.
(Esempio: "echo I am in your network, find me!" ;) )
- Infine, se intendiamo essere il router, potremo estendere il
nostro attacco al di fuori della rete locale in modo da poter fare
l'hijack di una connessione tra un computer della rete locale ed uno
al di fuori di questa rete.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
ATTACCHI DOS
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Ci sono molti metodi per utilizzare ARP per compiere attacchi DoS (denial of
service):
- Puoi inviare ARP reply di tutte le macchine di una rete locale
indicando il tuo indirizzo. Ciò causerà che i computer diventeranno
inconsci di chi sia veramente chi. Questo potrebbe causare la
nascita di una vera lotta dei computer sulle loro identità
- Indicando un indirizzo MAC non esistente in un ARP reply, puoi
rendere il computer impossibilizzato ad accedere alla destinazione.
Naturalmente anche qui devi inviare periodicamente l'ARP reply per
non far scadere la cache ARP
- Inoltre, puoi pure inviare un ARP reply che ha come indirizzo IP
quello di una macchina con sistema Windows, per far sì di far
apparire la "modal messagebox" sullo schermo dell'utente, ovvero la
simpaticissima schermata blu ;)
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
DIMOSTRAZIONE DI UN ATTACCO HIJACK
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Qui di seguito mostro una dimostrazione pratica di un attacco hijack basato
sugli stessi concetti di quello visto sopra, con la differenza che stavolta non
dobbiamo essere per forza nella stessa rete dell'obiettivo, ma bensì in quella della
vittima. Quindi se dovete attaccare un server, osservate un pò, e scegliete poi
qual'è il miglior metodo d'attacco per la vostra situazione. Questo attacco lo
descrivo maggiormente nei particolari rispetto al precedente, poichè è più facile
che si verifichino queste condizioni, ovvero che ci si trovi sulla stessa rete
della vittima, che su quella dell'obiettivo. Infatti, con il primo tipo di
attacco, precedentemente avremo dovuto hackare una macchina sulla stessa rete,
invece ora ci basta che per esempio qualcuno che ha un account su quel server
sia nella nostra rete (meglio se è il root!! ;)
In questo attacco sono coinvolti tre host : l'attaccante, la vittima e l'obiettivo.
- attaccante è la macchina usata dall'attaccante per l'hijack
- vittima è la macchina usata dalla vittima per una connessione
telnet verso la macchina obiettivo
- obiettivo è la macchina obiettivo che l'attaccante vuole
"compromettere". Qui è dove sta girando il
demone telnetd
Il seguente schema mostra che l'attaccante e la vittima si trovano sulla
stessa rete (che può essere anche una ethernet switched), mentre l'obiettivo
si può trovare da qualunque parte (naturalmente l'obiettivo potrebbe trovarsi
anche sulla stessa rete della vittima e dell'attaccante).
______________ ______________
| | | |
| ATTACCANTE | | VITTIMA |
| | | |
| 111.22.33.44 | | 222.11.33.44 |
|______________| |______________|
| |
| |
_____________|________________________________|___________________
|
_________|_________
| |
| ROUTER |
|___________________|
/
/
/
/
/
________/_________
| |
| NETWORK BACKBONE |
|__________________|
\
\
\
\
\
___\_____________
| |
| ROUTER |
|_________________|
|
___________________|_________________________________________________
|
_________|_________
| |
| OBIETTIVO |
| 55.66.77.88 |
|___________________|
Per effettuare l'attacco, la vittima deve usare telnet, rlogin, ftp o
qualunque altro programma TCP/IP non criptato.
Ecco uno scenario d'esempio, per comprendere il tipo d'attacco:
(ripeto d'esempio perchè naturalmente la vittima avrebbe potuto anche eseguire
ftp invece di telnet, ma i risultati non cambiano)
1. Attaccante: Determina l'indirizzo IP dell'obiettivo e della vittima. Ciò
può essere fatto facilmente con programmi come SATAN, finger,
systat, rwho o eseguendo who, ps o last da un account
precedentemente "ottenuto".
2. Attaccante: Esegue hunt come root dalla macchina attaccante. Attende finchè
hunt non indica di aver intercettato una sessione (hunt lo
farà capire cambiando il suo prompt da "->" in "*>")
3. Attaccante: Avvia il demone ARP, prepara il demona RST per essere usato in
seguito, abilita l'opzione "host name resolution" (per convenienza)
4. Vittima: Logga nell'obiettivo usando telnet. Esegue pine per leggere ed
inviare email
5. Attaccante: Si accorge della nuova connessione, e "lista" tutte le
connessioni attive per vedere se questa è
potenzialmente "interessante" ;). Se lo è, l'attaccante può o
solo osservare la sessione (sniffando) o può fare un hijack.
Scegliamo l'hijack :)
6. Vittima: Vede un nuovo prompt sconosciuto. Prova a premere invio, non sa cosa pensare.
Prova il web browser e vede che funziona bene (allora non è un problema
di rete). Non è sicuro di cosa pensare
7. Attaccante: Si accorge che la vittima ha una sessione come user normale ed
allora decide di "lasciarlo continuare"
(risincronizza lo stream TCP/IP)
8. Vittima: Vede che la sessione torna alla normalità.
Preoccupato e pensieroso decide di loggare come root per
dare un'occhiata alla situazione
9. Attaccante: Attiva il demone RST per prevenire nuove connessioni; aspetta
il momento per fare l'hijack della sessione root
10. Vittima: Esegue ssu per avere una root shell protetta da SecureID
11. Attaccante: Completa l'hijack dopo aver visto il login root
12. Vittima: Vede nuovamente apparire uno strano prompt.
Preme dinuovo invio. Stesso risultato di prima.
Prova il browser web. Stessa cosa.
Tenta una nuova sessione telnet. Non funziona.
Prova ftp. Non funziona.
13. Attaccante: Disabilita la command history, inserisce una backdoor, resetta
la sessione, disattiva il demone RST
14. Vittima: Finalmente ottiene una nuova sessione. Anche la sessione
originale ora funziona. Crede che sia un problema della rete o un problema
dello stack TCP/IP di Windows. Riavvia il sistema perchè tutto torni
alla normalità
15. Attaccante: Attende una mezza giornata, per far sì che il sysadmin si
convinca che tutto è normale, ed erano stati solo
"problemucci", dopodichè logga come root usando la backdoor,
installa un rootkit nel sistema (altre backdoor, sniffer), e
pulisce i file di log.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
PROTEZIONI E CONTROMISURE
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Qui di seguito sono menzionate le protezioni da prendere contro gli attacchi sopra
descritti.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
PROTEZIONE
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
L'ARP è un protocollo a basso livello, quindi usualmente nessuno ci si
interessa. Nonostante ciò puoi controllare i contenuti della tua cache ARP
tramite il comando arp. Anche Windows ha questo comando. Quindi, se vi sono
problemi unusuali nella rete, potrebbe essere d'aiuto controllare la cache
dell'ARP.
Un metodo per proteggersi da questi attacchi è di avere un hardware che renda
questi attacchi inutili o li renda maggiormente visibili (switched networks e
smart hubs). Ecco un'altra buona ragione per spendere in buon hardware.
Problemi con l'ARP possono essere evitati usando un design differente da
quello standard. Nell'ARP la risoluzione dinamica dei nomi
(dynamic name resolution) è risolta senza un server centralizzato.
Se vogliamo utilizzare un server centralizzato per far sì di forzare la
coincidenza biunivoca di un indirizzo ip ad un indirizzo MAC non ci dovrebbero
essere problemi. Ciò non dovrebbè richiedere troppo lavoro poichè gli
indirizzi ethernet sono quasi sempre permanenti.
E' possibile anche disabilitare ARP e configurare la tabella ARP manualmente.
Questo dà una protezione perfetta contro gli attacchi basati sull'ARP, ma è un
lavoro molto duro poichè la tabella ARP del computer deve essere aggiornata
manualmente ogni qual volta il computer cambia l'indirizzo IP o l'indirizzo
MAC nella stessa sottorete.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
DETENZIONE
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Se l'attacco hijacking alla connessione del computer è in corso con successo,
l'utente del computer vittima non visualizzarà nessun messaggio d'errore,
poichè ogni cosa sembrerà lavorare normalmente. Nonostante questo sarà
possibile rendersi conto dell'attacco visualizzando la cache ARP, e notando se
l'indirizzo MAC di un determinato ip è cambiato. Il computer dell'attaccante
può essere identificato dal suo indirizzo MAC e dopo di ciò potrà essere
disconnesso fisicamente dalla rete locale. L'attaccante può essere anche
scovato da un terzo computer, il quale sniffa la rete in cerca di ARP reply
forgiati ad hoc.
In attacchi DoS, è facile accorgersi che qualcosa non funziona bene,
nonostante la causa non potrebbe sembrare apparente. Il comando arp può essere
usato per visualizzare questi attacchi.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
CONSEGUENZE E PERDITE
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Cosa comportano gli attacchi ARP alle vittime, e perchè un attaccante dovrebbe
scegliere questa tecnica.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
PERDITE PER LE VITTIME
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Le perdite per una eventuale vittima, possono essere molto grandi, soprattutto
se l'attaccante inserisce comandi "cattivi" in una sessione telnet come per
esempio "rm -Rf *". Però spesso, l'attaccante può anche solo modificare i dati
dei pacchetti trasmessi o magari far apparire paroli "dolci" >:) sullo schermo
della vittima (come visto in precedenza tramite ECHO).
Invece, se viene compiuto un denial of service completo, ciò causa
l'impossibilità di utilizzare la rete attaccata.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
MOTIVAZIONI PER UN ATTACCO ARP - HIJACK
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Perchè qualcuno dovrebbe usare un attacco ARP?
Bene, un attacco ARP non è molto applicabile perchè, come abbiamo visto in
entrambi i tipi di attacchi, c'è bisogno sempre di trovarsi sulla rete locale
di un'altra macchina, però se viene combinato con il penetrare in un computer
della stessa rete locale, si possono fare cose davvero stupende!
E poi, le tecniche di hijacking sono molto potenti e con esse puoi fare di
tutto.
Quali sono i rischi durante l'hijacking?
Se si conosce cosa si sta facendo, gli altri computer della rete non si
accorgeranno mai di ciò che si sta facendo.
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
CONCLUSIONI
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Il protocollo ARP, non è stato progettato per essere sicuro, ma solo per fare
ciò a cui serve, ovvero inviare ARP request e ricevere ARP reply. Esso non ha
nessun tipo di autentificazione.
Il protocollo ARP è un "pilastro" del mondo IP, e proprio ora che stiamo
raggiungendo l'era dell'IP v6, è una necessità migliorare i protocolli base
come ARP. Esistono già dei miglioramenti nelle reti come lo switching che sta
aiutando molto a risolvere i problemi di gestione, però questa non è ancora la
soluzione finale al problema.
CAPITOLO OTTAVO
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
CONCLUSIONI DELLA GUIDA
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Finalmente ho concluso la guida.
Spero vi abbia insegnato cose nuove, e vi abbia animato di gioia e voglia di
nuove conoscenze! :)
Le tecniche qui descritte sono veramente stupende, e se sono sembrate troppo
difficili, basta un pò di pratica su qualche server illegale e giuro che
diventeranno un gioco da ragazzi!
Naturalmente con questo non voglio assolutamente incitare nessuno ad hackare
un server, ma magari, se si è un sysadmin, a testare la sicurezza del proprio
server "auto-attaccandosi".
Come avrete sicuramente notato, questa guida ha sorvolato molti argomenti,
che dovrebbero essere alla base dell'hacking. Il problema è stato il fatto che
la guida è nata prima come semplice articolo su come anonimizzarsi in rete, ma
poi si è ampliata talmente oltre i propri "orizzonti", da farmi decidere di
chiamarla come guida all'hacking.
Scrivere questo testo mi ha entusiasmato molto, e se lo stesso è accaduto
anche per voi vi prego di aiutarmi! Vorrei portare avanti questa guida in
nuove realease, correggendo errori, aggiungendo nuove tecniche e magari
inserendo anche qualche argomento non trattato. Quindi se sei d'accordo e vuoi
partecipare, contattami all'email xp_terminator@libero.it , naturalmente tutti
coloro che collaboreranno saranno riportati in un'apposita sezione della
guida. Infine voglio fare un grazie speciale a tutti i miei amici del canale
#hack di azzurra (irc.azzurranet.org) che mi hanno tenuto molta compagnia
durante le ore di realizzazione della guida, anche distraendomi un
pò troppo ;)). Inoltre un grandissimissimo ringraziamento va a tutti gli
autori riportati nella seguente sezione fonti, dalle quali ho potuto attingere
ed imparare molte informazioni.
Ciao, e alla prossima guida!!! :))
XpTerminator http://xpterminator.cjb.net
Ricordatevi che per domande, commenti, per mandarmi affanculo o per
presentarmi vostra sorella dovete scrivere a: xp_terminator@libero.it
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
FONTI
\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|\|/|
Ultime ma non per importanza le ottime fonti da cui ho attinto:
"Occultamento e falsificazione dell'IP" di David Oliveira, pubblicato su
Linux Mania numero 5
"Hijacking a TCP connection using an ARP attack" Jussi-Pekka Kentala, Sami
Levijoki (Department of Computer Science and Engineering - Helsinki
University of Technology)
"Session hijack script" di Dave Dittrich
"Guida di linux" di Bakunin (Per la tecnica delle email anonime con linux)
"Mimetizzazione termo ottica" (per CLI e BIC)
e "Tecniche di scanning" (per esempi di three-way-handshake) di Tritemius