Ocho siglas relacionadas con las vulnerabilidades (II): CWE y CAPEC

viernes, 31 de enero de 2014

Uno de los factores críticos sobre el que gira el mundo de la seguridad es el estudio y control de vulnerabilidades. Para ello existen organizaciones encargadas de tratar temas relacionados a este aspecto, como es el caso de MITRE, FIRST e ICASI. Veremos qué estándares utilizan y cómo aprovecharlos para entender mejor los problemas de seguridad. Si en la entrada anterior se cubrieron los CVE, en esta se hará los CWE y CAPEC.

CWE

CWE (Common Weakness Enumeration) es una lista de tipos de debilidades de software dirigida a desarrolladores y profesionales de la seguridad. Fue creada al igual que CVE para unificar la descripción de las debilidades de seguridad de software en cuanto a arquitectura, diseño y código se refiere. Se puede ver como un catálogo de debilidades documentadas que se suelen cometer programando, y que podría derivar en vulnerabilidades. Es muy utilizada por distintas herramientas de seguridad encargadas de identificar estas debilidades y para promover la identificación de las vulnerabilidades, mitigación y su prevención.

CWE satisface la necesidad que tienen las grandes empresas u organizaciones de conocer y tener catalogadas las distintas debilidades existentes. De esta forma pueden comprobar y asegurar sus productos frente a fallos de seguridad ya conocidos. De igual manera, los consumidores esperan que las soluciones compradas o contratadas estén correctamente protegidas frente a las debilidades conocidas, y así también utilizar este catálogo para analizar las posibles debilidades de soluciones adquiridas. Si se desarrolla con el ánimo de evitar las CWE en mente, se mitigan las posibilidades de que posteriormente se sufran vulnerabilidades.

Esta lista nace como iniciativa del MITRE para hacer frente a la diversidad de pensamiento sobre este asunto por parte de tres sectores: el académico, el comercial y el gubernamental.

La lista de CWE se ofrece en tres vistas:
  • Una de tipo diccionario, que incluye las debilidades debidamente enumeradas.
  • Una vista de árbol donde se clasifican las debilidades individuales.
  • Una nueva vista de árbol que permite a un usuario ampliar el conocimiento y las relaciones de las debilidades individuales encontradas en la vista anterior.
Cómo aprovechar la página del CWE


  • En el campo "Search by ID" podemos realizar una búsqueda especifica de aquellas debilidades cuando se conoce el CWE-ID sobre el cual está registrado.
  • En el enlace "Documents" se pueden encontrar todos los documentos públicos relacionados con CWE.
  • En los enlaces a "CWSS" y "CWRAF" se pueden encontrar toda la información relevante a estas dos siglas que se explicaran en próximos entradas.
  • En el enlace "Search the Site2 pueden realizarse búsquedas específicas de debilidades de software utilizando palabras clave que puede estar contenidas en el nombre o la descripción de las debilidades en caso de no conocer su CWE-ID. 
  • Con el enlace "NVD (National Vulnerability Database)" se puede ir directamente a la página web de la base de datos de vulnerabilidades del NIST, de la que también se hablará en una próxima entrada.
  • Con los enlaces "Vulnerabilitties (CVE)" y "Attack Patterns (CAPEC)" puede consultarse las otras dos listas. 
  • Con los enlaces "Weakness Scoring System (CWSS)" y "Weakness Risk Analysis Framework (CWRAF)", al igual que los enlaces comentados en el punto anterior, mostrará toda la información acerca de estas dos siglas.
La información almacenada por esta lista es clasificada para cada debilidad de la siguiente manera.

En la que se observa que una debilidad suele tener unas consecuencias comunes documentadas, unos patrones de ataque, y una probabilidad concreta de que sea explotada. Toda esta información permite saber a qué se enfrenta un usuario cuando ante una debilidad en el código.

En comparación con el catálogo de CVE, lógicamente esta lista contiene un numero considerablemente menor de registros. Mientras que en CVE existen unas 60.000 vulnerabilidades documentadas desde 1998 (ver gráfico), CWE almacena 714 debilidades conocidas.

Número de CVEs por año.
Fuente: http://www.inteco.es/blogs/post/Seguridad/BlogSeguridad/Articulo_y_comentarios/Ciberespionaje_criptografia
La última versión actualizada del top 25 de las debilidades más peligrosas que podrían encontrarse en el software, fue publicada el 13 de septiembre de 2011. Las cinco primeras de esta lista, son:
  • CWE-89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection)
  • CWE-78: Improper Neutralization of Special Elements used in an OS Command (OS Command Injection)
  • CWE-120: Buffer Copy without Checking Size of Input (Classic Buffer Overflow)
  • CWE-79:  Improper Neutralization of Input During Web Page Generation (Cross-site Scripting)
  • CWE-306: Missing Authentication for Critical Function
CAPEC

CAPEC (Common Attack Pattern Enumeration and Classification) es un catálogo de patrones de ataque que se encarga de recolectar información sobre ellos, junto a un esquema de clasificación exhaustiva. Estos patrones de ataques no son más que las descripciones de los métodos comunes utilizados para la explotación de vulnerabilidades.

Las entradas de esta conocida lista intentan dar a conocer la perspectiva del atacante y los métodos utilizados para explotar los sistemas. Se generan después de un análisis de los ejemplos de exploits específicos. Estos exploits son presentados como ejemplo de explotación de una vulnerabilidad, o incluso pueden ser propuestos para añadirse en esta lista en caso de no estar registrado.

Al igual que los demás catálogos , CAPEC intenta ofrecer la información necesaria para ayudar a mejorar la seguridad en todo el ciclo de vida de desarrollo de software y también apoyar las necesidades de los desarrolladores. Muchas de las vulnerabilidades que se registran comparten patrones de ataques, por tanto, no suelen generarse entradas en esta lista tan comúnmente como en la de vulnerabilidades. CAPEC cuenta con unas 400 entradas (patrones) actualmente.

Cómo aprovechar la página del CAPEC



  • En el campo "Search by ID" podemos realizar una búsqueda especifica de un patrón de ataque si conocemos valor sobre el cual fue registrado en esta lista.
  • En el enlace "Methods of Attack View" el diccionario ofrece una clasificación de los patrones de ataque según los métodos que estos implementen. En la siguiente imagen se puede observar cómo CAPEC clasifica estos ataques y ofrece una vista de directorio en los que se puede ir desplegando cada uno de ellos y observar los distintos patrones. 

Por cada patrón, se puede estudiar sus soluciones o mitigaciones comunes, los recursos necesarios, o las habilidades que son necesarias en el atacante para llevarlo a cabo.
  • En el enlace "Submit Content" se pueden proponer nuevos patrones de ataques para ser registrados en esta lista. Las instrucciones vienen detalladas en la página web. Sin embargo vale la pena mencionar que todo el proceso se basa en rellenar el formulario que nos suministran dentro del enlace con los detalles del ataque. Entre los más relevantes se encuentran:
    • Precondiciones necesarias.
    • Métodos del ataque (analysis, brute force, flooding, injection, spoofing, etc).
    • Conocimientos o habilidades requeridas para poder llevar a cabo este ataque.
    • Posibles soluciones o mitigaciones.
    • Debilidades asociadas (CWE-IDs)
    • Referencias, donde se suele hacer referencia a publicaciones que detallen o corroboren la propuesta del patrón de ataque propuesto.  
  • En el enlace "Documents" se pueden encontrar todos los documentos públicos relacionados con CAPEC.
  • En el enlace "Search the Site" pueden realizarse búsquedas específicas de patrones de ataques utilizando palabras clave. Esto es muy útil si no se conoce el CAPEC-ID del patrón pero se tiene una idea del nombre o las palabras que pueden estar relacionadas con él.
  • Y por último, los enlaces "Vulnerabilities (CVE)" y ‘Software Weakness Types (CWE)’ que conectan esta lista con las dos antes explicadas para poder consultarlas en caso de ser necesario.
Las tres listas del MITRE mencionadas están estrechamente vinculadas, es decir, una vulnerabilidad es explotada gracias a una debilidad conseguida en un software, que a su vez ha sido aprovechada a través de un patrón de ataque. Por tanto cada vez que cualquiera de las tres listas recibe una nueva entrada, ésta es considerada, comprobada y estudiada, por lo que muy probablemente se puedan generar o complementar los registros en cualquiera de las otras.

En nuestras siguientes entradas hablaremos de las otras dos siglas relacionadas con el ámbito de las vulnerabilidades: CVSS y CVRF.

* Ocho siglas relacionadas con las vulnerabilidades (I): CVE
Ocho siglas relacionadas con las vulnerabilidades (III): CVSS
* Ocho siglas relacionadas con las vulnerabilidades (IV): CWSS

Umberto Francesco Schiavo

Intercambio de datos entre páginas: SOP, CORS y WebMessage (y II)

miércoles, 29 de enero de 2014

Los navegadores son las aplicaciones más usadas por los usuarios a causa del desplazamiento del escritorio "a la nube" y por la grandes posibilidades que abarcan. La creciente complejidad del navegador ha permitido potenciar sus funcionalidades y (en consecuencia) aumentar los problemas de seguridad y su criticidad. Pero además, ha exigido nuevos métodos de intercambio de información y protocolos. Veamos algunos.


En el desarrollo web actual se pueden llegar a realizar múltiples peticiones AJAX a distintos componentes de la aplicación, como pueden ser gráficas que reciben JSON o un componente de login externoPuesto que SOP puede llegar a ser una política demasiado restrictiva para satisfacer esta demanda en algunos casos, la tecnología CORS nace como solución para compartir recursos con otros dominios sin llegar a poner en peligro la integridad de la información que manejan... siempre y cuando se implementen correctamente.


Usando CORS, se pueden realizar peticiones a otros dominios, como b.com. Fuente: http://linuxism.tistory.com/732
Cross Origin Sharing Resource (CORS) permite al navegador realizar una petición web a otro dominio que no cumpla con la política SOP siempre y cuando el dominio destino agregue la cabecera Access-Control-Allow-Origin, especificando a qué orígenes permite la petición. Por ejemplo:


Access-Control-Allow-Origin: http://www.dominio-tercero.com

Con apenas unas líneas, el navegador será capaz de realizar una petición XMLHttpRequest. Se observa cómo el flag Access-Control entra en juego:

Código JavaScript para realizar una petición XMLHttpRequest
En caso de que el servidor no responda con la cabecera Access-Control-Allow-Origin esperada, el navegador impedirá realizar la petición lanzando una excepción:

Chrome rechaza la petición XMLHttpRequest por no incluir el dominio destino la cabecera Access-Control-Allow-Origin
Por el contrario, si contiene la cabecera Access-Control-Allow-Origin, el código JavaScript obtendrá la respuesta en HTML o XML dependiendo del formato y continuará su ejecución. Como medida de seguridad, también es destacable que la cookie de sesión no se incluirá en la petición si el servidor no añade explícitamente la cabecera Access-Control-Allow-Credentials. De este modo, a menos que el servidor indique expresamente que quiere compartir sus recursos, el navegador no lo permitirá. Por otro lado los dominios que implementen esta funcionalidad añadiendo la cabecera Access-Control-Allow-Origin, permitirán al atacante leer el contenido de la página (lo que implica que además podrá evadir los Anti-Forgery Token que pueda contener la web).

Un posible ataque

Un escenario de ataque en el que el atacante obtuviese el contenido de una web interna y lo reportase, sería el siguiente:

Diagrama funcional de un posible ataque. Fuente: http://application-aegis.blogspot.com.es/2012/06/html5-feature-cross-origin-resource.html

El escenario consta de un servidor web interno que tiene habilitada la cabecera Access-Control-Allow-Origin a cualquier dominio representado con el asterisco (*), y una web atacante a la que el usuario accederá.

Una vez el usuario accede al sitio web del atacante, este incluirá una porción de código JavaScript que se ejecutará y provocará una petición XMLHttpRequest al servidor interno:


Código malicioso del atacante
Tras obtener el contenido de la petición, el JavaScript realizará una petición POST al sitio del atacante incluyendo el contenido de la web interna para almacenarlo en el servidor.

Por otro lado, Access-Control-Allow-Origin también permitiría evadir los Anti-Forgery Token. Este impedirá que un atacante pudiese forzar una acción en la web, sin que el usuario se diese cuenta.

Gracias a que CORS comparte el contenido de la página, se podría montar la otra web en un contenedor o un IFRAME y obtener el token haciendo una consulta al árbol DOM o filtrando por expresiones regulares:

Código para obtener el token de verificación
En este caso imprimimos el token, aunque podría usarse para formar una petición con parámetros y con ello ejecutar una acción:
Muestra del token de verificación
CORS es una forma de intercambiar información entre dominios, y esta funcionalidad abre otro vector para permitir que CORS pueda ser utilizado como puerta trasera para enviar información fuera de un dominio. Por ejemplo, en el caso de la existencia de un XSS, podría enviar la cookie de sesión para realizar un hijacking. Sería un comportamiento similar a lo que se ha dado en llamar shell of the future.

En cualquier caso CORS no es la única manera de intercambiar información entre dominios, pues con HTML 5 aparecen más formas que facilitan esta tarea y así nuevos vectores de ataque.

WebMessage

Otra forma de comunicarse entre dominios es WebMessage  que permite mandar y recibir mensajes mediante JavaScript sin necesidad de incluir una cabecera. Para usar esta funcionalidad basta con indicarlo en el JavaScript del "servidor" que recibirá el mensaje con un manejador de eventos y en la parte cliente que enviará el mensaje:

Código JavaScript del servidor para recibir para e imprimir el mensaje
Código JavaScript para enviar el mensaje


Es importante tener en cuenta de que en caso de que el "servidor" no maneje los mensajes, estos nunca llegarán.

Al necesitar un manejador explícito para usar WebMessage no se implementa SOP directamente, por lo que es importante comprobar el origen del cliente, porque si el servidor no comprueba el origen en su lógica, podría ser usado (y abusado) por otros dominios.

Además también es importante comprobar el contenido enviado por el usuario porque podría ser un vector de ataque para realizar un XSS a través de WebMessage:

Ejemplo de XSS preparado con WebMessage


Intercambio de datos entre páginas: SOP, CORS y WebMessage (I)
Oscar Sánchez
oscar.sanchez@11paths.com

Eleven Paths with Latch, in Campus Party Brazil

lunes, 27 de enero de 2014

This year is the seventh edition of Campus Party Brasil, that will take place in Sao Pablo, Brazil. For Eleven Paths, it will be a very special week in the Campus: a Hackathon will be organized,  where the contestants will put to the test the possibilities of our new Latch technology. Our Argentinian CSA, Claudio Caracciolo, from Eleven Paths, will give a presentation together with Leandro Bennaton about CiberSecurity on January 28th.

Hackathon is born as an intend of Telefonica to generate a meeting, fun and learning place, based on the development of applications from Latch's API, in order to integrate it to other platforms, or to give it different uses taking full advantage of its potential. The target is to generate new applications or implementations using Latct's API, (which is perfectly documented on our website), on purpose to get the most out of the tool and of the imagination of the assistants to Campus Party Brazil 2014

We hope really different applications will be developed at this edition of Hackathon, that is why we have proposed the following topics, not mutually exclusive:
  • Access Control for remote control account services to different operating systems, e-mail, CRM´s, etc.
  • Activate or deactivate accesses to administration account of a wi-fi routers.
  • Activate or deactivate SSID broadcast within a wi-fi net, or just turn on/off the net.
  • Activate or deactivate ignition key of a car, or make sure the car will not be turned on at certain range of hours.
  • Activate or deactivate a TOR, VPN, or Torrent client; or program a schedule in order to make it run under specific conditions or certain hours. 
  • Enable or disable RFID type access cards.
  • Activate or deactivate features of other phones or tablets. 
Participants may compete in teams or individually. The results will be evaluated and there will be great prizes for the winners:
  • 1st. place: AlienWare laptop.
  • 2nd. place: A tablet (Ipad or Galaxy)
  • 3rd. place: A Smartphone (Iphone 5 or S/note3)
The steps to participate in the hackathon that will be held since today, January 27th to January 29th, are:
  • Register for Campus Party to be able to access to the event.
  • Register for Latch Hackathon on https://www.elevenpaths.com/cpbr7
  • Access https://latch.elevenpaths.com and create an account and register for free, if you had not done it before.
  • Read the API documentation.
  • Develope based on the conditions and rules of Hackathon, , available on : http://www.vivo.com.br/campusparty 
Good luck to all contestant. We expect great ideas and contributions.

Eleven Paths con Latch, en la Campus Party de Brasil

Este año es la séptima edición de la Campus Party de Brasil, que tendrá lugar en la Ciudad de San Pablo. Para Eleven Paths será una semana muy particular en la Campus: se organizará un concurso estilo Hackathon en el que se pondrán a prueba las posibilidades de nuestra nueva tecnología Latch. También Claudio Caracciolo, CSA Argentino de Eleven Paths, dará una ponencia junto a Leandro Bennaton sobre CiberSeguridad el día 28.

El hackathon surge ante la intención de Telefónica de generar un espacio de encuentro, diversión y aprendizaje basado en el desarrollo de aplicaciones a partir de la API de Latch para poder ser integrada en distintas plataformas o bien, para darle diferentes usos originales y capaces de aprovechar todo su potencial. El objetivo concreto es la generación de nuevas aplicaciones o implementaciones utilizando la API de Latch (perfectamente documentada en nuestro sitio web) exprimiendo todo el potencial de la herramienta y la imaginación de los desarrolladores que asistan a la Campus Party de este año.

Esperamos que en esta Hackathon se desarrollen aplicaciones diferentes e imaginativas, por eso se han propuesto los siguientes temas, que no son excluyentes:
  • Controlar los accesos de las cuentas de servicios de control remoto a diferentes sistemas operativos, correo electrónico, CRM’s, etc.
  • Activar o desactivar accesos o las cuentas de administración de un router Wi-Fi.
  • Activar o desactivar el broadcast de un SSID en una red Wi-Fi, o directamente encender o apagar la red.
  • Activar o desactivar la llave de arranque de un automóvil, o bien hacer que el coche no pueda arrancarse en un determinado rango horario.
  • Activar o desactivar un cliente de TOR, de VPN, Torrent, o programarlo para que funcione ante determinadas condiciones o en determinados horarios.
  • Habilitar o no, tarjetas de ingreso tipo RFID.
  • Activar o desactivar funcionalidades de otros teléfonos o tabletas. 
Los participantes podrán competir en equipos o en forma individual, los resultados evaluados y habrá interesantes premios para los ganadores:
  • 1er. puesto: Un Portátil de AlienWare
  • 2do. puesto: Una Tablet (Ipad o Galaxy)
  • 3er. puesto: Un Smartphone (Iphone 5 o S/note3)
Los pasos para poder participar en el Hackathon que se desarrollará desde hoy día 27 al 29 de enero serán:
  • Inscribirse en la Campus Party para poder ingresar al evento.
  • Inscribirse para el Hackathon de Latch en https://www.elevenpaths.com/cpbr7
  • Ingresar a https://latch.elevenpaths.com y crearse una cuenta como desarrollador de manera gratuita, si aún no lo había realizado.
  • Leer la documentación de la API
  • Desarrollar en base a las condiciones y a las reglas del Hackathon, que se encuentran disponibles en: http://www.vivo.com.br/campusparty 
Le deseamos suerte a los concursantes y esperamos grandes aportes.

De cómo el malware modifica ejecutables sin alterar su firma

viernes, 24 de enero de 2014

Microsoft acaba de arreglar (a medias) un método que permitía alterar un fichero firmado con Authenticode. Aunque el método fue descubierto en 2009, no ha sido  hasta ahora, cuando se ha observado que ciertos programas han comenzado a usar la fórmula, que ha introducido una corrección (que todavía no se activa por defecto). Se trataba de aprovechar un fallo de diseño de Authenticode. Veamos cómo funcionaba.

Varios métodos para cambiar la integridad sin alterar la firma

Existían varios métodos para alterar una imagen de un binario firmado sin que el sistema se quejase de que la firma era incorrecta (de que se había alterado su integridad). El parche MS12-024, de abril de 2012, corrige algunos. Tiene el CVE-2012-015 y lo descubrieron Robert Zacek e Igor Glucksmann, de Avast. No se había observado en malware aún.  Pero sí que existía un problema pendiente de arreglar. El truco era muy sencillo.

Ya hemos hablado en varias ocasiones de Authenticode en este blog. Fundamentalmente, cuando se firma un binario, se calcula el hash de todo el flujo de datos del menos algunos pequeños huecos que "se salta": La cabecera del fichero llamada "Security directory RVA" (también llamada Certificate Table RVA) y el checksum del fichero completo.

En 2009 se comprobó que era posible además añadir código al final de un ejecutable, sin alterar la firma. Aunque publicaron herramientas para conseguirlo, se demuestra manualmente de manera muy sencilla, con cualquier editor hexadecimal. El truco consiste en que se puede añadir código más allá del final del fichero y modificar las cabeceras correspondientes de tamaño. La última parte del fichero (entre 1 y 4 kbs), cuando se firma, corresponde a la estructura PKCS que contiene la firma en sí. En esta estructura se encuentra el certificado y toda la información criptográfica de la firma. Para engañar a Authenticode, se le puede simplemente indicar al fichero en su cabecera que la estructura PKCS es un poco más larga (cambiar el valor del tamaño) y que abarque la parte añadida. Así de simple.

Cómo conseguirlo

Es necesario modificar el valor "Security Directory Size". En el ejemplo usado, el tamaño del directorio (de la estructura PKCS) es 0x1918 bytes. Si se van a añadir, por ejemplo, 16 bytes (0x10), se modifica el valor de 0x1918 a 0x1928 en el valor de la cabecera correspondiente. 
Un fichero cualquiera firmado, y las cabeceras correspondientes. Se ha modificado el tamaño de 1918 a 1928
 Este valor se repite más abajo en el fichero, en la estructura PKCS1_MODULE_SIGN.dwLength, que está dentro del PKCS. Encontrarlo es de nuevo muy sencillo. Se halla justo donde indique el offset de la cabecera Security Directory RVA. Se modifica ahí de nuevo el valor del tamaño. Pasa de de 0x1918 a 0x1928.

En ese mismo archivo (offset 0046c858 indicado por Security Directory RVA) se modifica el valor del tamaño PKCS
Luego, al final del fichero, se añaden los bytes necesarios con el texto o datos que se desee. En este caso, hemos añadido 16 bytes, comenzando por la palabra "ElevenPaths".

Datos añadidos justo al final del fichero, con un editor hexadecimal
Para comprobar que el tamaño del PKCS calculado es correcto, podemos simplemente restar el tamaño final del fichero (hasta dónde llegan nuestros datos añadidos) y el del offset donde comienza el PKCS (el valor de la cabecera). En el ejemplo, 0x46e180 - 0x46c858 = 0x1928. Este resultado debe corresponder con el dato que hemos modificado.

Al comprobar la firma, dirá que todo está correcto, y que no se ha perdido la integridad del binario, aunque lo hemos modificado hasta en tres puntos. Por completar, se podría modificar y actualizar la cabecera del checksum, pero no es imprescindible (Authenticode no lo tiene en cuenta).

Firma correcta del fichero de prueba, aun habiendo modificado hasta tres puntos diferentes.
¿De qué sirve añadir código ahí y por qué lo han corregido?
Esquema de cómo el malware se aprovechaba
de instaladores que acudían al Payload para descargar

Microsoft ha reaccionado a este problema cuando se ha encontrado malware (o al menos, pruebas de concepto) aprovechando el problema. De hecho, parece que fue Didier Stevens quien dio la voz de alarma este año. Encontró instaladores firmados válidos, cuyo código acudía a esa parte extra del fichero no firmado. Ahí habían añadido una URL de la que descargaba otro ejecutable. Este ejecutable descargado ya no estaba firmado.

Así, firmaban una sola vez un ejecutable, pero conseguían que sirviera para muchas instalaciones diferentes. Solo había que cambiar la parte añadida del binario, una URL en el payload, sin volver a firmar (la integridad se mantenía) y apuntar a otra URL donde se descargaba otro código. Firma una vez, instala cualquier cosa. Cómodo... pero peligroso.

El malware, sin embargo, ha visto en este método del instalador una oportunidad de pasar como instalador válido de un tercero, firmado, y descargar malware a su gusto. Ingenioso.

¿Cómo lo han corregido?

El parche MS13-098 comprueba que, tras el bloque PKCS propiamente, no se encuentran datos que no sean diferentes de cero. Si es así, la firma no será válida. Deja abierta la puerta a otros ataques, como reconoce la propia Microsoft, pero dependen ya de una muy mala práctica de los desarrolladores (introduciendo datos no firmados en la propia estructura PKCS...)

Pero este parche no estará activo hasta junio de 2014. Si se quiera activar ya, es necesario realizar un cambio en el registro (añadiendo un REG_SZ en la ruta adecuada con el valor indicado).

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config] "EnableCertPaddingCheck"="1"

En los sitemas de 64 bits, modificar además para binarios compilados nativamente en este arquitectura.

[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config] "EnableCertPaddingCheck"="1"

Y reiniciar. Teniendo en cuenta los problemas criptográficos que tuvo Microsoft con TheFlame a causa de una cadena de errores simples,... debería haber reaccionado antes a este problema y no tardar casi 5 años en solucionarlo.

Sergio de los Santos
ssantos@11paths.com

Videotutoriales de Metashield... ahora en YouTube

miércoles, 22 de enero de 2014

Hoy, las pérdidas de información más habituales ocurren a través de canales no visibles, como los metadatos o la información oculta en documentos. A través de estos ficheros compartidos con el exterior, podría ser posible obtener información crítica de la compañía que permite a un atacante identificar los activos y las redes. Las consecuencias de este filtrado de información pueden ser de gran impacto económico para la organización, además de que su reputación puede verse seriamente dañada. Metashield es nuestra apuesta para resolver esto.

Metashield Protector permite configurar una política de uso de metadatos en los servidores dentro o fuera de la organización. Prorporciona una solución ideal para controlar la información que se escapa de una organización.

Hemos subido algunos tutoriales a YouTube, con subtítulos en inglés, para dejar claro lo sencillo que son de usar e instalar. Disponemos de diferentes vídeos para explicar diferentes soluciones.

Metashield for IIS 

Una solución para el servidor Microsoft IIS que permite eliminar al vuelo los metadatos de los ficheros compartidos por web. Borra o reemplaza los metadatos de los documentos, contribuyendo a ofrecer una imagen más homogénea con respecto a los metadatos, o directamente libre de ellos.


Metashield for File Server

Limpia los documentos alojados en servidores compartidos internos, (o servidores FTP...) automáticamente, borrando los metadatos e información oculta y opcionalmente, reemplazándolos por los que se desee.



Metashield Forensics

Si se sospecha que se ha comprometido un sistema y se ha accedido de forma no autorizada a ficheros internos, MetaShield Forensics extrae evidencias digitales disponibles en los metadatos para facilitar un análisis forense.



Metashield for SharePoint

Limpia los datos servidos a través de servidores Microsoft SharePoint. Si la compañía proporciona servicios ECM (Enterprise Content Management) basados en SharePoint, este servicio ayuda a evitar que se filtre la información oculta en los ficheros.


Metashield for Client

Solución profesional para escritorios. Permite borrar la información de ficheros simplemente analizándolos con una opción añadida en el menú contextual. Ideal para limpiar ficheros antes de compartirlos con un tercero.


Metashield videotutorials... now on YouTube

Nowadays, most common information leaks occur through unseen channels such as metadata and unseen document information. Through these externally shared documents it is possible to obtain critical data from an organization that can allow an attacker to fingerprint its assets and computer network. The consequences of this leak may have economic impact and the organization reputation can be seriously harmed. Metashield is our bet to solve this.

Metashield Protector lets you configure a security policy of metadata in the documents you are serving outside your organization. It provides a holistic solution to control the information leaks through its product portfolio.

We have uploaded some Video tutorials to Youtube, with English subtitles, to make it clear how easy to install and use they are. We have different videos for different solutions.

Metashield for IIS 

Server based solution for sanitizing documents on the fly as they are served to users by Microsoft IIS web server. It deletes or replaces documents metadata on the fly, offering a normalized public image of the organization.



Metashield for File Server

Sanitizes documents hosted on file servers (FTP servers, etc.), automatically deleting their metadata and hidden information and optionally replacing it with the desired one.


Metashield Forensics

Do you suspect you have a compromised system due to unauthorized access to internal files and need a forensic analysis? MetaShield Forensics extracts digital and time-stamped evidences available in metadata for a later forensic analysis.



Metashield for SharePoint

Cleans data served by Microsoft SharePoint Servers. If your company provides ECM (Enterprise Content Management) services based on SharePoint this server based solution helps you prevent inadvertent information leak.




Metashield for Client

Professional solution for workstations. It allows to remove metadata from files, just right clicking on them. Ideal to clean files before sharing them with someone else.


Cómo eludir el filtro antiXSS en Chrome y Safari (descubierto por Eleven Paths)

lunes, 20 de enero de 2014

Los navegadores modernos cuentan con un filtro antiXSS que protege a los usuarios de algunas de las consecuencias de este tipo de ataques. Normalmente, bloquean la ejecución de cross site scriptings de forma que el código inyectado (normalmente JavaScript o HTML) no se ejecuta en el navegador de la víctima. Chrome llama a este filtro XSSAuditor. Nuestro compañero Ioseba Palop descubrió una manera de eludirlo hace meses. Puesto que ya se ha resuelto en la versión principal de Chrome, publicamos los detalles técnicos.

En ElevenPaths, hemos encontrado una forma de eludir el filtro antiXSS de Chrome. Esto significa que si la víctima visita una web con un problema de XSS del que se está intentando aprovechar un atacante, no estaría totalmente protegido. El fallo se basa en un uso incorrecto del atributo srcdoc de la etiqueta IFRAME, incluido en la definición de HTML5. Para realizar un ataque XSS en el navegador Google Chrome usando este fallo, la web debe incluir un IFRAME y debe ser capaz de leer cualquier atributo de este elemento desde parámetros HTTP (GET o POST) sin aplicar filtrado de caracteres. Después, en el parámetro IFRAME, el atributo srcdoc se puede incluir con código JavaScript. Chrome no lo filtra y se ejecutará.

Para reproducir la PoC, debería haber una página con un IFRAME como este.

Y la inyección HTML en el parámetro src sería:


y el filtro antiXSS fallaría y dejaría correr el script.


Google derivó el problema a Chromium, que no trata estas elusiones como problemas de seguridad, puesto que  XSSAuditor se considera una línea de defensa secundaria.

El problema se reportó el 23 de octubre. Lo arreglaron dos días después, haciendo que XSSAuditor cazara las propiedades reflejadas de srcdoc incluso sin una inyección en la etiqueta "IFRAME",. Chrome lo ha corregido en su versión 32.0.1700.76.

Otro fallo

Hace unas semanas, en este post, alguien se fijó en nuestra PoC como inspiración y desarrolló otra forma de eludir el filtro. Este fallo todavía no está corregido. El truco es inyectar una etiquesta "script" de apertura en un parámetro que se escriba directamente en el stream de salida de la respuesta HTTP (es decir, sin filtrar ningún carácter al igual que en el caso anterior). Bajo esta escritura debe existir contenido dentro de etiquetas scripts que pertenezcan a la propia página.


El comportamiento del navegador será incluir nuestra inyección (recordemos que sin cierre de etiqueta), obviar la apertura de "script" de la propia web, y ahora sí, utilizar el cierre de la propia web para generar un script bien formado y ejecutarlo sin ningún tipo de problema, consiguiendo así un bypass de XSSAuditor.



Safari, todavía vulnerable

Safari para Mac e iPhone también son vulnerables. Confirmaron la recepción del correo, y nos dijero que estaban trabajando en ello. Parece que todavía lo están, puesto que el programa aún es vulnerable. Cada vez que se ha intentado contactar con ellos, la respuesta que no había novedades y que estaban trabajando en ello. El filtro de Internet Explorer impide la ejecución, y Firefox no implementa ningún filtro anti XSS.

How to bypass antiXSS filter in Chrome and Safari (discovered by ElevenPaths)

Modern browsers usually have an antiXSS filter, that protects users from some of the consequences of this kind of attacks. Normally, they block cross site scripting execution, so the "injected" code (normally, JavaScript or HTML) is not executed inside victim's browser. Chrome calls this filter XSSAuditor. Our coworker Ioseba Palop discovered a way to bypass it months ago. Since it is already resolved in the "main" version of Chrome, we are publishing technical details now.

In ElevenPaths, we just found a way to evade XSS filter in Chrome. This means, if the victim visits a website with an XSS problem that an attacker is trying to take advantage of, it would not be fully protected. The  bug  is  based  on  a  misuse  of  srcdoc  attribute  of  IFRAME tag,  included  in  HTML5 definition.  To  perform an  XSS  attack  on Google  Chrome  Browser  using this  bug,  the website must  include an IFRAME and must be able to read any attribute of this element from HTTP parameters (GET/POST) without applying any charset filter. Then, in the IFRAME parameter,  the  srcdoc  attribute  may be included with JavaScript  code. Chrome cannot filter it and will be executed.

To reproduce the PoC, there should be a webpage with some IFRAME tag like this:



And an HTML injection on src parameter would be:


and XSS filter will fail and let the script run.


Google derived this to Chromium, who does not treat this bypasses as a security problem, since XSSauditor is considered a second defense line.

The problem was reported in October, the 23rd. They fixed it two days later, making XSSAuditor catch reflected srcdoc properties even without an "IFRAME" tag injection. Chrome has just fixed it in recent 32.0.1700.76 version.

Some other bug

A few weeks ago, in this post, someone took our PoC as an inspiration and developed another way of bypassing the filter. This one is still not fixed. The trick is to inject an opening "script" tag inside a parameter that is written directly in the HTTP request output stream. This is, without filtering any character just as our case. In this writing there should be content inside scripts tags that belongs to the web itself.



The browser will include our injection (remember, without closing the tag), omit the "script" opening tag from the web itself, and now, use the closing one from the web to create a well formed script and execute it... this is the bypass.




Safari, still vulnerable

Safari for Mac and iPhone is vulnerable as well. They confirmed our email, and told us they were working on it. And seems that they still are, since the program is still vulnerable. Everytime we have tried to contact back with them again, they reply back telling there is no news, but they are working on it. Internet Explorer filters it with its own filter, and Firefox does not implement an XSS filter by itself.

Vulnerabilidades escurridizas, invisibles en el código durante años

miércoles, 15 de enero de 2014

Hace poco se ha corregido una vulnerabilidad de desbordamiento de pila que afecta al servidor X11. Llevaba "escondida" en el código desde 1991, presente en muchas de las distribuciones Linux y permitiendo, para quien la conociese, elevar privilegios en el sistema afectado. ¿Existen otros casos de vulnerabilidades que han pasado desapercibidas durante años?

El caso X11

X11 es un servidor gráfico desarrollador por el MIT a mediados de los 80 que proporciona interfaz gráfica a los sistemas basados en UNIX. A principios de 2014, y usando una herramienta llamada cppcheck, se ha encontrado un desbordamiento de pila a la hora de procesar fuentes BDF con la librería libXfont. Básicamente, esto permite a un atacante local elevar privilegios a root haciendo que el sistema procese un tipo de letra especialmente manipulado. La sencillez del parche (que simplemente limita el tamaño) explica el problema. Se trata de un desbordamiento de pila "de libro").

-        if (sscanf((char *) line, "STARTCHAR %s", charName) != 1) {
+        if (sscanf((char *) line, "STARTCHAR %99s", charName) != 1) {
             bdfError("bad character name in BDF file\n");
             goto BAILOUT; /* bottom of function, free and return error */}

Página de descarga de cppcheck.sourceforge.net
X11, aun siendo un software extremadamente usado y popular, contuvo durante 23 años una vulnerabilidad, en principio, que parecía bastante sencilla de detectar por el ojo humano, pero que en realidad tuvo que se cazada con la ayuda de un programa automático.

Un caso Solaris

El  12 de febrero de 2007 se da a conocer una vulnerabilidad en (por aquel entonces) Sun Solaris 10 tan simple como sorprendente. El fallo permitía el acceso trivial como cualquier usuario (incluido root) a través de telnet. El error fue ya descubierto y corregido en sistemas UNIX en 1994, pero Solaris lo "reintrodujo"en sus sistemas en noviembre de 2002, con lo que pasó inadvertida durante unos 5 años. A través de un simple parámetro del cliente telnet ("-f", utilizado para traspasar las credenciales locales), se podía acceder a un servidor telnet en Sun Solaris 10 sin necesidad de autenticación. Sólo conociendo el nombre de usuario. El comando para "explotar" el fallo era:

telnet -l "-froot" [direccion_del_host]

El código del demonio telnet en Solaris 10 es abierto.

Un caso Oracle

El fallo CVE-2012-1675 en Oracle, reconocido por la compañía en abril de 2012, fue reportado en 2008 por Joxean Koret (@matalaz). Afectaba a todas las versiones de Oracle Database (desde 8i hasta la versión 11g R2). La vulnerabilidad permitiría controlar el tráfico cliente-servidor y modificarlo, a través de un ataque MITM. Aunque se reportó en 2012, la vulnerabilidad estaba en el código probablemente desde 1999. Además de la antiguedad del problema, Oracle protagonizó un episodio vergonzante en la gestión de parches. Koret, creyendo que había sido por fin solucionado, publicó todos los detalles. Haciendo gala de una respuesta totalmente absurda, Oracle respondió que en realidad "the vulnerability was fixed in future releases of the product", lo que no tenía sentido (fue corregida en futuras versiones).

Un caso Windows

A principios de 2007, todo el mundo hablaba de la vulnerabilidad de los Windows MetaFile (WMF) que supuso una pesadilla para Microsoft por muchas razones (se llegó a sacar un parche extraoficial por la comunidad, antes que la propia Microsoft). Era tan sencilla de explotar que Steve Gibson llegó a insinuar que podría ser intencionada, una puerta trasera incluida a propósito en el sistema operativo más famoso.

El fallo estaba basado en los registros de tipo META_ESCAPE, concretamente en el subcódigo SetAbortProc. En ella se deben especificar dos argumentos, uno que representarían el "Device Context" y el segundo sería una función a ejecutar ante un evento de cancelación de impresión. Controlarlos y ejecutar código era tan sencillo como enviarles los comandos adecuados. Stephen Toulouse escribió además en el blog oficial de Microsoft que el fallo estaba presente desde los tiempos de Windows 3.0, creado hacia 1990. SetAbortProc fue programada cuando la seguridad no representaban la mayor de las prioridades y fue introducida en los tiempos en los que procesar imágenes era lento y quizás fuese necesario abortar el proceso de impresión antes de que terminara, mucho antes incluso de que existiera el formato WMF. Aunque la funcionalidad fue perdiendo importancia, se fue portando junto con muchas otras, versión tras versión, en lenguaje ensamblador a los siguientes sistemas operativos que surgieron después. Se mantuvo por tanto unos 17 años en el código sin que nadie lo detectara. Ni siquiera los profesionales que se dedican a tiempo completo a encontrar fallos en Windows (que los hay).

¿Cómo puede ocurrir esto?

Los ejemplos expuestos son los más llamativos y escandalosos. Hay más ejemplos de todo tipo, en código abierto y cerrado. De hecho, todos los días se corrigen vulnerabilidades en sistemas operativos o programas que llevan años funcionando, y quizás las vulnerabilidades corregidas hoy llevan ahí ocultas desde que se usa ese sistema. Por ejemplo, muchas vulnerabilidades que se siguen encontrando en XP puede que estén ahí desde octubre de 2001, cuando fue sacado al mercado.

Las vulnerabilidades son inevitables, tanto en el diseño de programas como de protocolos. En este sentido, el fallo de Kaminsky en los DNS descubierto en 2008 es un buen ejemplo de un fallo de diseño que pasó desapercibido durante decenas de años, aun siendo un estándar completamente abierto aprobado en su teoría e implementado en la práctica por decenas de compañías.

istruecryptauditedyet.com
Poco parece que tenga que ver la eterna discusión sobre el código abierto o cerrado y las ventajas frente a la detección "temprana" de vulnerabilidades. Sin entrar en el aspecto filosófico del uso de software de código abierto, ¿en realidad resulta más sencillo encontrar vulnerabilidades en programas muy complejos de código abierto que en programas muy complejos de código cerrado? Un buen ejemplo es el caso TrueCrypt. Aunque sea de código abierto, sus usuarios necesitamos poder fiarnos totalmente de él, dada su importancia para proteger la confidencialidad. Pero para conseguirlo, se ha precisado de una campaña de recogida de fondos para (entre otras cosas) poder permitirse auditar su código, y premiar a los auditores que encuentren fallos en él. Llevan ya varios meses con el proyecto, y su sueño (porque no es fácil) sería realmente conseguir una auditoría completa de un código tan complejo como es cualquiera que trabaje con criptografía. Otro ejemplo de lo difícil que es auditar (o encontrar errores) en código en general y criptográfico en particular, es el desastre ocurrido en el demonio openSSL de Debian, que eliminó la entropía de creación de claves públicas y privadas en 2006. Nadie lo notó durante dos años.

Todo esto viene a recordar que de esos "miles de ojos" que pueden mirar el código, no son todos igual de efectivos... que algunos programas son más eficaces que el ojo humano, y que el hecho de que se permita mirar el código no significa que todo el mundo lo mire ni lo entienda realmente. El código abierto tiene muchas ventajas (prácticas y teóricas): en programas muy complejos una que sí se aprovecha en la práctica es que permite entender y mitigar (pero quizás no tanto detectar) las vulnerabilidades más rápidamente. Por supuesto, se puede argumentar que, si no fuese código abierto, no se hubiesen encontrado nunca estos fallos. Es posible. Defender uno u otro modelo es un asunto delicado para muchos. Lo que no hay que olvidar en cualquier caso es que auditar código desnudo es una tarea muy compleja que no puede ser delegada exclusivamente a programas. Necesita además del ojo humano, pero no cualquiera... no los "miles de ojos potenciales", sino de "pocos pero reales" que cuentan con gran experiencia, que son buenos programadores, profesionales, que saben interpretar correctamente los resultados de los programas automáticos de auditoría, que disponen de paciencia, tiempo... Y no se dedican todos estos recursos a todos los programas de código abierto (ni cerrado) "mágicamente". De hecho, lamentablemente, encontrar vulnerabilidades es una tarea a la que los atacantes profesionales parecen dedicar mucho más esfuerzo y empeño que cualquier comunidad o auditores y se centran en cualquier programa que les reportes beneficios, independientemente de la filosofía de código.

Sergio de los Santos
ssantos@11paths.com

Arquitectura y cifrado de seguridad en redes 3G

lunes, 13 de enero de 2014

Las redes de telefonía móvil, por su naturaleza radioeléctrica, son tanto o más vulnerables que otras redes de comunicaciones. Con su uso generalizado, garantizar la seguridad en este tipo de redes cobra mayor importancia. El estándar UMTS (Universal Mobile Telecommunications System) de telefonía 3G implementa un esquema de seguridad específico que intenta garantizar la confidencialidad y la integridad de la información enviada a través de la interfaz radio, ya sean datos de usuario o de señalización. ¿Cómo lo hace? Y, sobre todo... ¿lo consigue?

Fundamentalmente usamos hoy en día dos tecnologías:
  • 2G: Que es la combinación de GSM para voz (en Europa, porque en Estados Unidos se puede usar CDMA) y GPRS para datos. Estos estándares pueden ir cifrados o no, pero si lo están, ya se conocen formas de romperlo en un tiempo razonable. Además tiene un problema adicional: en el mundo 2G, el teléfono se autentica contra la torre pero no al revés. Por tanto se pueden "falsificar".
  • 3G: UMTS, del que hablaremos. La estación base (torre) sí se autentica contra el teléfono.
Actualmente, 2G es un desastre porque permite a un atacante suplantar la estación base (la torre) y que el teléfono se conecte a ella sin dudarlo. A todo esto ayuda bastante que los teléfonos "degraden" la conexión a 2G cuando lo necesitan y que uno de los modelos más usados (el iPhone) no permita evitar este comportamiento. Además, un atacante podría montar una estación base por relativamente poco dinero (actualmente, unos pocos miles de euros). El teléfono puede, para ahorrar batería o porque la señal es más fuerte, conectarse a esa estación base falsa que emite en 2G y ofrecer todos sus datos.

Arquitectura UMTS

A grandes rasgos, el sistema UMTS está dividido en dos grandes bloques lógicos:
  • El núcleo de red (Core Network, CN) desempeña labores de control de tráfico, señalización, conmutación y encaminamiento. Además, hace posible la conexión de UMTS con otras redes de comunicaciones. Reutiliza varios elementos ya presentes en la arquitectura 2G y soporta tanto conmutación de paquetes como conmutación de circuitos.
  • La red de acceso radio (UTRAN) se encarga de los aspectos de comunicaciones, tales como la gestión de los recursos radio, el control de potencia y el traspaso de llamadas.  Sus elementos principales son los controladores de red (RNC), que se encargan de gestionar una o varias estaciones base que dan cobertura a los terminales de usuario.

Arquitectura UMTS. Fuente: Wikipedia
Dado que la CN hereda elementos de la arquitectura 2G, es frecuente ver estaciones base GSM y UMTS coexistiendo dentro de una misma red móvil.

Arquitectura de Seguridad UMTS

La arquitectura de seguridad de UMTS está compuesta por un conjunto de características y mecanismos de seguridad. Un mecanismo de seguridad es un elemento que proporciona una característica de seguridad. Y una característica de seguridad es una funcionalidad de un servicio que satisface uno o varios requisitos de seguridad.

Brevemente, en UMTS tenemos cinco grupos de características de seguridad, cada uno orientado a hacer frente a ciertas amenazas y alcanzar determinados objetivos.
  • Seguridad en el acceso a la red (I en la figura): Proporciona acceso seguro a los servicios  y protege contra ataques en el enlace radio.
  • Seguridad en el dominio de red (II): Permite a los nodos del operador de red intercambiar datos de señalización de forma segura, y protege contra ataques en la red cableada.
  • Seguridad en el dominio del usuario (III): Permite a los usuarios disponer de acceso seguro a las estaciones móviles.
  • Seguridad en el dominio de aplicación (IV): Permite que las aplicaciones en el dominio de usuario y en el dominio del proveedor intercambien mensajes de forma segura.
  • Visibilidad y configuración de seguridad: Permite al usuario obtener información sobre las características de seguridad que  se están utilizando.
Arquitectura de seguridad UMTS. Fuente:www.etsi.org
En UMTS, por otra parte, tenemos tres grandes mecanismos de seguridad: el sistema de autenticación y acuerdo de claves; los algoritmos de integridad y confidencialidad; y el cifrado en bloque KASUMI. Los vemos a continuación.

UMTS Authentication and Key Agreement

El UMTS AKA es el mecanismo que gestiona todo el proceso de autenticación, basándose en un protocolo de tipo desafío-respuesta. Son los que se suelen utilizar para que una entidad verifique la identidad de otra sin revelar una clave compartida común.

El proceso UMTS AKA es gestionado por el registro de ubicación de visitante (Visitor Location Register, VLR), y consta de los siguientes pasos:
  1. El VLR envía al Registro de ubicación base (Home Location Register, HLR) del abonado una petición de autenticación.
  2. El HLR computa un conjunto de vectores de autenticación (AV1:AVn) a partir de la clave privada K del usuario (que solo se almacena en la propia USIM y en el HLR/AuC), y lo envía al VLR, que los almacena.
  3. El VLR escoge uno de los vectores de autenticación (AVi), y desafía a la USIM enviándole los campos RAND y AUTN (token de autenticación) del vector seleccionado.
  4. La USIM del usuario procesa el token de autenticación, y mediante su clave privada K puede comprobar que los datos recibidos solo pueden provenir de alguien que tenga acceso a esa clave, por lo que de esta forma la red queda autenticada frente al usuario. La USIM procede entonces a generar una clave de confidencialidad (CK), una clave de integridad (IK), y una respuesta para la red (RES).
  5. La USIM envía la RES al VLR.
  6. Como el VLR conoce el AV, puede computar la respuesta esperada (XRES), y contrastar la RES que recibe con ésta. De esta manera el usuario queda autenticado también. El VLR computa entonces CK e IK a partir del AV.
  7. Las CK e IK establecidas son transmitidas por la USIM y el VLR a las entidades encargadas de las funciones de integridad y cifrado (generalmente el RNC).
Mecanismo de control de integridad

La información de señalización es vital tanto para el usuario como para la red, por lo que es fundamental poder garantizar su integridad (para prevenir, por ejemplo, ataques de falsa estación base). Así, se implementa tanto en la estación móvil como en el RNC el llamado algoritmo f9. El proceso de verificación de integridad es como sigue:
Mecanismo de control de integridad UMTS. Fuente:www.etsi.org
  1. El dispositivo del usuario calcula un código de autenticación de mensaje de 32 bits (MAC-I) a partir de ciertos parámetros de entrada, entre ellos los propios datos y la IK  que se obtuvo en el proceso de autenticación.
  2. El MAC-I calculado se adjunta a los datos de señalización y se envía al controlador de red.
  3. Una vez que el controlador de red recibe la información de señalización con el MAC-I adjunto, calcula, empleando el mismo método que el dispositivo de usuario, el XMAC-I.
  4. La integridad de la información de señalización se comprueba comparando MAC-I y XMAC-I.
Mecanismo de control de confidencialidad

La confidencialidad de la información transmitida es esencial tanto para el usuario como para el operador móvil. De la comprobación de confidencialidad se encarga el denominado algoritmo f8, que funciona de la siguiente manera:
  1. El dispositivo de usuario, a partir de la CK previamente calculada durante la autenticación y otros parámetros, calcula una secuencia de cifrado. 
  2. Se realiza un XOR entre esta secuencia de bits y los datos, obteniendo un bloque de datos cifrados.
  3. Estos datos cifrados se envían a la red a través de la interfaz radio.
  4. El RNC, a partir de los mismos parámetros que el dispositivo de usuario (incluyendo la CK compartida), genera la misma secuencia binaria de cifrado.
  5. Realizando una operación XOR entre esta secuencia y el bloque cifrado recibido, se recuperan los datos originales.
Mecanismo de control de confidencialidad UMTS. Fuente:www.etsi.org
Algoritmo de cifrado por bloque KASUMI

Los algoritmos f8 y f9 de integridad y confidencialidad están basados en el algoritmo KASUMI. Este algoritmo de cifrado por bloque está desarrollado a partir de MISTY-1, y presenta una estructura de Feistel que opera con una clave de 128 bits sobre entradas y salidas de 64 bits.


Estructura Kasumi. Fuente: http://eprint.iacr.org/2010/013.pdf

El algoritmo KASUMI realiza ocho iteraciones o rondas y, para cada una, genera un conjunto de claves de ronda a partir de la clave K de 128 bits. Con esas claves de ronda se computa una función f, diferente para cada ronda. Cada una de estas funciones fi está compuesta por dos subfunciones, FLi y FOi, que dependen de los datos de entrada a esa ronda y de las claves.

Mientras que la función FL es relativamente sencilla (operaciones lógicas y desplazamientos binarios), la función FO presenta internamente una estructura de Feistel propia consistente en tres rondas, para cada una de las cuales se computa una subfunción FI que consta a su vez de otras tres rondas.

Debido a su complejidad, el algoritmo KASUMI ofrece un grado de seguridad elevado. Fue escogido por la 3GPP para la implementación de los algoritmos de confidencialidad e integridad en redes UMTS, además de integrarse posteriormente en las redes 2G. Sin embargo, varios equipos de investigación han intentado romperlo. Ya en 2003 se realizó una primera aproximación, que si bien no rompía el cifrado, lo eludía, haciendo posibles ataques MITM en GSM. Posteriormente, en 2005, investigadores israelíes propusieron un ataque boomerang contra KASUMI, que en realidad no resultaba práctico por su excesiva complejidad, pero comenzaba a medrar la confianza en el algoritmo. Finalmente, en 2010, investigadores del Weizmann Institute of Science de Israel consiguieron romperlo, obteniendo la clave completa en menos de dos horas utilizando un PC de sobremesa (y gracias a una tabla que fue previamente precomputada durante meses). Este ataque, curiosamente, no es efectivo contra el cifrado MISTY-1, que ha probado ser más robusto (pero también más consumidor de recursos) que KASUMI en contra de lo que sostenía inicialmente la 3GPP.

En general, los mecanismos anteriores hacen de UMTS un estándar relativamente seguro para la comunicación. Especialmente la doble autenticación (usuario-red y red-usuario) hace que UMTS sea difícil de vulnerar frente a ataques de hombre en el medio de falsa estación base, mientras perpetrar estos ataques en GSM resulta sencillo. Aunque el cifrado pueda considerarse fácil de romper, obtener el tráfico cifrado a través de ataques MiTM resultaría muy complejo para el atacante.

Las recientes tecnologías 4G, por otra parte, buscan mitigar los problemas de la actual generación. Entre las prestaciones de seguridad de LTE podemos encontrar la reutilización de la autenticación y acuerdo de claves UMTS, nuevos algoritmos para integridad y confidencialidad (SNOW 3G, AES) y una jerarquía de claves más profunda, con claves de hasta 256 bits.

Cristóbal Bordiú
cristobal.bordiu@11paths.com