Durante las últimas horas y los próximos días vas a oír hablar mucho del ataque Jekyll a la App Store. Un equipo compuesto por gente de Georgia Tech y de la Universidad Stony Brook ha conseguido introducir un malware en la App Store usando una táctica interesante, pero que no sólo afectaría a la App Store, sino que sería plausible usarla en cualquier plataforma informática independientemente de si está gestionada o no.
Apple realiza, antes de ponerlas a disposición del público, una revisión de todas las aplicaciones. Esta revisión se realiza de dos formas: una revisión técnica automatizada en la que se buscan problemas en el código (incluyendo la posibilidad de que la aplicación sea un malware) y una inspección visual.
El ataque Jekyll, en el que una aplicación se transforma en lo que no es basándose en una aplicación “que sí es” enmascara el código necesario para convertirse en un malware entre el código de la aplicación usando una técnica modular. Así, el código utilizado es válido y se utiliza para realizar las tareas que se esperan de la aplicación (en este caso, una aplicación de noticias de Georgia Tech) pero cuando se pone en marcha, se conecta a un servidor al que solicita instrucciones. Esas instrucciones pervierten toda la lógica del programa, cargando toda una nueva lógica para el código que se reutiliza para, por ejemplo, publicar tweets, tomar fotos, robar información personal y tratar de atacar otras aplicaciones además de incluso redirigir a Safari, el navegador por defecto de iOS, a un sitio web con más malware.
El problema es que esta nueva lógica de la aplicación, generada dinámicamente a través de esa petición al servidor, no se claramente cuando se realiza una inpsección del código de la aplicación ya que este “realiza las tareas” que se esperan de esa aplicación. Fascinante por una parte, muy problemático por otra, ya que usando esta táctica es factible no sólo atacar la App Store, sino pervertir cualquier aplicación en cualquier plataforma y/o sistema operativo.
En respuesta a la presentación de la documentación de este ataque en la Conferencia Usenix en Washington, Tom Neumayr, un portavoz de Apple, ha dicho que Apple ha realizado cambios en iOS al respecto de la información publicada en la documentación. Sin embargo, no ha indicado nada acerca del proceso de revisión de las aplicaciones, que es precisamente donde el grupo que creó la aplicación ha hecho más incidencia: aparentemente la revisión “visual” de la aplicación sólo duró unos pocos segundos, según los datos monitorizados por el equipo.
Para Apple se abre un difícil camino (y de hecho, para cualquier market de aplicaciones) a la hora de tratar de prevenir un problema de este tipo ya que una auditoría inicial del código solicitado por la aplicación al arrancar no es suficiente: simplemente la aplicación podría esperar hasta el arranque número 10 o a un uso de más de X horas de la aplicación para empezar solicitar las órdenes al servidor, por lo que la aproximación al filtrado de este tipo de entrada de contenido resulta compleja salvo que en Cupertino modifiquen las propias reglas de la App Store además del núcleo de OS X para impedir que una App altere su lógica inicial utilizando información descargada desde internet.
Habría que crear un hash con el contenido del código binario del programa y antes de cada ejecución calcular el hash y compararlo con el almacenado original. Si no es el mismo se trata de una modificación dinámica de las sentencias de control del programa, y ello invalidaría su ejecución mostrando además un aviso a Apple del hecho para analizar y en su caso bloquear la App.
#1 es que yo creo que el contenido binario del programa no cambia, simplemente hay una sentencias que no funcionan hasta que se les da la orden desde el exterior.
Sin duda con alguna solución darán, pero ya sabéis lo que supondrá… un poco de tocar las pelotas más a los desarrolladores o a los usuarios. Y todo porque unos se aburrían!!! 😀
#1 #2 si, se trata de un troyano tipico y lirondo, el realizar una aplicación que se autoinyecte código (vamos que se recompile) en tiempo de ejecución y varie una vez instalada, salvo que a posteriori se haga la inyección de código desde fuera como un “modulo” es “prácticamente imposible” (vamos, muy complicado). Por eso el tema del hash no seria muy valido.
Respecto a porque se han enterado ahora, puede ser porque las pruebas automatizadas por las que pasa una aplicación cuando la mandas no son tan “buenas” como parecen y el manual que hay después, pues tampoco es capaz de detectar esas movidas.
Vamos que es un fallo que existe en todos los sistemas y lo más que pueden hacer es que el sistema consulte con una lista de direcciones (la tipica blacklist de toda la vida) a las que la maquina se la evite conectar.