Share on Google+Share on FacebookTweet about this on Twitter

Ayer se hizo público el JB para la firmware 4.X de Apple para los iPhone/iPod Touch, y por tanto el JB tanto para el iPhone 3G, 3G y el nuevo iPhone 4. Lo interesante de todo ello es que se ha llevado a cabo de nuevo por medio de un exploit en safari. Y es que de nuevo en esta ocasión para realizar el JB tan solo es necesario restaurar a la versión más nueva (hasta la fecha) y dirigir el navegador a la web:

http://jailbreakme.com

Y eso es todo.

Pero eso es tan solo la buena noticia, dado que este método evidencia la torpeza de los ingenieros de Apple, así como la razón por la cual Apple está considerada la peor empresa dle mundo a nivel de seguridad del software ¿Que tiene que ver una cosa con la otra? Todo.

Hace ya algún tiempo en el artículo sobre los exploits explicaba esto, pero vamos a hacer un breve resumen de todo aquello. El sistema de hacer JB publicado simplemente se basa en hacer uso de un exploit que afecta a TODOS los ipod touch/iphone con versión mayor o igual a la 3.X. Si el lado bueno y amigable es que cualquier dispositivo con dicha versión podría beneficiarse de hacer un JB rápido y cómodo… el problema aparece cuando cuanquier usuario malintencionado usa dicho exploit pero con fines no tan generosos.

Un exploit no es más que un pequeño programa informático, cadena de texto, datos aparentemente sin sentido… que logran que un programa dado falle, produciendo en este una serie de anomalías. Este exploit dispararía en el programa estas anomalías generalmente por descuidos que los programadores pasan por alto y que una tercera persona que ha estudiado el caso logra comprender y aprovecharse de ello. Dada la naturaleza de estos errores de programación, la naturaleza del exploit es diferente. Pero al final, el único objetivo del exploit es inducir al software objetivo en un estado anómalo, gracias a ese fallo de programación. Es por ello que dependiendo del comportamiento anómalo que pueda experimentar el programa objetivo, el exploit será más o menos peligroso. Un ejemplo muy sencillo a esto sería por ejemplo una vulnerabilidad en el decodificador de imágenes JPG de un navegador, que se diese el caso de que si una imagen fuese constituida con una serie de bits específicos el decodificador del navegador fallase y con él el navegador experimentase un error y se cerrase. Pues bien, el objetivo máximo que podría lograr este exploit es reiniciar el navegador. ¿Pero que pasaría si el exploit permite lo que se denomina ejecución de código remoto?

Imaginar ahora un exploit que lo que ataca no es un decodificador de imagen en el software, sino la pila del sistema operativo que gestiona dicho programa, en este caso el OS del iPhone/iPod Touch, y el navegador es Safari. Imaginar que el exploit lo que logra es que Safari se vea afectado por un desbordamiento de buffer. Esto que puede significar? En los sistemas operativos, normalmente las variables de un programa o función en ejecución están en la pila del sistema, y al final de esta la dirección de retorno del programa. Que pasaría si pudiésemos modificar la pila del sistema a través de una aplicación cualquiera? Que con suerte podríamos ejecutar el programa que quisiésemos!! Volviendo a Safari, yo que soy muy mal intencionado creo una Web maligna que cuando es visitada envía una serie de datos a priori sin sentido hacia el navegador objetivo. El usuario no lo sabe, pero esos datos están por ejemplo haciendo que Safari almacene en una variable definida como una variable de 8 caracteres un dato de 30 caracteres!! Que sucede? La pila tenía solo 8 bytes de espacio reservado para esa variable, no 30!! Pero la pila no sabe de límites, estos se imponen en el código del programa, y este le dijo a la pila que reservara espacio solo para 8. Así, que Safari sin saberlo coloca en la pila del sistema un dato de 30 bytes en vez de un dato de 8 Bytes. ¿Cual es el problema? Bueno, hemos dicho que la pila almacena las variables del programa en ejecución más otras cosillas más al final de la pila suele encontrarse la dirección de retorno del programa. Imaginar que Safari reservó espacio de 8bytes para esa variable, y justo despues de esa se reservaron otros 18 bytes para otra, y que los últimos 4 bytes fuera la dirección de retorno. Si esto es así y safari coloca los 30 bytes en la posición en la que originalmente solo se pensó que iría un dato de 8, la pila se sobreescribirá!! la variable de 8 bytes quedará con el contenido de los primeros 8 bytes del dato maligno, pero es que la segunda variable de 18 bytes quedará completamente sobreescrita también, y también la dirección de retorno!! Es decir, simplemente sobrecargando una variable que inicialmente no estaba pensado para ello, se ha logrado sobreescribir sin problema alguno dos variables y la dirección de retorno.

La dirección de retorno a fin de cuenta no es más que un salto de instrucción que hace que el sistema devuelva el control en un punto concreto del código. Si tenemos nuestro programa malicioso en un buffer de la aplicación podemos de forma facil hacer que el sistema ejecute ese código, ya que este creerá que ese lugar es por donde iba el cógido ejecutándose antes de entrar en la función que fuese. El resultado? Atacando Safari se logra que el sistema operativo ejecute un programa que nosotros suministramos de fuera.

Vale, esto puede parecer todo un poco técnico, pero en realidad es muy simple.  Básicamente gracias a un fallo de seguridad de los programadores CUALQUIER usuario que conozca el exploit puede crear una página web maliciosa que cuando cualquier usuario de iPhone/iPod Touch al abrirla quede expuesto a lo que desee el atacante. En este caso se ha usado para hacer el JB, pero simplemente cambiando el Payload el resultado puede ser que te roben cualquier dato dele teléfono, agenda, correos… o peor aun!!! Que se hagan con el control TOTAL de tu dispositivo. Es decir, simplemente con visitar una web y sin tu darte cuenta de nada tu dispositivo es controlado de forma remota por cualquier hacker.

Como evitar esto? No se puede. Son los ingenieros de software, programadores, analistas… los que tienen que evitar que existan exploits que permitan ejecución de codigo. Mientras que los prgramadores de Apple continúen siendo tan torpes, cualquier hacker en el momento que desee puede hacerse con el control con prácticamente cualquier iPhone / iPod del mercado, incluyendo el iPhone 4 por supuesto. Pero esto no es ciencia ficción, esto YA es un echo, y la prueba viviente de ello es el nuevo JB. Si el JB existe gracias a dicho exploit, os puedo garantizar que son muchos que están usando dicho exploit para apoderarse de información y de muchos dispositivos ahora mismo. Y cuando hablo de control total me refiero a control total, desde robo de cualquier información, realizar llamadas…

La solución? Parches y más parches y más actualizaciones… Que esa es otra, ya llevamos 26 actualizaciones de software y aun nos encontramos con exploits de nivel crítico como el que permite el JB. El problema es que el JB es público y cualquiera podría interesarse por el tema y crear una web maliciosa para apoderarse de tantos iphone caigan en sus manos. Sin querer dar ideas, podría anunciar una versión de mi web para iPhone/iPod/iPad y lo que realmente hago es colocar en dicha web el exploit para hacerme con todos los incautos.

 

El problema es el mismo, creo que el 99% de todos los usuarios de dispositivos móviles, PCs… no son conscientes de lo importante que es usar un sistema seguro. El problema no es un virus que entra en nuestro sistema por nuestra torpeza!! Sino el cegarse y creerse que simplemente no sucede nada porque nadie puede interesarse en nosotros. Díganselo a políticos, directivos o cualquier otro que para ellos su equipo o su dispositivo portatil es esencial para su trabajo y que además contiene información altamente sensible. Eso sí, raro es el día que no escuchamos que un hacker ha hecho público un listado con millones de cuentas de Facebook, de Gmail, de Hotmail, de… o que han pillado a alguien que controlaba una red Zombi para enviar Spam… Es algo que he dicho siempre, si no te importa la seguridad, entonces deja a partir de ahora la puerta de tu casa abierta por las noches. Te van a robar la primera noche? Puede que sí puede que no, pero lo que es seguro es que antes o después es posible que tengas un buen susto. Y hasta que esto no se comprenda, Internet seguirá siendo a la par que una gran herramienta, un lugar en el que hacerse multimillonario puteando al ingenuo.

El principal problema que tiene la comunidad Apple desde mi punto de vista es precisamente el que se crean estar más seguros que ningún otro usuario, cuando es exactamente lo contrario. Esto produce una aparente sensación de seguridad al usuario, lo que le hace ser tremendamente descuidado y despreocupado. Si tenemos en cuenta que Apple posee el mayor indice de problemas de seguridad aun cuando sus productos tienen una penetración en el mercado mínima, hacerse con el control de un MAC, MacBook, iPhone, iPad… es una tarea que llega a ser muy simple para cualquier hacker mediocre, no hace falta siquiera irte a grandes gurús para ello. Y por supuesto!! sin que el usuario sepa absolutamente nada, el usuario continuará creyendo que su iPhone es seguro, que su MAC es seguro… cuando en realidad están accediendo a sus datos, archivos, fotos, contraseñas, agenda, calendario…. y jamás se dará cuenta. Hasta que un día, al igual que si dejas la puerta abierta de tu casa, tendrás un buen susto y te empezarás a tomar la seguridad algo más en serio.

 

Por cierto, no, actualmente no hay ningún sistema de protección para este y otros exploits que actualmente se conocen contra el iPhone/iPad/iPod Touch. Esto significa que con la publicación del JB el número de web maliciosas que pueden apoderarse con el control total de tu dispositivo o instalarte un virus, o lo que sea, se van a multiplicar exponencialmente. Es más, si tengo tiempo haré una pequeña demostración de lo “sencillo” que es hacer esto (una vez se conoce el exploit por supuesto). El verdadero genio no olvidemos es aquel que descubre los exploits y es capaz de prepararlo todo para la ejecución de código remoto. El resto en comparación es coser y cantar.