Un numero crescente di sviluppatori di applicazioni iOS utilizza una tecnica che permette loro di modificare a distanza il codice nelle loro applicazioni senza passare attraverso il normale processo di revisione di Apple, potenzialmente aprendo la porta ad abusi e rischi per la sicurezza per gli utenti.
La tecnica è una variazione di patch a caldo, è un modo di aggiornare dinamicamente un sistema o applicazione senza riavviarlo. In questo caso, un’applicazione iOS è aggiornata dallo sviluppatore senza dover presentare una nuova versione per iOS App Store e poi attendere la revisione dei cambiamenti di Apple, un processo che può essere lungo.
L’implementazione di questa tecnica, che è una variante di patch a caldo, nasce da un progetto open – source chiamato JSPatch. Gli sviluppatori dopo aver aggiunto il motore JSPatch alla loro applicazione, richiede solo 7 linee di codice, possono configurare l’applicazione per caricare sempre il codice JavaScript da un server remoto che controllano, questo codice è poi interpretato dal motore JSPatch e trasformato in Objective-C, il linguaggio di programmazione utilizzato per applicazioni iOS.
I ricercatori di sicurezza di FireEye in un post sul blog hanno detto che JSPatch è una manna per gli sviluppatori di applicazioni iOS:
«Nelle mani giuste, può essere utilizzato per distribuire rapidamente ed efficacemente i patch e gli aggiornamenti del codice. Ma in un mondo non utopico come il nostro, dobbiamo supporre che i malintenzionati possono sfruttare questa tecnologia per scopi non previsti».
Il problema è che l’applicazione di patch a caldo è in contrasto con il modello di sicurezza di iOS. Apple ha fatto uno sforzo significativo per costruire e mantenere un ecosistema app sano e pulito. Il componente essenziale che contribuisce a questo status quo è l’App Store, che è protetto da un processo di valutazione completo che scruta tutte le applicazioni presentate. Mentre il processo ha lo scopo di proteggere gli utenti iOS e garantire applicazioni che soddisfano gli standard di Apple per la sicurezza e l’integrità (ci sono alcune restrizioni concernenti la sicurezza che Apple impone alle applicazioni di terze parti e che sono applicate solo attraverso il processo di revisione di App Store), JSPatch consente agli sviluppatori di ignorare tali politiche. Ad esempio, utilizzando questo metodo, un’applicazione può accedere ad alcune API iOS senza averlo dichiarato quando è stato presentato e accettato nell’App Store. Si può anche accedere alle API con restrizioni che solo le applicazioni di Apple sono autorizzate a usare, in pratica un’applicazione potrebbe cambiare le impostazioni di sistema, enumerare i tipi di account sul dispositivo, raccogliere i metadati delle immagini nelle informazioni dell’album fotografico o quelli dell’accesso memorizzati negli Appunti. Attualmente ci sono alcune limitazioni a ciò che gli aggressori possano fare, ma queste possono facilmente scomparire se gli sviluppatori di JSPatch scelgono di visualizzare le funzioni aggiuntive di Objective-C, o se i creatori di app apportano alcune modifiche al loro motore JSPatch.
I ricercatori sicurezza di FireEye in conclusione hanno detto:
«Abbiamo dimostrato cinque esempi che utilizzano JSPatch come vettore di attacco. La tecnologia JSPatch potenzialmente permette a un individuo di aggirare in modo efficace la protezione imposta dal processo di revisione di App Store ed eseguire azioni arbitrarie e potenti sul dispositivo senza il consenso da parte degli utenti.
JSPatch sviluppata in Cina, dal suo lancio nel 2015, ha ottenuto il successo nella regione cinese, molti profili popolari e apps cinesi hanno adottato questa tecnologia. Abbiamo scansionato un totale di 1.220 applicazioni in App Store che utilizzano JSPatch. Molti sviluppatori fuori dalla Cina l’hanno adottato. Da un lato, questo indica che JSPatch è una tecnologia utile e desiderabile nel mondo dello sviluppo IOS. D’altro canto, segnala che gli utenti sono più a rischio di essere attaccati – in particolare se non si prendono precauzioni per garantire la sicurezza di tutte le parti coinvolte. Nonostante i rischi posti da JSPatch, non abbiamo individuato come dannose alcuna delle suddette applicazioni».
