Un brutto esempio di phishinig

La diffusione dei Ransomware ha portato molta attenzione al tema della sicurezza informatica ed in particolare verso tutti i metodi di protezione dai ransomware, trascurando l’esistenza di altre pericolose minacce.

Fra queste c’è senza dubbio in Phishing, che continua attraverso campagne mirate a sottrarre dati personali da rivendersi nel mercato nero.

Stamattina mi è capitato di osservare un messaggio di phishing correttamente classificato, ma che mi ha fatto riflettere su alcuni aspetti caratterizzanti di questo messaggio.

Vediamo come era composto:

Received-SPF: pass (google.com: best guess record for domain of root@mail.yervaguena.com designates 5.56.57.43 as permitted sender) client-ip=5.56.57.43;
To: <rimosso>
Subject: Accesso bloccato al tuo account CheBanca associato con l'indirizzo e-mail angelopenduzzu@gmail.com .
From: CheBanca! <noreply.5206@ingdirectitalia.it>
Reply-To: noreply.5206@ingdirectitalia.it
Content-Type: text/html
Message-Id: <20160531204406.3DFF513A22A@mail.yervaguena.com>
Date: Tue, 31 May 2016 22:44:06 +0200 (CEST)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<a href="http://www.chebanca.it.voKUCJ.thearborist.co.nz/.chebanca.it/?sicurezza=voKUCJ">
<img src="http://www.chebanca.it.Rzfuwt.thearborist.co.nz/images/chebancalogo205.png" height="261" width="632" border="0"></a> <text-align:center;margin-top: -19px;\"><b> </b></p></div
</html>'

Gli aspetti interessanti sono due:

L’indirizzo del mittente usa il dominio ingdirectitalia.it di proprietà di una nota banca online che opera a livello internazionale, purtroppo da una rapida analisi scopriamo che non hanno registrato un record SPF e quindi il messaggio non è stato bloccato.

dig ingdirectitalia.it TXT
; <<>> DiG 9.10.3-P4-Ubuntu <<>> ingdirectitalia.it TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41050
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ingdirectitalia.it.        IN    TX
;; AUTHORITY SECTION:
ingdirectitalia.it.    3600    IN    SOA    dns1.fastweb.it. dnsmaster.fastweb.it. 2015121001 10800 900 604800 86400
;; Query time: 1133 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Wed Jun 01 07:10:48 CEST 2016
;; MSG SIZE  rcvd: 95

L’indirizzo a cui punta il collegamento inizia con http://www.chebanca.it che ad una lettura superficiale potrebbe anche far credere che si tratti dell’indirizzo giusto, mentre invece il vero dominio è: thearborist.co.nz

Infine un’ultima considerazione, nelle intestazioni possiamo trovare che il messaggio è stato spedito da uno script php:

X-PHP-Originating-Script: 0:ch3.php

Il furto di identità è ancora una pratica molto diffusa e le campagne di Phishing quotidiane. Un incidente di sicurezza causato dalla perdita di credenziali di accesso può produrre danni economici più ingenti rispetto al BitCoin solitamente necessario per acquistare la chiave di decrittazione per un ransomware (acquisto che continuiamo a sconsigliare perchè significherebbe incrementare le disponibilità economiche e la motivazione dei gruppi che sviluppano e diffondono ransomware).

L’unico modo per risparmiare è dotarsi di un antispam efficace in grado di bloccare i messaggi più pericolosi.

Logo_Esva

LibraESVA è la soluzione Italiana ai problemi di spam e phishing, in grado di ridurre drasticamente del 99,99% la presenza di messaggi di spam nelle nostre mailbox ed ridurre quasi a zero la presenza di malware negli allegati potendo effettuare la scansione con più motori antispam.

Argonavis é partner LibraESVA e può fornirti tutte le informazioni commerciali e tecniche per implementare LibraESVA e migliorare la sicurezza della tua infrastruttura ed in particolare della posta elettronica.

Richiedi Informazioni

Zimbra, spostare le mail da una cartella

A volte può capitare di dover spostare le mail contenute in una cartella, in un’altra dello stesso account.

Questo semplice script mostra come è possibile

#!/bin/bash
# ./move.sh <utente@dominio> <cartella partenza> <cartella destinazione>
user=$1
folder1=$2
folder2=$3
list=$(zmmailbox -z -m ${user} search -t message in:/${folder1} | grep mess | awk 'BEGIN {FS=" "}{print $2}')
array=($list)
riga=0
righe=${#array[@]}
while [ $riga -lt $righe ]; do
    echo ${array[riga]}
    zmmailbox -z -m ${user} mm ${array[riga]} /${folder2}
    let riga+=1
done

Argonavis è in grado di fornire supporto tecnico e commerciale su Zimbra, se hai necessità di altre informazioni puoi mandare un messaggio.

Richiedi Informazioni

Backscattering

Il backscatter è il termine utilizzato per indicare la diffusione di messaggi di mancato recapito di un messaggio di spam originato da altri, ma utilizzando l’indirizzo email della vittiamo come mittente.

Questo genere di messaggio viene generato perché l’indirizzo email a cui lo spammer, a tentato di inviare il messaggio non esiste, o comunque il server che gestisce quel dominio non è stato in grado di consegnare il messaggio che aveva accettato in precedenza (per approfondire reject vs bounce)

Il problema fondamentale è che il protocollo SMTP impone ad un server che ha ricevuto un messaggio e che per qualsiasi ragione non è stato in grado di consegnarlo, di generare una mail di errore, per avvertire il mittente. Quindi bloccare o limitare questi messaggi sarebbe una violazione del protocollo, vale a dire che la soluzione è molto peggiore del problema.

La chiave per arrivare ad una soluzione è nel passaggio “un server che ha ricevuto un messaggio” infatti il problema si supera evitando che il nostro server riceva (reject) messaggi che non è in grado di recapitare. Il messaggio si intende ricevuto, nel momento in cui viene permessa la trasmissione della parte DATA del messaggio, di conseguenza basterebbe verificare prima di permettere la trasmissione l’esistenza dell’indirizzo per ridurre notevolmente il rischio di backscatter.

Una domanda legittima è del perché devo preoccuparmi di non inviare messaggi che sono richiesti dal protocollo.
Le motivazioni sono:

Perché è molto fastidioso per chi riceve il messaggio ritrovarsi la casella inondata di messaggi di ritorno per email che non sono mai stati inviati.
Perché è altissimo il rischio di finire in RBL e vedersi rifiutata la maggior parte della posta inviata dal server.
Perché il nostro server dovrebbe lavorare per smistare posta che non potrà consegnare e di conseguenza utilizzerà risorse e banda per messaggi inutili.

Zimbra permette di difendersi dal backscatter, il controllo dei recipient si attiva con i seguenti comandi

su zimbra
zmlocalconfig -e postfix_smtpd_reject_unlisted_recipient=yes
zmmtactl upgrade-configuration

Argonavis è in grado di fornire supporto tecnico e commerciale su Zimbra, se hai necessità di altre informazioni puoi mandare un messaggio.

Richiedi Informazioni

Sender Policy Framework

Sender Policy Framework (SPF), è una tecnica utilizzata per limitare gli abusi nell’invio di messaggi di posta elettronica. Al contrario di altre tecniche che servono a limitare lo spam ricevuto dal dominio, SPF evita che qualcuno possa inviare messaggi utilizzando il nostro dominio come mittente.

La tecnica, codificata nel RFC 4408, consiste nel dichiarare quali sono i server autorizzati a spedire posta per il nostro dominio, ne consegue che un messaggio inviato da qualsiasi altro server a nostro nome si configura come un abuso e di conseguenza il messaggio verrà rifiutato (per appronfondire puoi leggere reject vs bounce) dal destinatario.

Le informazioni sui server autorizzati vengono pubblicate su un record TXT della configurazione del dominio.

Il record viene composto in questa maniera:

"v=spf1 <qualificatore1><meccanismo1> <qualificatore#><meccanismo#>"

I meccanismi possibili sono:

all  ip4 | ip6 | a | mx | ptr | exists | include

ciascun meccanismo può essere preceduto da un qualificatore

"+" | "-" | "~" | "?"

Vediamo alcuni esempi:

E’ valida esclusivamente la posta inviata dalla rete identificata dal record A

"v=spf1 a/24 a:offsite.example.com/24 -all"

E’ valida esclusivamente la posta inviata dall’indirizzo identificato dal record MX

"v=spf1 mx/24 mx:offsite.domain.com/24 -all"

E’ valida esclusivamente la posta inviata dalla rete 192.168.0.1/16

"v=spf1 ip4:192.168.0.1/16 -all"

Argonavis è in grado di fornire supporto tecnico per configurare correttamente il vostro server di posta, se hai necessità di altre informazioni puoi mandare un messaggio.

Richiedi Informazioni

Reject vs Bounce

Capita che alcuni messaggi ricevuti dal nostro server di posta, non possano essere effettivamente consegnati, ad esempio il destinatario del messaggio non esiste nel nostro dominio.

In questo caso il protocollo SMTP prevede due possibilità: il reject (rifiuto) o il rimbalzo (bounce).

La differenza fra queste due tecniche è abbastanza fine, ma sostanziale.

Nel caso di reject del messaggio il server di posta verifica le intestazioni che gli sono state fornite, e se riscontra degli errori, non accetta il comando DATA, per cui la trasmissione del messaggio viene interrotta prima che il messaggio venga ricevuto.

Nel caso di bounce, invece, il server di posta accetta il messaggio completamente, per analizzarlo successivamente, in questo caso se il server considererà di non poterlo consegnare, deve generare un messaggio da recapitare al mittente per informarlo delle ragioni per cui non è stato possibile consegnare la mail.

Le differenze fra queste due strategie si possono sintetizzare in questa maniera:

Reject è meno rapido nella ricezione del messaggio, in sistemi poco performanti rischia di mandare in timeout la sessione SMTP, ma riduce il traffico generato ed evita il rischio di backscattering
Bounce è più rapido nella chiusura della sessione SMTP, ma accetta ogni volta l’intero messaggio, anche se non verrà mai consegnato ed è alto il rischio di essere considerato server di backscattering.

Esiste una ulteriore possibilità, detta Silently dropping, tipicamente utilizzata nelle quarantene, il messaggio viene completamente accettato, non viene consegnato (a seguito del verdetto di un insieme di regole) ma non viene generato il messaggio di mancato delivery. L’utente è ancora in grado di sbloccare manualmente la consegna del messaggio.

Argonavis è in grado di fornire supporto tecnico per ottimizzare la tua configurazione, se hai necessità di altre informazioni puoi mandare un messaggio.

Richiedi Informazioni

Categorie