26/04/2012

Analisi di un attacco di phishing

Ormai stressato dalle n-mila email di phishing che puntualmente superano i filtri antispam, ho deciso di fare chiarazza 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.21

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
[sudo] password for nightfly:

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 uno script (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:Userseldo>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.

27/11/2011

IP pubblico blacklistato da out.virgilio.it

Da un po' di tempo a questa parte mi capita di non ricevere le notifiche via mail da qualcuno dei miei server. Purtroppo ciò accade saltuariamente ed in modo pseudorandom, quindi per mettere bene a fuoco la problematica ho dovuto effettuare un'attenta analisi degli eventi.

blacklist.jpg

Ma andiamo con ordine. Ieri, dopo aver aperto il mio client di posta elettronica, mi sono accorto che mancavano TUTTE le email di notifica del mio server casalingo (qualche giorno prima mi era successo la stessa cosa con il server di un amico commercialista). Accedo quindi alla shell via SSH e lancio il comando:

nightfly@nightbox:~$ cat /var/log/exim4/mainlog | grep mioindirizzoemail

Una delle entry riportava le seguenti informazioni:

** *@nightbox.it R=hub_user_smarthost T=remote_smtp_smarthost: SMTP error from remote mail server after MAIL FROM:<> SIZE=2430: host rm.virgilio.it [62.211.72.20]: 550 mail not accepted from blacklisted IP address [188.11.59.93]

Uhm, il mio IP pubblico, ovvero 188.11.59.93 è stato blacklistato dall'SMTP di virgilio... ma per quale motivo?

Mi collego dunque al sito www.senderbase.org e digito il mio indirizzo IP pubblico. Come risultato mi becco una bella schermata in cui c'è scritto che l'IP da me digitato è classificato come poor ed è stato inserito nella pbl di spamhaus.org. Bene, ma cosa diavolo è questa pbl? Cito testualmente:

The Spamhaus PBL is a DNSBL database of end-user IP address ranges which should not be delivering unauthenticated SMTP email to any Internet mail server except those provided for specifically by an ISP for that customer's use. The PBL helps networks enforce their Acceptable Use Policy for dynamic and non-MTA customer IP ranges.

Ok, quindi il problema è dovuto al fatto che ho inviato le email al mio MTA (out.virgilio.it) senza essermi prima autenticato. Inoltre, il controllo viene effettuato solo sugli IP pubblici che iniziano con 188.*, ovvero gli ultimi (in ordine di tempo) messi a disposizione per gli utenti di Aliceadsl.

Ne è la riprova il fatto che gli altri server che utilizzano un IP pubblico diverso da 188.* non vengono blacklistati, nonostante continuino a non usare l'autentica per connettersi all'SMTP di virgilio.

Per completezza, queste sono le blacklist su cui si basa l'SMTP citato in precedenza:

http://www.spamhaus.org
http://ipremoval.sms.symantec.com
http://cbl.abuseat.org
http://psbl.surriel.com

Ma come fare per risolvere il problema? Semplice, basta fare in modo che venga utilizzata l'autentica in fase di invio dei messaggi email (soluzione definitiva), oppure cambiare indirizzo IP pubblico, sperando che non ce ne venga assegnato nuovamente uno del blocco 188.* (soluzione temporanea).

A presto.

Aggiornamento

A quanto pare il controllo sull'autenticazione SMTP è stato esteso anche ad altri netblock, ad esempio il 79.*. Dunque vi consiglio di settare l'autentica per lo smarthost (se utilizzate exim4 come mail server locale, potete trovare informazioni utili in questo post).

29/10/2010

Postfix: configurazione minimale

Premesso che esistono tantissimi mail agent per i sistemi *nix, questa guida ha come scopo quello di illustrare una configurazione minimale (ma funzionale) di postfix su CentOS.

Per prima cosa è necessiario installare tale applicativo. Per semplicità utilizzeremo yum:

[nightfly@centosbox ~]# yum install postfix

Una volta completata l'installazione del pacchetto occorre passare alla sua configurazione. In particolare, vogliamo che postfix invii ad un server SMTP esterno (smarthost) il nostro messaggio di posta, il quale verrà successivamente recapitato sulla nostra mailbox (ad esempio @email.it).

A tal proposito, sarà necessario creare il file sender_canonical all'interno della dir /etc/postfix:

[nightfly@centosbox postfix]# touch sender_canonical

La sintassi da utilizzare all'interno di questo file è la seguente:

<nome utente> <indirizzo di posta da usare come mittente>

Ad esempio:

nightfly nightfly@miodominio.it

Ovviamente il nome del dominio deve essere valido, altrimenti il server SMTP esterno risponderà picche.

A questo punto lanciamo il comando:

[nightfly@centosbox postfix]# postfix sender_canonical

attraverso il quale postfix creerà un file sender_canonical.db da utilizzare per individuare l'indirizzo di posta del mittente in fase di invio.

Modifichiamo infine il file main.cf aggiungendo la seguente stringa:

sender_canonical_maps = hash:/etc/postfix/sender_canonical

Riavviamo postfix:

[nightfly@centosbox postfix]#service postfix restart

ed inviamo una mail di prova utilizzando il comando mail:

[nightfly@centosbox postfix]# mail vostroindirizzo@email.it

Diamo un'occhiata al file messages nella dir /var/log, magari utilizzando un | grep postfix:

[nightfly@centosbox postfix]#cat /var/log/messages | grep postfix

e se otteremo un output simile al seguente:

Oct 29 10:24:42 test-monitor postfix/smtp[7611]: 80FC8301F1: to=<indirizzo@email.it>, relay=mx.email.it[212.97.34.36]:25, delay=0.32, delays=0.07/0/0.04/0.22, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C4F714400C)

vuol dire che la nostra mail è stata inviata con successo.

See ya.

10:58 Scritto da: nazarenolatella in SO: Linux | Link permanente | Commenti (1) | Segnala | Tag: postfix, centos, smtp, sender_canonical | OKNOtizie |  Facebook