Cookies, Supercookies, y otros amigos. ¿Estoy siendo controlado?

Hace unos días volvió a salir a escena un asunto ya difundido hace casi ya un año, allá por octubre de 2014: El seguimiento que algunos proveedores de Internet y/o operadoras de telefonía móvil estaban haciendo de sus clientes. El caso se dio a conocer con Verizon y sus «perma-cookies» (http://www.wired.com/2014/10/verizons-perma-cookie/).

Aunque no hace mucho que se lleva hablando de esta forma de identificar usuarios y observarlos, todo parece indicar que no es algo novedoso.

Privacidad en Internet. Cookies

Las cookies han sido y son un método común para recoger información de los navegadores y con ello, del usuario que hay detrás. Como siempre, el principal interés es ganar dinero y se trata de obtener cuanta más información mejor, sobre los patrones de comportamiento de una persona para después explotarla convenientemente comercialmente. Lógicamente además de los intereses puramente económicos existen otros con distintos objetivos (políticos, sociales, etc).

¿Que es una cookie? Pues simplemente un «fichero» que se almacena en el navegador del ordenador o dispositivo del usuario y que servirá para obtener información e identificar al navegante al acceder a sitios web. Esto unido a la ejecución de scripts, generalmente javascript o archivos flash, se consigue procesar y recuperar muchísima información. Visítese por ejemplo en enlace de una editorial (elmundo.es) para consultar su política de cookies y enterarse de quienes y con qué objetivo hacen uso de ellas.

cookies

– Las cookies, un elemento común para gestión de información en navegadores web –

Este abuso de la privacidad del internauta ha llevado a la aparición de «leyes reguladoras» para tratar acotar el uso de las cookies o al menos, pretenderlo. Aquí en España la Agencia Española de Protección de Datos publicó la Guía sobre  Cookies  para ofrecer orientaciones sobre cómo cumplir con las obligaciones previstas en el apartado segundo del artículo 22 de la Ley 34/2002, de servicios de la sociedad de la información y de comercio electrónico (LSSI). Esta normativa sobre cookies se inició en 2012 y ha pasado por varias revisiones y adaptaciones, la última en 2014.

¿Supercookies? Cookies on steroids

Con las cookies tradicionales, el usuario tiene cierto control sobre su uso ya que, en cualquier momento puede decidir limpiarlas de su navegador y eliminar los rastros tanto de cookies como de archivos cacheados. No obstante la aparición de nuevas tecnologías como HSTS han sido aprovechadas para hacer más persistente el almacenamiento de información de modo que la limpieza de caché y cookies no basten para eliminar los rastros identificadores. Esto se ha pasado a denominar «supercookies» (vaya manía de poner nombre a todo) y como decimos, utilizando HSTS y los flags asociados como max-age (véase artículo sobre HSTS) se consigue, en ocasiones, el ansiado objetivo de la persistencia.

Un demostración de persistencia via HSTS podemos encontrarla aquí:  http://www.radicalresearch.co.uk/lab/hstssupercookies

 

Éramos pocos y…. vinieron las operadoras

Recientes resultados arrojados de los estudios de la iniciativa accessnow.org para la libertad digital , han demostrado que las cookies e incluso las supercookies se quedan atrás en cuanto a lo que identificación y seguimiento de usuarios se refiere.

 

En el estudio realizado a través de http://amibeingtracked.com/ se demuestra como, en concreto las operadoras de telefonía móvil nos identifican y seguramente, nos observan. En este caso el método es aún más eficaz, ya que no se almacena nada en el dispositivo del cliente y por lo tanto es imposible evitar ser identificados limpiando caché o cookies. ¿Como lo hacen?. Utilizando el poder que les confiere ser nuestro proveedor de acceso a Internet.

- Operadoras móviles y privacidad -

– Operadoras móviles y privacidad –

Cabeceras HTTP

Del estudio se concluye que se están haciendo uso del protocolo http para inyectar una o más cabeceras que identifiquen al usuario al acceder a un sitio web. Para ello la operadora intercepta la solicitud http del cliente y contando con sus datos de acceso a Internet que ella misma proporciona crea unos identificadores para el usuario. Estos identificadores se usarán para crear un perfil donde la operadora irá almacenando toda la información de navegación y patrones de comportamiento del cliente. En el caso que de alguna empresa interesada solicite a la operadora información sobre clientes (seguramente tras un jugoso pago), la operadora se encargará de inyectar cabeceras http que de información del cliente que está visitando el sitio. Una vez identificado, y con la información recopilada, el sito web se encargará de dar un «tratamiento especial» al visitante.

Prueba de concepto

Tras leer el estudio The Rise of Mobile TrackingHeaders: How Telcos Around the World Are Threatening Your Privacy  y visitar la página de demostración http://amibeingtracked.com/ me picó la curiosidad de saber qué cabeceras estaba inyectando mi operadora.

Para averigurarlo, escribí una página web muy simple con un pequeño script en php para recoger las cabeceras y comprobar que sucedía. Basta con acceder a la página desde tu dispositivo  utilizando tu red de datos móviles:

 

cabeceras http movistar

– Inspección de cabeceras HTTP utilizando una conexión de datos móvil con Movistar –

 

 

Vaya, resulta que tenemos un par de cabeceras http ( X-Up-Subno y Tm-User-Id) que no resultan especialmente tranquilizadoras. ¿Es necesario que la operadora inserte estos identificadores del cliente en su tráfico? ¿porqué no se informa al usuario?. ¿Cual es el objetivo?

Tests de inyección

Puedes probar tu mismo el resultado con tu operadora, accediendo al test que hemos preparado. Ojo! Utiliza una conexión de datos móvil (3g, 4g, etc):

—>  Test de inyección html  (básico, by securityinside.info)

—> Test de inyección de accessnow.org

 

Uso y abuso de identificadores

Lógicamente las operadoras defenderan que su uso es legítimo y únicamente con intenciones de monitorización del servicio, pero cuando menos, resulta sospechosillo. Googleando un poco y buscando información sobre esas cabeceras llegamos al punto de partida: Verizon y sus métodos, como podemos leer en este artículo: https://www.eff.org/deeplinks/2014/11/verizon-x-uidh.

Como se sugiere en el estudio anteriormente referenciado, es muy probable que, sin consentimiento del usuario se estén almacenado perfiles y patrones de comportamiento con objeto de monetizarlo a través de su distribución para campañas de marketing o ventas personalizadas.

En este ejemplo, un supuesto cliente «Kavita» accede a la red móvil para consultar un sitio web (privacybegone.com) y su operadora manipula la petición con la inyección de cabeceras:

- Ejemplo de funcionamiento de inyección de cabeceras http -

– Ejemplo de funcionamiento de inyección de cabeceras http. FUENTE: accessnow.org –

La compañía privacybegone.com, a través de las cabeceras identifica al usuario y le ofrece unos contenidos «personalizados»:

- Uso de las cabeceras para identificar al usuario . FUENTE: accessnow.org -

– Uso de las cabeceras para identificar al usuario . FUENTE: accessnow.org –

¿Que puedo hacer?

Pues frente a la manipulación de cabeceras por parte de tu ISP u operadora móvil, bastante poco, por no decir nada. No servirán las opciones de navegación de incógnito, ni el Do Not Track,  ni limpiar cache. Es algo que sucede una vez las comunicaciones han abandonado nuestro dispositivo y donde ya no tenemos control.

La inyección de cabeceras solo funcionarán en comunicaciones http, y no será posible su inclusión en comunicaciones bajo ssl (https). Desafortunadamente aún son muy numerosos los sitios que que utilizan http.

Seguramente, esto es solo la punta del iceberg. Hoy en día la privacidad en Internet es algo más difícil de mantener.

Sigue #Windows10 heredando el mismo REGEDIT ¿?

Hola a todos, recientemente Microsoft ha lanzado su nuevo sistema operativo de escritorio bajo el nombre de “Windows 10” e invita a todas las personas con sistemas operativos Windows XP, Windows 7, Windows 8 y Windows 8.1 a descargarlo gratuitamente bajo la única condición de tener una licencia legal http://www.microsoft.com/es-es/windows/windows-10-upgrade

 

Aunque se ha rumorado por allí que hay equipo “no legales” que están recibiendo igualmente la actualización.

 

En este sentido y viendo curiosamente una idea que se ha ocurrido es ver si el famoso REGEDIT sigue teniendo la misma estructura de código que viene arrastrando desde Windows 7.

 

El REGEDIT es el corazón del sistema operativo de Windows y no son muchos los administradores de sistemas y CISO que toman las medidas necesarias para que los usuarios comunes o delincuentes informáticos entren en el y realicen algunas travesuras como eliminar programas, cambiar las fuentes al sistema, corromper el sistema operativo etc. etc.….. hay que reconocer que dentro de nuestro grupo PIRULETO HACKING TEAM ya se ha realizado una travesura “sana” en algún Kiosco digital.

 

Ahora a ponernos manos a la obra.

 

En este ejemplo vamos a ver si la clave RUN, que es la que permite ejecutar programas apenas iniciar Windows (el malware le encanta esta llave de registro) sigue estando en el mismo sitio en los diferentes sistemas operativos arrancando desde Windows 7, luego Windows 8.1 y finalmente Windows 10.

 

Como siempre he dicho una imagen vale mas que mil palabras:

 

Advertencia: Tocar el REGEDIT es muy peligroso sino tienes conocimientos técnicos ni se te ocurra tocarlo.

 

Windows 7

2015-08-20_19-09-55Figura 1. Menú de Inicio de Windows 7

2015-08-20_19-11-02Figura 2. Registro de Windows 7

Windows 8.1

2015-08-20_19-13-39Figura 3. Búsqueda de Registro en Windows 8.1

2015-08-20_19-14-42Figura 4. Registro de Windows 8.1

Windows 10

2015-08-20_19-18-15Figura 5. Menú de Inicio de Windows 10

2015-08-20_19-19-56Figura 6. Registro de Windows 10

Como podemos ver y concluir sigue teniendo el mismo formato lo que nos hace deducir por ende que seguimos con el mismo REGEDIT heredado desde Windows 7.

Comprensible que realizar un cambio de arquitectura de software es muy costoso y se sigue una misma estructura para facilitar las migraciones de versiones y programas pero, en mi opinión se puede mejorar a medida que se evoluciona el sistema operativo esto con respecto al REGEDIT que como hemos visto no ha cambiado nada.

Medidas preventivas para evitar que nos modifiquen el REGEDIT.

  • No dar privilegios administrativos a los usuarios de nuestra red corporativa
  • Desplegar políticas de seguridad a través de nuestro directorio activo vía Group Policies Management Console GMPC https://technet.microsoft.com/es-es/library/Cc754948(v=WS.10).aspx
  • Utilizar software de terceros para proteger cambios en nuestro REGEDIT
  • Utilizar sistemas de alertas e intrusión en nuestros sistemas operativos que detecten cambios en el REGEDIT

 

Hasta una próxima……..

Amenaza Silenciosa I

Cuando trabajo cazando malware, una de las cosas que suelen cantar a la hora de encontrar artefactos maliciosos es la aparición de ejecutables extraños en los sistemas de persistencia más comunes, como, por ejemplo, en algunas claves de registro. Un día me pregunté, ¿es posible generar una amenaza silenciosa, que no cante mucho en los sistemas de persistencia, sin utilizar técnicas extrañas? Veamos como de fácil o difícil sería.

Dridex

No es la primera vez que hablo de temas relacionados con Dridex en este blog. En este caso lo hablaré de su mecanismo de persistencia. Es un sistema simple pero efectivo que da muchos dolores de cabeza a los administradores de sistemas a la hora de eliminarlo de una red.
Una vez infectado con Dridex, al ejecutarse, este se inyecta en el proceso Explorer.exe y se borra del sistema. Pero, ¿cómo logra entonces persistir?
Cuando Dridex detecta que Windows se va a cerrar se escribe a si mismo con la estructura <nombre aleatorio>.TMP y añade a la clave de registro HKEY_CURRENT_USER\ Software\Microsoft\Windows\CurrentVersion\Run el valor:

"rundll32.exe C:\DOCUME~1\\APPLIC~1\.tmp NfInitialize"

Cuando se vuelve a ejecutar el reiniciar el sistema, el fichero .TMP se vuelve a borrar y la clave del registro desaparece.
Esto no sólo hace su detección muy complicada, ya que la mayoría de los antivirus funcionan analizando los ficheros en disco y los que analizan la memoria no analizan todas la páginas, si no que la manera más fácil y barata de desinfectar las maquinas es desenchufándolas y quitándoles la batería si son ordenadores portátiles, lo cual complica la desinfección. ¿Os imagináis que gracia le hará al que le toque ir desenchufando dos mil ordenadores?
Sin utilizar ninguna técnica nueva, esto consigue que la detección en base a la aparición de artefactos sospechosos en sistemas de persistencia de la que hablaba en la introducción sea imposible una vez Windows ha arrancado: ni vamos a encontrar un ejecutable en %TMP% o %APPDATA% , ni vamos a ver nada en las claves del registro.

Alternate Data Streams

Alternate Data Stream (ADS) es una característica de NTFS en principio diseñada para almacenar información sobre un ficheros sin tener que utilizar otros ficheros. Estos metadatos se escriben en el disco duro a continuación de los datos del fichero.
Si miramos un registro de la Master File Table (MFT) de NTFS, se puede ver la diferencia entre un fichero sin ADS y uno con ADS.
Registro de fichero en MFT:
Screen Shot 2015-08-12 at 10.44.54 PM
Registro de fichero en MFT con ADS:
Screen Shot 2015-08-12 at 10.44.38 PM

Images extraídas del documento: Alternate Data Streams: Out of the Shadows and into the Light de Ryan L. Means (2003).

Como se puede ver, en el registro con ADS aparece un segundo stream de datos después de los datos del fichero.
En el pasado se han utilizado ADS para ocultar malware y ejecutarlo desde ahí.
Con la llegada de Windows 7, Microsoft deshabilitó la posibilidad de ejecutar directamente nada que estuviera almacenado en ADS. Aun así, hay formas indirectas de ejecutar estos binarios.

Infección de ficheros

Una de las cosas que me lleva a escribir esta serie de artículos es la siguiente hipótesis: ¿y si en lugar de añadir un nuevo binario a cualquiera de los sistemas de persistencia infectamos un binario que ya esté en uno de estos mecanismos?
Es decir, aprovechando la estructura de los ficheros PE, ¿puedo inyectar mi programa en un ejecutable que previamente he detectado que persiste?
La respuesta es, en principio, que sí, puedo. La realidad es que no sé cual será la dificultad de realizar esto en sistemas operativos modernos, pero lo que sí que sé es que en muchos proyectos de “compromise discovery” * pasaría desapercibido.

Objetivos

Este post es sólo la introducción a un viaje en el que sólo he empezado a dar los primeros pasos en el que voy a tratar de replicar las técnicas comentadas en el post y del que espero volver con los siguientes resultados:

  • Aumentar mi conocimiento de inyección de procesos en Windows.
  • Mejorar y terminar de comprender cómo funcionan el hooking de funciones en Windows.
  • Conocimiento profundo de los diferentes métodos de persistencia en sistemas Windows.
  • Comprender el sistema de ficheros NTFS.
  • Ver como funciona la infección de ficheros a nivel práctico.
  • Aplicación de las técnicas clásicas de infección en un entorno moderno.
  • Profundizar en la API de Windows.

¿Qué puede esperar el lector?

  • Un montón de referencias y enlaces a recursos que utilice.
  • Pruebas de concepto (al menos de las partes relevantes).
  • Los resultados explicados tan bien como pueda.
  • Largas esperas y poca periodicidad :P.

Mientras sigo pasito a pasito, ¿se os ocurre alguna otra técnica o forma de hacer que un bicho pase desapercibido y se me haya pasado?

* Compromise discovery es el nombre que reciben los proyectos en los que un equipo con conocimiento en respuesta ante incidentes se presenta en una compañía, toma un “snapshot” de los sistemas de la compañía y analiza esa información en busca de evidencias de compromiso.

auditoria-de-codigo

Auditoría de código: algo necesario pero que nunca hacemos (parte 1)

A lo largo de varias publicaciones, vamos a adentrarnos en el mundo de la auditoría de código para ver lo importante que es tener cierto control de lo que se hace para poder construir nuestro software de la forma más segura posible.

Una pequeña (bueno, no tanto) introducción

En el mundo de la seguridad de la información, como en todo, hay ciertos elementos más importantes que otros y que impactan de lleno sobre la posibilidad o no de que algo ocurra.

El usuario es un actor principal dentro de este mundo. Lo que yo llamo la “constante de inutilidad” (capacidad para cometer errores con los que decir “joer, qué inútil soy!”) de las personas es un factor vital para la seguridad global de un sistema, ya que si ponemos cientos de medidas pero el usuario publica la contraseña maestra en Facebook, estamos perdidos…

Todos tenemos un torpe en nuestro interior que nos empuja a cometer fallos, a despistarnos, a relajarnos y a dejar pasar cosas de forma inconsciente y (más a menudo de lo esperado) totalmente consciente.

Esto mismo se puede llevar al mundo del desarrollo de software. Cada vez que nos ponemos el mono de desarrolladores y comenzamos a picar código, podemos cometer una serie de errores o seguir patrones “desaconsejables” que pueden hacer que nuestro resultado sea totalmente vulnerable.

La evolución del código fuente

A lo largo de las últimas décadas, el desarrollo de software ha crecido exponencialmente. El uso de nuevas tecnologías en un mundo cada vez más conectado ha creado una gran dependencia de software que gestione y coordine todo.

Cuando comencé en esto de la informática, me dedicaba a escribir en BASIC programas de decenas de líneas, incluso me atrevía a hacer cosas con cientos de líneas que luego grababa en cinta.

Hoy en día, cualquier desarrollo sencillo se nos va a los miles y crece de forma increíble si hablamos de grandes funcionalidades. Mira, por ejemplo, cómo van creciendo las cifras conforme hablamos de software (loc = lines of code):

100.000 loc

Photoshop 1.0

2.500.000 loc

Windows 3.1

9.500.000 loc

Firefox 38

40.000.000 loc

Windows 7

61.000.000 loc

Facebook

 

¿Y esto en qué nos afecta?

Lógicamente, cuanto mayor es algo que hacemos, más probabilidad de fallo hay en su interior. Este tipo de soluciones software se desarrollan por grandes equipos de personas que cuentan con peculiaridades, manías y constantes de inutilidad diferentes.

En este escenario aparecen siempre fallos, problemas, descuidos que harán que ese software sea vulnerable, poniendo en peligro a la organización, empresa o usuario que lo utiliza.

Ahorra mientras solucionas

Generalmente se suele ver “desde arriba” que los procesos de auditoría de código son una pérdida de tiempo y que si surge un fallo, ya se arreglará. La verdad es más cruda, arreglar fallos se vuelve más y más caro cuanto más avanza el desarrollo.

Solucionar, mitigar o eliminar posibilidades de fallo es sencillo y barato en el momento del diseño. Hacerlo cuando hay varios millones de líneas y cientos de usuarios haciendo uso del software se puede volver inmensamente complejo y costoso.

Entonces la pregunta que surge es directa, ¿cuándo se debe hacer una auditoría de código? El momento óptimo ocurre cuando estamos alrededor del 70% del desarrollo de cada versión funcional y sobre un proyecto que podamos compilar.

¡Pero mucho ojo!, hay que buscar equilibrio entre el desarrollo y el auditor, el objetivo es mejorar, no entorpecer.

¿Manos a la obra?

En esta entrada sólo queríamos hacer una introducción al proceso de auditoría de código para ir avanzando en las siguientes entradas. Si te parece interesante lo que hemos empezado a contar, no dudes en pasarte por aquí para entrar en detalle.

¡Te esperamos!