Anonymous hacks Chinese websites

A screen shot of the hacked home page for Chengdu city's business district.

Messages by the international hacking group Anonymous went up on a number of Chinese government websites on Thursday to protest internet restrictions. On a Twitter account established in late March, Anonymous China listed the websites it said it had hacked over the last several days. They included government bureaus in several Chinese cities, including in Chengdu, a provincial capital in southwest China. Some of the sites were still blocked on Thursday, with English-language messages shown on how to circumvent government restrictions. In a message left on one of the hacked Chinese sites, cdcbd.gov.cn, a home page for Chengdu's business district, the hackers expressed anger with the Chinese government for restrictions placed on the internet. "Dear Chinese government, you are not infallible, today websites are hacked, tomorrow it will be your vile regime that will fall," the message read. "So expect us because we do not forgive, never. What you are doing today to your Great People, tomorrow will be inflicted to you," one of the messages read. Al Jazeera's Melissa Chan, reporting from Hong Kong, said that the attack was interesting because Anonymous had mostly previously stayed away from attacking Chinese websites. "This is just (Anonymous') second attack (on Chinese websites)," Chan said. "The first one a few months ago had been a corporate attack against a Chinese company and it had exposed corporate fraud. This time, of course, the message was more general about online censorship in China." Chan also pointed out the attacks did not target national websites, but smaller sites for government bureaus and minor cities. "The other interesting thing is that the messages they left were left in English, so then that begs the question of whether they wanted to try to reach out to the Chinese public or not," Chan said. Some websites that Anonymous said it attacked were working Thursday, and government officials denied the sites were ever hacked.

Source: Al Jazeera

La subdola minaccia del Cross Site Scripting

Al contrario del mondo reale, in quello virtuale la distanza non ha alcuna importanza e la diffusione di Internet ha creato una sorta di enorme megalopoli che ci permette di vivere allo stesso tempo in perfetta solitudine o in mezzo a una moltitudine. Parlando di sicurezza, nel mondo reale la distanza è un parametro fondamentale visto che la minaccia deve essere fisicamente vicina. Lo stesso ovviamente non vale per il mondo virtuale dove chiunque è soggetto a minacce che possono arrivare da qualsiasi parte della rete e perciò molto più frequentemente.

Il cross site scripting è una tipologia di attacco che può essere portato a compimento anche se solo uno dei tre attori principali della società informatica sono incauti: utenti, sviluppatori e amministratori di sistema.

Come funziona

Il cross site scripting è un attacco informatico prodotto da un hacker che consiste nell’iniettare uno script in una applicazione web vulnerabile, la quale inconsapevolmente farà eseguire lo script nel browser dei suoi utenti.

Un primo schema molto semplificato è il seguente:

causerà la formattazione a titolo di tutto 

L’hacker in qualche modo avvelena il sito web facendo si che le pagine richieste da un utente contengano lo script realizzato dall’hacker.

La prima domanda che salta in mente allo sviluppatore riguarda la sicurezza degli script. Non erano forse stati pensati per essere intrinsecamente sicuri? Sappiamo infatti che gli script possono accedere ad un numero limitato di risorse e che il browser impedisce loro, tra le altre cose, di accedere ad un arbitrario file su disco o di eseguire chiamate di sistema. Il fatto è che gli script possono essere considerati sicuri in quanto eseguiti nel contesto dell’applicazione web per cui sono stati scritti. Non è certamente di interesse per un sito divulgare le  informazioni sensibili che gli sono state affidate dall’utente. Diverso è se lo script è pensato da qualcuno che vuole rubare queste informazioni.

Rivalutando gli script in quest’ottica, ecco che le risorse a cui devono poter accedere possono risultare a rischio. Per esempio i dati presenti nella pagina web del sito vulnerabile, i dati prelevabili con richieste Get/Post/XmlHttp al sito di provenienza, i cookie persistenti o ancora dei dati XML usati per esempio da Ajax.

Già nel nostro primo semplice esempio lo script dell’hacker potrebbe intercettare la funzione di onsubmitdelle credenziali del sito e spedirle all’hacker. Visto che gli script hanno pieno accesso al DOM della pagina html che li contiene, l’operazione sarebbe estremamente semplice da realizzare.

Descritto il meccanismo a grandi linee, entriamo in maggiore dettaglio comunciando a suddividere gli attacchi di cross site scripting in due macrocategorie: persistenti e volatili.

Cross site scripting persistente

Gli attacchi persistenti consistono nell’iniettare lo script nel web server in modo che venga salvato e riproposto agli utenti che lo visitano. A prima vista questo tipo di attacco potrebbe sembrare difficile da attuare, ma prendiamo in esame due esempi molto popolari: i forum e i blog.

Nel primo caso l’hacker posta uno script nel messaggio di un forum. I post più recenti tipicamente vengono mostrati a tutti gli utenti che si collegano alla pagina principale del sito e lo script viene immediatamente eseguito dai browser.
Nel secondo caso l’hacker posta uno script in un blog aperto per l’occasione. Gli ultimi post di un blog sono generalmente pubblicati sul cosiddetto “muro” che aggrega i post di tutti gli utenti di quel sito. Forse a qualcuno è già capitato di vedere l’effetto di un Html mal formattato in un post di un blog: nella pagina che aggrega tutti i post la mancata chiusura di un il resto della pagina. In modo similare il sito che ospita il blog che sia vulnerabile al cross site scripting, spedirà lo script dell’hacker a tutti i visitatori di quella pagina.

L’entità del danno provocato da questa vulnerabilità può variare dalla più totale innocuità a un feroce attacco. L’hacker potrebbe firmare dei messaggi a nome dell’utente oppure leggere i suoi dati sensibili. O ancora lo script potrebbe consegnare nelle mani dell’hacker la password dell’utente per quel forum/blog. Quanto queste credenziali possano essere importanti dipende dall’accortezza dell’utente a non usarle, ad esempio, per l’accesso al proprio conto bancario. In sostanza anche i siti che si reputano a zero rischio per la bassa importanza del contenuto del proprio sito, possono creare una grave minaccia. Questo è un chiaro esempio di quanto la sicurezza sia una miscela costruita su più elementi e con tutti gli attori del sistema informatico.

Cross site scripting volatile

Molti siti interessanti dal punto di vista dell’hacker non hanno una struttura come forum o blog, e non è quindi possibile per l’hacker persistere lo script usato per rubare informazioni all’utente, perciò l’attacco può avvenire solo durante una sessione attiva tra utente e sito vulnerabile.

La soluzione è più semplice di quanto non si possa pensare: sarà l’utente stesso ad iniettare lo script dell’hacker nel sito vulnerabile, il quale restituirà all’utente lo script immediatamente eseguito nel suo browser con la stessa capacità dirompente già vista in precedenza.

Uno degli attacchi di cross site scripting più diffusi inizia con un attacco di social engineering che ha come mezzo una apparentemente innocua email che promette una vincita milionaria sicura. In mezzo alle milioni di email di spam che girano su internet, molte sono un attacco di cross site scripting.

Credo che nessuno possa negare che tragicamente non sarebbero pochi gli utenti a cliccare sul link per cercare di riscuotere la presunta vincita milionaria.

Al click dell’utente si apre, ad esempio, il sito della banca che l’hacker ha prescelto in quanto vulnerabile al cross site scripting e di cui presume che l’utente ne sia un cliente. Il risultato è l’apertura del browser che non desta alcun sospetto all’utente che brama la vincita fortunata.

A questo punto il browser esegue una GET o POST della pagina vulnerabile del sito della banca trasmettendo lo script avvelenatore.

Come risultato il browser riceve la pagina inquinata dallo script che viene eseguito immediatamente. Lo script, essendo stato scaricato dal dominio del sito della banca, ha accesso al cookie che incautamente custodisce le credenziali per accedere alle operazioni sul conto corrente, e che viene prontamente trasmesso all’hacker. Infine viene subito caricata un’altra pagina per non insospettire l’utente.

Di tutta questa operazione l’utente non fa in tempo a vedere il caricamento della pagina della banca in quanto avviene in tempi rapidissimi. Il furto delle credenziali è avvenuto e l’utente con tutta probabilità non si è accorto di nulla.

Mini Laboratorio

Allo scopo di fare un semplice test dimostrativo, costruiamo due semplici siti web con Asp.net 2.0: il sito vulnerabile e quello dell’hacker.

Il sito vulnerabile consta di una sola pagina, Default.aspx nella quale dovremo disabilitare esplicitamente ValidateRequest di cui parleremo più avanti:

<%@ Page ValidateRequest="false" …. %>

Inoltre saranno necessari due soli controlli: un bottone di nome “btSetCookie” per creare il cookie persistente da rubare ed una label per consentire l’injection di uno script.

Il gestore dell’evento di click del bottone imposterà ad esempio le ipotetiche credenziali dell’utente, e sarà necessario cliccarlo solo una prima volta per creare il cookie persistente su disco:

protected void btSetCookie_Click(object sender, EventArgs e)

{

HttpCookie ckUser = new HttpCookie("Utente", "Raffaele");

");
ckUser.Expires = DateTime.Now.AddDays(1);
ckPassword.Expire

HttpCookie ckPassword = new HttpCookie("Password", "passwor

ds = DateTime.Now.AddDays(1);

Response.AppendCookie(ckUser);

Response.AppendCookie(ckPassword);



}

Nella Page_Load Load invece daremo il benvenuto all’utente prendendo una stringa dalla QueryString

protected void Page_Load(object sender, EventArgs e)

{

string Name = string.Empty;

!= null)
Name = "Buongiorno " + Reques

if(Request.QueryString["Name"

]t.QueryString["Name"];

lblInjection.Text = Name;



}

Il caso della QueryString è il più semplice da iniettare ma un attacco analogo può essere effettuato usando ad esempio una HTTP-POST.

Aprendo il sito vulnerabile con l’indirizzo: http://sitovulnerabile/Default.aspx?Name=Raffaele vedremo il messaggio “Benvenuto Raffaele”.

Veniamo ora al sito dell’hacker il cui compito è solo quello di raccogliere le credenziali rubate degli utenti che cadono nella trappola.

Qui è presente una sola pagina vuota, default.aspx che raccoglie e salva su disco le QueryString che gli vengono passate.

protected void Page_Load(object sender, EventArgs e)

{

string s = Request.QueryString["Cookie"] + "\r\n";

e.AppendAllText(FileName, s);
Response.Redirect("

string FileName = Server.MapPath("~/Hacked.log");

Fi

lhttp://blogs.ugidotnet.org/raffaele");



}

A questo punto è tutto pronto e non resta che spedire un milione di email con la promessa della vincita milionaria, sperando che qualcuno, la cui banca soffra di vulnerabilità al cross site scripting, abbocchi.

Il messaggio di posta elettronica in formato html, sarà composto in questo modo e inietterà per mano dell’utente lo script fatale nel sito web.

Hai vinto un milione di euro



Clicca 

qui per riscuotere

Al posto del nome utente viene iniettato lo script che redirige il browser dell’utente sul sito dell’hacker passando per intero il cookie del dominio contestuale alla pagina aperta, la banca vulnerabile nel nostro semplicistico esempio.

Come proteggere l’applicazione web

Per portare a compimento un attacco di cross site scripting abbiamo visto che l’hacker deve trovare il modo di far eseguire uno script nel browser utente nel contesto di un sito che abbia delle informazioni preziose da rubare.

In sostanza lo script viene fatto transitare verso l’applicazione web per poi essere erogato all’interno di una nuova pagina ed eseguito dal browser. Nel caso di cross site scripting volatile il browser che eroga lo script è lo stesso che riceve la pagina avvelenata, mentre nel caso del persistente questo non è necessariamente vero.

Negli attacchi di cross site scripting non ha importanza se il canale di trasmissione sia protetto da SSL o se l’utente sia autenticato. Lo schema a blocchi mostra che il sito vulnerabile ha mancato due capisaldi fondamentali nella scrittura di codice sicuro: la validazione dell’input e la codifica dell’output.

La validazione dell’input e la codifica dell’output

La validazione è un controllo di congruità che è tanto più efficace quanto è meno generico. Se ad esempio ci aspettiamo un indirizzo email, la validazione con una regular expression è sicuramente il sistema più efficiente. Se invece è il messaggio di un post in un forum il controllo sarà evidentemente più complesso perché il corpo del messaggio potrebbe contenere emoticon o una formattazione html che potrebbero nascondere delle pericolose insidie.

Il primo passo è quello di identificare nella applicazione tutti i punti di ingresso dei dati che provengono dall’utente, siano essi i dati di una form, della QueryString, di un database condiviso con un’altra applicazione o da una pagina che usa Ajax.

Questi dati in ingresso sono pericolosi non solo per il cross site scripting ma per una più generica script injection o ancora per SQL injection. In parole povere tutto l’input su cui non possiamo mettere la mano sul fuoco deve essere validato in modo rigoroso.

Il tipo di validazione da effettuarsi cambia ovviamente dall’uso che facciamo di questi dati. Se sono destinati a essere rimandati alla pagina web perché l’utente li possa confermare, andranno validati in modo da evitare che contengano tag e script.

Se sono destinati al database potremo demandare la validazione ad esempio alla classe Sql Parameter e non curarci della presenza di tag e script sempre che non vengano rimandati a una pagina web successivamente.

Il processo di validazione non può limitarsi alla mera sostituzione o codifica dei simboli di minore e maggiore.

Come abbiamo visto all’inizio gli script possono anche essere all’interno degli attributi o degli eventi di un tag html, rendendo vana questa contromisura.

Un altro potente veicolo di script è “expression” che consente di iniettare codice con stessa capacità distruttiva già vista in precedenza:

Non farò un elenco dei tag che possiamo considerare sicuri o a rischio. L’elenco rischierebbe di essere poco esaustivo e dovrebbe tenere conto di come vengono processati in ciascun browser. Non ritengo questa strategia sufficientemente sicura anche se in rari casi può essere l’unica soluzione.

I danni

Se non bloccati, questi attacchi possono arrivare a essere estremamente pericolosi. Oggi per motivi di comodità e standardizzazione il contenuto Html e gli script sono spesso presenti anche nei rich client scollegati da Internet.

Naturalmente il problema della validazione vale anche per questi perché potrebbero fungere da mezzi per veicolare un pericoloso script.

La tipologia di danni è molto variabile e può andare dal furto di credenziali all’attacco di altri siti vulnerabili, sistema tipicamente usato dagli hacker per far perdere le loro tracce. Il sistema più diffuso rimane sempre il furto del cookie che è il punto più debole di un’applicazione web vulnerabile.

Se il rimedio migliore è ovviamente quello di applicare le tecniche di validazione dell’input e di codifica dell’output, esiste un modo per mitigare il problema del furto dei cookie ed è un nuovo attributo specifico di Internet Explorer chiamato HttpOnly che è disponibile a partire dalla IE6 Service Pack 1.

I ladri di cookie e i browser

Lo scopo di HttpOnly è di informare il browser che il cookie non deve essere accessibile dagli script ma è disponibile solo per essere inviato al web server.

La sintassi aggiornata per Set-Cookie è la seguente e l’attributo HttpOnly è case-insensitive, cioè non ha importanza se le lettere siano maiuscole o minuscole:

Set-Cookie: =[; =]...

[; expires=][; domain=]

[; path=][; secure][;HttpOnly]

Grazie a questo attributo le tipologie di attacchi di cross site scripting che si basano sul furto delle informazioni presenti dentro un cookie, sono scongiurate. In pratica uno script che, eseguito ad esempio in Internet Explorer 7, dovesse tentare di leggere document.cookie, otterrebbe una stringa vuota.

Questo non significa però che HttpOnly sconfigga la totalità degli attacchi cross site scripting. Infatti lo script potrebbe cambiare la password di un utente registrata nel cookie con una nota solo all’hacker senza neppure farsi mandare il contenuto del cookie.

Bisogna sempre ricordare che è una soluzione lato client il cui più evidente vantaggio, al contrario delle soluzioni lato server, è che l’utente ha in mano la possibilità di ridurre i propri rischi, installando la versione più aggiornata del browser. In altri termini, chi naviga con browser che ignorano HttpOnly (per esempio IE6 senza SP1) è a maggiore rischio nel caso di attacchi cross site scripting.

Http Only ribadisce il concetto, se ce ne fosse ancora bisogno, che l’installazione delle patch e l’aggiornamento delle nuove versioni di applicazioni (specie se sono i browser) e dei sistemi operativi è quanto mai fondamentale.

Cosa comporta l’implementazione di questo attributo per lo sviluppatore? È evidente e auspicabile che una buona protezione nasca dall’adozione di tutte quelle buone pratiche di validazione e codifica dell’output citate in precedenza ma l’implementazione di questo attributo rimane una soluzione molto importante perché la sua messa in opera è molto rapida, ha un impatto estremamente basso sulla revisione del codice e quindi della sua messa in produzione, tutti dati fondamentali per siti di dimensioni medio/grandi.

Per gli sviluppatori Asp classic la soluzione consiste nell’aggiunta di HttpOnly al cookie usando il solito Response.AddHeader. Gli sviluppatori Asp.net possono usare lo stesso sistema o più elegantemente impostare a true la proprietà HttpOnly della classe HttpCookie.

Ancora più rapida è la soluzione del tag http Cookies del web.config che abilita l’attributo HttpOnly per tutti i cookies usati nell’applicazione. Come si può vedere dall’esempio, l’adozione di questa strategia è realmente poco invasiva per lo sviluppatore.

HttpCookie CookieNome = new HttpCookie("Nome", "Raffaele");
CookieNome.HttpOnly = true;

ome);

Response.Cookies.Add(Cookie
N

oppure

In teoria la migliore implementazione dovrebbe tenere conto della versione del browser installata ed evitare ad esempio la registrazione di informazioni sensibili per chi non supporta HttpOnly. Questa strategia purtroppo non è rapida alla luce del fatto che lo User Agent non è sufficiente per sapere se Internet Explorer 6 abbia o meno la service pack 1 installata.

Dal fronte degli altri browser c’è da registrare che purtroppo sono ancora tanti a non aver ancora voluto implementare il supporto per questo attributo; nel caso di Firefox 2.0 l’implementazione è tuttora in discussione dall’anno 2002 ed alla data di questo articolo non è ancora giunta al termine (maggiori dettagli a questo link: https://bugzilla.mozilla.org/show_bug.cgi?id=178993). 

Al posto di HttpOnly, FireFox 2.0 ha deciso una implementazione differente, basata su nuovi metodi non standard javascript, e non compatibile con HttpOnly il cui approfondimento (http://blog.mattmecham.com/archives/2006/09/http_only_cookies_in_firefox.html) va al di là dello scopo di questo articolo.

Gli strumenti offerti da Asp.net

Fin dalla versione 1.1 Asp.net offre un controllo sull’input utente grazie a validateRequest che scongiura gli attacchi più comuni come il post di tag Html, la presenza di script nei cookie, nei form o nelle QueryString.

Di default validateRequest è abilitato e la sua disabilitazione ha senso solo se si vuole dare all’utente la possibilità di postare Html/script e si effettua una scrupolosa validazione su questo input.

<%@ Page validateRequest="true"  %> (true è il default)

Per evitare di disabilitare la validazione solo per uno dei controlli, si potrebbe ricorrere ad un piccolo espediente:

• Durante la onSubmit criptare il contenuto del controllo di cui non si vuole la validazione grazie alla funzione ‘encode’ di javascript
  
• Mettere il risultato criptato dentro un controllo all’interno del form
  
• Usare HttpUtility.Decode per decodificare i dati criptati sul lato server
  
• Validare accuratamente i dati ricevuti
  

Possiamo dire che Asp.net ha risolto il problema della validazione? La risposta è no, in quanto a seconda del contesto è molto facile nascondere codice javascript nei tag della pagina. L’attributo validateRequest rimane solo uno degli strati di difesa che sono necessari nelle applicazioni web.

Un altro valido strumento di difesa che deve essere sempre usato congiuntamente e non in modo alternativo è la codifica di ciò che presentiamo sulla pagina.

Il loro uso è molto semplice e si presta per esempio per evitare che il browser legga il tag

È importante notare che HtmlEncode codifica le doppie virgolette ma non le singole. Perciò è buona abitudine usare le doppie virgolette negli attributi e negli eventi delle pagine in quanto questa semplice precauzione renderebbe inutili le parti di script con singole e doppie virgolette.

Abbiamo già visto che non sono solo i simboli di maggiore e minore a dover essere temuti. L’iniezione di script all’interno della pagina può essere molto più subdola. Per sfruttare al meglio il prezioso filtro della codifica dell’output abbiamo in Asp.net 2.0 un nuovo e potente alleato: la libreria anti cross site scripting.

La libreria anti cross site scripting

In Microsoft esiste un team che si occupa specificamente di problemi relativi alla sicurezza, le performance e la privacy il cui nome è “ACE Team” (http://blogs.msdn.com/ace_team).

Questo gruppo ha creato una libreria chiamata “Anti-Cross Site Scripting Library” arrivata alla versione 1.5 e scaricabile a questo link: http://www.microsoft.com/downloads/details.aspx?FamilyId=EFB9C819-53FF-4F82-BFAF-E11625130C25&displaylang=en

Lo scopo di questa libreria è dare allo sviluppatore dei collaudati e robusti metodi di codifica di tutto ciò che proviene da una sorgente non completamente fidata, tipicamente i dati letti da una form utente o di un database condiviso con altre applicazioni.

Nella attuale versione 1.5 della libreria sono esposti sette metodi statici che prendono una stringa e restituiscono la stringa codificata:

public static string HtmlEncode(string s);

public static string HtmlAttributeEncode(string s);
public static string JavaScriptEncode(string s);

static string VisualBasicScriptEncode(str
public static string UrlEncode(string s);
public
 ing s);
public static string XmlEncode(string s);


public static string XmlAttributeEncode(string s);

Ciascuno di questi metodi è specifico per la destinazione della stringa. Se ad esempio dobbiamo creare un url, il metodo da usare sarà UrlEncode; se invece dovessimo aggiungere un attributo ad un tag Html, dovremmo invece usare HtmlAttributeEncode.

La libreria si basa sul principio di inclusione, vale a dire che a seconda della destinazione della stringa viene definito un set di caratteri ammessi e tutti gli altri vengono codificati. Attributi Html e Url non condividono lo stesso set di caratteri da lasciare inalterati e quindi ecco spiegati i diversi metodi esposti dalla libreria. Una trattazione più ampia sul suo uso si trova a questo link: http://msdn2.microsoft.com/library/aa973813.aspx.

In qualità di Security MVP ho avuto il privilegio di testare lo scorso Novembre in anteprima la libreria e rilevare all’ACE team l’assenza nella libreria di un metodo che permetta di filtrare una iniezione di javascript usando “expression”.

Prendiamo in esame il caso in cui l’utente possa scrivere il colore per personalizzare lo sfondo di un div.

La personalizzazione del colore avverrebbe con:

style="background-color:" + ColoreUtente;

Se al posto del nome del colore l’input dovesse essere "expression(alert('Ciao'));", verrebbe eseguito lo script nella pagina.

Al momento la libreria è sprovvista di metodi che permettano di filtrare questo tipo di injection su cui è importante che ciascun sviluppatore rifletta e prenda le contromisure più opportune come ad esempio una regular expression per filtrare la parola ‘expression’ seguita dalla parentesi tonda ignorando eventuali spazi.


L’ACE team mi ha assicurato che c’è forte determinazione a evolvere la libreria in modo da coprire anche scenari di questo tipo nelle future versioni.

È realistico pensare che in futuro i server control di Asp.net useranno nativamente i metodi di questa libreria diminuendo la superficie di attacco.

Conclusione

Abbiamo preso in esame una piccola rosa di attacchi basati sull’esecuzione di script che possono rendere molto spiacevole la navigazione dell’utente.

La sicurezza dell’utente dipende da tutti gli attori del sistema informatico. L’utente può parzialmente difendersi mantenendo aggiornato il browser e il sistema operativo; lo sviluppatore può rendere più sicura la sua applicazione seguendo le buone norme di validazione e codifica dell’output; l’amministratore di sistema può verificare la corretta configurazione dell’applicazione (ad esempio escludendo il verb TRACE dal web server) e analizzare scrupolosamente i log.

iTunes truffa di uno sviluppatore e attacco hacker?

Nelle ultime ore si è diffusa a macchia d’olio la notizia secondo cui l’App Store e gli account di molti utenti iTunes siano stati attaccati: alcuni si sono ritrovati con degli acquisti singoli di oltre 600$. La responsabilità fatta risalire ad un hacker asiatico che avrebbe prima spinto i libri di un misterioso editore vietnamita verso l'alto e poi rubato denaro ad alcune carte di credito.

Per quanto possano essere sicuri, non esistono sistemi impenetrabili e immuni da attacchi di hacker, e la scorsa notte l’App Store ne ha dato un’eloquente dimostrazione. Come riportato dal portale TheNextWeb e da una serie di tweet di utenti iTunes sparsi in tutto il globo, sembrerebbe che alcune pagine del servizio di digital delivery di Apple siano state attaccate: in particolare si tratta della sezione Libri, nella quale sono state messe in evidenza una serie di applicazioni fasulle e potenzialmente dannose. La prima e grossa ondata di libri pare sia stata prontamente rimossa (non è ancora chiaro se da Apple o dagli stessi sviluppatori), sebbene anche sull’App Store italiano ne siano ancora presenti alcuni.

Come se non bastasse, molti utenti hanno segnalato che conseguentemente all’hack di App Store, anche i loro account iTunes sono stati attaccati: diverse persone provenienti sia dagli Stati Uniti che dall’Europa riferiscono che costose applicazioni fasulle siano state acquistate dal loro account, arrivando a spendere oltre 600$ per un singolo prodotto.

Al momento le informazioni sono molto confuse e contraddittorie e risulta quasi impossibile capire esattamente come siano adate le cose. Le segnalazioni di hack citate a supporto delle tesi dell'attacco informatico risalgono, infatti, anche a mesi fa e non è facile da dire se le carte di credito siano state compromesse da errori commessi del titolare o se siano state rubate le informazioni direttamente sui server Apple.

In attesa di capire che cosa sia successo e che cosa stia succedendo, cosa che potrebbe avvenire già oggi, a titolo di prudenza potrebbe essere una buona idea cambiare la password al vostro account e, per chi è più scrupoloso, e nelle impostazioni cambiate il metodo di pagamento in “Nessuno” finché non si saranno calmate le acque.