No more maintained.
Now just a test in a lab.
Mail Security
Problematiche di sicurezza relative alla posta e ai server di posta più comuni.
Il Buco di Sendmail
Tipo Infobox: ARTICLES - Skill: 1- NOVICE
La notizia fa già discutere e non potrebbe essere altrimenti.
Nasce il 3 Marzo da ISS che annuncia la scoperta di una seria nuova vulnerabilità di Sendmail, uno dei server SMTP più usati in rete. Rimbalza nelle headlines dei primi security alert, si annuncia ampiamente sul sito di Sendmail Inc, compare nel CERT advisory 2003-7 e approda, con qualche ora di ritardo su Slashdot. Mentre s'infiammano in rete discussioni e disquisizioni, considerazioni e consigli, ironie e preoccupazioni, inizia un nuovo round della sfumata lotta fra hackers e sysadmins. I primi a ingeniarsi nel trovare il modo di sfruttare la vulnerabilità annunciata, alcuni dei secondi in affannosa ricerca delle patch con in mente orrorifiche visioni di mass mailing e worming.
Sendmail è uno dei simboli dell'OpenSource e di Internet stessa. Ha consegnato messaggi fin dagli arbori della rete, scambiando email e file fra server Unix in tempi innocenti, quando non ci si preoccupava molto della sicurezza dei sistemi e dei protocolli. E' cresciuto di versione in versione e si è portato dietro una logica complessa, estremamente flessibile ma a suo modo contorta, che ha richiesto ripetute correzioni e pezze per rincorrere le sempre più variegate vulnerabilità che gli venivano trovate.
Negli ultimi tempi il suo sviluppo si era consolidato, da almeno un paio d'anni non venivano scoperti bug pericolosi e, nonostante la crescente concorrenza di altri mailer OpenSource come Postfix e Qmail, nati dopo e intrinsecamente più sicuri, è stato per molti una scelta stabile e affidabile.
Il buco reso noto il 3 Marzo, ma scoperto da settimane e comunicato il 31 Gennaio a Sendmail Inc. dal team X Force di ISS per permettere di preparare un'adeguata patch al momento dell'annuncio pubblico, sfrutta una falla presente nel codice di tutte le versioni di Sendmail, fino alla 8.12.8, rilasciata con la correzione del problema.
Uno dei meccanismi di controllo degli indirizzi di posta elettronica presenti negli header di un messaggio (tipicamente to: from: cc: e bcc:) gestisce in modo non corretto una variabile e questo può essere sfruttato per dare luogo ad un buffer overflow, che può essere utilizzato per eseguire comandi arbitrari sul sistema con i privilegi con cui gira Sendmail, solitamente root.
Ufficialmente non esiste ancora un exploit diffuso in rete in grado di sfruttare questa vulnerabilità, ma ISS ne ha dimostrato l'applicabilità su sistemi in produzione e il fatto di poter essere attivato tramite gli header di un qualunque messaggio di posta ne amplia in modo smisurato la pericolosità.
Gli scenari che si aprono nelle menti dei cracker più crudeli (un vero hacker non metterebbe mai in circolazione un simile exploit) e dei tecnici più consapevoli sono inquietanti e variegati. Orde di spam-mail maligne, che portano nei loro header un payload virulento, in grado di compromettere server non patchati e, eventualmente, duplicarsi e diffondersi, come un feroce worm sterminatore di Sendmail non aggiornati.
I virus writer staranno già pensando ad una nuova generazione di virus, la cui definizione sfuma in quella di worm, che non infetta i client Windows degli utenti finali ma i server Unix che ne gestiscono tutti i messaggi, si diffondono via mail, ma, a differenza di normali virus, lo fanno automaticamente, senza nemmeno l'ignaro intervendo umano, possono corrompere sia server di posta pubblici che server interni, nel cuore delle reti aziendali, attraversando firewall per la lecita porta 25 e consegnando a destinazione mail dagli effetti arbitrari, secondo l'arbitrio di chi le ha mandate.
La prospettiva non è nuova, anche una recente vulnerabilità di Fetchmail, un programma opensource molto utilizzato su Linux, e altri Unix, per scaricare e processare posta da un server remoto, permette di ottenere privilegi di root tramite un buffer overflow che può essere potenzialmente sfruttato con una normale email.
Il fatto di non aver ancora visto in circolazioni un worm o un virus che possano sfruttare questi buchi e eventualmente trovare un meccanismo per auto diffondersi dipende dalla intrinseca difficoltà di un simile attacco, soprattutto se si cerca di renderlo efficace su ignoti e generici sistemi. Ma questo non deve far stare tranquilli gli amministratori di sistema pigri o troppo occupati: il recente worm SQL Slammer ha messo in ginocchio Internet sfruttando un buco di sicurezza reso pubblico, con relative patch, più di sette mesi fa ed è presumibile che molti, con diversi scopi e diverse mentalità, si impegneranno per realizzare un exploit praticamente utilizzabile.
Simili prospettive inevitabilmente riscalderanno le prese di posizione sull'approccio alla sicurezza del software aperto rispetto a quello proprietario, scateneranno scherno e polemica fra fanatici di Linux e dell'OpenSource e militanti di Windows e avranno eco variabile su siti tecnici e d'informazione in rete.
Tecnicamente questa è un'altra vulnerabilità grave di un software molto diffuso su server Internet, permette un root compromise da remoto, praticamente il peggio che possa accadere ad un sistema Unix, non è ancora diffuso un exploit che possa sfruttarla ma potrebbe esserlo in futuro, con conseguenze e possibilità di diffusione potenzialmente notevoli; si risolve semplicemente aggiornando il proprio Sendmail, pratica che non è certo immediata se si devono ricompilare i sorgenti, ma diventa estremamente semplice o addirittura automatica, se il vendor del proprio Linux o Unix ha provveduto a rilasciarne i pacchetti aggiornati.
Chi ha una macchina con RedHat Linux 8.0, per esempio, ha potuto aggiornare Sendmail, praticamente senza interrompere il servizio, prima ancora di vederne la notizia in rete.
Chi utilizza una versione commerciale di Sendmail, ha potuto scaricare immediatamente comode patch dal sito di Sendmail Inc, mentre su Sendmail.org venivano pubblicati i nuovi sorgenti della versione 8.12.8. Gradualmente tutte le distribuzioni Linux e i produttori Unix stanno rilasciando i propri aggiornamenti: il problema è potenzialmente troppo serio per poter essere sottovalutato.
I tempi di risposta, anche grazie alla oculata policy di disclosure adottata da ISS che ha permesso il rilascio della patch contemporaneamente all'annuncio pubblico della vulnerabilità, sulla disponibilità degli aggiornamenti da parte di molti vendor sono stati inequivocabilmente rapidi. A dimostrazione che il supporto commerciale per prodotti OpenSource esiste, è efficace e giustifica il suo costo, che spesso è al di sotto delle medie di mercato.
I pregi e le insidie dell'OpenSource, in termini di sicurezza, si sono rilevati in tutte le loro contraddizioni. ISS ha fatto un profondo code auditing sui sorgenti di Sendmail per individuare questa falla, il codice di Sendmail stesso ne uscirà rafforzato e più sicuro, dopo l'ennesima profonda revisione che ha subito, gli amministratori di sistemi vulnerabili hanno il tempo di aggiornare le loro macchine ma molti server resteranno scoperti, dimenticati, potenzialmente vulnerabili e insicuri. Se qualcuno, con diverso spirito e intenzioni fosse riuscito a scoprire per primo questo buco, avrebbe avuto la possibilità di penetrare un grandissimo numero di server e, se fosse riuscito a farne un worm avrebbe, ancora una volta, potuto mettere in ginocchio la rete, almeno per qualche ora.
Questa intrinseca vulnerabilità di Internet e dei suoi server, in realtà, prescinde dalla policy di rilascio del codice e investe l'apparentemente irrisolvibile problema di praticamente ogni software usato in rete: prima o poi qualcuno, con metodi ingeniosi e approcci innovativi, riuscirà a trovarne una nuova falla e questo richiederà l'inevitabile pezza.
Nella corsa senza fine alla sicurezza informatica chi si aggiorna per primo vince.
Modifica del banner di Sendmail
Tipo Infobox: TIPS - Skill: 4- ADVANCED
Mascherare il welcome banner di Sendmail (220 GIOVE ESMTP Sendmail 8.12.5/8.12.5; Fri, 10 Jan 2003 10:53:52 +0100) come di ogni servizio di rete, nascondendone la versione e altre informazioni potenzialmente sfruttabili NON è, in se, una buona misura di sicurezza, ma può risultare un tampone comodo per eludere scan di larga scala in cerca di porte aperte e relativi servizi gestiti da versioni di software vulnerabili ad attacchi noti.
[root@GIOVE root]# telnet GIOVE 25
Trying 127.0.0.1...
Connected to GIOVE.
Escape character is '^]'.
220 GIOVE ESMTP Sendmail 8.12.5/8.12.5; Fri, 10 Jan 2003 10:53:52 +0100
Si può configurare Sendmail per modificare il testo visualizzato nel banner:
- nel file di configurazione (sendmail.cf), il parametro da modificare è, dalla versione 8.7, SmtpGreetingMessage:
#Impostazione di default
# SMTP initial login message (old $e macro)
O SmtpGreetingMessage=$j Sendmail $v/$Z; $b/
#Impostazione modificata
# SMTP initial login message (old $e macro)
O SmtpGreetingMessage=$j GIOVE $b/
- sul file m4 da preprocessare (sendmail.mc) si usa la definizione: define(`confSMTP_LOGIN_MSG',message) dove message è il testo, con variabili, customizzabile. Nel nostro caso: define(`confSMTP_LOGIN_MSG',$j GIOVE $b/)
Al riavvio di Sendmail (killall -HUP sendmail) ecco il nuovo messaggio:
[root@GIOVE root]# telnet GIOVE 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 GIOVE ESMTP GIOVE Fri, 10 Jan 2003 10:54:41 +0100
Disabilitare l'uso di VRFY e EXPN su Sendmail
Tipo Infobox: TIPS - Skill: 4- ADVANCED
Sendmail permette attraverso il comando VRFY la verifica di indirizzi email residenti sul server di posta.
Dal momento che viene spesso usato per scopi di intrusione e spam, è opportuno disabilitare questa funzione per prevenire attacchi del genere. Un'altro utile comando, che può essere usato per scopi ostili, è EXPN, con cui si visualizzano tutti gli indirizzi email membri di una lista.
In molte configurazioni predefinite di Sendmail recenti, l'uso di questi comandi è già disabilitato di default.
Il comando VRFY permette di verificare se esiste l'utente specificato:
[root@sole /]# telnet sole 25
Trying 192.168.100.64...
Connected to sole.
Escape character is '^]'.
220 sole ESMTP SMTP SOLE; Fri, 10 Jan 2003 12:34:21 +0100 (CET)
vrfy atomo
250 2.1.5 <atomo@sole>
Il comando EXPN mostra tutti i membri della lista indicata:
...
vrfy staff
250 2.1.5 <atomo@sole>
250 2.1.5 <molecola@sole>
250 2.1.5 <protone@sole>
Per disabilitare il comando VRFY e EXPN modificare l'opzione PrivacyOptions all'interno del file sendmail.cf:
#Configurazione (su vecchi Sendmail proposta di default) che permette l'uso entrambi i comandi VRFY e EXPN
# privacy flags
O PrivacyOptions=authwarnings
#Configurazione che con novrfy e noexpn disabilita i comandi smtp VRFY e EXPN
# privacy flags
O PrivacyOptions=authwarnings,novrfy,noexpn
- modifica dal file sendmail.mc
define('confPRIVACY_FLAGS', 'authwarnings,novrfy,noexpn')
Ricaricato o riavviato il demone di sendmail:
bash-2.05# telnet sole 25
Trying 192.168.100.64...
Connected to sole.
Escape character is '^]'.
220 sole ESMTP SMTP SOLE; Fri, 10 Jan 2003 14:31:04 +0100 (CET)
vrfy atomo
252 2.5.2 Cannot VRFY user; try RCPT to attempt delivery (or try finger)
Modifica banner di Postfix
Tipo Infobox: TIPS - Skill: 4- ADVANCED
Postfix è un mail server OpenSource piuttosto diffuso e apprezzato per la sicurezza.
Modificare il banner smtp di Postfix (220 GIOVE ESMTP Postfix) è un operazione semplice e diretta.
Editare il file di configurazione di Postfix ( main.cf )
#configurazione originale
smtpd_banner = $myhostname ESMTP $mail_name
#configurazione modificata
smtpd_banner = Mail Server ESMTP
Riavviato il servizio di Postfix ecco il nuovo banner:
[root@GIOVE root]# telnet giove 25
Trying 10.0.0.17...
Connected to GIOVE.
Escape character is '^]'.
220 Mail Server ESMTP
File Permission di Sendmail
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Nell'esplicare le proprie funzioni Sendmail deve spesso creare nuovi file. I permessi di tali file sono determitanati dal valore impostato all'interno del file di configurazione.
L'opzione che determina i permessi da attribuire ai file è TempFileMode. Il valore di default nelle distribuzioni Linux è 0600 può variare fino a 0666.
-modifica del valore da sendmail.cf:
# temporary file mode0600
O TempFileMode=
-modifica del valore da sendmail.mc:
define(`confTEMP_FILE_MODE', 0600)
Sendmail prima di utlizzare i file .forward e :include: effettua dei controlli sui loro permessi per verificare se è sicuro utlizzarli. Per bypasssare questo controllo è necessario abilitare l' opzione DontBlameSendmail
- da sendmail.cf:
#permette la modifica al file .forward da parte del gruppo
O DontBlameSendmail=forwardfileingroupwritabledirpath
- da sendmail.mc:
OPTION ('confDONT_BLAME_SENDMAIL', 'forwardfileingroupwritabledirpath')dnl
Impostare DNSBL su Sendmail
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE
Utilizzare RBL basate su DNS in Sendmail è semplice, sopratutto se il proprio Sendmail è stato compilato per supportare la feature dnsbl.
Nella configurazione M4, in sendmail.mc basta aggiungere uno o più righe con la seguente sintassi:
FEATURE(`dnsbl',`IPserverDNS',`"Messaggio di errore di risposta"')dnl
Considerare che questo comporta, per ogni mail in arrivo, del lavoro addizionale sul server di posta e una query DNS esterna per ogni server specificato.
Valutare anche la natura delle black list: alcune contengono IP di mail server con relay aperti, altri indirizzi IP dedicati a connessioni DialUP, altri indicano macchine con socks proxy aperti (di cui si può abusare per inviare spam).
Bisogna inoltre considerare che si rischia di andare incontro a vari falsi negativi, rifiutando mail che in realtà sono legittime (e magari anche importanti), soprattutto quando si utilizzano RBL particolarmente aggressive (una delle più note in questo senso è SPEWS).
Ecco alcuni esempi di configurazione che utilizzano server dnsbl in rete, prima di utilizzarli verificare il loro indirizzo e i termini d'uso: alcuni sono aperti, altri soggetti a registrazione o condizioni commerciali, altri potrebbero non essere più in uso. In ogni caso NON inserirli tutti: sono troppi, parzialmente ridondanti e possono non essere liberamente utilizzabili
Versioni con un messaggio di errore, che indica da quale RBL si è filtrati
FEATURE(dnsbl,`relays.mail-abuse.org',`"550 Mail from " $&{client_addr} " refused - open
junkmail relay. CONSULT YOUR MAILSERVER ADMIN. See http://relays.mail-abuse.org/
cgi-bin/nph-rss?" $&{client_addr}""')dnl
FEATURE(`dnsbl',`relays.orbs.org',`"550 Mail from " $&{client_addr} " refused - open relay.
CONSULT YOUR MAILSERVER ADMIN. See: http://www.orbs.org"')dnl
FEATURE(`dnsbl',`mr-out.imrss.org',`"500 Mail from " $&{client_addr} " refused - open relay.
CONSULT YOUR MAILSERVER ADMIN. See http://www.imrss.org/"')dnl
FEATURE(`dnsbl',`dssl.imrss.org',`"550 Mail from host " $&{client_addr} " refused: We do not
accept deliveries direct from remote dialups. CONSULT YOUR ISP. Use your ISPs local
SMTP server or authenticate via POP3 first. See http://www.imrss.org/dssl/"')dnl
FEATURE(`dnsbl',`rsbl.aupads.org',`"550 Mail from " $&{client_addr} " refused: spam site.
See http://www.aupads.org/cgi-bin/rsbl-lookup?host_to_find="$&{client_addr}""')dnl
FEATURE(`dnsbl',`orvedb.aupads.org',`"550 Mail from " $&{client_addr} " refused: open relay.
CONSULT YOUR MAILSERVER ADMIN. See: http://www.aupads.org/cgi-bin/ordb-lookup?
host_to_find="$&{client_add}""')dnl
FEATURE(`dnsbl',`duinv.aupads.org',`"550 Mail from host " $&{client_addr} " refused: CONSULT
YOUR ISP. We do not accept deliveries direct from remote dialups. Use your ISPs local
SMTP server or authenticate via POP3 first. See http://www.aupads.org/cgi-bin/
duinv-lookup?host_to_find="$&{client_addr}""')dnl
Elenco senza messaggi di errore preimpostati o con messaggi minimi
FEATURE(`dnsbl', `blackhole.compu.net')dnl
FEATURE(`dnsbl', `list.dsbl.org')dnl
FEATURE(`dnsbl', `opm.blitzed.org')dnl
FEATURE(`dnsbl', `dun.dnsrbl.net',`dnsrbl refused - Dialup address use your local mailserver')dnl
FEATURE(`dnsbl', `Dialups.relays.OsiruSoft.com',`osirusoft refused - Dialup address use your local mailserver')dnl
FEATURE(`dnsbl', `bl.spamcop.net')dnl
FEATURE(`dnsbl', `inputs.relays.osirusoft.com')dnl
FEATURE(`dnsbl', `relays.ordb.org')dnl
FEATURE(`dnsbl', `Spamsites.relays.OsiruSoft.com')dnl
FEATURE(`dnsbl', `Spamhaus.relays.OsiruSoft.com')dnl
FEATURE(`dnsbl', `Spews.relays.OsiruSoft.com')dnl
FEATURE(`dnsbl', `flowgoaway.com')dnl
FEATURE(`dnsbl', `pm0-no-more.compu.net')dnl
FEATURE(`dnsbl', `blackholes.intersil.net')dnl
Disabilitare l'uso di VRFY in Postifx
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE
Il protocollo SMTP offre una serie di comandi utili per visualizzare informazioni inerenti il server di posta. Questi comandi però possono esser sfruttati per scopi non del tutto etici.
Per evitare ciò è consigliabile disabilitare alcuni comandi tra cui il VRFY che permette la verifica di inidirizzi email sul server. Ad Esempio:
telnet pippo.com 25
220 pippo.com ESMTP Postfix
vrfy pippo
252 pippo
Nel file di configurazione di Postfix ( main.cf ) inserire la seguente dichiarazione:
# disabilita il comando VRFY
disable_vrfy_command = yes
Per attivare la modifica alla configurazione di postfix è necessario ricaricare il servizio ( /etc/init.d/postfix reload )
telnet pippo.com 25
220 pippo.com ESMTP Postfix
vrfy pippo
502 VRFY command is disabled
Il comando VRFY sul server pippo.com è disabilitato.