Thursday, 31 March 2016

Esto es lo que tendría que hacer el FBI para hackear un Android

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/importantes/esto-es-lo-que-tendria-que-hacer-el-fbi-para-hackear-un-android/
TAGS: FBI

Las últimas noticias sobre el hackeo del iPhone 5C por parte del FBI siguen resonando todavía. ¿Qué habría pasado de intentarlo con un Android? Analizamos una serie de casos plausibles.


El asunto del culebrón entre Apple y el FBI sigue trayendo cola. Aunque parece que por ahora la guerra ha llegado a una tregua, los debates sobre si las compañías tecnológicas deberían proporcionar a los gobiernos una puerta trasera para entrar en sus dispositivos siguen muy vivos. Como ya imaginamos que sabes, todo esto forma parte de la onda expansiva mediática provocada desde el atentado de San Bernardino en diciembre de 2015, en el que murieron 14 personas y 24 resultaron heridas de gravedad. Hace poco nos enteramos de que el FBI habría conseguido entrar en el iPhone 5C de uno de los terroristas responsables con la ayuda de la empresa israelí Cellebrite, lo que sirvió para que el público no haya parado de preguntarse sobre la seguridad de Apple desde entonces.


Ahora imaginemos que el terrorista utilizase el sistema operativo móvil de la competencia. ¿Qué pasaría si el FBI hubiese querido hackear un Android? En Motherboard se han hecho la misma pregunta, y la investigación que han conducido al respecto nos va a permitir aclararlo.


Antes de entrar a comentar los resultados de la investigación, vale la pena señalar que en el mismo medio apuntan a que al menos hubo 63 peticiones de desbloqueo de iPhones y terminales Android -nueve de los cuales ejecutaban el sistema operativo del robot verde- en el pasado, según la American Civil Liberties Union. En todos ellos se alegó que los motivos para iniciar una investigación federal tenían que ver desde con cargos menores por tráfico de drogas, a casos más graves relacionados con la pornografía infantil.


Google Nexus 5XGoogle Nexus 5X



¿Cómo podría el FBI acceder a un terminal Android?


Lo primero que hicieron los investigadores fue revisar la documentación sobre el cifrado de disco de Android. Hay que tener en cuenta que el cifrado de datos en los smartphones implica que exista una clave de desbloqueo que crea el propio teléfono. Esta contraseña se consigue combinando un código definido por el usuario y un número largo y complicado, específico del dispositivo individual que se utiliza.


Las vías de ataque posibles que quedan pasan por tratar de intervenir el terminal por fuerza bruta, lo que es altamente complicado. Sin embargo, en ocasiones acceder a los datos cifrados de un teléfono no requiere romper ningún código. Para ello, se apunta a los siguientes casos plausibles:



  • Se puede instalar una aplicación creada expresamente en un teléfono objetivo con el objeto de extraer información. Google habría hecho algo similar en 2011 cuando envió un parche a los Nexus para limpiar malware de forma remota, aunque no se sabe si esto sigue siendo posible.

  • Muchas apps utilizan el API de copia de seguridad de Android. Esto significa que hay un respaldo de la información, y que se puede acceder a ella desde la web de la propia copia de seguridad.

  • Si los datos se almacenan en una tarjeta SD externa puede que no estén cifrados. Sólo las versiones más recientes de Android permiten cifrar tarjetas de memoria extraíbles.

  • Si el teléfono tiene un sistema de desbloqueo por huella digital, siempre y cuando se consiga una imagen de la huella del usuario se puede usar para acceder a la información almacenada.

  • En el caso de que el terminal haya sido rooteado la seguridad estará probablemente debilitada, lo que facilita la tarea de acceder a los datos.

Si ninguna de estas opciones está disponible, entonces no queda más remedio que intentar entrar por la fuerza.


https://www.youtube.com/watch?v=P-b0PcEpg9g

Estas son las posibilidades de éxito de un ataque por fuerza bruta


Hay dos formas de realizar un ataque por fuerza bruta: online y offline. En ocasiones es más fácil hacerlo de forma offline, ya que basta con copiar los datos del dispositivo en un ordenador más potente y usar software especializado y otras técnicas con las que probar distintas combinaciones de claves.


Por otra parte, los ataques offline pueden ser más costosos. Para realizarlos sería necesario probar con cada posible clave de cifrado existente o, si no es posible, intentar descubrir la contraseña del usuario y después la específica del dispositivo. Este proceso podría llevar, en total, una cantidad de tiempo absurdamente alta. Estamos hablando de miles de millones de años.


Esto deja el ataque online como única posibilidad. Si se dispone de la clave específica del dispositivo, se reduce mucho el tiempo de desbloqueo si solo es necesario descifrar la contraseña definida por el usuario. Por otra parte, el teléfono podría estar protegido contra ataques online. Este tipo de protección iría desde un tiempo entre cada intento de desbloquear el teléfono, al borrado total de la memoria del dispositivo tras un número de intentos.


Dispositivo Android en proceso de cifradoDispositivo Android en proceso de cifrado / Tony Webster editada con licencia CC BY-SA 2.0



Desbloquear un Android protegido: sólo con software MDM


Según se recoge, el dispositivo utilizado para realizar las pruebas fue un Nexus 4 con Android 5.1.1 Lollipop y el cifrado de disco activado. En primer lugar se intentó entrar introduciendo códigos por fuerza bruta, lo que después de cinco intentos colocaba un contador de 30 segundos en la pantalla. Después de otros cinco fallos se pidió al equipo que reiniciara el teléfono, y cuando se habían producido 30 fallos en total la memoria se borró por completo.


¿Cómo podían entrar en el dispositivo entonces? La única forma sería emular la herramienta de administración remota que algunos iPhone tienen instalada, lo que se conoce como mobile device management o MDM. Para emular esta herramienta, construyeron la suya propia para Android y verificaron que se podía resetear la contraseña de desbloqueo del usuario sin que este lo supiese.


Y aún así, la investigación de Motherboard no pretende sentar cátedra, sólo aproximarse a cómo el FBI podría ingeniárselas para romper las protecciones de cifrado de un terminal Android.


Borrado de datos en un recovery de AndroidBorrado de datos en un recovery de Android / stwn editada con licencia CC BY-SA 2.0



¿Por qué el FBI no quiere revelar sus técnicas de hackeo?


Que el FBI usa exploits y se aprovecha de vulnerabilidades informáticas en sus investigaciones esvox populi. Lo que no es tan conocido son los métodos que utilizan para llevarlas a cabo. Es lógico que la agencia federal quiera proteger sus técnicas de hackeo para futuras investigaciones, igual que no quiere ofender a las terceras partes que les asisten o a otros gobiernos que quieran usar las mismas tecnologías. Esto ha quedado bastante claro con el caso de Cellebrite.


El año pasado el FBI hizo uso de estas técnicas secretas cuando se apoderó de la web de pornografía infantil Playpen y la mantuvo en sus servidores durante 13 días. Durante este período se dedicó a identificar a los usuarios que la visitaban usando una herramienta de investigación de red específica, y en ningún momento reveló cómo consiguió el exploit parahackear la web y a sus usuarios.


Todo este secretismo plantea una pregunta importante: Si el FBI conoce una vulnerabilidad de un programa que afecta a los usuarios y el desarrollador no es consciente de la misma, ¿debería revelarla al público en algún momento? El gobierno estadounidense es muy claro en este aspecto: a no ser que se trate de una amenaza muy seria para la seguridad nacional, o de una necesidad imperiosa de las fuerzas de la ley, es la propia agencia la que decide si debe hacerlo o no.


Mientras el FBI siga usando técnicas sofisticadas de hacking para hacer cumplir la ley y mientras siga recurriendo a terceras partes para ello, es casi seguro que todo el asunto seguirá siendo un secreto.


Source:http://www.malavida.com/


Noticias de seguridad informática

No comments:

Post a Comment