All’inizio della settimana mi è giunta una lettara da parte di H3G Italia, meglio conosciuta come Tre.

Nella lettera venivo informato che ero stato promozionato per “un’offerta al bacio” riservata solo alle persone che hanno ricevuto la comunicazione come me.
L’offerta, sicuramente niente male, avrebbe previsto la tariffa di 7 centesimi per ogni minuto di chiamata (con scatto di 15 cents) e per ogni sms il tutto per 90 giorni. Oltre alla tariffa speciale sarebbe stato previsto un rimborso di tutte le ricariche effettuate tra marzo e maggio: ogni ricarica fatta concorreva all’aumento di un bonus, di egual valore della ricarica, per chiamare tutti i numeri 3 e tutti i numeri fissi.

Perchè parlo al condizionale passato? Semplice, il numero di telefono promozionato e specificato sulla lettera non è mio e non ho nemmeno idea di chi sia. Per un attimo ho creduto che qualche dealer disonesto mi avesse intestato usim a mia insaputa, ma facendo una visita su uno dei principali forum riguardante H3G ho notato che il problema è generalizzato in tutta Italia.

Palese errore nella gestione delle anagrafiche, tanto grave da arrivare ad inviare le lettere anche a chi aveva espresso il rifiuto a ricevere offerte commerciali.

Ai clienti alla quale è arrivata la lettera con numerazione errata nella giornata di oggi è stato spedito un sms:

Causa errore di stampa potrebbe ricevere una lettera promozionale da parte di 3 contenente informazioni inesatte. La invitiamo a non prenderla in considerazione.

Ai dealer sommersi da clienti alquanto perplessi è stata rilasciata questa FAQ:

FAQ per gestione Clienti erroneamente destinatari del mailing

• A)Ma esistono dei numeri attivati sulla mia anagrafica di cui io non sono a conoscenza? No, la lettera è stata recapitata al suo indirizzo ma il numero di telefono che è stato riportato per errore non è il suo
• B)Ma anche io avrò attiva la promozione descritta sul mio numero di telefono? No l’offerta è riservata ad alcuni clienti. (vedi punto D)
• C)Ma perché non avendo prestato il consenso ho comunque ricevuto una comunicazione commerciale? Prima di inviare qualsiasi comunicazione vengono sempre effettuate delle verifiche per rispettare la scelta dei clienti che come lei non desiderano ricevere comunicazioni commerciali. In questo caso si è verificato un errore sui sistemi che ha annullato i controlli ordinari. Le confermo che per future eventuali comunicazioni, terremo sempre in considerazione la sua volontà circa il trattamento dei dati
• D)Perché riservate le promozioni solo ad alcuni clienti? 3 effettua con continuità promozioni diverse sui propri clienti, coinvolgendo di volta in volta clienti diversi. 3 non mancherà di riservarle in futuro nuove attività promozionali
• E)Ho visto che esiste una tariffa più vantaggiosa della mia….7c€ per SMS e al minuto verso tutti…posso averla anche io visto che è più vantaggiosa della mia attuale? Mi dispiace ma è un’opzione tariffaria e non posso attivarla, ma se vuole possiamo trovare insieme il piano tariffario più in linea con le sue esigenze

E’ stato inoltre chiarito che sono i numeri ad essere promozionati e non l’anagrafica.
Che un errore così pesante e pericoloso per la privacy dei clienti passi inosservato alle autorità?

E’ stato scoperto un grave bug all’interno di telnetd in Solaris 10 e 11 (SunOS 5.10 e 5.11), le versione 9 o inferiori non sembrano essere affette dal problema.
Il demone telnet, al momento di un login remoto, passa degli switch direttamente al processo per il login per permettere all’utente root il login con altri account senza bisogno di password. Il bug permette, se telnetd è avviato con privilegi di root, di effettuare login senza bisogno di autenticazione.

Di seguito è riportata la parte di codice (preso dal progetto OpenSolaris) responsabile del problema:

/usr/src/cmd/cmd-inet/usr.sbin/in.telnetd.c
3199 } else /* default, no auth. info available, login does it all */ {
3200 (void) execl(LOGIN_PROGRAM, “login”,
3201 “-p”, “-h”, host, “-d”, slavename,
3202 getenv(”USER”), 0);
3203 }

/usr/src/cmd/login/login.c
1399 case ‘f’:
1400 /*
1401 * Must be root to bypass authentication
1402 * otherwise we exit() as punishment for trying.
1403 */
1404 if (getuid() != 0 || geteuid() != 0) {
1405 audit_error = ADT_FAIL_VALUE_AUTH_BYPASS;
1406
1407 login_exit(1); /* sigh */
1408 /*NOTREACHED*/
1409 }
1410 /* save fflag user name for future use */
1411 SCPYL(user_name, optarg);
1412 fflag = B_TRUE;

Telnetd è disabilitato di default solo sull’update 3 di Solaris. Su update 1 e 2 telnetd è attivo di default con privilegi ristretti.
Siamo nel 2007 e demoni come telnet dovrebbero essere in disuso da anni ormai, ma non sempre è così. ISC suggerisce, a chi proprio non riesce a farne a meno, alcuni modi per ridurre l’impatto del bug.

Nel 1994 la stessa vulnerabilità fu scoperta in IBM AIX.

Alcuni giorni fa volendo scaricare la registrazione di uno speech tenuto da un amico mi sono imbattuto in MegaUpload, uno dei tanti servizi per l’upload pubblico.

Aprendo con Firefox il link, passato dall’amico, mi si è presentata la pagina che invita ad installare la toolbar di MegaUpload la quale informa che:

Tutti gli slot di download assegnati al tuo paese ([PAESE]) sono attualmente in uso. Riprova tra qualche ora o installa la Megaupload Toolbar per l’accesso immeditato – con la toolbar installata non sussistono limitazioni di slot.

Poco più sotto sono elencati i requisiti minimi:

• Microsoft Windows (98, ME, NT, 2000, XP or Vista)
• Microsoft Internet Explorer version 5.0 or greater

Non volendo, sin da subito, pensare che le slot sono solamente un pretesto per far installare la toolbar, ho cercato di scaricare il file in due momenti diversi della giornata, ma evidentemente le slot, previste da MegaUpload, sono uguali a 0.
Non avendo Windows sulla mia macchina principale ho aperto la macchina virtuale con Windows 2000 Server che utilizzo per i test e ho deciso di installare la toolbar per capirne il comportamento.

Ho aperto il link del file su MegaUpload mentre uno sniffer salvava tutte le richieste HTTP inviate.
Header delle richieste inviate:

User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.50727; MEGAUPLOAD 1.0)

Capito che l’User-Agent era l’unica cosa che la toolbar personalizzava in IE non è stato difficile, tramite il plug-in Agent Switcher di Firefox crearne una ad hoc. Si noti che l’applicazione di MegaUpload controlla solamente che la stringa “MEGAUPLOAD” si trovi all’interno dell’header User-Agent pertanto è possibile utilizzarne anche uno di questo tipo:

Mozilla/5.0 (X11; U; Linux i686; it; rv:1.8.1.1) Gecko/20061228 Firefox/2.0.0.1 MEGAUPLOAD

Mi rendo conto che ciò che ho spiegato non rappresenta niente di innovativo o particolarmente tecnico, ma ciò che voglio far capire è che soprattutto nelle Web-Apps tutti i dati che arrivano dall’utente, compresi gli header HTTP, non devono mai essere considerati validi di default.
A riguardo si vedano casi di SQL-injection tramite header User-Agent e Referer.

Nella recente intervista Stefan Esser, ha annunciato che a Marzo inizierà il “Month of PHP bugs”.

Stefan Esser è un consulente di sicurezza tedesco che da anni ha a che fare con software OpenSource.
Circa 6 anni fa è entrato a far parte degli sviluppatori di PHP, grazie a questa mansione è stato a stretto contatto con i sorgenti di PHP capendo così che essi non erano scritti con la sicurezza come obiettivo. Ha così deciso di creare il security team all’interno di PHP per poter gestire in maniera ottimale il report di bug e il rilascio di patch.
Qualcosa nel frattempo è andato storto tanto da farlo ritirare dal gruppo di sviluppatori PHP.

Dal 2004, Stefan, ha iniziato un progetto personale chiamato “Hardened PHP” il quale fornisce patch per aumentare la sicurezza del codice ufficiale. “Hardened PHP” è stato recentemente rimpiazzato da Suhosin, progetto nato dall’idea di dividere “Hardened PHP” in due parti distinte. La protezione dello Zend Engine, per difendere il “core” da buffer overflow, implementata come patch ai sorgenti originali e un’estensione che integra tutti gli altri tipi di protezione.
Suhosin risulta trasparente sia all’utente sia allo sviluppatore: implementa il controllo sui parametri passati alla funzione mail() per evitare injection di header, effettua la crittografia dei dati delle sessioni e dei cookie, blocca le url nei parametri delle funzioni include e require, ecc…

Stefan Esser mentre parla del futuro “Month of PHP bugs”:

Its goal is to make people and especially the PHP developers aware that bugs in PHP exist. While this sounds obvious for everyone on the outside, it is actually required. PHP has a very bad reputation when it comes to security, which is mostly caused by all the advisories about security holes in PHP applications.

Lo scorso Venerdì, Websense, ha riportato che il sito dello stadio Dolphin è stato compromesso inserendo all’interno della home page un link ad un file JavaScript che tenta di installare una backdoor sfruttando due vulnerabilità su Microsoft Windows.

Lo stadio Dolphin avendo ospitato il Super Bowl ha ricevuto, negli scorsi giorni, migliaia di visite.

Il file JS utilizzato dai cracker, sfruttando le vulnerabilità MS06-14 e MS07-004, cerca di eseguire sul sistema w1c.exe (MD5 ad3da9674080a9edbf9e084c10e80516). Il file, come descritto nel bollettino di McAfee, una volta eseguito inizia a comunicare con un host remoto e aspetta risposte da esso. Una volta ricevuto l’ok, installa un nuovo servizio sul sistema dal nome MSMGS.EXE con firma della società camuffata in “Kaspersky Lab”.

Si pensava ad un attacco mirato ad un sito che avrebbe avuto molte visite in pochi giorni ed invece “l’epidemia” è molto più vasta. ISC segnala, infatti, che sono molti i domini compromessi dall’aggiunta del file JS nelle home page. Molti webmaster dei siti Web colpiti dai cracker hanno rimosso il codice JavaScript malevolo, ma molti altri non sono ancora intervenuti.

La lista dei siti utilizzati dai cracker per ospitare gli script JS sono:

• w1c.cn (nome file “3.js”)
• dv521.com (nome file “3.js”)
• www.natmags.co.uk (nome file “3.js”)
• bc0.cn (nome file “3.js” e “1.js”)
• 137wg.com (nome file “1.js”)

E’ consigliato di disabilitare la visione di questi domini via browser inserendoli in blacklist oppure, per amministratori di rete, bloccare tutte le query DNS sui propri server (il modo più veloce è utilizzare il file hosts presente su tutti i SO).

Jeremiah Grossman, noto esperto di sicurezza nelle applicazioni web, propone un nuovo approccio ai browser Web del futuro: Don’t Trust Server-Side Security.  Sono necessarie policy di  protezione, non solo suoi comportamenti dell’utente, ma anche su quelli dei siti web che si stanno visitando.