Este año hemos tenido la oportunidad de volver a asistir a la última edición del congreso No cON Name, el congreso público de seguridad informática más longevo de España (nacido en 1999, en Palma de Mallorca), cuya última edición se llevó a cabo en 2015. Durante el discurso inaugural, la organización remarcó que la edición de 2016 no se llevó a cabo por dificultades de financiación y que actualmente se están buscando nuevos formatos que puedan encajar con el congreso, con el objetivo de evitar la repetición de ponentes y charlas en las diversas “Cons” que se realizan en España. A continuación, os dejamos un breve resumen de las presentaciones que se realizaron durante su primera jornada.
"Win API hooking by using DBI: log me, baby!" (Ricardo J. Rodríguez)
Ricardo J. Rodriguez empezó su charla con una definición e introducción a los frameworks
DBI. Esencialmente estos son capaces de controlar que sucede durante la ejecución de un binario.
Posteriormente se centró en el DBI
Pin desarrollado por
Intel en 2005. Pin tiene la característica de vincularse a procesos que se encuentran en marcha y tiene soporte para las arquitecturas 32 y 64 bits en Windows y Linux e Itanium sólo en Linux.
Existen 3 tipos de APIs en PIN: las básicas, que implementan funcionalidades básicas y son independientes de la arquitectura, las específicas de la arquitectura (opcodes y operands), y las APIs basadas en llamadas que proporcionan rutinas que definen donde y qué se instrumentaliza.
Pin proporciona dos modos de análisis o instrumentalización: JIT mode, donde una copia del binario se modifica al vuelo y el binario original nunca es ejecutado y el Probe mode, donde las instrucciones de la aplicación son modificadas y se insertan saltos (trampolines) para alterar el funcionamiento normal de la aplicación instrumentalizada.
Pin destaca de otros frameworks DBI por su granularidad. Más allá de la instrumentalización básica a nivel de bloque o instrucción, Pin proporciona instrumentalización de eventos a nivel de rutinas, grupos de bloques (traces), durante la creación o destrucción de hilos y en la carga y descarga de imágenes, llamadas de sistema, .... Y aún más importante, Pin proporciona las funciones necesarias para acceder a datos importantes cuando estos eventos ocurren.
La charla terminó con algunas instrucciones sobre cómo configurar Pin en entorno Windows y dos ejemplos de uso de Pin.
"WinregMITM: Inyectando código remotamente en el registro de Windows"
(Santiago Hernández Ramos)
Santiago ofreció una fantástica presentación sobre un problema de seguridad en el protocolo
WinReg debido a un fallo en su implementación. WinReg es un protocolo cliente/servidor que proporciona gestión remota del registro de Windows. Éste se apoya en otros protocolos como SMB,
RPC para llevar a cabo su cometido.
En el protocolo
WinReg, el cliente y el servidor negocian una sesión a través del protocolo RPC. Para que las llamadas RPC sean seguras hay que construir previamente un
contexto de seguridad. Seis
niveles de autenticación pueden establecerse según el contexto de seguridad haya negociado. Los niveles de autenticación van del 0 (ninguna protección) al 6 (integridad y cifrado). El encargado de implementar los niveles de autenticación que el contexto de seguridad exige es el
proveedor de seguridad.
Cuando un cliente inicia la conexión con el servidor mediante WinReg, se le asocia un contexto de seguridad de nivel de autenticación 6. Si durante la conexión se produce un error el contexto de seguridad es desechado. Un error puede ser algo tan sencillo como el uso de credenciales incorrectas para autenticarse con el servidor de WinReg.
Un fallo en la implementación del protocolo WinReg permite que tras el error en la conexión se establezca un nuevo contexto de seguridad con nivel de autenticación 0. La comunicación a partir de ese momento se realiza en claro y sin integridad.
El trabajo de Santiago no termina ahí si no que escribe la herramienta
WinregMITM para aprovechar esa vulnerabilidad. Tras envenenar la cache ARP del cliente y servidor la aplicación WinregMITM permite romper la conexión existente entre cliente y servidor para forzar la reconexión sin cifrado. A partir de entonces la aplicación será capaz de ver y manipular la conversación entre ambos. En este punto sólo hay que esperar a que el cliente realice un cambio en el servidor para cambiar el valor introducido legítimamente por el valor deseado por el atacante.
El ataque no es trivial ya que debido al cambio de la clave de registro realizado por el atacante el tamaño del paquete cambia. Esto afecta tanto a los campos de control de las capas inferiores (SMB y/o RPC) cómo al número de secuencia de sesión TCP que se basa en la longitud del paquete. WinregMITM es capaz de filtrar los paquetes específicos, modificar los campos necesarios, recalcular los campos de control y los números de secuencia TCP para terminar reconstruyendo el paquete y reenviarlo evitando así que la conexión se rompa.
"¿Dónde has estado? Encontrando evidencias en tu móvil" (Alex Ribot)
La charla de Alex nos descubre distintas fuentes y métodos para encontrar información de posicionamiento en dispositivos móviles.
El conocido sistema de geolocalización GPS ha sido mejorado con AGPS (Assited-GPS). Éste proporciona posicionamiento en interiores, a pesar de hacerlo con menor precisión en tales circunstancias, aprovechando la información relativa a la celda de telefonía y las señales WiFi cercanas. Este método ahorra batería y necesita sólo 2 satélites GPS para lograr una localización precisa. El rango de error en la precisión mediante posicionamiento por celda de telefonía se estima entre los 25 y los 1000 metros. Usando WiFi el rango se reduce de los 10 a los 100 metros. Por último el sistema por GPS va desde los 7,8 a los 16 metros.
Tanto iOS como Android tienen en sus acuerdos de privacidad cláusulas que solicitan el consentimiento para transmitir, coleccionar, procesar y usar los datos de localización que nuestros dispositivos envían. Las API encargadas de proporcionar información de posicionamiento son la
Core Location para iOS y la
Google’s Fused Location o la
Android Location API en Andoid.
Las fuentes de datos para obtener la geolocalización son múltiples.
A nivel de tarjeta SIM tenemos varios identificadores o códigos de área que son almacenados en la propia tarjeta: LAC (Location Area Code), FPLMN (Forbidden Public Land Mobile Network).
A nivel de sistema operativo la información guardada en el sistema de ficheros no es normalmente accesible y a menudo hay que rootear el dispositivo o sacar un dump de la memoria. En Android existe una base de datos SQLite con las redes WiFi y los IDs de las celdas (codificados en Base64) que el dispositivo ha captado. También podemos encontrar un historial con los SSSID, algunos BSSID y sus correspondientes passwords a los que el móvil se ha conectado. En IOS tenemos principalmente las
Frequent Locations, una base de datos SQLlite que retiene las ubicaciones aproximadamente durante 1 día, ficheros con algunos datos de geolocalización históricos, y archivos de preferencias plist en formato binario de difícil interpretación y la
Location cache, con información de posicionamiento por celdas (1 semana aprox.) y por WiFi (4 días aprox.)
A nivel de aplicación, existen múltiples aplicaciones que pueden almacenar información de geolocalización para desarrollar correctamente su actividad o para otros fines como mostrar publicidad. Evidentemente cada app necesita su correspondiente permiso para poder acceder a la posición del dispositivo.
A nivel de usuario, los dispositivos se pueden configurar para que se almacene la ubicación en los metadatos de imágenes y videos. Otras fuentes como imágenes tomadas en sitios públicos conocidos o conversaciones por chat o email donde se revela la ubicación son también válidos.
Para finalizar,
a nivel de Cloud, tanto IOS como Android posibilitan la localización de los dispositivos en caso de robo o pérdida, y especialmente Android proporciona un historial de localizaciones vinculado a la cuenta Gmail del dispositivo.
"Atacando implementaciones Whitebox Cryptography" (Jordi Ventayol)
Jordi, comenzó su presentación describiendo las principales diferencias entre los diferentes tipos de implementaciones criptográficas. En primer lugar, describió el tipo Whitebox, en el cual el criptoanalista dispone del control total y toda la información acerca del sistema criptográfico. En segundo lugar, describió el tipo Greybox, en el que ya no se dispone del control del sistema, y únicamente de datos relativos a los tiempos de ejecución de los algoritmos, al consumo eléctrico del dispositivo criptográfico, del campo magnético generado, etc. Finalmente, describió el tipo Blackbox, en el que únicamente se dispone de la información de las entradas y las salidas del sistema. La ponencia nos sitúa en el primero de los tipos.
Posteriormente, Jordi explicó que las implementaciones Whitebox son utilizadas en dispositivos HCE (Host Card Emulation), generalmente incluidos en smartphones para poder realizar pagos de forma equivalente a los realizados con tarjetas (basadas en la tecnología SIM).
Finalmente, y a través de varios ejemplos, expuso los principales mecanismos de protección en entornos Whitebox. Entre ellos, se encuentran el uso de tablas de búsqueda (look-up tables) para embeber la clave de cifrado, la introducción de aleatoriedad en dichas tablas, el enmascaramiento y la ofuscación tanto del código como de los datos.
"IoT - The New Big Brother" (Luis Enrique Benitez)
Luis Benítez, miembro del Departamento de Auditoría de Internet Security Auditors, puso sobre la mesa cómo los distintos dispositivos conectados recopilan información de los hábitos de uso y consumo de sus usuarios. Luis expuso que durante los últimos años ha estado analizando distintos dispositivos y que en todas ellas ha detectado carencias en la seguridad en mayor o menor grado.
Algunos ejemplos son una Smart TV que recaudaba información; un grupo de canales en particular no solo recaudaba información cuando se accedía a su contenido sino que también envía datos técnicos del dispositivo, la lista de canales sintonizados y el orden en que estos se encontraban, remarcando además que dicha información era enviaba cada 4 segundos.
También habló de dispositivos para monitorizar el consumo energético. En este caso detectó un fallo en la plataforma web que permitía acceder a los datos de consumo en tiempo real de cualquier usuario. Comentaba Benítez que esto permitiría realizar un perfil exhaustivo del usuario. Interpretando los datos de consumo se podrían llegar a deducir hábitos como la hora en que el usuario se despierta o cuando está durmiendo o fuera de casa. A esto hay que sumarle que entre los datos recaudados estaban las coordenadas GPS de donde se encontraba instalado el dispositivo y el nombre que el usuario le había asignado.
Posteriormente habló de una lavadora smart, la cual enviaba información cada 30 segundo del estado del lavabo. Una vez comprendido la lógica de la aplicación le permitía emular las peticiones recibiendo en su dispositivo móvil mensajes ininterrumpidos de que su ciclo de lavabo había terminado. También mostro serias carencias de seguridad en el portal del fabricante, el cual permitía gracias a un fallo de seguridad crear un usuario con rol de administrador.
Luis cerró su ponencia hablando de la plataforma Smart City SENTILO, la cual contaba con múltiples deficiencias de seguridad.
Las conclusiones de la charla son sobre todo dos: la necesidad de integrar la seguridad desde el principio en el desarrollo de las aplicaciones y la necesidad de una certificación de dispositivos IoT que proporcionen un mínimo de garantías en cuando al diseño y a las actualizaciones.
"El badUSB se juntó con el wifi... Y se lió parda" (Ernesto Sanchez y Joel Serna)
Ernesto y Joel, realizaron una breve introducción a los famosos dispositivos denominados BadUSB. Estos dispositivos, son dispositivos que intentan hacerse pasar por simples unidades de almacenamiento USB, pero que presentan funcionalidades ocultas. En su ponencia, presentaron su experiencia en el desarrollo de uno de estos dispositivos, con la novedad de incorporar WiFi.
En primer lugar, Ernesto y Joel hablaron sobre la funcionalidad de estos dispositivos para evadir los antivirus de los sistemas a los que son conectados. Describieron como es posible lograrlo, forzando al sistema a reconocer el dispositivo como HID (Human Interface Device -como un ratón, teclado, etc-) en lugar de memoria USB, con el objetivo de evitar que el antivirus proceda al análisis de su contenido y pueda descubrir el malware almacenado. Esta funcionalidad, la implementaron a través del módulo ATMEGA32U4.
Posteriormente, detallaron la mejora que llevaron a cabo al incluir un módulo WiFi al dispositivo, para poderlo controlar remotamente a través de la carga de scripts. Esta mejora, la implementaron a través del módulo ESP8266. A su vez, comentaron la existencia de otros proyectos en esta línea, como por ejemplo WiDucky.
Finalmente, Ernesto y Joel expusieron las dificultades de su trabajo a la hora de incorporar un módulo SD adicional, con el objetivo de permitir al dispositivo su reconocimiento de nuevo como unidad de almacenamiento (para evitar el rechazo del mismo por parte del usuario), una vez anulado el antivirus del sistema objetivo.
Autores:
Carlos Antonio Sans García
ISO 27001 L.A., ISO 22301 L.A., CISA
Dpto. Consultoría
Francesc Guitart
Dpto. Sistemas