Laboratorio di reti
Transcript
Laboratorio di reti
Laboratorio di reti Beretta Andrea, matr. 686368 [email protected] Obbiettivo Analisi di un "capture" tcpdump, al fine di identificare e categorizzare le attività di rete in corso, e proporre soluzioni per migliorare e salvaguardare il network Principali attivita’ di rete riscontrate Portscan da probe.hackerwatch.org Subito all’inizio del capture si puo’ notare una richiesta fatta dall’indirizzo IP 80.183.5.128 al DNS server con IP 212.216.112.112, per richiedere l’indirizzo IP di probe.hackerwatch.org. Ottenuta la risposta, viene eseguito con successo il three way handshake con 67.98.69.136, ovvero probe.hackerwatch.org, e fatta una richiesta tramite il metodo GET della pagina con URI /probe/hitme.asp, specificando la versione del protocollo http (1.1). In questa pagina e’ presente un form, dove e’ stato premuto il tasto Hitme, a cui e’ seguita un’altra richiesta con il metodo POST di /probe/hitme.asp, passando alla pagina il parametro Action=Hit+Me. Il metodo POST infatti chiede al server di accettare dei dati forniti insieme alla richiesta http da parte del client ed eseguire un’operazione relativa alla URI specificata nella richiesta. A questo punto dalla pagina in questione viene avviato un portscan sulle principali porte di 80.183.5.128. Il sito infatti invia diverso pacchetti TCP con flag SYN impostato ad 1 per vedere le porte aperte. Infatti 80.183.5.128 risponde con un pacchetto con attivi i flag RST, ACK nel caso la porta sia chiusa, oppure con SYN, ACK nel caso la porta sia usata da qualche servizio. L’attivita’ impiega circa una trentina di secondi, e vengono controllate (in alcuni casi piu’ di una volta) solamente le porte relative ai principali servizi come http, telnet, ftp, ssh, pop3, netbios, imap, finger. Vengono inoltre inviati anche diversi pacchetti SYN alle porte 1098 e 4098. Tra i vari servizi provati gll unici risultati attivo sono stati http ed https, come si puo’ notare dai pacchetti con i flag SYN ed ACK ai frame 321 e 418. In questi caso 67.89.69.136 completa la sincronia trilaterale rispondendo con un pacchetto ACK e infine chiude la connessione con un FIN-ACK: 320 321 323 324 33.381836 33.382812 33.381836 33.381836 67.98.69.136 80.183.5.128 67.98.69.136 67.98.69.136 80.183.5.128 67.98.69.136 80.183.5.128 80.183.5.128 TCP TCP TCP TCP 3960 > http http > 3960 3960 > http 3960 > http [SYN] [SYN, ACK] [ACK] [FIN, ACK] Avendo completato la sincronia trilaterale con l’unico servizio aperto si suppone si sia trattato di un TCP Connect scan Portscan da https://www.grc.com Al frame 475 viene richiesto IP di grc.com (204.1.226.226), e poi avviato il three way handshake con la porta 443 di 204.1.226.226 ed eseguito lo scambio di chiavi, come si puo’ notare dai diversi pacchetti relativi ad SSL. Successivamente, mentre e’ ancora in corso l’invio dei pacchetti da probe.hackerwatch.org, viene contattato nuovamente il DNS server 212.216.112.112 richiedendo l’indirizzo IP di www.grc.com (frame 515 dopo 58.618164 sec.), ottenendo in risposta 204.1.226.230 Viene fatto un altro three way handshake con l’indirizzo IP 204.1.226.230 e fatta la richiesta POST http://www.grc.com/x/ne.dll?bh0bkyd2 . Molte delle immagini contenute nelle pagine, inoltre, sono hostate su images.grc.com, come si puo’ osservere da diverse richieste GET oltre che dalla richiesta al DNS server per risolvere il nome di tale host. La pagina richiesta precedentemente con metodo POST corrisponde al servizio shieldsUP. AL frame 919 viene inviato un pacchetto ICMP (echo request) da 204.1.226.228 a 80.183.5.128, e una volta ritornato l’echo reply ha inizio il portscan. Sono presenti un gran numero di tentativi di connessione da 204.1.226.228, sempre dalla porta TCP 62496, diretti a tutte le porte TCP in ordine dalla 0 alla 1055, riconoscibili per il flag SYN impostato a uno. 80.183.5.128 risponde con un SYN,ACK nel caso sulla porta sia in ascolto qualche servizio o applicazione, oppure con RST,ACK. In caso di risposta positiva, 204.1.226.230 non termina neppure il three way handshake inviando un pacchetto RST,ACK, resettando la connessione. Dovrebbe quindi trattarsi di un SYN scan. 951 81.294922 952 81.295898 ACK] [...] 954 ... 955 ... ACK] [...] 984 ... ACK] 204.1.226.228 80.183.5.128 80.183.5.128 204.1.226.228 TCP 62489 > 139 [SYN] TCP 139 > 62489 [RST, 204.1.226.228 80.183.5.128 80.183.5.128 204.1.226.228 TCP 62489 > 135 [SYN] TCP 135 > 62489 [SYN, 204.1.226.228 80.183.5.128 TCP 62489 > 135 [RST, L’invio dei SYN inizia dal frame 922(circa 81 sec) e termina col 3345 (113.6 sec). Tra le porte TCP aperte di 80.183.5.128 (riconoscibili per avere risposto con un SYN-ACK) si annovarano la 445(microsoft-ds), 443(https), 135(epmap), ed 80(http). Durante lo scan inoltre sono presenti anche alcuni pacchetti del servizio messenger destinati alla porta UDP 135, probabilmente per testare se il servizio e’ attivo sulla macchina target. Portscan da Scan.sygatech.com Al frame 3583 (161.45 sec.) viene contattato attraverso http://www.google.it (il cui indirizzo e’ 66.249.85.99), il sito web http://scan.sygatetech.com, probabilmente conseguentemente alla ricerca della query test+personal+firewall, come si puo’ notare da un campo Referer dell’header http del pacchetto in questione. e dopo il three way handshake viene effettuata una ricerca con la query test+personal+firewall. A questo punto viene avviato il three way handshale con l’indirizzo IP 207.33.111.32, viene fatta una richiesta con il metodo GET della risorsa specificata dall’URI / come si puo’ notare dal frame 3591 : GET / HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/xshockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Referer:http://www.google.it/search?sourceid=navclient&hl=it&ie=UTF8&rls=GGLD,GGLD:2003-43,GGLD:it&q=test+personal+firewall Accept-Language: it Accept-Encoding: gzip, deflate If-Modified-Since: Wed, 20 Oct 2004 21:25:41 GMT If-None-Match: "8bc30-40cc-4176d7d5" User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Host: scan.sygatetech.com Connection: Keep-Alive Analizzando la richiesta stessa ed i campi costituenti l’header si uo’ notare che la versione del protocollo http sia la 1.1, il browser utilizzato Mozilla/4.0, e l’host a cui la richiesta si riferisce. Una stessa richiesta con un diverso header host puo’ infatti riferisi a due distinte risorse web. L’header host e’ diventato obbligatorio per tutte le richieste http dalla versione 1.1 del protocollo. L’utilita’ di questo campo dell’header e’ legata alla necessita’ di potere tradurre senza problemi piu’ URL in un solo indirizzo IP. Una soluzione del genere e’ fondamentale per quei server che hostino diversi siti, come il caso di un webserver apache che utilizzi la direttiva VirtualHost. L’header Connection: Keep-Alive specifica infine la persistenza della connessione, in modo che la stessa non venga chiusa non appena la risposta sia stata completamente inviata al client. La risposta di scan.sygatetech.com e’ invece la seguente : HTTP/1.1 304 Not Modified Date: Wed, 11 May 2005 10:37:15 GMT Server: Apache/1.3.27 (Unix) Connection: Keep-Alive Keep-Alive: timeout=30, max=300 ETag: "8bc30-40cc-4176d7d5" La prima riga e’ la “linea di stato” , che riporta la versione del protocollo utilizzato per la risposta, un codice numerico che indica l’esito della richiesta, ed una rappresentazione testuale dell’esito stesso. Tale codice, detto status code, e’ costituito da 3 cifre decimali, e nel caso riportato, iniziando con il numero 3, indica una redirezione della richiesta su un’altra locazione. Seguono richieste tramite il metodo GET delle diverse immagini presenti all’interno della pagina identificata dalla URI / . Successivamente viene cliccato il link che punta alla pagina probe.htm (lo si puo’ desumere dal campo referer dell’header della richiesta http, che riporta l’indirizzo http://scan.sygatetech.com ). Successivamente richiesta con il metodo GET la pagina / images/sygate.html. Il protocollo utilizzato passa poi da http ad https, come si puo’ osservere dal pacchetto TCP 3668 con il flag SYN impostato ad 1 e diretto alla porta 443, e ad alcuni pacchetti relativi a SSL. Dal frame 3700 (178.6 sec.) ha inizio lo scan originato dall’indirizzo 207.33.111.35 e diretto a 80.183.5.128, verificando tra i principali servizi (finger, telnet, ssh, ftp, pop3, http, smtp) quali siano attivi. Il primo tentativo di connessione riguarda la porta 80, che essendo aperta risponde con un SYN-ACK. Inviato l’ACK di conferma, viene quindi fatta una richiesta con il metodo HEAD a 80.183.5.128. Il metodo HEAD e’ identico al GET, con la differenza che in risposta ad esso il server restituira’ esclusivamente l’header della risposta e non il body. 80.183.5.128, pero’, chiude la connessione inviando al mittente un pacchetto con i flag FIN ed ACK (pacchetto numero 3704). I vari pacchetti del portscan risultano, inoltre, inframezzati da pacchetti originati dalla porta 443 di https://scan.sygatetech.com e contengono il codice html della pagina che fara’ da report dell’attivita’ svolta, e probabilmente costituiscono il body della risposta http alla richiesta fatta col metodo GET della pagina da cui e’ stato avviato il portscan. Successivamente vengono richieste nell’ordine con il metodo GET le pagine prestealthscan.html, /images/sygate.html, stealthscan.html, /images/sygate.html, pretrojanscan.html, /images/sygate.html, /trojanscan.html, ecc. come si vede dall'http-referrer ecc. Richieste le varie pagine vengono avviete le diverse parti dello scan. Durante le varie parti dello scan vengono prima controllate le porte relative ai principali servizi, come auth, finger, telnet, ssh, ftp, pop3, http, smtp ecc. In ogni caso vengono inviati un gran numero di pacchetti TCP con il flag SYN impostato ad 1 a diverse porte, in molti casi con la porta sorgente corrispondente a quelle di qualche servizio. Nei pacchetti facenti parte del portscan sono infatti presenti diversi pacchetti con source port 53(dns), 80(http), 21(ftp), 25(smtp), 110 (pop3) ecc. Una soluzione del genere potrebbe essere giustificata come un tentativo per eleudere le regole di filtraggio di un eventuale firewall, presumendo che lasci passare i pacchetti relativi ai principali servizi applicativi. Non esiste dubbio che si trati di un portscan, osservando il grande numero di pacchetti inviato alle porte piu’ disparate. Come nei casi precedenti, porte chiuse ritornano un RST, ACK, mentre quelle aperte un SYN, ACK. Anche in questo caso, la sincronia trilaterale non viene terminata, ma viene inviato un pacchetto con il flag RST impostato a 80.183.5.128, come si puo’ ad esempio vedere dai frame 3940, 3941, 3942 ad esempio. Si tratta quindi ancora di un SYN scan. Un'altra caratteristica evidente del fatto che si tratta di un portscan e’ dovuta al fatto che i pacchetti vengono inviati “a blocchi”, ovvero in gruppi, tutti con la stessa porta sorgente e catturati con il medesimo tempo. Ad esempio si possono osservare i gruppi 4225-4232, 42664272 ecc. che verificano diverse porte di destinazione TCP. Da segnalare, inoltre, il fatto, che i numeri di porta di destinazione dei pacchetti del portscan non sono in ordine strettamente crescente ( per es. non seguono un pattern del tipo 1001, 1002, 1003, 1004, 1005 … 1100 … ), probabilmente in modo da rendere il pattern del portscan un minimo meno evidente. Dallo scan delle porte TCP sono risultate aperte le porte 80, 445, 443, e 8080. A partire dal frame 4611 e’ invece possibile osservare unp scan UDP, verso diverse porte di destinazione in ordine non sequenziale, e con porte sorgenti differenti. L’origine e’ sempre l’indirizzo IP 207.33.111.35, a cui 80.183.5.128 risponde con dei pacchetti ICMP (Port unreachable) Tra questi pacchetti UDP, in particolare si puo’ notare il numero 4784, diretto alla porta 1900. Ethereal indica questo pacchetto come malformato. La porta 1900 corrisponde al servizio di rilevamento SSDP e permette il rilevamento di periferiche Universal Plug and Play presenti in rete. Nell’esempio riportato il pacchetto fa parte di un portscan, ma in alcuni casi pacchetti malformati diretti a questa porta potrebbero causare un overflow. Poiche’ il servizio dovrebbe girare un kernel space, si potrebbe arrivare anche ad una compromissione del sistema, secondo quanto riportato da alcuni advisory. Sulla macchina in questione il servizio non risulta attivo, in ogni caso gli advisory che hanno trattato il problema raccomandano di configurare il firewall in modo da bloccare l’accesso dall’esterno alle porte UDP 1900 e 5000. Sempre rimanendo in tema di pacchetti UDP malformati ne e’ presente anche uno alla posizione 4703 diretto alla porta 53. Un possibile obbiettivo di un simile pacchetto, oltre alla verifica del DNS server potrebbe essere causare un Denial of Service. Infatti le versioni di ethereal precedenti alla 0.9.3 hanno un problema con il dissector DNS, e particolari pacchetti malformati potrebbero fare entrare lo sniffer in un ciclo infinito, stando ad un Security advisory di SCO. Non sono infine da escludere attacchi Dos Diretti ad un DNS server. Ad esempio MaraDNS server, puo’ essere soggetto a blocchi in seguito al processing di pacchetti opportuni pacchetti malformati, impedendo quindi la risoluzione delle richieste successive. www.ansa.it Al frame 4867 viene chiesto l'indirizzo di www.ansa.it al DNS server 212.216.112.112. Ottenuta la risposta con l'indirizzo IP 194.244.5.201, 80.183.5.128 richiede la root directory del sito web con una GET / . Dalla risposta http di www.ansa.it si puo' osservare che il server e' Sun-ONE webserver. La pagina ritornata riporta la data 11 Maggio 2005, e l'ora 11:28, mentre l'ora presente negli header della risposta del webserver e' 9:28. Tra le news la notizia di una possibile joint venture tra toyota e General Motors per lo sviluppo di un motore ad idrogeno. Al frame 5012 invece viene richiesto al DNS l'indirizzo IP di adsweb.tiscali.it (213.205.36.37) e seguentemente vengono fatte delle richieste GET / banner/2005/IT/ansa_728*90***button.swf, e GET /banner/2005/IT/netobserver120x240***button.swf, per dei banner, probabilmente filmati in flash, vista l'estensione del file, inclusi nella pagina del sito dell'ansa precedentemente caricata, e da qui direttamente linkati. nssdcftp.gsfc.nasa.gov Al frame 6007 si puo' osservare una connessione ftp (riconoscibile dalla porta di destinazione 21) di nssdcftp.gsfc.nasa.gov (128.183.114.83), in seguito alla richiesta di risoluzione del nome presso il solito DNS server usato nel resto dal capture(pacchetto 6005). Una volta connesso il login viene fatto come utente Anonymous, ed alla richiesta di password viene fornito un indirizzo email per la precisione [email protected] . A questo punto l'utente indica l'utilizzo della modalita' passiva con il comando PASV, in modo che il server specifichi al client quale sia la porta maggiore di 1024 a cui connettersi per il trasferimento dei dati. Il server risponde con una serie di sei numeri decimali che indicano il socket di connessione da utilizzare. Nel frame 6032 tali valori sono ad esempio 128, 183, 114, 83, 160, 204, per indicare il socket corrispondente all’indirizzo ip 128.183.114.83 ed alla porta 160*256+204=41164. Si puo’ infatti notare come successivamente venga fatto il three way handshake con la porta in questione (pacchetto 6033) e chiesto il listing di / : drwxrwxr-x drwxrwxr-x -rwxr-xr-x -rw-r--r-drwxr-xr-x --x--x--x drwxrwxr-x d--x--x--x drwxrwxr-drwxrwxr-x drwxrwxr-x drwxr-xr-x drwxr-x--drwxrwxr-x drwxrwxr-x drwxrwxr-x drwxrwxr-x dr-xr-xr-x 15 root sys 15 root sys 1 njames admin 1 root other 3 root admin 2 root other 2 root other 3 root other 9 root image 14 root admin 10 bilitza itm 5 bell photo 2 root admin 10 njames admin 44 root sys 11 root sys 7 root std 5 root other 1024 May 11 1024 May 11 1419 Dec 10 4561 May 6 1024 Nov 29 96 Mar 22 96 Feb 13 1024 Nov 24 81920 Mar 25 1024 Feb 12 1024 Apr 4 1024 Nov 13 1024 Nov 5 1024 Mar 12 1024 May 2 1024 May 9 1024 Feb 22 96 Sep 20 2004 . 2004 .. 2002 00README.TXT 2003 Access_Warning_Priv.html 2001 admind 2001 bin 2001 dev 2003 etc 14:52 image 2004 miscellaneous 2001 models 2001 photo_gallery 2004 pub 2004 selected_software 14:53 spacecraft_data 15:44 staging 16:41 standards 2000 usr L'utente tenta quindi di cambiare un paio di volte la directory corrente, ma l'operazione viene negata a causa di permessi d'accesso, prima di andare in /photo_gallery/. Ancora una volta viene dato il comando PASV per indicare l'intenzione di utilizzare la modalita' passiva; ricevuta la risposta dal server viene eseguito il three way handshake con la porta 41166, e quindi il listing della directory: drwxr-xr-x drwxrwxr-x -rwxr-xr-x drwxr-xr-x drwxr-xr-x drwxr-xr-x -rwxr-xr-x 5 15 1 2 8 7 1 bell root bell bell bell bell bell photo sys photo photo photo photo photo 1024 1024 2075 5120 1024 96 6474 Nov May Nov Nov Nov Nov Nov 13 11 13 13 13 13 13 2001 2004 2001 2001 2001 2001 2001 . .. AAREADME.TXT caption hi-res image photogallery-faq.txt Cambiata nuovamente la directory corrente in hi-res, nuovamente comando PASV e sincronia trilaterale con la porta 41167. Altro listing: drwxr-xr-x drwxr-xr-x drwxr-xr-x drwxr-xr-x drwxr-xr-x drwxr-xr-x drwxr-xr-x drwxr-xr-x 8 5 2 2 12 2 2 2 bell bell bell bell bell bell bell bell photo photo photo photo photo photo photo photo 1024 1024 2048 96 1024 1024 1024 96 Nov Nov Nov Nov Nov Nov Nov Nov 13 13 13 13 13 13 13 13 2001 2001 2001 2001 2001 2001 2001 2001 . .. astro misc planetary solar spacecraft special Cambio directory con il comando cd astro, ancora comando PASV con risposta Entering Passive Mode (128,183,114,83,160,208), connessione con la porta 41168 e directory listing: drwxr-xr-x 2 bell photo drwxr-xr-x 8 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo hst_bubble_ngc7635_0004.tiff -rwxr-xr-x 1 bell photo hst_carina_ngc3372_0006.tiff 2048 1024 14759134 14938100 14802276 15609480 6777962 16025486 1506848 6821964 Nov Nov Nov Nov Nov Nov Nov Nov Nov Nov 13 13 13 13 13 13 13 13 13 13 2001 2001 2001 2001 2001 2001 2001 2001 2001 2001 10180918 Nov 13 2001 . .. hst_30doradus_9933a.tiff hst_30doradus_9933b.tiff hst_abell2218_0008.tiff hst_antennae_9734a.tiff hst_antennae_9734a1.tiff hst_antennae_9734b.tiff hst_blkhole.tiff -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo hst_crescent_ngc6888_0023.tiff -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo hst_eskimo_ngc2392_0007.tiff -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo hst_neutron_star_9732.tiff -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo hst_pillars_m16_close.tiff -rwxr-xr-x 1 bell photo hst_southern_crab_9932.tiff -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo -rwxr-xr-x 1 bell photo 14141510 Nov 13 17009192 Nov 13 2001 hst_crab_nebula.tiff 2001 12538368 Nov 13 6753142 Nov 13 2001 hst_deep_field.tiff 2001 6626990 12785442 12718769 17402102 17445482 6269820 9942508 16190929 15134147 Nov Nov Nov Nov Nov Nov Nov Nov Nov 13 13 13 13 13 13 13 13 13 2001 2001 2001 2001 2001 2001 2001 2001 2001 hst_hcg87_9931.tiff hst_helix_detail.tiff hst_helix_nebula.tiff hst_lagoon_detail.tiff hst_lagoon_nebula.tiff hst_lmc_9944.tiff hst_m80_9926.tiff hst_ms1054-03_9928.tiff 12962556 1359868 6695963 7415014 16701120 1201644 16593128 14039022 11798390 11619546 Nov Nov Nov Nov Nov Nov Nov Nov Nov Nov 13 13 13 13 13 13 13 13 13 13 2001 2001 2001 2001 2001 2001 2001 2001 2001 2001 hst_ngc2207_9941.tiff hst_ngc3314_0014.tiff hst_ngc3603_9920.tiff hst_ngc4414_9925.tiff hst_ngc4438_0021.tiff hst_ngc6822_0101.tiff hst_omicron_ceti.tiff hst_papillon_9923.tiff hst_pillars_m16.tiff 16525626 Nov 13 2001 14158914 14081802 15120701 15100503 6794916 16180206 2001 2001 2001 2001 2001 2001 Nov Nov Nov Nov Nov Nov 13 13 13 13 13 13 hst_starform_ngc2366.tiff hst_starform_ngc604.tiff hst_stingray_nebula.tiff hst_tmr1.tiff hst_trifid_9942.tiff hst_wolf-rayet_9838.tiff L'ultima serie di comandi e' costituita dal comando TYPE I, e seguito da un altro PASV. In questo caso la porta indicata dal server e' la 41170, utilizzata per il download di un’immagine, richiesta con il comando RETR hst_antennae_9734a1.tiff . Infine viene terminata la sessione con il comando QUIT e chiusa la connessione con un pacchetto [RST,ACK] da 80.183.5.128 a nssdcftp.gsfc.nasa.gov. www.webzcan.com Al frame 6879 viene richiesto al DNS server 212.216.112.112 l'indirizzo IP di www.google.it, e ritornata la risposta con 66.249.85.104, per richiedere con metodo GET una pagina corrispondente al risultato della ricerca della query remote+portscan. Successivamente, al frame 6905, 80.183.5.128 richiede l'indirizzo IP di www.webzcan.com (217.160.226.86), in modo da potere eseguire una richiesta con metodo GET della pagina / Contents/pService.htm. La richiesta e' stata effettuata provenendo da un link ritornato da google, in risposta alla query di ricerca remote+portscan, come si vede dal campo referer dell’header http. Successivamente non deve essere stata trovata una risorsa richiesta, poiche' viene ritornato da 217.160.226.86 (webserver Apache 1.3.29 su piattaforma Unix) un codice di errore 404. Infine viene chiusa la connessione da parte di 80.183.5.128 . www.phlack.org Al frame 7295 viene richiesto al DNS l'indirizzo IP di www.phlak.org (140.211.166.28) e quindi richiesta con il metodo GET la pagina / modules/section/index.php?op=viewarticle&artid=1. Osservando l'header referer della richiesta http, la richiesta e' conseguenza di una ricerca effettuata con google con la query use+nessus+online. Infatti controllando il frame 7241 troviamo una richiesta a www.google.it con metodo GET della pagina di ricerca con query use+nessus+online. Probabilmente il sito visitato e' stato realizzato utilizzando il cms Xoops (vista anche l'inclusione del javascript xoops.js richiesto con metodo GET al frame 7735). A conferma della pagina come risultato della particolare query con google il fatto che tala pagina parli proprio di Nessus, come il security tool of the week, per la settimana del 17/11/2003. Successivamente viene avviata nuovamente una connessione con 140.211.166.28, riconoscibile dal pacchetto con il flag SYN impostato a uno e fatta la richiesta GET / modules/mydownloads. Il server che hosta il sito e' apache 1.3.26 con php 4.3.8 su piattoforma debian GNU/Linux. Al frame 7379 inoltre viene chiesto al DNS di risolvere l'indirizzo IP di www.paypal.com (216.113.188.34). Nella pagina visitata su phlak.org e' infatti presente un'immagine hostata su www.paypal.com (<input type="image" src="https://www.paypal.com/en_US/i/btn/xclick-but04.gif" border="0" name="submit" alt="Make payments with PayPal - it's fast, free and secure!">), probabilmente usata come tasto per un form di donazioni a favore di www.phlak.org. ui.skype.com Al frame 7795 da 80.183.5.128 viene fatta una richiesta http con il metodo GET della URI / ui/0/1.2.0.48/it/getlatestversion?ver=1.2.0.48&uhash=1c8ac507ea3e08750ef3f3a7bf6 41e2f3 all'host ui.skype.com, corrispondente all'indirizzo IP 212.72.49.131. Secondo gli header della richiesta http essa e' stata fatta usando la versione 1.2 di skype. Portscan da http://www.darkeiler.com Al frame 8054 (838.6 sec.) viene contattato attraverso http://www.google.it (il cui indirizzo e’ 66.249.85.99), il sito web http://www.derkeiler.com/Service/Portscan ,dopo avere effettuato la ricerca online+portscan, come si nota dal Referer della richiesta http. Prima di effettuare il three way handshake, viene contattato il DNS server 212.216.112.112, per risolvere l’indirizzo IP di www.derkeiler.com. Il DNS ritorna una risposta con l’indirizzo IP 195.140.232.111. Viene quindi fatto il three way handshake e richiesta con il metodo GET la uri / Service/Portscan. All’interno della pagina richiesta e’ presente un banner pubblicitario visualizzato ricorrendo ad un javascript presente su pagead2.googlesyndication.com. Viene infatti fatta una richiesta con metodo GET anche della risorsa pagead2.googlesyndication.com/pagead/show_ads.js , che viene richiamata dalla pagina www.derkeiler.com/Service/Portscan come mostrato dal referer al frame 8089. Referer: http://www.derkeiler.com/Service/PortScan/ Accept-Language: it Accept-Encoding: gzip, deflate If-Modified-Since: Fri, 06 May 2005 22:10:53 GMT; length=9268 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Host: pagead2.googlesyndication.com Connection: Keep-Alive In seguito viene chiesta piu’ volte la URI /Service/Portscan/Result, e piu’ volte chiusa la connessione con la porta 80. Dal frame 8314 inizia poi il portscan verso porte TCP, con gruppi di diversi pacchetti con lo stesso “tempo” di cattura. Le porte di destinazione non sembrano seguire un pattern particolare, mentre la porta sorgente, cambia ad ogni pacchetto, sempre pero’ con numeri piuttosto alti, tendenzialmente superiori a 64000. Anche in questo caso si tratta di un SYN-SCAN, infatti nel caso su una porta sie in esecuzione qualche servizio applicativo la sincronia trilaterale non viene completata, inviando un pacchetto di reset da 195.140.232.111 a 80.183.5.128. Il portscan molto corposo, riguarda un gran numero di porte TCP, in circa 8 secondi vengono infatti inviati 1400-1500 pacchetti. Al termine del portscan risultano aperte le seguenti porte TCP: 80 - http 135 - epmap 443 - https 445 - microsoft-ds 3000 – il webserver incluso in ntop (software per traffic monitoring) , oppure la backdoor Kutex 8080 – squid, tomcat 9999 - abyss webserver oppure le Backdoor lateda e beasty, o ancora il trojan The Prayer 49489 Portscan da onlinecheck.emisisoft.com Al frame 11775 80.183.5.128 richiede al DNS server 212.216.112.112 l'indirizzo IP di http://onlinecheck.emsisoft.com/ (195.70.106.2), e successivamente contatta questo sito web. Osservando l'header della richiesta http si puo' notare anche in questo caso come il referer sia la pagina dei risultati di una ricerca con google, con la query online+portscan. Successivamente vengono chieste con il metodo POST la pagina default.aspx e scan.aspx con alcuni parametri come ad esempio portscan=1. A questo punto il computer 80.183.5.128 viene sottoposto ad un portscan, mentre tra i diversi pacchetti diretti ad esso ve ne sono diversi provenienti dalla porta 80, contenenti nel body del messaggio http le varie parti di codice html che vanno a costituire la pagina con i risultati dell'operazione di scanning. Tra i diversi tentatativi e' stata provata piu'volte la connessione alle porte 27274, 12345 corrispondenti a due vecchie backdoor particolarmente note quali subseven e netbus. Dall'operazione risultano aperte le porte TCP seguenti : 80 - http 135 - epmap 443 - https 445 - microsoft-ds 3000 – il webserver incluso in ntop (software per traffic monitoring) , oppure la backdoor Kutex 9999 – abyss webserver oppure le Backdoor lateda e beasty, o ancora il trojan The Prayer www.liveye.net Al frame 14441 viene fatta una richiesta GET / all’indirizzo IP 62.149.195.127 corrispondente ad http://www.liveye.net. Seguono le richieste di ulteriori pagine per la precisione : GET GET GET GET /ita/index.html /ita/chisiamo.html (referer e' index.html) /ita/prodotto.html (referer chisiamo.html) /ita/contatti.html (referer contatti.html) Inoltre, secondo le informazione contenute nel cookie utilizzato, il login dell’utente che ha richiesto la pagina e' [email protected], la lingua l’italiano (lang=it) ed il tema scelto Lookout. Infine la connessione viene chiusa da 80.183.5.128 inviando un pacchetto TCP con i flag [RST][ACK] Attivita’ msn messenger In base ai pacchetti presenti nel capture, un utente sulla macchina 80.183.5.128 ha in esecuzione microsft msn messenger. Sono infatti presenti alcuni pacchetti TCP con porta di destinazione e di origine 1863, diretti all’indirizzo 207.46.107.102 . Sebbene nel capture e’ sono del tutto assenti i pacchetti relativi all’avvio della connessione da parte di un utente, l’invio delle informazioni relative al client e l’autenticazione dell’utente, e’ possibile riscontrare alcuni pacchetti relativi a questo sistema di messaggistica. Ad esempio sono presenti diversi pacchetti ping diretti da 80.183.5.128 a 207.46.107.102. Tali pacchetti hanno una funzione analoga al comando ping di IRC e sono riconoscibili dal comando PNG presente nel payload del pacchetto. Analogamente sono presenti delle risposte a questi ping, da parte di 207.46.107.102 e caratterizzate dalla presenza nel payload del comando QNG. Alla ricezione del pacchetto QNG viene inviato in risposta un pacchetto di acknowledgement con il flag ACK impostato ad 1. Questi pacchetti vengono normalmente utilizzati per testare la latenza tra client e server oppure per assicurare che la connessione tra le due parti resti attiva, e non venga magari chiuso il relativo socket. Si puo’ infatti notare come tali pacchetti vengano inviati ad intervalli piu’ o meno regolari, ogni 45-50 secondi circa. Altro pacchetto di interesse e’ il 3775, contente nel payload il comando FLN [email protected] , da 207.46.107.102 a 80.183.5.128 . Il Comando FLN dovrebbe essere inviato dal notification server quando un utente della propria lista si disconnette oppure “nasconde” la propria presenza. Sono inoltre presenti pacchetti contenenti la stringa UBX [email protected]. Il comando UBX e’ il comando gemello di UUX. UUX viene inviato al notification server da un utente che ha modificato il proprio messaggio personale o il brano attualmente in riproduzione. UBX al contrario viene inviato dal server a coloro che abbiano l’utente in questione nella propria lista di contatti per notificare la cosa. Il primo parametro del comando e’ l’identificativo del contatto che ha effettuato la modifica, ed il secondo la lunghezza del payload. Sono poi presenti degli UBX da [email protected]. Nel capture sono presenti due UBX relativi [email protected] . Nel primo caso(pacchetto 6078) il payload risulta 0 e manca la parte data: UBX [email protected] 0 Nel secondo caso invece il payload del pacchetto 6085 e’ il seguente, e probabilmente riporta la modifica del messaggio personale de [email protected], che desidera avvisare del fatto che si trovi a casa: UBX [email protected] 70 <Data><PSM>I'm at the house</PSM><CurrentMedia></CurrentMedia></Data> Sono infine presenti anche due pacchetti diretti dal sever al client conteneti il comando NLN (6080 e 6087). Tale Comando serve per indicare il proprio "status" (ad sempio Available, busy, idle, ecc...). Probabilmente essi dovrebbero essere usati per inviare un messaggio di notifica della propria presenza, include il proprio status, il display name(nickname?), e un numero che rappresenta diverse informazioni riguardo il client. Nel capture analizzato l’utente su 80.183.5.128 ha ricevuto la notifica seguente, che sta ad indicare che l'utente [email protected] puo' ricevere messaggi, non essendo occupato con altro , e vuole che ci si riferisca a lui come Jamey Kirby : NLN IDL [email protected] Jamey%20Kirby 1073795116 Attivita’ samba-netbios Nello scan sono presenti diversi pacchetti relativi al protocollo smb-cifs, che tendenzialmente rispettano un medesimo pattern. Inizialmente viene fatto un trhee way handshake sulla porta TCP 445 della macchina con indirizzo 80.183.5.128, ed inviato un pacchetto con il comando SMB_COM_NEGOTIATE (distinguibile dal codice esadecimale 0x72), in cui vengono specificati i dialetti cifs che il client e’ in grado di comprendere, ovvero il set di comandi riconosciuti, specificati come stringhe ASCI terminate dal carattere NULL. A questo punto 80.183.5.128 risponde, facendo una comparazione sulle stringhe ricevute ricerca il set di comandi di livello piu’ alto che e’ in grado di riconosce. Effettuata la ricerca viene inviata una risposta contenente un indice per identificare la posizione del dialetto scelto nella lista spedita precedentemente. Anche in questo caso il codice che rappresenta il comando e' 0x72 . 80.183.5.128 ritorna anche un identificatore di sessione. La fase successiva e’ il setup della sessione SMB. Un server con un livello di sicurezza “userlevel” richiede l’autenticazione degli utenti prima di concedere loro l’accesso alle risorse condivise. Questa fase viene invece saltata nel caso di sicurezza al livello share-level. Generalmente l’accesso per il browsing Secondo il protocollo CIFS il nome per questa fase e’ SessionSetupAndX. L’idea di base e’ quella di inviare uno username ed una password per ottenere in risposta uno UID. Tra le informazioni inviate dal client al server, all’interno del pacchetto possiamo trovare un buffer contenente la password cifrata, lo username, ed altre stringhe che indicano il nome del sistema operativo ed il LAN manager. La dimensione di tale buffer e’ specificata dal campo Bytecount In tutte le richieste effettuate a 80.183.5.128 viene ritornato al richiedente lo UID 48(come si puo’ vedere dal campo User ID). Ottenuto uno UID un utente tenta di connettersi a qualche condivisione, specificando in un pacchetto la condivisione richiesta. Il comando usato dovrebbe essere Tree Connect andX request, identificato dal codice 0x75. Il nome dalla share richiesta e’ contenuta in un buffer, la cui lunghezza viene specificata da bytecount. Nei pacchetti catturati da ethereal si nota che viene richiesta la condivisione identificata dalla stringa PATH:\\80.183.5.128\ipc$ . Segue quindi una risposta da parte del server, Tree Connect AndX Response (0x73): se la condivisione specificata dal client esiste e l’utente ha i privilegi d’accesso richiesti allora il server ritorna una risposta positive com il campo Tree Id impostato ad un numero usato come riferimento per la risorsa. Se la condivisione non esiste o i privilegi sono insufficianti il server ritornera’ l’opportuno errore. Nelle risposte date dal server alle richieste il valore Tree Id era sempre impostato a 2048. Infine l’utente cerca di accedere a files o directory nelle condivisione per cui ha ottenuto il TID. All’interno del capture abbiamo due situazioni distinte : - una richiesta di Path:\lsarpc da parte dell’indirizzo IP 80.59.46.218 (indirizzo spagnolo, del provider telefonica.es, TELEFONICA DE ESPANA). Due richieste di Path:\srvsvc da parte di 195.70.106.2, quindi appartenente allo scan fatto da parte di onlinecheck.emsisoft.com. In entrambi i casi il risultato dell’operazione e’ l’errore STATUS_ACCESS_DENIED, probabilmente perche’ il richiedente non ha aveva i privilegi d’accesso necessari all’interno del contesto definito dai valori del Tree Id e UID. Nel primo caso, una richiesta simile corrisponde a quelle fatte dal worm Sasser e da altri worm della stessa famiglia, stando a quanto affermato dall’articolo Detecting activity that may be due to LSASS worms, presente su www.symantec.com . Nel secondo caso invece viene richiesta l’interfacca Server Service (srvsvc) Remote Procedure Call. Essa consente di gestire file e stampanti e rispondere alle richieste fatte da altri computer riguardo a risorse condivise sul computer locale. Le restrizione di accesso verso i servizi RPC, come appunto srvsvc, sono fondamentali, ma talvolta possono trovarsi configurazioni in cui e’ possibile accedervi con accessi anonimi, sfruttando SMB NULL SESSION con la condivisione IPC$ (interprocess communication) Le null sessions sono una modalita’ di comunicazione del protocollo Server Message Block (SMB), note ance come Accessi anonimi, e consentono ad un utente anonimo di ottenere informazioni attraverso la rete (come ad esempio nomi di utenti e condivisioni) o di accedere a alcune risorse senza autenticazione. Sfruttando un’accesso anonimo, su sistemi malconfigurati, un attacker potrebbe quindi usare delle Remote Procedure Call, raccogliere info su password, gruppi, utenti, servizi, persino tentare un’escalation dei privilegi. Nello scan non dovrebbe di trattarsi di un’attivita’ malevola, poiche’ inserita all’interno del testing e dello scan eseguito dal sito onlinechek.emsisoft.com . In ogni caso il sistema controllato sembrerebbe essere configurato correttamente, poiche’ viene ritornato l’errore STATUS_ACCESS_DENIED alle richieste effettuate. Attivita’ sulla porta UDP 23713 E’ stata notata dell’attivita’ sulla porta UDP 23713, in cui sono coinvolti diversi indirizzi IP. Per gran parte del capture (a partire dal terzo pacchetto) vengono inviati dall’indirizzo IP 82.50.155.97 (un’ADSL telecom italia) pacchetti alla porta 23713, con porta sorgente 38976. 80.183.5.128 risponde con un pacchetto UDP destinato alla porta 38976 e con porta sorgente 23713. Ogni pacchetto contiene 3 bytes di dati. A partire dal pacchetto 186 sono presenti altri pacchetti alcuni pacchetti da 80.183.5.128 a 83.211.72.34 (Adsl Eutelia), tutti dalla porta 23713 alla UDP 32411. In ogni occasione l’indirizzo di Eutelia ritorna un pacchetto ICMP di destination unreachable (port unreachable). Sono poi presenti ancora pacchetti verso la porta udp 23713 di 80.183.5.128 e risposte con porta sorgente udp 23713. Lo scambio avviene con diversi indirizzi IP, come 82.255.172.67 (Proxad, provider francese), 131.211.109.123 (Solisnet, universita' di Utrecht) ecc. Attivita’ sulla porta TCP 135(epmap) Nel capture si possono notare alcuni pacchetti legati alle RPC, Remote Procedure Calls, ovvero un meccanismo comunicazione tra processi che che permette ad un programma che funziona su un computer di eseguire codice su un sistema remoto. Esistono diversi exploit che sfruttano le vulnerabilità di questo sistema, che permettono l'esecuzione di codice arbitrario. Per esempio dal frame 346 si possono osservere in diversi momenti due serie di pacchetti scambiati tra 80.183.5.128 e 80.183.10.77 (un’adsl telecom tin easy lite a giudicare dall’indirizzo IP). Altra attivita’ su questa porta di 80.183.5.128 viene generata da parte di: - 82.52.27.158 (telecom italia) dal frame 12147 80.165.2.178 dal frame 14565. Il mittente in questo caso e’ un indirizzo danese TDCBREDBAANDSADSL-PROF-NET. 80.116.255.36 dal frame 715. Trattasi di un ADSL tin-easy lite L’attivita’ su questa porta, comunque, non si limita solo a questi indirirzi IP, ma anche diversi altri, ADSL tin-easy lite, Telecom Italia, neuf telecom ecc. Per la precisione durante queste connessioni vengono fatte delle bind e delle chiamate alle interfacce MGMT, DSSETUP, ed IsystemActivator, alle quali 80.183.5.128 risponde con lo status di errore nca_s_fault_access_denied. Tutti questi pacchetti sono molto probabilmente dei tentativi di sfruttare vulnerabilita’ presenti nel servizio Microsoft Remote Procedure Call. Tale meccanismo e’ stato utilizzato anche dal noto worm blaster. Vista la frequenza con cui questi pattern di traffico si ripetono da diversi indirizzi IP, si suppone appunto che tali macchine siano state colpite dal worm in questione. Tuttavia tali tentativi non raggiungono l’obbiettivo di compromettere 80.135.5.128; il sistema in questione probabilmente e’ stato gia’ patchato o comunque configurato correttamente. Altre attivita’ rilevate Nell’analisi del capture sono state rilevate anche altre attivita’ tra cui si annoverano: - - - - Al frame 460 l’indirizzo di Telecom Italia 80.183.98.41 tenta di accedere allo share IPC$ al frame 1460 un tentativo di connessione verso la porta 4480 (riconoscibile dal flag SYN ad 1) da 82.49.143.50 a 80.183.5.128. L’indirizzo IP di origine e’ una ADSL Telecom, mentre la porta di destinazione dovrebbe essere quella usata da Proxy+, un software per windows che permette di svolgere le funzioni di firewall, proxy e mail server; ai frame 3778 e 7975 l’indirizzo IP 80.21.242.156 (Comune di Montecatini Terme) tenta una connessione sulla porta TCP 4662 di 80.183.5.128. Questa porta viene normalmente utilizzata per il trasferimento dei file dai vari programmi per il peer to peer basati sul protocollo e2k, come emule ad esempio. Dal frame 11698 l’indirizzo IP 80.183.47.34 (altra adsl telecom) invia per tre volte un pacchetto TCP con flag SYN impostato a uno sulla porta 139(netbios-ssn) di 80.183.5.128. Diversi pacchetti da 84.52.134.9 verso 80.183.5.128, con porta sorgente 1259 e destinazione 14528 - Strani pacchetti per il servizio window messenger, provenienti dagli IP 222.77.185.44 e 61.152.158.151, che riportano messaggi di avviso con errori critici riguardo allo stato di 80.183.5.128, per esempio avvisando di una corruzione del registro di windows, o ancora 47 diversi errori critci invitando a visitare alcuni siti per correggere tali errori quali http://reg-scanner.com, http://reg-patch.com, http://registryfixit.com ed eventualmente scaricare ed eseguire alcuni software che dovrebbero correggere i presunti problemi. Sarebbe decisamente improbabile che windows inviti scaricare un software di riparazione del registro senza passare per il download center di microsoft, quindi si presume che gli alert inviati volessero attirare utenti sui siti indicati, si spera per scopi pubblicitari, e non per scaricare qualche malware. Considerazioni relativa alla salvaguardia del network I portscan non dovrebbero destare preoccupazione, poiche’ eseguiti da siti contattati direttamente dalla macchina “target”. Si presume che non si tratti di attivita’ volte alla raccolta di informazioni per un successivo attacco, ma piu’ ad un controllo per verificare lo stato della macchina in questione. Si consiglia invece di filtrare a livello di firewall tutte le porte che risultano aperte e non debbano essere accessibili da remoto. Attenzione particolare andrebbe prestata alle porte 3000 e 9999. Esse corrispondono a servizi perfettamente legittimi come il webserver integrato in ntop od il webserver Abyss, ma potrebbe anche trattarsi di backdoor come Beasty, Lateda oppure Kutex In ogni caso si consiglia di verificare se queste backdoor siano realmente presenti sul computer in questione. La porta 8080 invece potrebbe essere usata da Tomcato oppure Squid. Se tali servizi non fossero effettivamente utilizzato si consiglia di disattivarli. Riguardo a squid inoltre si consiglia di prestare particolare attenzione alla sua configuraazione, specialmente per quanto riguarda l’autenticazione degli utenti, i meccanismi di logging,ed eventuali ACL. Se il servizio non deve essere acceduto da un’interfaccia esterna, da parte di indirizzi ip che non siano gia’ noti a priori, si consiglia di filtrare a livello di firewall su tale interfaccia la porta associata. Lo stesso discorso e’ valido per la porta 80. A meno che non esista la reale necessita’ di avere un webserver accessibile da web sulla propria macchina, e’ consigliabile arrestare tale servizio o perlomeno filtrarlo a livello di firewall, poiche’ potrebbe esporre a diversi attacchi, sfruttando eventuali vulnerabilita’. Si cosiglia, inoltre, anche di filtrare le porte TCP 139 e 445 utilizzate per la condivisione di file e stampanti, poiche’ molto spesso vulnerabilita’ dei protocolli CIFS ed SMB possono consentire attacchi di diverso tipo. In caso il servizio debba essere attivo ed accessibile sarebbe opportuno disabilitare tutte le condivisioni di default non utilizzate, ed impostare sempre il livello di sicurezza come “user-level” in modo da richiedere l’autenticazione degli utenti che accedono alle differenti risorse. Infine, il computer in questione sembrerebbe sicuro rispetto alla vulnerabilita’ sfruttata da blaster. In caso contrario sarebbe stato consigliabile verificare la presenza del worm, eventualmente rimuoverlo con qualche tool, ed aggiornare windows in modo da correggere la vulnerabilita’ sfruttata. Andrebbero inoltre di bloccate tramite un firewall le porte usate da RPC, ovvero TCP 135, 139, 445 e 593; UDP 135, 137, 138 and 445, stando a diversi advisory disponibili in rete.