hit counter
Nuova ondata di attacchi SQL Injection/iFrame: l'importanza della sicurezza applicativa e del security patching - NonSoloSecurity Blog di Feliciano Intini - Site Home - TechNet Blogs

NonSoloSecurity Blog di Feliciano Intini

Notizie, best practice, strategie ed innovazioni di Sicurezza (e non solo) su tecnologia Microsoft

Nuova ondata di attacchi SQL Injection/iFrame: l'importanza della sicurezza applicativa e del security patching

Nuova ondata di attacchi SQL Injection/iFrame: l'importanza della sicurezza applicativa e del security patching

  • Comments 1
  • Likes

La blogosfera "sicura" (nome scherzoso con cui identifico l'insieme di blog/e-magazines in tema sicurezza che cerco di leggere quotidianamente) ha già ampiamente battuto questa notizia, e quindi dovreste essere già tutti consapevoli di quanto sto per riportarvi, ma in questo caso ho deciso che fosse giusto il "melius abundare" e unirmi al coro per ribadire alcuni concetti forse ovvi ai più esperti ma indubbiamente utili per comprendere come si sta evolvendo lo scenario di rischio su Internet.

E' in corso una nuova ondata di attacchi SQL Injection/iFrame che sta coinvolgendo progressivamente alcune centinaia di migliaia di siti web.

Intanto è importante sottolineare, come già fatto dal blog del MSRC, che questi attacchi non stanno sfruttando la vulnerabilità segnalata nel recente security advisory e tanto meno stanno sfruttando vulnerabilità già note relative alla piattaforma Microsoft (e quindi già corrette, con tanto di security patch risolutiva già disponibile): gli attacchi sono di tipo SQL Injection, come ribadito dal post sul blog di IIS al riguardo (dove potete trovare una ricca serie di link di approfondimento alle best practice di protezione rispetto a questo tipo di problematiche).

Questo mi porta a fare la prima considerazione: l'importanza fondamentale della sicurezza applicativa rispetto all'evoluzione del cosiddetto Web 2.0. Come riportato dal post di F-Secure, l'aumento di soluzioni web che accettano dei dati in ingresso direttamente forniti dagli utenti (blog, forum di discussione, moduli di feedback, e così via...) e il contemporaneo utilizzo dei server SQL nel backend di tali soluzioni, espone inevitabilmente ad attacchi di SQL injection se tali dati non vengono verificati prima di essere memorizzati. Quindi non basta aggiornare i sistemi web server con le patch di sicurezza di TUTTO il software che ci gira su: è doveroso anche assicurarsi di aver scritto codice sicuro per tutto il codice custom che viene eseguito da tali web server. Questo per quanto riguarda le responsabilità degli amministratori dei web server.

Guardiamo poi in breve alla dinamica con cui si sviluppano questi attacchi (descritta con qualche dettaglio in più dagli ultimi due post del blog di Panda Security, qui e qui): la compromissione dei web server di cui detto si realizza con l'aggiunta di uno script a tutte le pagine web; il malcapitato utente che atterra su questi siti che ritiene sicuri (mentre sono stati "infettati") esegue lo script e viene dirottato inconsapevolmente verso alcuni siti web sotto il controllo di questi pirati informatici (fino ad ora si segnalano 3 domini, nmidahena.com, aspder.com e nihaorr1.com che sarebbe utile filtrare sui vostri proxy). Tali siti eseguono del codice che è in grado di installare del malware sul vostro computer se questo viene trovato vulnerabile ad una serie di vecchie vulnerabilità per cui esiste già la patch (un esempio di quelle che sembrano essere utilizzate: MS06-014, MS07-004, MS07-018, MS07-033, MS07-055).

Seconda considerazione: il security patching urgente è una best practice che non si deve abbandonare mai. Per le aziende questo vuol dire dotarsi di processi di patch management che non siano ostacolati da troppa burocrazia e di strumenti che abilitino alla distribuzione rapida ed estesa degli aggiornamenti di sicurezza. Per gli utenti finali questo vuol dire assicurarsi di aver abilitato l'automatismo degli aggiornamenti di sicurezza, sia per i prodotti Microsoft che per tutti quelli che lo prevedono (e di operare una revisione periodica del livello di aggiornamento di quelli che non lo prevedono: esempio, WinZip). Un PC perfettamente aggiornato non è attaccabile in modo silente e l'unico rischio residuo rimane quello del consenso da parte dell'utente all'installazione di quanto questi siti pericolosi possano proporre in modo più o meno subdolo.

Share this post :
Comments
  • Due mesi fa vi avevo parlato di nuove ondate di attacchi di tipo SQL Injection , poi un mese fa ho ritenuto

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment