Lezioni sulla lettura degli header

Falsificazioni da riconoscere



Lo spammer può falsificare gli header 'Received:'?
L'indicazione della provenienza negli header 'Received:' esiste sempre? Potrebbe essere falsa ?
Un esempio interessante
Quando troviamo l'indirizzo IP, possiamo contare che sia giusto o potrebbe essere falsificato pure quello?
Può succedere che lo spammer, usando un proxy, riesca ad apparire su un ip diverso da quello a cui si trova?

Lo spammer può falsificare gli header 'Received:' ?

Sì, ma eventuali header falsificati possono solo essere gli ultimi della catena. Lo spammer non può impedire che i computer successivi al suo nel trasportare il messaggio mettano i propri received. Quindi fino ad un certo punto la catena sarà corretta e attendibile, da quel certo punto potremo, in qualche caso, avere degli header falsificati, ossia costruiti in modo da assomigliare a header veri e messi lì per confondere le idee. Generalmente il punto in questione si può individuare: c'è sempre qualcosa che non torna se si esamina il tutto con attenzione.


L'indicazione della provenienza negli header 'Received:' esiste sempre ?

Teoricamente un server potrebbe anche non dichiarare chi è stato a passargli il messaggio. Quando questo avviene, siamo in presenza o di un anonymous remailer o di un server gestito da personale non competente. Esclusi quei pochi sistemi che deliberatamente operano in questo modo (e che comunque generalmente adottano soluzioni per evitare di lasciarsi abusare dagli spammer), la probabilità che organizzazioni serie abbiano un server configurato male che faccia da remailer anonimo è praticamente nulla, visti i rischi niente affatto da ridere che correrebbero (pensate se qualcuno utilizzasse un server anonimo per perpetrare reati gravi, che so, mandare minacce di morte a qualcuno o cose del genere). Vedremo, in uno dei successivi casi pratici, una organizzazione certo non criminosa che, o per scarsa informazione o per negligenza o semplicemente per qualche errore commesso nel configurare il software, è incorsa proprio in questo problema. In effetti vecchie versioni di Sendmail (in particolare la 8.6) mettevano per default dei Received privi della dovuta informazione e, quando un server venga migrato a nuove versioni tenendo i vecchi file di configurazione, l'inconveniente può verificarsi anche in versioni recenti; per esempio, un Received come il seguente:

Received: from tyuyq by xx.xxxx.ac.za; (8.9.3/1.1.8.2/03Nov94-1202PM)
    id MAA22307; Sat, 12 Jun 1999 12:47:39 +0200 (GMT+0200)

indica un sendmail 8.9.3 (che per default dovrebbe produrre dei Received corretti) che, però, usa ancora il file di configurazione (sendmail.cf) versione 1.1.8.2, creato nel novembre 94. Come si vede, viene riportata solo la non significativa stringa 'tyuyq' che lo spammer ha inserito nel comando HELO.

Il fatto che, tramite l'HELO, lo spammer abbia modo di inserire una stringa arbitraria entro il Received, rende possibili certi offuscamenti di cui vedremo tra un attimo un esempio. A volte lo spammer passa come HELO un semplice indirizzo IP che non c'entra nulla. Altre volte, approfittando di buchi nei software dei mail server utilizzati, una stringa talmente lunga da impedire l'apparizione delle parti significative dei Received in questione (di fatto rendendo anonimo un server che, usato normalmente, non lo sarebbe).


Un esempio interessante

Tempo fa mi è stato segnalato un caso di falsificazione che val la pena di vedere. Più che di falsificazione, comunque, si potrebbe parlare di trucco per intorbidare le acque.
Vediamo:

From: ajhejmuaje@126.com
Received: from servidor2.bauer.es ([195.61.24.2])
 by smv198-mc.mail.com (8.9.3/8.9.1SMV070400) with SMTP id WAA21539;
 Wed, 21 Mar 2001 22:22:33 -0500 (EST)
Received: from myrop (ew6.southwind.net [216.53.98.70]) by
onyx.southwind.netfrom homepage.com (114.230.197.216) by
newmail.spectraweb.ch from default (m202.2-25.warwick.net [218.242.202.80])
byhost.warwick.net (8.10.0.Beta10/8.10.0.Beta10) with SMTP id e9GKEKk19201
([63.44.155.8]) by servidor2.bauer.es (Lotus SMTP MTA v4.6.1  (569.2
2-6-1998)) with SMTP id C1256A17.00129C3A; Sun, 22 Mar 1970 04:23:31 +0100
Message-ID: <0000749b6e86$00001ced$00007697@mcpeely.concentric.net
(mcfeely.concentric.net [217.15.198.83])by darius.concentric.net
(8.9.1a/(98/12/15 5.12)) id PAA04003from default (m202.2-25.warwick.net
[218.242.202.80]) byhost.warwick.net (8.10.0.Beta10/8.10.0.Beta10) with SMTP
id e0GKEKk19201>
Subject: Viagra Alternative & FREE Herbs!
Date: Wed, 21 Mar 2001 14:15:27 -0800
X-Priority: 1
X-MSMail-Priority: High

Questo spam era arrivato a un indirizzo creato su mail.com (noto servizio di forwarding). Il server di mail.com ha ricevuto il messaggio da un server spagnolo, come specificato nel primo header:

Received: from servidor2.bauer.es ([195.61.24.2])
 by smv198-mc.mail.com (8.9.3/8.9.1SMV070400) with SMTP id WAA21539;
 Wed, 21 Mar 2001 22:22:33 -0500 (EST)

Questo primo header è sicuramente corretto, essendo stato inserito dal servizio direttamente usato dall'utente che aveva ricevuto lo spam. Il server spagnolo è il primo sconosciuto che troviamo nella catena, e ci aspettiamo quindi che il successivo Received sia opera sua. Come successivo Received troviamo questo mostruoso guazzabuglio:

Received: from myrop (ew6.southwind.net [216.53.98.70]) by
onyx.southwind.netfrom homepage.com (114.230.197.216) by
newmail.spectraweb.ch from default (m202.2-25.warwick.net [218.242.202.80])
byhost.warwick.net (8.10.0.Beta10/8.10.0.Beta10) with SMTP id e9GKEKk19201
([63.44.155.8]) by servidor2.bauer.es (Lotus SMTP MTA v4.6.1  (569.2
2-6-1998)) with SMTP id C1256A17.00129C3A; Sun, 22 Mar 1970 04:23:31 +0100

Non abbiamo ancora parlato del problema dei relay aperti (che verrà trattato in più d'una delle successive pagine) e non è il caso che anticipiamo il discorso. Per ora diciamo solo che il server spagnolo ha (o almeno aveva, al momento dello spam) un problema di sicurezza, per causa del quale veniva utilizzato dagli spammer. Inoltre il server spagnolo, essendo nelle condizioni di creare a tutta la rete dei problemi di spam, era censito in varie "liste nere" pubblicamente accessibili. Tali liste nere riportavano, sui rispettivi siti, esempi di messaggi di test veicolati da tale server, completi di header. A questo punto si delinea già il modo per venire a capo di quel guazzabuglio: procurarsi un Received costruito dal server spagnolo in condizioni normali e vedere se le cose combinano. Questa possibilità, ossia procurarsi un normale Received del medesimo server (mediante test oppure trovandolo già pubblicato presso siti delle liste di blocco), è estremamente utile in tutti i casi in cui si dubiti, per esempio per via della struttura insolita di un Received, di come si possa effettivamente interpretare l'header.

Nel caso in esame, andando sul sito di una lista nera (anche delle liste nere parleremo più avanti) si trovava quindi l'esempio di header Received che riportiamo qui di seguito. Si tratta del Received preso da un messaggio di test risalente circa a quegli stessi giorni:

Received: from tester42.orbs.org ([62.250.3.55]) by servidor2.bauer.es
 (Lotus SMTP MTA v4.6.1  (569.2 2-6-1998)) with SMTP id C12569F1.006131A4;
 Thu, 12 Feb 1970 18:41:37 +0100

Se si confronta con il precedente header, si nota che la struttura è la stessa. A parte l'SMTP id (che è, e deve essere, di volta in volta sempre diverso) combina tutto, perfino la data sballata (pur essendo lo spam del marzo 2001, il server spagnolo aveva una data di sistema nel 1970). In pratica, è ora chiaro che lo spammer ha fatto in modo che il server spagnolo ricevesse una stringa di HELO fatta così:

 myrop (ew6.southwind.net [216.53.98.70]) by
 onyx.southwind.netfrom homepage.com (114.230.197.216) by
 newmail.spectraweb.ch from default (m202.2-25.warwick.net [218.242.202.80])
 byhost.warwick.net (8.10.0.Beta10/8.10.0.Beta10) with SMTP id e9GKEKk19201

Quindi, rivedendo l'intero header evidenziato in tutte le parti all'infuori della stringa di Helo:

Received: from myrop (ew6.southwind.net [216.53.98.70]) by
onyx.southwind.netfrom homepage.com (114.230.197.216) by
newmail.spectraweb.ch from default (m202.2-25.warwick.net [218.242.202.80])
byhost.warwick.net (8.10.0.Beta10/8.10.0.Beta10) with SMTP id e9GKEKk19201
([63.44.155.8]) by servidor2.bauer.es (Lotus SMTP MTA v4.6.1  (569.2
2-6-1998)) with SMTP id C1256A17.00129C3A; Sun, 22 Mar 1970 04:23:31 +0100

ci appare che, nonostante la cortina fumogena sollevata, lo spammer non ha potuto nascondere di essere all'indirizzo 63.44.155.8


Quando troviamo l'indirizzo IP, possiamo contare che sia giusto o potrebbe essere falsificato pure quello?

Quanto al fatto che l'indirizzo IP riportato esplicitamente da un mailserver entro l'header 'Received:' possa essere errato, la risposta è NO. Gli spammer più organizzati possono tuttavia farci trovare una particolare situazione alla quale dedichiamo il successivo approfondimento. Al fine di limitarci a quel che ci occorre vedere, terremo la trattazione il più banale possibile. Per chi volesse andare più a fondo sarà certamente utile partire dalla RFC793. Per chi, al contrario, preferisse accontentarsi di una risposta veloce (che, in fondo, è l'unica di cui fare uso in pratica), va bene saltare il seguente approfondimento e considerare semplicemente che, se interpretando correttamente un Received si individua un indirizzo IP, quell'indirizzo era comunque sicuramente usato dallo spammer.


Approfondimento

IP spoofing e spam

Per come funziona il protocollo IP, ogni host che trasmette dati in rete indica in ogni pacchetto, oltre all'indirizzo IP dell'host che intende raggiungere, anche il proprio. In teoria è quindi assolutamente possibile che, programmando opportunamente i moduli TCP/IP del proprio software (moduli che generalmente sono inclusi nel sistema operativo), si possano spedire pacchetti con indirizzi o inesistenti o appartenenti ad altri computer che non c'entrano nulla. Questa pratica è detta IP spoofing e viene sovente utilizzata in rete (per lo più da parte di ragazzotti dispettosi) per attacchi di tipo denial of service. Il problema per chi volesse utilizzare l'IP spoofing al fine di mandare email anonime è che, come si è visto, qualsiasi transazione SMTP richiede interazione tra i due computer coinvolti, interazione che deve avvenire nell'ambito di una connessione TCP ininterrotta. In altre parole, il computer che spedisce la mail deve essere in condizioni di ricevere i messaggi del server a cui si è connesso e, a fronte di ogni messaggio ricevuto, inviare il successivo comando che il protocollo prevede a quel punto. Se ci si è presentati al server con un indirizzo falso, le risposte del server non potranno essere ricevute, in quanto andranno a finire o ad un computer realmente esistente chissà dove ma che non se le aspetta (e che le scarterà), o ad un indirizzo inesistente (andando così ad arricchire il cosidetto "rumore di fondo" della rete globale).

Può quindi sembrare che, per chi tenta l'invio di email con indirizzo mittente spoofato, la situazione sia semplicemente analoga a quella di chi lavorasse su un computer a video spento: è difficile ma si può pensare di riuscire almeno a fare qualche semplice operazione. C'è però di più: il fatto di mantenere una sessione TCP ininterrotta richiede che tutti i segmenti TCP scambiati tra i due computer contengano ciascuno un numero di sequenza. Ognuno dei due computer invia all'altro degli ACK, ossia include nei propri segmenti il numero di sequenza che si aspetta di trovare nel prossimo segmento che riceverà dall'altro host. Se quindi uno dei due computer non è in grado di ricevere gli ACK dall'altro, non potrà neanche sapere qual è il numero di sequenza da usare nel prossimo segmento, e quindi non sarà in grado di mantenere la connessione valida.

Esiste la RFC1948, in cui si parla di attacchi basati sul fatto che, in certe implementazioni del TCP/IP, i numeri di sequenza successivamente richiesti alla controparte in sessione sono predicibili. Oggi tale evenienza è piuttosto rara, in quanto la facile predicibilità dei numeri di sequenza è considerata un serio problema di security e viene quindi velocemente corretta, nei software che ne risultano affetti, non appena il produttore ne viene a conoscenza. Possiamo quindi escludere di trovare spam con IP spoofato? A stretto rigore di termini lo potremmo escludere. Vediamo però cosa può succedere.

Nell'estate 2001 è stato segnalato che certi spammer dispongono di hardware e software speciali per avvalersi di tecniche di spoofing. Per sintetizzare al massimo, diciamo che lo spammer utilizza un computer con due distinte interfaccie di rete (per esempio, una scheda di rete e un modem). Questo gli consente di avere, sul medesimo computer, due indirizzi IP forniti da due provider diversi: chiamiamoli IP-1 e IP-2. Tramite IP-1, il software dello spammer entra in contatto con i server di mail che ha prescelto per veicolare la propria spazzatura, e in ciascun pacchetto che invia a tali server mette l'altro indirizzo, IP-2, come indirizzo mittente. Pertanto ogni risposta del server di mail viene diretta a IP-2 e quindi, pur seguendo tutt'un'altra strada attraverso la rete, finisce col giungere allo stesso computer di partenza. Il software dello spammer resta quindi in grado di accedere ai numeri di sequenza e quant'altro necessario per proseguire correttamente la sessione tramite IP-1. Il server di mail, dunque, vede soltanto IP-2, ed è quindi IP-2 che comparirà nei Received.

Se dunque in ogni caso un indirizzo IP usato dallo spammer resta individuabile e può pertanto essere segnalato all'abuse desk competente, qual è il vantaggio per lo spammer nell'usare questa tecnica? Semplicemente che IP-1, l'indirizzo che resta nascosto, usualmente corrisponde ad una connessione costosa e ad alta capacità, una connessione che consente l'invio veloce di mailing di dimensioni enormi e che sarebbe veramente seccante, per lo spammer, vedersi chiudere. Al contrario, IP-2 può essere una semplice connessione dial-up, poco costosa e che lo spammer può velocemente rimpiazzare non appena gli venisse chiusa. Un vantaggio quindi non eclatante ma che può essere in certi casi anche molto significativo per lo spammer.

Cosa possiamo fare noi di fronte a questa situazione? Per la verità non molto: possiamo giusto far saltare allo spammer la connessione su IP-2. Che esista anche l'altra connessione potremmo difficilmente venirlo a sapere, dato che dagli header effettivamente non risulta. Contro questa tecnica possono essere efficaci solamente opere di prevenzione, che prima o poi dovranno diventare pratica comune in tutta la rete. Dell'opera di prevenzione necessaria si è già occupata la RFC2827 del maggio 2000, intitolata "Network Ingress Filtering". In sostanza, il provider che fornisce connettività ad una rete o ad un utente deve applicare un filtraggio a livello IP sui pacchetti provenienti da quella rete o da quell'utente, in modo da bloccare qualsiasi pacchetto non abbia, come indirizzo mittente, uno di quelli assegnati all'utente in questione. In particolare, si parla anche di filtraggio automatico sui remote access server delle reti dial-up, e si auspica che sempre più reti adottino queste raccomandazioni. In effetti è certo che, se tutte le reti fossero filtrate, ci sarebbero molti problemi in meno per tutti, e non solo di spam.

Può succedere che lo spammer, usando un proxy, riesca ad apparire su un ip diverso da quello a cui si trova?

Può succedere ed è una pratica che, fin dal 2001, ha iniziato a diventare sempre più comune. Probabilmente ciò si deve all'arrivo di apposito software per spammer in grado di aprire sessioni SMTP attraverso proxy insicuri. Molti utenti della rete certamente hanno già sentito parlare di proxy: si tratta di un servizio che tutti o quasi i provider offrono ai propri clienti e che può essere usato, per esempio, per navigare il web senza presentare ai siti visitati il proprio vero indirizzo ip. In pratica, il proxy viene interposto e il sito visitato vede l'ip del proxy, senza poter conoscere dove sia realmente l'utente. Durante la navigazione, il proxy riceve le richieste dal browser dell'utente, le passa al server web su cui c'è il sito da visitare e, avuta la risposta, la passa indietro al browser che la aveva richiesta.

Quel che probabilmente è meno noto è che ci sono proxy di molti tipi. Se il normale utente di solito usa un proxy http per la navigazione web, in realtà ci sono proxy che possono svolgere questa funzione di intermediario per qualsiasi protocollo che viaggi su TCP. Naturalmente i proxy sono stati pensati per utilizzi legittimi e, se tutto va bene, grazie ad essi si conseguono dei vantaggi in molte situazioni. Dal punto di vista dalla sicurezza c'è però una esigenza ben precisa: ogni proxy deve svolgere il proprio servizio solo ed esclusivamente per gli utenti che siano autorizzati ad usarlo. Come poi il proxy debba decidere se un utilizzo è autorizzato o no, la cosa può variare: può deciderlo, per esempio, in base all'appartenenza dell'ip ad un certo blocco, oppure in base ad una autenticazione. Quando invece un proxy accetta di servire le richieste senza svolgere controlli o svolgendoli in maniera inadeguata, si parla di "open proxy", ovvero di proxy insicuro.

Un proxy insicuro ha elevata probabilità di diventare uno strumento con cui si commettono abusi. Per esempio, molti newsgroup usenet sono stati spesso e a lungo soggetti a flooding che venivano immessi utilizzando un gran numero di proxy insicuri sparsi per il mondo. Fermare tali abusi risulta spesso complicato, anche se l'aggressore non può avere alcuna certezza di essere imprendibile (normalmente i proxy, anche se insicuri, producono dei log).

Quando si parla di proxy insicuri usati dagli spammer, in genere ci si riferisce a diversi tipi di proxy (anche se fondamentalmente fanno tutti la stessa cosa). Esistono, e sono usati dagli spammer, i proxy SOCKS, che per default ascoltano sulla porta TCP/1080 e funzionano secondo l'omonimo protocollo (di cui alla RFC1928). Esistono poi vari tipi di proxy http (che tipicamente ascoltano su porte TCP come la 3128, 80 o 8080). Spesso i proxy http supportano un comando CONNECT (vedasi la RFC2817), col quale si può dirigere una sessione generica su un altro computer, potendo specificare su quale porta. Il comando CONNECT è appunto uno di quelli preferiti dagli spammer, che ovviamente scelgono come destinazione la porta 25 di un mailserver.

Possiamo a questo punto osservare che gli spammer fanno anche uso di veri e propri "cavalli di Troia" per diffondere il loro traffico. Un cavallo di Troia è, come noto, un programma malizioso che viene eseguito all'insaputa del legittimo utilizzatore del computer su cui, di solito con l'inganno, è stato impiantato. I trojan, nella maggior parte dei casi, prevedono di essere controllati remotamente, attraverso la rete, da qualcuno che per loro tramite può guadagnare il completo controllo del computer vittima. Ecco allora che, nel 2003, si è iniziato a sentir parlare di trojan appositi per spammer, che gli spammer cercano di impiantare sulle macchine di utenti ignari. Questi trojan, una volta in funzione, contattano via email lo spammer per informarlo dell'indirizzo ip su cui sono attivi. A questo punto lo spammer si connette al trojan e lo utilizza come se fosse, ai fini pratici, un server di posta elettronica. Il risultato è che l'utente infettato, all'oscuro di quel che gli sta succedendo, diventa suo malgrado un punto di origine di spam, nascondendo il vero indirizzo dello spammer (chi indaga sullo spam esaminando gli header, può giungere solo all'indirizzo dell'utente infettato). Dubitiamo che questo tipo di attacco sia possibile da parte dello spammer senza incorrere in reati da codice penale, tuttavia non troviamo che ci sia da stupirsi: gli spammer sono personaggi che, molto spesso, hanno un profilo criminale. Possiamo solo raccomandare a chiunque di essere sempre il più possibile prudente nell'uso del proprio computer: non si mandino in esecuzione programmi della cui affidabilità non si possa essere del tutto certi, e si faccia uso di un antivirus aggiornato.

A questo punto, che significa questa cosa dei proxy (e dei trojan) per chi investiga sullo spam?

Significa che, esaminando gli header come visto nelle pagine precedenti, può succedere che riusciamo a individuare solo una parte del percorso del messaggio di spam, quella avvenuta come posta elettronica vera e propria, attraverso transazioni SMTP. Se, al punto di immissione trovato, esiste un proxy aperto, le possibilità di scoprire il vero ip a cui si trovava lo spammer sono assai scarse. Sono del tutto nulle se si trattava di un trojan.

Il problema viene combattuto dagli antispammer mediante l'uso di blacklist apposite per i proxy insicuri, oltre che cercando di segnalare la presenza dei proxy aperti agli amministratori della rete in questione, affinché intervengano per farli sistemare. In alcuni casi, è stato possibile ottenere i log dei proxy abusati, risalendo quindi alla connessione originaria dello spammer. Ovviamente per molti di questi proxy non esisterà un amministratore in grado di fornire i log, ma per molti sì (e lo spammer che si accinge ad usare un proxy insicuro può solo essere insicuro pure lui su quel che gli succederà).

Un altro strumento di cui gli antispammer si avvalgono per combattere lo spam da proxy è l'adozione di appositi honeypot, ossia di macchine su cui gira un software che si comporta in apparenza come se fosse un proxy insicuro. Tenere in esercizio un sistema del genere, spesso detto "proxypot", è cosa non alla portata di tutti: richiede un connessione permanente, ottima competenza tecnica, attitudini da smanettone software, scaltrezza e molto tempo libero, tuttavia risulta anche essere molto divertente e consente di osservare da vicino molti aspetti interessanti, che non si potrebbero scoprire in altro modo, di come lo spam viene distribuito. Normalmente il gestore del proxypot intercetta i test, con cui gli spammer cercano di verificare se a quell'indirizzo sta un proxy che si riesca a utilizzare, e fanno in modo che i test riescano, che quindi i messaggi di prova vengano effettivamente recapitati allo spammer. A quel punto lo spammer, caduto nella trappola, inizia a usare il proxy per consistenti invii di spam e, ovviamente, il proxypot finge di accettare il tutto regolarmente, questa volta però senza inoltrarlo. Spariscono così nel nulla molti "spam run" (così vengono di solito chiamati i cicli di invio effettuati da uno spammer), che lo spammer crede siano andati regolarmente a segno. Ovviamente il gestore del proxypot vede il vero indirizzo ip da cui lo spammer opera e provvede a segnalarlo al provider del caso.

Quindi per noi le cose non cambiano molto: all'ip in cui si constata che lo spam è stato originato, c'è comunque un problema, di cui il provider responsabile deve occuparsi. Il problema può essere direttamente lo spammer, oppure un problema di sicurezza dovuto a un proxy mal configurato oppure a un trojan. In caso di proxy o trojan, lo spammer potrebbe riuscire a tenere nascosta la sua connessione originaria.

Avremo comunque modo di vedere, nelle successive pagine, che si può colpire lo spammer non solo sulla connessione che ha usato per inviare lo spam, ma anche su altre risorse per lui ben più fastidiose da perdere.


Indice    << Precedente    Successiva >>

Ultimo aggiornamento: 28 luglio 2003

Leonardo Collinelli

e-mail