La vulnerabilità in CocoaPod Dependency Manager ha esposto milioni di app

Una vulnerabilità legata all’esecuzione di codice in modalità remota identificata sul server CocoaPods centrale avrebbe potuto consentire a un utente malintenzionato di avvelenare qualsiasi download di pacchetti, rivela il ricercatore di sicurezza Max Justicz.

Un gestore delle dipendenze per i progetti Cocoa Swift e Objective-C, CocoaPods ha più di 82.000 librerie e viene utilizzato in oltre 3 milioni di applicazioni. Lo strumento è stato creato utilizzando Ruby e può essere utilizzato con Ruby predefinito su macOS.

La vulnerabilità identificata, spiega Justicz, risiede in una funzione progettata per verificare che, quando una specifica del pacchetto è stata caricata su CocoaPods, non si collegasse a un repository privato.

In breve: il modo in cui la funzione ha controllato il contenuto di un flag avrebbe potuto consentire a un utente malintenzionato di fornire contenuti personalizzati e abusarne per eseguire comandi.

La vulnerabilità è stata rivelata lunedì a CocoaPods e lo stesso giorno è stata distribuita una patch lato server.

“L’exploit è una combinazione di input dell’utente non-igienizzata ottenere attraverso a una chiamata param git che può essere utilizzato per inviare carichi remoti”, CocoaPods sviluppatore Orta Therox spiega.

Lo sfruttamento riuscito del difetto, osserva, potrebbe portare all’esecuzione di comandi shell arbitrari sul server, consentendo così a un aggressore di leggere le variabili di ambiente e scrivere nel repository CocoaPods / Specs o persino di leggere il database del trunk.

Sebbene la patch fosse distribuita sul lato server e le installazioni di CocoaPods non fossero interessate, gli sviluppatori avrebbero comunque dovuto accedere nuovamente al repository centrale di Podspecs (trunk) e distribuire eventuali nuovi Podspec.

La modifica interrompe anche le distribuzioni automatizzate su CocoaPods e richiede agli sviluppatori di sostituire i loro COCOAPODS_TRUNK_TOKEN. Ciò, tuttavia, garantisce che nessun altro abbia accesso ai propri pod.

La vulnerabilità è stata introdotta nel 2015 ma, nonostante il lungo periodo durante il quale il difetto risiedeva sul server, il team di CocoaPods non crede che il repository CocoaPods Specs sia stato manomesso. Inoltre, dicono, non ci sono prove che qualcuno abbia sfruttato la questione nel modo descritto da Justicz.

“Tuttavia, solo perché non è stato dimostrato, non significa che non sia successo. 6 anni sono tanti. Lo scenario peggiore è che un utente malintenzionato avrebbe potuto utilizzare questa tecnica per ottenere l’accesso al nostro database dei trunk”, osserva Therox.

Sebbene il database del trunk contenga indirizzi e-mail già pubblici, contiene anche chiavi di sessione, che potrebbero essere utilizzate per consentire agli utenti non autenticati di connettersi ai pod. Pertanto, CocoaPods sta eliminando tutte le chiavi di sessione, per evitare la compromissione del pod.

“Dal punto di vista della nostra indagine, non possiamo rilevare automaticamente se qualcuno ha schierato una copia avvelenata di un Pod”, osserva Therox.