Avendo completato la sincronia trilaterale con l unico servizio aperto si suppone si sia trattato di un TCP Connect scan

Transcript

1 Laboratorio di reti Beretta Andrea, matr 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 al DNS server con IP , per richiedere l indirizzo IP di probe.hackerwatch.org. Ottenuta la risposta, viene eseguito con successo il three way handshake con , 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 Il sito infatti invia diverso pacchetti TCP con flag SYN impostato ad 1 per vedere le porte aperte. Infatti 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 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 completa la sincronia trilaterale rispondendo con un pacchetto ACK e infine chiude la connessione con un FIN-ACK: TCP 3960 > http [SYN] TCP http > 3960 [SYN, ACK] TCP 3960 > http [ACK] TCP 3960 > http [FIN, ACK] Avendo completato la sincronia trilaterale con l unico servizio aperto si suppone si sia trattato di un TCP Connect scan Portscan da Al frame 475 viene richiesto IP di grc.com ( ), e poi avviato il three way handshake con la porta 443 di 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 richiedendo l indirizzo IP di (frame 515 dopo sec.), ottenendo in risposta Viene fatto un altro three way handshake con l indirizzo IP e fatta la richiesta POST 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.

2 AL frame 919 viene inviato un pacchetto ICMP (echo request) da a , e una volta ritornato l echo reply ha inizio il portscan. Sono presenti un gran numero di tentativi di connessione da , 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 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, non termina neppure il three way handshake inviando un pacchetto RST,ACK, resettando la connessione. Dovrebbe quindi trattarsi di un SYN scan TCP > 139 [SYN] TCP 139 > [RST, ACK] [...] TCP > 135 [SYN] TCP 135 > [SYN, ACK] [...] TCP > 135 [RST, ACK] L invio dei SYN inizia dal frame 922(circa 81 sec) e termina col 3345 (113.6 sec). Tra le porte TCP aperte di (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 ( sec.) viene contattato attraverso (il cui indirizzo e ), il sito web 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 , 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: 8&rls=GGLD,GGLD: ,GGLD:it&q=test+personal+firewall Accept-Language: it Accept-Encoding: gzip, deflate If-Modified-Since: Wed, 20 Oct :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 ) 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.

3 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/ Not Modified Date: Wed, 11 May :37:15 GMT Server: Apache/ (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 ). 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 e diretto a , 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 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 , 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 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 , 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 , 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

4 crescente ( per es. non seguono un pattern del tipo 1001, 1002, 1003, 1004, ), 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 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 , a cui risponde con dei pacchetti ICMP (Port unreachable) Tra questi pacchetti UDP, in particolare si puo notare il numero 4784, diretto alla porta 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 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 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. Al frame 4867 viene chiesto l'indirizzo di al DNS server Ottenuta la risposta con l'indirizzo IP , richiede la root directory del sito web con una GET /. Dalla risposta http di 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 ( ) 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 ( ), 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 per la precisione @notset.com. 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 ed alla porta 160* = Si puo infatti notare come successivamente venga fatto il three way handshake con la porta in questione (pacchetto 6033) e chiesto il listing di / :

5 drwxrwxr-x 15 root sys 1024 May drwxrwxr-x 15 root sys 1024 May rwxr-xr-x 1 njames admin 1419 Dec README.TXT -rw-r--r-- 1 root other 4561 May Access_Warning_Priv.html drwxr-xr-x 3 root admin 1024 Nov admind --x--x--x 2 root other 96 Mar bin drwxrwxr-x 2 root other 96 Feb dev d--x--x--x 3 root other 1024 Nov etc drwxrwxr-- 9 root image Mar 25 14:52 image drwxrwxr-x 14 root admin 1024 Feb miscellaneous drwxrwxr-x 10 bilitza itm 1024 Apr models drwxr-xr-x 5 bell photo 1024 Nov photo_gallery drwxr-x--- 2 root admin 1024 Nov pub drwxrwxr-x 10 njames admin 1024 Mar selected_software drwxrwxr-x 44 root sys 1024 May 2 14:53 spacecraft_data drwxrwxr-x 11 root sys 1024 May 9 15:44 staging drwxrwxr-x 7 root std 1024 Feb 22 16:41 standards dr-xr-xr-x 5 root other 96 Sep 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 5 bell photo 1024 Nov drwxrwxr-x 15 root sys 1024 May rwxr-xr-x 1 bell photo 2075 Nov AAREADME.TXT drwxr-xr-x 2 bell photo 5120 Nov caption drwxr-xr-x 8 bell photo 1024 Nov hi-res drwxr-xr-x 7 bell photo 96 Nov image -rwxr-xr-x 1 bell photo 6474 Nov photogallery-faq.txt Cambiata nuovamente la directory corrente in hi-res, nuovamente comando PASV e sincronia trilaterale con la porta Altro listing: drwxr-xr-x 8 bell photo 1024 Nov drwxr-xr-x 5 bell photo 1024 Nov drwxr-xr-x 2 bell photo 2048 Nov astro drwxr-xr-x 2 bell photo 96 Nov misc drwxr-xr-x 12 bell photo 1024 Nov planetary drwxr-xr-x 2 bell photo 1024 Nov solar drwxr-xr-x 2 bell photo 1024 Nov spacecraft drwxr-xr-x 2 bell photo 96 Nov 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 e directory listing: drwxr-xr-x 2 bell photo 2048 Nov drwxr-xr-x 8 bell photo 1024 Nov rwxr-xr-x 1 bell photo Nov hst_30doradus_9933a.tiff -rwxr-xr-x 1 bell photo Nov hst_30doradus_9933b.tiff -rwxr-xr-x 1 bell photo Nov hst_abell2218_0008.tiff -rwxr-xr-x 1 bell photo Nov hst_antennae_9734a.tiff -rwxr-xr-x 1 bell photo Nov hst_antennae_9734a1.tiff -rwxr-xr-x 1 bell photo Nov hst_antennae_9734b.tiff -rwxr-xr-x 1 bell photo Nov hst_blkhole.tiff -rwxr-xr-x 1 bell photo Nov hst_bubble_ngc7635_0004.tiff -rwxr-xr-x 1 bell photo Nov hst_carina_ngc3372_0006.tiff

6 -rwxr-xr-x 1 bell photo Nov hst_crab_nebula.tiff -rwxr-xr-x 1 bell photo Nov hst_crescent_ngc6888_0023.tiff -rwxr-xr-x 1 bell photo Nov hst_deep_field.tiff -rwxr-xr-x 1 bell photo Nov hst_eskimo_ngc2392_0007.tiff -rwxr-xr-x 1 bell photo Nov hst_hcg87_9931.tiff -rwxr-xr-x 1 bell photo Nov hst_helix_detail.tiff -rwxr-xr-x 1 bell photo Nov hst_helix_nebula.tiff -rwxr-xr-x 1 bell photo Nov hst_lagoon_detail.tiff -rwxr-xr-x 1 bell photo Nov hst_lagoon_nebula.tiff -rwxr-xr-x 1 bell photo Nov hst_lmc_9944.tiff -rwxr-xr-x 1 bell photo Nov hst_m80_9926.tiff -rwxr-xr-x 1 bell photo Nov hst_ms _9928.tiff -rwxr-xr-x 1 bell photo Nov hst_neutron_star_9732.tiff -rwxr-xr-x 1 bell photo Nov hst_ngc2207_9941.tiff -rwxr-xr-x 1 bell photo Nov hst_ngc3314_0014.tiff -rwxr-xr-x 1 bell photo Nov hst_ngc3603_9920.tiff -rwxr-xr-x 1 bell photo Nov hst_ngc4414_9925.tiff -rwxr-xr-x 1 bell photo Nov hst_ngc4438_0021.tiff -rwxr-xr-x 1 bell photo Nov hst_ngc6822_0101.tiff -rwxr-xr-x 1 bell photo Nov hst_omicron_ceti.tiff -rwxr-xr-x 1 bell photo Nov hst_papillon_9923.tiff -rwxr-xr-x 1 bell photo Nov hst_pillars_m16.tiff -rwxr-xr-x 1 bell photo Nov hst_pillars_m16_close.tiff -rwxr-xr-x 1 bell photo Nov hst_southern_crab_9932.tiff -rwxr-xr-x 1 bell photo Nov hst_starform_ngc2366.tiff -rwxr-xr-x 1 bell photo Nov hst_starform_ngc604.tiff -rwxr-xr-x 1 bell photo Nov hst_stingray_nebula.tiff -rwxr-xr-x 1 bell photo Nov hst_tmr1.tiff -rwxr-xr-x 1 bell photo Nov hst_trifid_9942.tiff -rwxr-xr-x 1 bell photo Nov 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 a nssdcftp.gsfc.nasa.gov. Al frame 6879 viene richiesto al DNS server l'indirizzo IP di e ritornata la risposta con , per richiedere con metodo GET una pagina corrispondente al risultato della ricerca della query remote+portscan. Successivamente, al frame 6905, richiede l'indirizzo IP di ( ), 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 (webserver Apache su piattaforma Unix) un codice di errore 404. Infine viene chiusa la connessione da parte di Al frame 7295 viene richiesto al DNS l'indirizzo IP di ( ) e quindi richiesta con il metodo GET la pagina / modules/section/index.php?op=viewarticle&artid=1. Osservando l'header referer della

7 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 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 , 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 con php su piattoforma debian GNU/Linux. Al frame 7379 inoltre viene chiesto al DNS di risolvere l'indirizzo IP di ( ). Nella pagina visitata su phlak.org e' infatti presente un'immagine hostata su (<input type="image" src=" 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 ui.skype.com Al frame 7795 da viene fatta una richiesta http con il metodo GET della URI / ui/0/ /it/getlatestversion?ver= &uhash=1c8ac507ea3e08750ef3f3a7bf6 41e2f3 all'host ui.skype.com, corrispondente all'indirizzo IP Secondo gli header della richiesta http essa e' stata fatta usando la versione 1.2 di skype. Portscan da Al frame 8054 (838.6 sec.) viene contattato attraverso (il cui indirizzo e ), il sito web 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 , per risolvere l indirizzo IP di Il DNS ritorna una risposta con l indirizzo IP 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 come mostrato dal referer al frame Referer: Accept-Language: it Accept-Encoding: gzip, deflate If-Modified-Since: Fri, 06 May :10:53 GMT; length=9268 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;.NET CLR ) 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 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 a

8 Il portscan molto corposo, riguarda un gran numero di porte TCP, in circa 8 secondi vengono infatti inviati pacchetti. Al termine del portscan risultano aperte le seguenti porte TCP: 80 - http epmap https microsoft-ds 3000 il webserver incluso in ntop (software per traffic monitoring), oppure la backdoor Kutex 8080 squid, tomcat abyss webserver oppure le Backdoor lateda e beasty, o ancora il trojan The Prayer Portscan da onlinecheck.emisisoft.com Al frame richiede al DNS server l'indirizzo IP di ( ), 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 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, corrispondenti a due vecchie backdoor particolarmente note quali subseven e netbus. Dall'operazione risultano aperte le porte TCP seguenti : 80 - http epmap https 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 Al frame viene fatta una richiesta GET / all indirizzo IP corrispondente ad Seguono le richieste di ulteriori pagine per la precisione : GET /ita/index.html GET /ita/chisiamo.html (referer e' index.html) GET /ita/prodotto.html (referer chisiamo.html) GET /ita/contatti.html (referer contatti.html) Inoltre, secondo le informazione contenute nel cookie utilizzato, il login dell utente che ha richiesto la pagina e' federico@liveye.net, la lingua l italiano (lang=it) ed il tema scelto Lookout. Infine la connessione viene chiusa da inviando un pacchetto TCP con i flag [RST][ACK] Attivita msn messenger In base ai pacchetti presenti nel capture, un utente sulla macchina ha in esecuzione microsft msn messenger. Sono infatti presenti alcuni pacchetti TCP con porta di destinazione e di origine 1863, diretti all indirizzo 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.

9 Ad esempio sono presenti diversi pacchetti ping diretti da a 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 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 secondi circa. Altro pacchetto di interesse e il 3775, contente nel payload il comando FLN g_ates@hotmail.com, da a 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 ed@tfb.com. 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 ed@tfb.com. Nel capture sono presenti due UBX relativi ed@tfb.com. Nel primo caso(pacchetto 6078) il payload risulta 0 e manca la parte data: UBX ed@tfb.com 0 Nel secondo caso invece il payload del pacchetto 6085 e il seguente, e probabilmente riporta la modifica del messaggio personale de ed@tfb.com, che desidera avvisare del fatto che si trovi a casa: UBX ed@tfb.com 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 ha ricevuto la notifica seguente, che sta ad indicare che l'utente ed@tfb.com puo' ricevere messaggi, non essendo occupato con altro, e vuole che ci si riferisca a lui come Jamey Kirby : NLN IDL ed@tfb.com Jamey%20Kirby 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 , 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 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.

10 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 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:\\ \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 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 (indirizzo spagnolo, del provider telefonica.es, TELEFONICA DE ESPANA). - Due richieste di Path:\srvsvc da parte di , 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 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 E stata notata dell attivita sulla porta UDP 23713, in cui sono coinvolti diversi indirizzi IP.

11 Per gran parte del capture (a partire dal terzo pacchetto) vengono inviati dall indirizzo IP (un ADSL telecom italia) pacchetti alla porta 23713, con porta sorgente risponde con un pacchetto UDP destinato alla porta e con porta sorgente Ogni pacchetto contiene 3 bytes di dati. A partire dal pacchetto 186 sono presenti altri pacchetti alcuni pacchetti da a (Adsl Eutelia), tutti dalla porta alla UDP 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 di e risposte con porta sorgente udp Lo scambio avviene con diversi indirizzi IP, come (Proxad, provider francese), (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 e (un adsl telecom tin easy lite a giudicare dall indirizzo IP). Altra attivita su questa porta di viene generata da parte di: (telecom italia) dal frame dal frame Il mittente in questo caso e un indirizzo danese TDC- BREDBAANDSADSL-PROF-NET 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 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 ; 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 tenta di accedere allo share IPC$ - al frame 1460 un tentativo di connessione verso la porta 4480 (riconoscibile dal flag SYN ad 1) da a 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 (Comune di Montecatini Terme) tenta una connessione sulla porta TCP 4662 di 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 l indirizzo IP (altra adsl telecom) invia per tre volte un pacchetto TCP con flag SYN impostato a uno sulla porta 139(netbios-ssn) di Diversi pacchetti da verso , con porta sorgente 1259 e destinazione 14528

12 - Strani pacchetti per il servizio window messenger, provenienti dagli IP e , che riportano messaggi di avviso con errori critici riguardo allo stato di , 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 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 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.