Modelo de "Acuerdo de Nivel de Privacidad" para Cloud Services

Uno de los principales (y más delicados) aspectos que hay que tener en cuenta a la hora de realizar una la contratación de servicios de Cloud Computing es, sin duda alguna, el acuerdo de servicio que se establece entre el cliente y el proveedor de servicios. En este acuerdo, uno de los factores más críticos e importantes a tener en cuenta es la privacidad y, en concreto, el punto referente a la protección de datos que un proveedor de servicios de Cloud Computing se compromete a mantener con respecto al tratamiento de los datos de carácter personal.

No se debe confundir este tipo de acuerdos con los Acuerdos de Nivel de Servicio, también conocidos por sus siglas en inglés SLA (Service Level Agreement). Estos son usados generalmente para proporcionar métricas y otro tipo de información acerca del rendimiento de los servicios. En concreto, el Acuerdo de Nivel de Privacidad está orientado a suministrar a los clientes actuales y potenciales de servicios Cloud Computing, una herramienta para evaluar y calificar el compromiso del proveedor del servicio en el ámbito de la privacidad. De igual manera, facilita a los proveedores una herramienta para promocionar sus buenas prácticas respecto a la privacidad y a la protección de los datos, volviéndose especialmente interesante sobre todo cuando la información que se va a gestionar no se encuentra dentro de las mismas fronteras de la entidad que va a contratar el servicio con el proveedor.

Para ello la Cloud Security Alliance (CSA), organización de referencia encargada de promover el uso de buenas prácticas para ofrecer garantías de seguridad en Cloud Computing, además de educar sobre los usos de esta tecnología, ha publicado este año un modelo de Acuerdo de Nivel de Privacidad (Privacy Level Agreement, PLA), disponible tanto en inglés como en español, estableciéndose como un estándar de uso para las organizaciones a la hora de regular la privacidad en los servicios que puedan contratarse en la nube. Dentro de este acuerdo se contemplan los objetivos que deben cumplir este tipo de acuerdos, las consideraciones e investigaciones que deben realizarse antes de contratar el servicio y por último el esquema del acuerdo.

El esquema se encarga de contemplar aspectos tan cruciales como:

• La información del proveedor de servicio (denominación, dirección del lugar de establecimiento, representante local en la UE, función asumida en materia de protección de datos, datos de contacto del delegado de protección de datos que atenderá las solicitudes del cliente y datos de contacto del responsable de seguridad de la información).
•  Las categorías de datos personales que el cliente puede o no transmitir o tratar en la nube. 
• Las formas en que los datos serán tratados. Esto abarca desde las tareas llevadas a cabo por iniciativa del proveedor, las que el cliente solicita adicionalmente y las que éste llevará a cabo por cuenta propia. Además incluye temas como subcontratistas, uso de software adicional en el sistema del cliente o la ubicación de los datos personales. Este último aspecto supone una de las principales polémicas de este tipo de servicio. En función de la ubicación donde se encuentren almacenados los datos, una entidad, al estar sujeta a las leyes y regulaciones del país o región donde se ubica y no a donde resida el cliente, se puede ver afectada por leyes y regulaciones diferentes en temas de privacidad y protección de datos. Un claro ejemplo de ley (quizás intrusiva) es la americana USA Patriot ACT.
• Temas relacionados a transferencia y migración de datos transfronterizos ante situaciones de normalidad y emergencia.
• Medidas de seguridad técnicas, físicas y organizativas que se implementarán para la protección de los datos, además de las medidas de seguridad que se implementarán para satisfacer su disponibilidad, integridad y confidencialidad, así como también transparencia, aislamiento, capacidad de intervención, portabilidad y responsabilidad.
• Temas relacionados a la supervisión y monitorización por parte del cliente al proveedor de servicio para verificar que cumple apropiadamente con las medidas de seguridad descritas.
• Auditorías de terceros al proveedor del servicio, y al servicio contratado. También la posibilidad de facilitar al cliente informes, estudios y frecuencia con la que se actualizan.
•  Notificación de violaciones de datos de carácter personal o de la privacidad de la información del cliente.
• Políticas de retención de datos del proveedor del servicio, condiciones para devolver los datos de carácter personal y su destrucción una vez el servicio haya finalizado.
•  Políticas y procedimientos para garantizar el cumplimiento legal del acuerdo por parte del proveedor de servicio, subcontratistas y socios de negocios, así como la cooperación de cada uno de ellos con el cliente para el cumplimiento legal de las disposiciones de protección de datos.
• Procesos para la gestión y respuesta de peticiones de revelación de datos de carácter personal por parte de autoridades.
• Compensaciones en caso de que el proveedor de servicio, subcontratistas y socios de negocios incumplieran las obligaciones descritas en el acuerdo.
• Datos de contacto y procedimiento para preguntas y reclamaciones que el proveedor del servicio o subcontratistas pudieran recibir por parte del cliente.
• Alcance de las pólizas de ciberseguros del proveedor de servicio de Cloud Computing incluyendo seguros relativos a fallos de seguridad.

Este modelo busca contribuir a la generación de confianza y transparencia en la prestación de este tipo de servicios. Pare ello, la Cloud Security Alliance se ha basado en la normativa europea en materia de protección de datos en vigor, además de tener en cuenta las buenas prácticas y recomendaciones de distintas autoridades de protección de datos como el Grupo Europeo de Protección de Datos del Artículo 29 y la Agencia Española de Protección de Datos.

De esta manera, el Acuerdo de Nivel de Privacidad puede ser considerado como una herramienta para reducir las barreras u obstáculos existentes entre clientes y proveedores a la hora de la adquisición de este tipo de servicios.

Umberto Schiavo

umberto.schiavo@11paths.com

Keyloggers y protecciones de credenciales en banca online (y II)

Los keyloggers o registradores de teclas han supuesto un problema de seguridad desde el principio de los tiempos. Todavía son usados y su capacidad para capturar contraseñas sigue siendo muy considerada por atacantes. Más aún cuando los métodos de pago y la banca online son tan populares (y siguen protegidos fundamentalmente por contraseñas y sus variantes). A pesar de su veteranía y de los distintos métodos aplicados para combatir el malware que recoge lo escrito en el teclado, ¿siguen suponiendo un problema? ¿Los hemos superado?

Doble canal

Dando por hecho que el malware campando a sus anchas en un sistema infectado tiene toda la ventaja, las entidades de pago necesitaban un doble canal de autenticación. Los OTP son caros, pero el móvil es ubicuo. Este método se supone muy seguro por definición: habría que infectar los dos dispositivos para que el atacante pudiese realmente conseguir información valiosa. El problema es que Android en estos momentos permite la instalación de cualquier aplicación y, por tanto, resulta sencillo de infectar. El usuario, creyendo que necesita una aplicación para autenticarse, instala también un troyano en su teléfono Android. El atacante registra la información del sistema y la del móvil. Ya dispone de todo lo necesario para robar.

Troyano para Android que reenvía los SMS enviados por la banca online

¿Y por qué no la red?

Tras el breve (e incompleto) resumen descrito, podemos centrarnos en el tráfico de red, un punto interesante. Todo lo que ocurre en pantalla (las pulsaciones del teclado virtual, la introducción de la contraseña con el portapapeles...) al final acaba viajando por la red. Podríamos pensar que es un asunto ya superado, puesto que ¿qué banco no utiliza ya cifrado punto a punto con SSL/TLS que impide el acceso a la información? Pero cuando el malware controla en el sistema operativo y no al revés, tiene acceso a los datos de red a nivel de navegador, antes y después de que sean cifrados. Cualquier troyano medianamente avanzado hoy en día controla, almacena y envía al atacante el tráfico que viaja hacia el banco. Toda labor de ofuscación en la pantalla queda en nada si luego es enviado en texto claro por la red. ¿Cómo se combate esto?

Algunos programadores ofuscan la información. Suelen utilizar funciones JavaScript para "ocultar" la información antes de enviarla a la página que debe validarla. El atacante obtendrá los datos codificados si esnifa la red. Pero como toda seguridad por oscuridad, solo tiene que estudiar el JavaScript de la página y revertirlo para comprobar cómo se ha ofuscado. No es realmente una solución definitiva.

Otros cifran la información que viajará a su vez cifrada por SSL/TLS. Pero hay formas y formas de hacerlo. Cifrar la información con un valor fijo, aunque se utilicen de algoritmos estándar, sigue siendo seguridad por oscuridad, con lo que no es realmente eficaz. La clave de cifrado de la contraseña debe ser variable. Se debe implementar un "desafío-respuesta" entre la web que autentica y el cliente. Por ejemplo, el banco envía una contraseña variable en cada sesión con la que se cifrará (con AES, o DES...) la contraseña introducida por el usuario. Todo esto viajará por la red. Pero entramos en uno de los problemas más antiguos del juego del cifrado: ¿cómo envía el banco a través de un medio inseguro (y de forma cómoda para el usuario) la contraseña "primigenia" con la que cifrar las otras credenciales? Si el atacante está en la red y puede ver el tráfico en texto claro, también podría llegar a conocer la primera contraseña enviada, por muy variable o ofuscada que esté.

Tráfico POST hacia una banca online que envía la contraseña sin ofuscar ni cifrar

Actualmente muchas entidades optan por enviarla en texto claro en el hipotético caso de que implementen un sistema de este tipo. Pero por ahora (y solo por ahora) estas entidades están relativamente a salvo de los troyanos bancarios tradicionales... por una razón curiosa.

El malware tradicional espía la red, pero no puede espiarlo "todo". Ante la cantidad de información que recogen y el número de infectados, deben saber descartar lo que no les vaya a suponer un beneficio inmediato. Así que suelen activarse para recoger la información del tráfico de páginas cifradas (sea cual sea, si va por SSL, es que viaja información sensible) y de formularios en general que estén marcados como "password". Pero... incluso así no suelen recogerlo-robarlo todo. Deben descartar también el tráfico cifrado entrante. Al malware no le interesa robar el tráfico que viene hacia el sistema del usuario, solo el saliente, el que contiene los POSTS con los datos. Así que los ladrones no suelen cazar una hipotética clave "primigenia" con la que cifrar la información y que vendría definida por el banco con el tráfico entrante, por simple economización de recursos y por no incrementar el volumen de datos robados. El banco, por ahora, puede respirar un poco más tranquilo... a menos, eso sí, que los atacantes estudien específicamente estas características y decidan incluirlo en el código del malware.

En resumen, en un sistema infectado, toda medida puede ayudar a mitigar (y solo mitigar) el malware más genérico, y esto convierte a la guerra contra los keyloggers y "sniffers" en una huída hacia adelante en el que solo se está a salvo mientras la contramedida tomada no sea tan popular que los atacantes decidan incluir un ataque específico de serie en su arsenal. ¿Está perdida la guerra? Solo sabemos que se necesita un enfoque de autenticación muy diferente al actual para evitar que tenga éxito.

* Keyloggers y protecciones de credenciales en banca online (I)

Sergio de los Santos

ssantos@11paths.com

@ssantosv

Fallo en la criptografía e implementación Java de las tarjetas SIM permite su clonación remota

Otra interesante presentación en la Black Hat de Las Vegas será la de Karsten Nohl, que demostrará cómo se puede tener total acceso a una tarjeta SIM de varios operados solamente enviando un mensaje SMS y aprovechando fallos de seguridad Java en la implementación del software de la tarjeta SIM.

Las tarjetas SIM pueden ser actualizadas por la operadora a través de SMS. Estos son mensajes cifrados e "invisibles" que interpreta la tarjeta y sirven para enviar órdenes a Java Card, que el software que suelen ejecutar las SIM. Una cadena de errores permite obtener total acceso a los dispositivos:

• El atacante envía un SMS cifrado falsificando el número de la operadora. El teléfono lo interpreta como real e intenta descifrarlo. La falta de autenticación de remitente en los SMS es algo que ya ha traído algún que otro problema a muchos usuarios.
• La tarjeta, como no puede descifrar el mensaje, devuelve por SMS un código de error al atacante, cifrado. Este código devuelto solo se da en un cuarto de los casos de tarjetas estudiadas. El resto ignora el mensaje falso.
• Aunque podían usar AES, o TripleDES, este mensaje cifrado suele estarlo con DES de 56 bits. Algo que puede romper un ordenador corriente hoy en día en cuestión de pocos minutos con ayuda de tablas rainbow.
• Con esta información, el atacante ya puede hacerse pasar totalmente por la operadora y enviar mensajes que la tarjeta interpretará como actualizaciones. El atacante envía entonces instrucciones para que la tarjeta descargue applets con funcionalidades que la Java Card interpretará. Los applets, restringidos en la máquina virtual, ya permiten bastantes acciones en la tarjeta como para que sea preocupante su ejecución.

  

  Fuente: http://www.oracle.com/technetwork/java/javacard/javacard1-139251.html

• Pero obviamente no acaba aquí. También han encontrado que la implementación de la sandbox en la máquina virtual es deficiente en al menos dos grandes fabricantes de SIM, lo que permite salirse y tomar total control del software que controla la tarjeta. Esto significa, "rootkitear" la SIM en sus entrañas, independientemente del teléfono.

En resumen, gracias a esta combinación de errores (básicos y evitables), parece que lo más grave es que (dadas estas circunstancias que dependen de la operadora y el fabricante de la tarjeta) se podría clonar una tarjeta en remoto en cuestión de minutos y solo sabiendo su número, puesto que un atacante tendría capacidad para acceder a toda su información.

Sin embargo, a pesar de la gravedad del problema, no todas las tarjetas son vulnerables. Nohl (que ya ha destapado otros problemas en las tarjetas SIM en años anteriores) afirma que de 1000 tarjetas comprobadas en dos años, solo una de cada cuatro es vulnerable. También concluye que es poco probable que los atacantes reales estén aprovechando este fallo.

Sabremos más detalles en la Black Hat.

Keyloggers y protecciones de credenciales en banca online (I)

Los keyloggers o registradores de teclas han supuesto un problema de seguridad desde el principio de los tiempos. Todavía son usados y su capacidad para capturar contraseñas sigue siendo muy considerada por atacantes. Más aún cuando los métodos de pago y la banca online son tan populares (y siguen protegidos fundamentalmente por contraseñas y sus variantes). A pesar de su veteranía y de los distintos métodos aplicados para combatir el malware que recoge lo escrito en el teclado, ¿siguen suponiendo un problema? ¿Los hemos superado?

Los keyloggers funcionaron en los 90 de una forma sencilla: interceptaban las funciones del sistema operativo que recogían las pulsaciones de teclas. Las escribían en un fichero, se imprimían en pantalla y se le enviaban al atacante. Fueron tremendamente populares y consiguieron robar contraseñas de correo y otros servicios a pesar del cifrado web. A principios de la década pasada, con la explosión de la banca online hubo que combatirlos con ideas más ingeniosas.

Teclados virtuales

Teclado virtual que cambia de posición y reordena las letras

Fue una de las primeras reacciones de la banca contra los keyloggers. Si recogían las pulsaciones de teclado, qué mejor que evitar que el usuario tecleara. Pulsaría sobre una animación en pantalla. Esta medida es ahora casi un estándar en la banca online. Pero pronto supieron eludirla. El malware comenzó a capturar pequeños trozos de pantalla como imágenes alrededor del ratón cuando se hacía "click", que se almacenaban en orden temporal y permitían al atacante saber la secuencia de tecleo en el teclado virtual. La contramedida de los programadores (en aquellos tiempos, bancos brasileños y rusos) fue ocultar las teclas en cuanto se pulsaban. El número era sustituido por un asterisco, y la secuencia que obtendría el atacante entonces sería una serie de imágenes con teclas sin información útil. ¿La reacción de los atacantes? Grabar en vídeo el movimiento de ratón.

Secuencia de imágenes grabada por un troyano ante un teclado virtual

Contraseñas incompletas

Algunos bancos decidieron entonces que con solo dar una parte de la contraseña al banco, bastaba. El atacante no podría obtener la contraseña por completo. Esta medida fue también invalidada. Bien porque el malware podría simplemente esperar varias conexiones hasta completar la contraseña, bien porque podía modificar la página legítima para que realmente pidiera toda la secuencia de números o letras... o coordenadas. Todavía hoy es habitual que phishing y troyanos pidan toda la tarjeta completa. El usuario medio piensa que, a más coordenadas (más contraseñas), más seguridad.

Troyano que modifica una web de banca online para pedir toda la contraseña en vez de solo una parte

Gestores de contraseñas

Para los usuarios más avanzados que se manejan con gran cantidad de contraseñas, los gestores permiten almacenarlas todas de forma segura. Cuando se va a utilizar una contraseña, se hace doble click sobre la deseada y esta queda en el portapapeles esperando a ser pegada en el campo correcto. Pero contra los gestores de contraseñas el malware también sabe qué hacer. Obviamente, caza el contenido del "clipboard" cuando el usuario visita el banco. Esto es menos habitual, pero ocurre.

Pero el juego no acabó aquí. Existían otros vectores de ataque que aprovechar y otras contramedidas que implementar que veremos en la siguiente entrega.

* Keyloggers y protecciones de credenciales en banca online (y II)

Sergio de los Santos

ssantos@11paths.com

@ssantosv

Espiar las comunicaciones móviles por 300 dólares

Tom Ritter y Doug DePerry de iSEC Partners, demostrarán en la Def Con de Las Vegas cómo interceptar el tráfico (voz, datos, mensajes...) de cualquier teléfono móvil Verizon que se encuentre a unos metros de una femtocelda manipulada por ellos. El ataque solo necesita una inversión de 300 dólares en equipamiento. ¿Es realmente insegura la comunicación móvil?

Una periodista entra en una habitación de hotel para hablar con Ritter y DePerry. Sin preparación previa, Ritter le muestra el número de móvil de la chica en la pantalla del portátil. Ella confirma que es el suyo. La periodista realiza una llamada de forma totalmente normal y, minutos después, Ritter le reproduce la grabación de la conversación en el mismo portátil. No importa el modelo de teléfono. ¿Cómo es posible? En realidad, esto ya se ha investigado con anterioridad, pero parece que han perfeccionado el ataque que sea más barato, más sencillo y sobre un operador conocido.

Conceptos previos

Fuente: http://www.pcmag.com/article2/0,2817,2421782,00.asp

Una femtocelda es como un router que te alquila tu compañía telefónica móvil para zonas sin demasiada cobertura. Ofrece cobertura a unos 25 metros a la redonda  y recoge la señal de los teléfonos alrededor. La femtocelda se conecta a internet a través de una línea ADSL (de la propia compañía) y ofrece cobertura móvil en zonas rurales o con difícil acceso, llevando las llamadas a través de Internet. Es un servicio que ofrecen Movistar, Vodafone, Orange...

En resumen, se trata de una pequeña antena telefónica como las que podemos observar en cualquier torre y que ofrece cobertura, solo que personalizada, más pequeña y que va a través de la red. Por ejemplo, nos permite elegir a qué números dar cobertura y a cuáles no, como si pudiésemos dar de alta la MAC de nuestro ordenador en el router Wi-Fi.

Ataques previos

Se conocen muchos ataques contra la telefonía móvil (la compañía española Taddong es experta en el asunto y han ofrecido numerosas demostraciones prácticas). 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. Si podemos hacer la analogía con Wi-Fi, su estado sería más o menos el de WEP. 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: Es el protocolo UMTS. Los datos van también cifrados, pero todavía no se conocen ataques prácticos que permitan romperlo. La estación base (torre) sí se autentica contra el teléfono. Siguiendo con la analogía, se trataría de WPA con Radius.

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. Importante destacar que no podría recibir llamadas a menos que el atacante enrute el tráfico a la red móvil real, algo más complejo. Hoy en día pues, si utilizamos 3G para comunicarnos, los datos pueden mantenerse relativamente seguros por ser un cifrado fuerte y por la autenticación.

¿Cómo lo han hecho y qué diferencia a este ataque de otros?

En este ataque en concreto, parece que han montado una estación base (torre) con una femtocelda manipulada (lo que abarata costes) asociada a un operador conocido. El teléfono de la víctima se conecta a ella y parece que "degrada" a 2G (dicen ser los primeros que han usado CDMA en vez de GSM), para que los atacantes puedan descifrar el tráfico.

Cualquiera podría comprar una femtocelda en eBay y manipularla, pero no le sería útil. Para que funcione, la compañía telefónica tiene que darla de alta y permitir que se comunique con la red móvil a través del ADSL. Así que en la práctica, comprar una femtocelda y que alguien se conecte a ella no le lleva al "mundo real" de las comunicaciones, o sea, no podría llamar. Sin embargo, manipular una femtocelda de una reconocida y popular marca en Estados Unidos y que las víctimas puedan realmente realizar llamadas y transmitir datos, sí parece bastante relevante.

Lo han conseguido pues aprovechando un fallo de seguridad de estas femtoceldas de este operador. No han dado más detalles. Según Verizon ya lo han arreglado, emitiendo un parche para el Linux que llevan dentro todas las femtoceldas. Según Ritter y DePerry, el parche no soluciona del todo el problema.

Será necesario esperar a su presentación en Las Vegas llamada "I Can Hear You Now: Traffic Interception and Remote Mobile Phone Cloning with a Compromised CDMA Femtocell". Mientras, aquí se puede encontrar un vídeo de demostración.

Una mirada técnica (y curiosa) al sistema Authenticode (II)

En esta segunda parte seguiremos viendo cómo se firma realmente un archivo, y la (poca) documentación existente. También comprobaremos que si bien se especifica que sólo se puede usar el algoritmo SHA1 para firmar, no es difícil encontrar ficheros firmados con MD5 e incluso SHA256

¿Cómo calcular el hash Aunthenticode?

Se supone que el hash Authenticode no es más que un SHA-1 selectivo sobre algunas partes del binario. Está documentado (de aquella manera) por Microsoft, sin embargo no hay muchas herramientas que lo calculen y muestren. Existen varias formas de saber el hash Authenticode de un binario. Una fórmula sencilla es mirándolo en el propio código, puesto que está incrustado. Normalmente en el offset 0x85 de la dirección virtual relativa marcada por Security Directory (en la cabecera). Por ejemplo el programa PE Explorer lo toma de ahí para mostrarlo. Por supuesto es modificable... a costa de la validez de la firma. Tomamos de nuevo el ejemplo del binario de Opera. Mirando las cabeceras y haciendo una pequeña suma, sacamos su hash SHA1 Autenticode.

El SHA1 Authenticode incrustado en una dirección relativa y cómo calcularlo

Podemos confirmar que es correcto con otros programas, como PE Explorer.

PE Explorer muestra el hash correctamente. Es más, lo toma directamente del binario de la dirección anteriormente descrita

También se puede calcular con cathash.exe. Esta pequeña herramienta calcula tanto el hash "normal" como el SHA1 de Authenticode especial (sin algunas cabeceras). 

Esta herramienta muestra los dos hashes, el "real" y el de Authenticode

Para implementarlo nosotros mismos, deberíamos usar la función CryptCATAdminCalcHashFromFileHandle de la DLL Wintrust.dll, que devuelve ese SHA1 especial. Pero existe también CryptCATAdminCalcHashFromFileHandle2, que permite especificar qué hash usar: SHA1 o SHA2 (256 bits). Esta función solo es válida en Windows 8 y 2012. Existen por tanto programas ya firmados con SHA2 y lo veremos en las siguiente entrada. Incluso con MD5. El problema con este último algoritmo es que ya se han hecho experimentos para intercambiar la firma entre binarios con colisiones.

¿Se puede "desfirmar" un binario?

Para estos experimentos con colisiones, es necesario "arrancar" la firma de un binario. ¿Se puede eliminar la firma electrónica? Sí. Se han desarrollado varias herramientas sencillas que permiten "desfirmar" un binario. Por ejemplo, delcert.exe. O un script en Python (solo funciona con la rama 2.7) de Didier Stevens mucho más completo que permite otras acciones sobre los ficheros. Eliminar la firma, extraerla, ponérsela a otro binario... etc. El resultado de eliminar una firma no suele ser exactamente igual al fichero original firmado, por una sencilla razón. Estas herramientas que eliminan certificados también machacan las cabeceras. Por ejemplo, ponen a cero la cabecera "Security Directory RVA" (dirección virtual relativa) y elimina el resto de bytes (unos 4k). Dejan el ejecutable "útil" pero no coincidirá exactamente byte por byte con el original. Lo que sí seguirá coincidiendo, lógicamente, es el hash Autenticode. En la siguiente imagen se observa cómo he arrancado el certificado a Opera, (y lo he convertido en Opera15unsig.exe) con la herramienta de Didier.

Se elimina la firma con disitool y luego se calcula el hash Authenticode del original y del sin firmar. Coinciden.

Al pasarle luego la herramienta cathash tanto al original como al nuevo, el hash oficial cambia, pero el hash SHA1 usado para Authenticode, no.

En la siguiente entrega, veremos cuántos ficheros firmados con MD5, SHA1 y SHA256 hay en un Windows XP, 7 y 8, gracias a un pequeño programa que hemos desarrollado.

* Una mirada técnica (y curiosa) al sistema Authenticode (I)
* Una mirada técnica (y curiosa) al sistema Authenticode (y III)

Sergio de los Santos

ssantos@11paths.com

@ssantosv

Una mirada técnica (y curiosa) al sistema Authenticode (I)

Los robos de certificados para firmar ejecutables son muy habituales en los últimos años. Opera, Adobe... incluso la propia Microsoft han sufrido este problema. Certificar un ejecutable es importante para darle veracidad. Si además se consigue certificar robando la identidad a otro, la suplantación de identidad es casi perfecta. Authenticode es la tecnología de Microsoft que comprueba la validez de las firmas de los ficheros. Vamos a estudiarla un poco en profundidad, deteniéndonos en sus curiosidades.

Authenticode es un método integrado en Windows para comprobar la firma de un ejecutable: su integridad y origen. Usa criptografía asimétrica y simétrica estándar, además de certificados. Los binarios son comprobados al vuelo en cuanto se ejecutan en cualquier Windows actual. En Vista además se introdujo un código de colores para dar visualmente una mejor impresión de quién firmaba los archivos y su confianza. Pero todo esto ya está muy visto. Veamos otras curiosidades.

Esquema oficial de Authenticode sacado de sus especificaciones

Utiliza SHA-1... pero no de todo 

Cuando se firma criptográficamente un flujo de datos, normalmente lo que se hace es calcular su hash y firmar el resultado, por simple cuestión de eficiencia. En Authenticode el hash utilizado es habitualmente SHA-1, aunque soporta todavía MD5. En las especificaciones, se puede leer:

This algorithm [MD5] is supported only for backwards-compatibility requirements and should not be used to sign new content.

Pero nada de esto es totalmente cierto. Como veremos en la siguiente entrega, no es raro encontrar ficheros en los que se usa MD5 para firmar su contenido. También hay que aclarar que el SHA-1 calculado no se realiza sobre todos los bits del archivo original, sino que se omiten algunas partes en la cabecera porque luego, una vez firmado, cambiarán. Así que el hash original del fichero antes de la firma no es el hash firmado por Authenticode. Según la documentación oficial:

Hashing the PE Header, omitting the file's checksum and the Certificate Table entry in Optional Header Data Directories 

Demostrarlo es fácil. Por ejemplo según la documentación el checksum de la cabecera de un archivo PE no se usa para calcular el hash que será firmado y comprobado por Autenticode. Si tomamos como ejemplo la última versión del ejecutable de Opera firmado, podemos modificar ese pequeño trozo de binario y seguirá siendo válido a ojos de Windows una vez ejecutado.

Se puede realizar la prueba de forma sencilla. Sobre el fichero original, se modifica el checksum con cualquier programa que permita la modificación de cabeceras. El resultado no altera la firma Authenticode.

Se modifica el valor del checksum en la cabecera con cualquier programa

La firma sigue siendo válida, puesto que se omite ese checksum al calcular el hash

Sin embargo (y evidentemente), cualquier cambio en el binario en sí (por ejemplo la cabecera DOS), hará que se invalide la firma.

Ante cualquier cambio en el binario

Lógicamente la firma queda invalidada

En la siguiente parte veremos cómo calcular específicamente el hash SHA-1 "especial" y otras curiosidades.

* Una mirada técnica (y curiosa) al sistema Authenticode (II)
* Una mirada técnica (y curiosa) al sistema Authenticode (y III)

Sergio de los Santos

ssantos@11paths.com

@ssantosv

El fallo en el proceso de validación de firma de Android, y el foco del miedo

Android.com

La noticia de la semana ha sido el descubrimiento de un fallo en Android que permite eludir la validez del sistema de firma de código. El problema ha trascendido y preocupado especialmente a los usuarios no técnicos, con razón puesto que se trata de un fallo serio. Sin embargo, las razones del miedo generado parecen haber sido otras, puesto que en el anuncio de la vulnerabilidad se ha puesto el foco en ciertas afirmaciones que han "ayudado" a que la vulnerabilidad sea temida por todos pero entendida por pocos.

Los APK de Android están firmados. En teoría esto debería garantizar la integridad del fichero y su procedencia (a quién pertenece el certificado) pero como se permite autofirmar APKs, en realidad la firma solo garantiza que el programa no ha sido alterado después de la firma. En la práctica, sin un sistema de firma más "agresivo", lo cierto es que requerir la firma no ofrece todas las garantías potenciales que ofrece. Lo que ha encontrado una empresa muy reciente de Estados Unidos (Bluebox, fundada el año pasado) es que es posible alterar el contenido de un APK firmado sin que se "rompa" esta firma. El problema no es criptográfico sino que se encuentra en el sistema de validación de firma de Android. No han dado más detalles técnicos.

A partir de aquí, la imaginación se pone en marcha, no sobre el problema en sí (cómo lo han conseguido), sino sobre qué catastrófica situación nos depara. El aspecto más grave, como señala la propia BlueBox, sería alterar un paquete APK firmado por el propio fabricante (que tiene mayores privilegios) y ejecutarlo en el sistema, lo que le otorgaría total acceso al código de un tercero. Una especie de "troyanización perfecta" respetando la integridad del paquete original.

Sin datos técnicos pero sí "estadísticos"

En el anuncio oficial, afirman que avisaron a Google en febrero, pero que no darán datos técnicos hasta la Black Hat de agosto. También hablan de la posibilidad de que el fallo se use para esparcir malware y recurren a los números y periodos grandes, además de porcentajes cercanos a cien para provocar un cóctel perfecto de miedo en el usuario. "El 99% de los Android son vulnerables", "900 millones de dispositivos afectados", "presente desde hace cuatro años". Lo que algunos medios generalistas y usuarios han sintetizado en titulares erróneos es que casi todos los Android "están infectados por un troyano desde hace cuatro años". Este ha sido el efecto de la forma en la que BlueBox, a falta de poder revelar datos técnicos, ha explicado la importancia del fallo (que según ellos mismos, se arregla con dos líneas de código. Samsung ya lo ha hecho en algunos de sus dispositivos).

Porque aunque BlueBox explique el problema de forma correcta y efectivamente se trate de una vulnerabilidad muy relevante, este tipo de información suele ser finalmente malinterpretada. Hablar de número de afectados, porcentajes y fechas, puede eclipsar el resto de la información. Imaginemos que, en el anuncio previo que realiza Microsoft antes de su ciclo de actualizaciones, se hablara de "un grave fallo (o peor aun, "troyano") que afecta al 99% Windows" o "al 85% de los PCs del mundo". Algo cierto, pero de alguna manera irrelevante por implícito, puesto que es lo "habitual" ante cualquier fallo previamente desconocido. Si recurriésemos a las mismas cifras sobre Java, sería aún peor. Cada problema de seguridad en Java (que sí suele ser usado intensamente por atacantes) afecta potencialmente a 3 mil millones de dispositivos, como anuncia la propia Oracle mientras se instala. Si bien las cifras podrían ser ciertas, jugar estas cartas de alguna manera pone el foco en un punto diferente del problema.

Transmitir tranquilidad

Lo que parece más importante es informar sobre que el fallo es sin duda grave y, por lo que se intuye, ha sido un imperdonable descuido de Android en su forma de comprobar las firmas. Sin embargo, es poco probable que esté siendo explotado por atacantes en la actualidad para infectar al usuario medio, por el simple hecho de que no les es necesario recurrir a trucos criptográficos para mantener altos los niveles de infección en Android. ¿Ha sido usado a otro nivel, para realizar espionaje industrial a nivel profesional? No se sabe. Pero para el usuario de "a pie", el atacante dispone de otras técnicas mucho más sencillas que ya le permiten la ejecución de código en el terminal con los permisos adecuados para llevar a cabo sus propósitos.

FaaS: Técnicas de pentester

FaaS (Foca as a Service) es un servicio pensado, diseñado e implementado con el fin de simular y automatizar el pensamiento de un pentester. La intención de FaaS será la de realizar tareas de manera inteligente, buscando el comportamiento adecuado ante las posibles pruebas de auditoría que se irán realizando continuamente. En el instante en que FaaS detecte una situación extraña, vulnerabilidad o error de configuración, lanzará sus acciones con el objetivo de obtener el máximo provecho de cada evidencia, como lo haría un pentester.

Identificación

Se definen estrategias orientadas a la determinación de los aspectos críticos para una empresa que sean accesibles desde el exterior. Aunque se podría determinar esta búsqueda manualmente, será posible iniciar la evaluación automáticamente con solo proporcionar el nombre de los dominios que posee la empresa.

Configuración

Una vez determinados los aspectos que marcan el inicio de la evaluación de seguridad, será posible configurar el proceso completo. Se puede elegir entre qué tipo de clases de análisis serán utilizados para realizar la evaluación. La configuración predeterminada permite al cliente utilizar todas las acciones que un pentester experto recomienda para llevar a cabo el modelo Pentesting by Design, sin embargo se proporciona la posibilidad al cliente de utilizar las clases que él crea conveniente, pudiendo editar la configuración del proceso.

Características: El punto de partida

El punto de partida, como se ha mencionado anteriormente, es el dominio o dominios de la organización a auditar. Otros puntos de partida interesantes son los metadatos que existen en los documentos públicos y los servicios que las organizaciones disponen en Internet accesibles a cualquier usuario.

Tras utilizar alguna de las tres vías de partida que tiene el servicio se obtendrá un gran volumen de datos. Estos serán almacenados para su posterior análisis y explotación en el proceso de pentesting. El sistema generará tareas que auditarán y evaluarán la seguridad de todos los recursos encontrados en Internet pertenecientes a la organización propietaria del dominio. Las fases que el sistema recorre son las siguientes:

• Enumeración de objetos proporcionando un mapa de la organización.
• Análisis de la información pública buscando vulnerabilidades o configuraciones erróneas.
• Explotación de vulnerabilidades para la verificación de fallos de seguridad en los recursos públicos.
• Reporte de información sobre vulnerabilidades reconocidas en el proceso, informe de recomendaciones sobre malas configuraciones o políticas erróneas y creación de mapa de activos con el fin de detectar propiedades que poseen las organizaciones.

El sistema transforma las pruebas en información que le es útil al cliente y puede utilizar para la toma de decisiones el entorno al modelo de seguridad que rige la empresa u organización. Se detalla la vulnerabilidad y la recomendación de seguridad, mediante el uso de un diccionario de vulnerabilidades. También se notifica al usuario cuando las auditorías se encuentran completadas.