Alcuni blog di sicurezza negli ultimi giorni stanno ponendo l’attenzione su una e-mail, che tramite phishing, si propone come un controllo dell’ISP che ospitata il proprio dominio.

Gli attacker prendendo le e-mail di contatto specificate nei WHOIS dei domini spediscono una richiesta, in inglese, che inivta ad caricare sul proprio spazio uno script in php (offuscato) che, secondo quanto scoperto dalle prime indagini, raccoglie informazioni sul sistema, apre una shell e installa un bot IRC scritto in Perl.

Solitamente il mittente, falsificato, è il proprio ISP, ma sono state rilevate anche varianti con mittente lo US FDIC (Federal Deposit Insurance Corporation).

I file php allegati che sono stati rilevati fin ora sono:

• webguard.php, size 130990 bytes, MD5: 1071956063131f0fd178ace92ab526bb e SHA1: c47dd28e336030e3d940b66e2884aba91124a831
• vprotect.php, size: 156686 bytes, MD5: 43f3c330f6e85943fd4a60c3b89787e2 e SHA1: d58bcb698417cbcf005a0e26e9e962a5097892d9

Quello che segue è una delle varianti della mail:

Dear #Nome dell’ISP# valued Members

Regarding our new security regulations, as a part of our yearly maintenance we have provided a security guard script in the attachment.

So, to secure your websites, please use the attached file and (for UNIX/Linux Based servers) upload the file “guard.php” in: “./public_html”

or (for Windows Based servers which use ASP) upload the file “guard.asp” in: “./wwwroot” in your site.

If you do not know how to use it, you can use the following instruction:

For Unix/Linux based websites that use PHP/CGI/PERL:
1) Download the attachment named “guard.zip”
2) Extract file “guard.php”
3) Login to your site Control panel.
4) Open “File Manager” window.
5) Go through “Public_html” or “htdocs”
6) Choose “Upload Files”
7) Upload the file “guard.php”
Check its URL too “http://www.yoursite.com/guard.php”, if it is ok

For Windows based websites that use ASP:
1) Download the attachment named “guard.zip”
2) Extract file “guard.asp”
3) Login to your site Control panel.
4) Open “File Manager” window.
5) Go through “wwwroot” directory
6) Choose “Upload Files”
7) Upload the file “guard.asp”
Check its URL too “http://www.yoursite.com/guard.asp”, if it is ok

Thank you for using our services and products. We look forward to providing you with a unique and high quality service.

Best Regards

#Nome dell’ISP#

L’attacco è stato rilevato per la prima volta l’8 Febbraio 2007 (Solid Space – Bluehost) mentre i principali blog ne stanno parlando solo negli utlimi giorni.

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.

La società di sicurezza Finjan ha pubblicato due giorni fa un articolo che fa luce su un pericoloso quanto imbarazzante problema nella blacklist di siti phishing di Google.
Secondo quanto spiegato da Finjan, l’estensione antiphishing di Google, la quale permette la segnalazione di siti sospetti da parte degli utenti, ha inavvertitamente raccolto e reso pubblici gli id di sessione e alcuni indirizzi email e password.
Ciò è accaduto perchè utenti, non molto esperti, hanno segnalato il sito al database solo dopo essere caduti nella “rete dei pescatori”. E’ chiaro, quindi, che Google è solo responsabile di non aver controllato che le url inserite nel database non contenessero le username e password di ignari utenti.

Google, dopo la segnalazione di Finjan a Gennaio, ha provveduto ad eliminare (non poteva togliere la query string?) dal proprio database antiphishing tutti gli URL contenenti dati che potevano essere utilizati per scopi non leciti.
E’ stata anche rilasciata una nuova versione della toolbar in grado di togliere dall’url eventuali query string.

Nel JRE (Java Runtime Environment), la macchina virtuale di Sun necessaria per far girare le applet e le applicazioni Java, è stata scoperta una vulnerabilità che mette a serio rischio gli utenti Web.

Il problema deriva da un buffer overflow nel JRE causato da una errata gestisce delle immagini GIF. Attraverso la creazione di una speciale immagine malformata, un aggressore può riuscire ad eseguire una applet Java con i massimi privilegi, inclusa, quindi, anche la manipolazione di file locali.

Per riuscire nell’attacco però deve essere l’utente a vistare un sito appositamente creato; ma oramai non è difficile nascondere iframe creati appositamente.
Sebbene la falla sia stata resa pubblica solo di recente da Zero Day Initiative, la sua correzione risale allo scorso dicembre: le versioni non vulnerabili di JRE sono la 5.0 Update 10, la 1.4.2_13, e la 1.3.1_19 e l’ultima versione 6. Per verificare quale versione di JRE sia installata nel proprio sistema, è possibile seguire le istruzioni, contenute nella parte finale, dell’advisory di Sun.

Stefano Di Paola e Giorgio Fedon hanno presentato al ventitreesimo “CCC Congress” un paper sulla sovversioni di Ajax.

All’interno del documento è stata presentata al pubblico la vulnerabilità, scoperta da Stefano, sul plugin Acrobat Reader che porta ad attacchi UXSS (Universal XSS), UCSRF (Universal CSRF) e CE (code execution).

Tutti i documenti pdf aperti con il plugin di Adobe all’interno di Firefox (versione 1.* e 2.*) o Internet Explorer (solo versione 6) sono vulnerabili agli attacchi sopra riportati. Tutte le piattaforme dove è disponibile Adobe Acrobat reader plugin sembrano interessate dal problema.

L’attacco con impatto più ampio è l’injection di JavaScript:

http://path/pdffile.pdf#UXSS=javascript:alert(�UXSS�);

Non sono il JavaScript può essere iniettato su host remoti ma anche su documenti locali:

file:///C:/Program%20Files/Adobe/Acrobat%207.0/
Resource/ENUtxt.pdf#UXSS=javascript:alert(“XSS”);
file:///C:/Programmi/Adobe/Acrobat%207.0/Resource/
ENUtxt.pdf#UXSS=javascript:alert(“XSS”);

(le  URI sono state spezzate per problemi di spazio)
mettendo così a repentaglio anche la sicurezza locale della macchina. I due esempi riportati sono abbastanza banali ma basta pensare ad un uso malizioso di JavaScript in locale per capire che non sarebbe difficile leggere o scrivere file.

Molte banche che offrono il controllo del proprio conto online hanno dei PDF (sul medesimo dominio) su statistiche o note informativi sui prodotti offerti. Per un attacker non sarebbe difficile tramite document.cookie rubare i cookie di ignari utenti.
Per risolvere il problema lato utente finale è necessario aggiornare alla versione 8 il plugin oppure, con Firefox, impostare il donwload dei file PDF.
Lato webmaster invece è consigliabile ospitare i file PDF su un dominio diverso dal quello principale oppure forgiare ad arte gli header HTTP in modo che venga forzato il download del PDF.

Maggiori informazioni si trovano sul sito dell’autore e su GnuCitizen.