Varie vulnerablità su libero.it e infostrada.it

Tre giorni fa Rosario Valotta ha segnalato una vulnerabilità XSS (Cross-Site Scripting) su uno dei portali più importanti d’Italia: libero.it. Niente di strano se non fosse per la risposta data dallo staff di Libero su Punto Informatico il giorno successivo alla pubblicazione.
Ne riporto una piccola parte:

Se anche la stringa venisse decodificata, non si otterrebbe la password, né altri strumenti utili per accedere in qualsiasi modo agli account.
[...]
Libero ha anche sottolineato di ritenere utile e preziosa l’informazione offerta dai bug hunter e sembra intenzionata a rispondere allo stesso Vallotta direttamente su BugTraq.

Parole che fanno riflettere molto. Soprattutto mi aspettavo una risposta dal team di sviluppo interno, anche per indicare verso chi segnalare eventuali nuovi bug. visto che l’unico contatto ufficiale al momento è il call-center.

Ieri, Matteo Flora, nella pubblicazione di un bug XSS, scoperto da lui, all’interno del dominio libero.it aveva provato a rinnovare l’invito al team di sviluppo di una “collaborazione”, ma visto che ad oggi la soluzione da loro applicata è quella del “fixing silenzioso” abbiamo deciso di pubblicare insieme un advisory cumulativa degli ultimi bug trovati sui portali del gestore arancione.

I bug segnalati nel documento, dove sono spiegati più in dettaglio, sono 4:

  • Nella pagina per la gestione degli errori nella parte amministrativa dei blog della piattaforma libero.it la variabile contenente l’errore non è validata.

    blog.libero.it/XSS/aux_messaggio.php?msg=%3Cscript%3Ealert(%22a%22)%3C/script%3

    Crediti: Rosario Liotta

  • Nella pagina di registrazione ad infostrada.it la variabile contenente il numero di telefono non è validata.

    www.infostrada.it/pls/portal30/inorder_155.pkg_pronto1055.show_page1?pref=02&tel=%3Cscript%3Ealert(%22a%22)%3C/script%3E&offer=HI

    Crediti: Matteo Flora

  • Nella pagina del dettaglio delle offerte su infostrada.it e 155.libero.it la variabile che identifica ogni singola offorta non è validata e porta ad una SQL Injection e all’information leakage.

    http://www.infostrada.it/pls/portal30/infostrada.offerta.dettaglio?vid=%3E

    http://155.libero.it/pls/portal30/w155.page_offerta.libero?tipo=%3E

    Crediti: Matteo Flora

  • Nella pagina, su HTTPS, che fa da gateway per l’autenticazione su 155.libero.it la variabile che contiene la password inserita non è validata.

    155.libero.it/pls/portal30/w155.pkg_authentication.Login_url?p_requested_url=/pls/portal30/w155.home&site2pstoretoken=&ssousername=anyrandomuser&password=%22%3E%20script%3Ealert%28%27XSS%21%27%29%3B%3C/script%3E%3Cbr%20style%3D%22

    Crediti: Matteo Carli

In Italia gli XSS vengono considerati ancora come vulnerabilità di secondo piano, ma da quanto dimostrato l’user-input è un dato da validare e tenere sempre sotto controllo.
Non consiglio di prendere alla leggera gli XSS; MySpace ha problemi di questo tipo da tempo ed è previsto che ve ne siano ancora molti non pubblicati: Aprile sarà il Month of MySpace Bug.

 

Windows indicato come sistema operativo più sicuro

La notizia proviene dall’undicesimo Symantec Internet Security Threat Report. L’analisi rilasciata da Symantec prende in esame le vulnerabilità (inclusi quelli dei sistemi operativi) degli ultimi sei mesi del 2006.
Durante questo periodo 39 vulnerabilità, 12 delle quali gravi, sono state scoperte in Microsoft Windows. Il tempo medio impiegato per il rilascio di patch, da parte di Microsoft, è di 21 giorni. Nel primo semestre 2006 le vulnerabilità segnalate sono state 22 con 13 giorni medi per il rilascio delle patch.
Al secondo posto della classifica si trova Red Hat Linux con 208 vulnerabilità, di cui 2 gravi e 58 giorni di media per il rilascio dei fix. Nella prima metà del 2006 il numero dei bug segnalati in RHL sono stati 42 con 13 giorni medi per il fix.
La classifica continua con Mac OS X e HP-UX.

Sono sicuro che gli investimenti di Microsoft, fatti negli utlimi anni, abbiano contribuito a rendere più sicuri prodotti come Windows XP (SP2) e Windows Vista.
Da una ricerca fatta da Jeff Jones, rilasciata il giorno dopo quella di Symantec, Vista si è dimostrato più sicuro nei 90 giorni successivi al lancio sul mercato rispetto a XP.
Anche in questo documento viene messo a confronto Windows con sistemi come Red Hat Linux (Workstation 4), Ububtu (6.06 TLS), SUSE (Desktop 10) e altri.
Le ricerche di Symantec e di Jones non riportano la lista delle vulnerabilità prese in esame per le loro statistiche, così ho deciso di percorrere a ritroso la lista su Secunia, per Ubuntu le parti interessate sono: mono, gdm, kernel, ruby, gpg, ecc…
Nella lista di Windows XP Pro si trovano (sempre in ordine cronologico inverso): CSRSS (kernel), NetrWkstaUserEnum (kernel), CSRSS (kernel), Outlook Expres, CSRSS (kernel), ecc…

Non ci vuole molte a capire che il tipo di vulnerabilità dei due sistemi operativi sono completamente differenti; nella prima lista sono presenti maggiormente funzionalità non facenti parte del Kernel essendo applicazioni di terze parti, la seconda lista invece riporta problemi relativi al kernel di Windows.
Com’è possibile mettere a confronto un sistema operativo, come Ubuntu, che fornisce nativamente circa 10.000 pacchetti con uno come Windows che ne fornisce si e no 20?

In questa gara non ci sono vincitori, ma solo vinti.

 

HttpOnly Cookie implementati in Firefox 3

L’attributo HttpOnly dello header HTTP “Set-Cookie” serve per rendere invisibile un cookie ai linguaggi client-side come JavaScript.
Tramite questa tecnica, sviluppata da Microsoft, un browser invierà i cookie di un dominio solamente al server contattato inibendone, ad esempio, la lettura tramite il classico “document.cookie” di JavaScript.

HttpOnly Cookie è stato implementato per la prima volta in IE 6 sp1, da pochi giorni è stato integrato di default anche nella terza beta di Firefox 3.

HttpOnly è ancora una tecnologia poco utilizzata: è stata implementata ufficialmente su PHP dalla versione 5.2 Ci sono però dei workaround per utilizzarla anche sulle versioni precedenti.

Per chi volesse provare HttpOnly su Firefox 2 può usare l’estensione “httpOnly” scritta da Stefan Esser. L’estensione non segue la vera implementazione usata da Microsoft: tutti i cookie in arrivo, contrassegnati dal flag HttpOnly vengono criptati con AES tramite un hook di Firefox. Un altro hook decripta i cookie solo quando vengono inviati tramite HTTP, in questo modo i cookie ottenuti tramite JavaScript saranno inutilizzabili perché criptati.

Segnalo inoltre, che da poche ore sono stati rilasciati Firefox 2.0.3 e Firefox 1.5.0.11 che correggono alcuni bug di sicurezza venuti alla ribalta negli scorsi giorni.

 

Il phishing contro Poste Italiane non si ferma

Nelle ultime ore sta circolando un messaggio di phishing contro i clienti di Poste Italiane confezionato diversamente a quelli, già segnalati, delle scorse settimane.

La mail confezionata risulta ben fatta e scritta in un Italiano corretto. A fianco potete vedere uno screenshot della mail originale che comprende i loghi di Poste Italiane. Di seguito riporto il testo originale e alcune intestazioni:

To: xxxxxx@xxxxx.xxx
Subject: Poste.it chiede la vostra collaborazione
From: Poste Italiane <BPOL@poste.it>
Reply-To: BPOL@poste.it

Caro cliente Poste.it,
Il Servizio Tecnico di Poste Italiane sta eseguendo un aggiornamento programmato del software al fine di migliorare la qualita’ dei servizi bancari. Le chiediamo di avviare la procedura di conferma dei dati del Cliente. A questo scopo, La preghiamo di cliccare sul link che troverà alla fine di questo messaggio
Acceda ai servizi online di Poste.it e verifichi il suo account »
Il sistema automaticamente, dopo aver ricevuto la documentazione e averne verificato la completezza e la veridicità, provvederà immediatamente a riattivare il suo account.
Grazie della collaborazione lo staff di Poste.it

Come ogni classico messaggio di phishing il link associato al testo “Acceda ai servizi online di Poste.it e verifichi il suo account »” porta ad un dominio simile a quello originale proprio per confondere gli utenti meno esperti.
L’indirizzo utilizzato per ospitare le pagine falsificate di Poste Italiane è hxxp://postepay.us/ il quale effettua una ridirezione verso hxxp://faq.cybersmart.co.za/attachments/.poste/.poste/
Il dominio utilizzato per il phishing è ospitato sull’indirizzo IP 196.15.138.10 che ha come DNS host name php.cybersmart.co.za .
Il messaggio, almeno nel mio caso, risulta partito da un server Web di kasserver.com .

Consiglio la visione del video rilasciato da pochi giorni da Poste Italiane che spiega come difendersi da questo tipo di truffe.

 

Gmail a rischio sicurezza per colpa di un documento xml

L’insieme di una vulnerabilità XSS in Google Groups e un documento XML utilizzato per l’intregrazione tra Gmail e Google Groups può permettere ad un attaccante, tramite una URL costruita ad hoc di rubare:

  • il token di autenticazione a Gmail
  • il nome e l’indirizzo e-mail di tutti i contatti di Gmail

Non è per niente sicuro esporre pubblicamente un documento di quel tipo; ogni nuovo XSS scoperto all’interno di google.com (a causa delle restrizioni del Cross-Domain Restrictions) potrebbe essere usato per rubare in maniera completamente trasparente i dati dell’utente.
Nell’esempio pratico fornito dall’autore viene utilizzato proprio un XSS, ancora funzionante, segnalato su sla.ckers.org.
Per maggiori informazioni consiglio la lettura dell’articolo originale.