HPKP: Cuando una medida de seguridad deja de ayudar

Suelo explicar muchas veces en qué consiste la fortificación de un sistema de una manera que pretende ser didáctica. Se reduce a las reglas de aplicación de configuraciones y medidas de seguridad de cualquier servicio en el ejercicio de su rol para ponérselo complicado a cualquier atacante y siempre las contamos de manera sencilla.

Figura 1: HKPK: Cuando una medida de seguridad deja de ayudar

La primera de ellas es Mínima Superficie de Exposición, la segunda Mínimo Privilegio Posible, y la tercera Defensa en Profundidad. Es decir, debemos ejecutar solo el código (y/o los programas que son estrictamente necesarios para la ejecución de su rol. Todos los componentes deben tener el mínimo de permisos necesarios para que si un componente caiga el atacante obtenga el mínimo privilegio del sistema, y se deben aplicar todas las medidas de seguridad por capas que sean posibles asumiendo que las medidas de seguridad anteriores han caído, siempre y cuando una medida de seguridad no anule a otra.

Figura 2: Conferencia sobre gestión de la seguridad informática

Es esta parte en la que "una de seguridad no anule a otra" la que a veces hay que explicar un poco más, y para que la gente lo entienda suelo hablar del uso de NIDS (Sistemas de Detección de Intrusiones en Red) e IPSEC o del uso de WAFS (Web Application Firewalls) y Certificate Pinning. Es decir, cifrar ayuda a prevenir ataques, pero elimina posibilidades a los sistemas de detección de ataques. Una medida da privacidad sobre otra. Sí, por supuesto que se pueden utilizar escenarios más complejos para garantizar que se cumplen las funciones de prevención y detección, pero seguramente necesitemos nuevas tecnologías de seguridad o transformar las medidas que ya tenemos.

Este es el caso del pinning de certificados. Hubo un tiempo en el que las técnicas de Certificate Pinning, es decir, la fijación de un certificado digital en el end-point controlado y utilizado por el servidor se vio como una manera de fortificar la comunicación entre el cliente y el servidor. La idea es simple y poderosa, ya que consiste en decirle al cliente "éste es mi certificado digital y solo éste", si alguien quiere comunicarse contigo con otro certificado digital, ignóralo. Fantástico. Ya no hay alertas, ya no hay forma de que un atacante haciendo un ataque de red en IPv4 o IPv6 pueda meterse en medio de la comunicación. Todo son ventajas. O eso parecía.

Figura 3: Ataques en redes de datos IPv4&IPv6 (3ª edición)
En este libro explico los ataques mitm en IPv6 de Bridging

La realidad es que aplicar HKPK (HTTPS Public Key Pinning) a las opciones de las HTTP Security Headers de los servicios web trajo también un buen montón de problemas que ha hecho que al final los principales navegadores de Internet hayan optado por no soportarla y hacer que HKPK pase al olvido de las medidas de seguridad.

Nosotros, que hemos escrito mucho en el blog de ElevenPaths de Certificate Pinning, de HSTS, HKPK y Certificate Transparency, que son tecnologías complementarias y superpuestas que han ido intentando mitigar el programa del acceso y la manipulación de la información entre un cliente y un servidor. Incluso hemos sacado herramientas como PinPatrol para revisar la configuración de certificados que han llegado vía HSTS y HKPK a tu Firefox, y por supuesto lo hemos aplicado en muchos sitios. Y os garantizo que también hemos sufrido inconveniencias con el pinneo de los certificados, la gestión de la caducidad y la actualización de los certificados digitales por culpa de fallos de seguridad que han aparecido en ellos, etcétera, lo que ha llevado a que tuviéramos serios debates sobre la conveniencia  o no de pinnear los certificados.

De hecho se acuñó un término que se llama HKPK Suicide, que consiste en desplegar y pinnear en clientes un certificado digital y luego perder, por un problema de gestión o seguridad - por ejemplo un ransomware que cifra los archivos del servidor - el acceso al certificado digital, con lo que la conexión con ese dominio se ha perdido para siempre - hasta que caduquen los certificados en cliente - y no hay mucho que hacer.

Figura 4: HPKP Suicide

Por supuesto, no solo por error, un atacante que consigue control de una aplicación web puede inyectar las cabeceras HTTP de seguridad y hacer que se envíe a los clientes el pinneo de un certificado que no existe durante un tiempo enorme, lo que imposibilitaría que hubiera conexión entre el cliente y el servidor. Esto, que se llamó Ransom PKP haría que dejaran de funcionar las conexiones y que solo reinstalando los clientes se pudieran volver a recuperar.

Figura 5: Ransom PKP

Este tipo de ataques se pueden encontrar no solo en entornos en los que se haga un control total del servidor, sino que si aparece una vulnerabilidad de HTTP Header Injection en la aplicación web, se podrían llegar a hacer uso de las cabeceras HSTS o HKPK para hacer exactamente lo mismo. De hecho, algunas variables como max-age que se utiliza para definir el tiempo de vida del pinneo de un certificado digital en el navegador, se han ido limitando para que el ataque no durase años y se limitara solo a un par de meses como mucho.

Figura 6: Hacking Web Technologies

A este tipo de problemas hay que sumar que HSTS con HKPK a veces no ha servido para resolver los problemas, y vimos como aparecían problemas como Delorean que permitían caducar los certificados del almacén de HKPK, o que si eras capaz de interceptar la primera petición HTTP de un cliente a un servidor que utiliza HSTS y HKPK pero que su certificado no viene cargado en el almacén del navegador web del cliente, se podía hacer un ataque de Bridging HTTP-HTTPS, como el que hicimos nosotros entre IPv4&IPv6.

Pero es que además, hemos visto que el uso de HKPK también ha tenido sus contrapartidas. El hacer uso de HSTS ha permitido la aparición de las famosas SuperCookies para espiar a los clientes y romper su validación, además de poder hacer un listado de los sitios web a los que navega un cliente con un sencillo ataque de Time-Based Web Browsing, para medir los tiempos que tarda en ir a un sitio web dependiendo de si tiene ya guardado el certificado digital de ese sitio o no en el almacén HKPK.

Figura 7: HSTS Supercookies

En definitiva, para conseguir mitigar un problema de seguridad hemos ido generando tecnología. Primero HTTPS para poner una capa de seguridad con un túnel SSL a las conexiones HTTP. Luego nos dimos cuenta de que podían eludir el tráfico HTTPs forzando tráfico HTTP, y creamos HSTS (HTTP Strict Transport Protocol), pero nos dimos cuenta de que una navegación HTTPS no tenía porque significar una navegación HTTPS contra el servidor correcto porque se podían utilizar certificados digitales controlados por el atacante y que no dieran alertas, así que creamos el Certificate Pinning y HPKP (HTTP Public Key Pinning) para usar solo "éste" certificado. Y al final tenemos dudas de si hemos generado más problemas de seguridad, privacidad, disponibilidad, y gestión de los que hemos resuelto con esta aproximación, por lo que HKPK desaparece de los navegadores.

Toda esta historia nos tiene que hacer reflexionar sobre la importancia de debatir y analizar correctamente una nueva medida de seguridad en Internet, y del valor de todos los investigadores y hackers que han ido estudiando los límites de las implementaciones que se han hecho. Por un lado tengo la sensación de ver como fracasa una medida de seguridad, por otro lado tengo la sensación de ver cómo avanza la ciencia gracias a todos los que constantemente están buscando los límites de las nuevas tecnologías.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Seguir con Google la pista a Documentos PDF por los datos de su Certificado Digital

La firma digital que se pone en un documento lleva implícitos los datos del firmante que iban en el certificado digital que se utilizó. Estos datos pueden ser, por supuesto, los datos de un DNIe, que se haya utilizado para dicho menester, o los que aparecen en un certificado emitido por la FNMT para la interacción con la administración pública.

Figura 1: Seguir con Google la pista a Documentos PDF por los datos de su Certificado Digital

No hay mucho misterio más que los datos de la firma digital que se estampa en un documento PDF se pueden leer en claro, y aunque muchos de los visores de documentos PDF no avisan de que el documento lleva una firma digital, Google sí indexa esa información - tal y como me indicó mi amigo rootkit, que tanto disfruta del Hacking con Buscadores -, por lo que se puede utilizar como parámetro de búsqueda.

Figura 2: Documentos firmados del Department Of Defence de USA

Esto permite, por ejemplo, que una organización pueda localizar donde han sido publicados - e indexados - documentos que hayan sido firmados digitalmente con sus certificados.

Figura 3: Documentos firmados por un empleado del DoD

Pero también puede ser un leak de información no deseado, sobre todo por la cantidad de datos personales que acompañan a cualquier certificado digital emitido a una persona particular, como por los que sabemos que hay en certificados digitales tan populares como el del DNIe o la FNMT.

Figura 4: Documentos con certificados digitales de la NASA

Así que, con unas sencillas búsquedas en Google puedes saber si algún documento PDF que hayas firmado digitalmente ha sido publicado en la red y está emitiendo datos personales tuyos que no deseas. 

Figura 5: Documentos públicos en la red con firmas digitales de certificados FNMT

Por supuesto, la búsqueda por campos de los certificados digitales afectará a todo documento que almacene en formato de texto plano - o incluso en metadatos - los datos del certificado digital, así que no solo tienen que ser certificados digitales en documentos PDF.

Saludos Malignos!

Meterpreter Paranoid Mode: Conexión segura en tu payload #metasploit

Recientemente he estado probando este script de bash llamado Meterpreter Paranoid Mode. La idea del autor de este script, seguramente, venga de este artículo de Rapid 7 sobre cómo de paranoicos podemos volvernos a la hora de configurar un Meterpreter. Sin duda, es un tema interesante, ya que los payloads que manejamos manejan, al final, información importante. Evitar que nos detecten por la evaluación de la comunicación mediante el cifrado de ésta, es algo que, en algunos entornos, puede ser fundamental. Eso sí, a nosotros nos ha llamado la atención el nombre por nuestro querido WordPress in Paranoid Mode.

Figura 1: Meterpreter Paranoid Mode

Meterpreter Paranoid Mode permite a los usuarios fortificar los staged/stageless de las conexiones de Meterpreter, teniendo que chequear para ello un certificado. La idea es sencilla: el script crea un certificado en formato PEM, el cual será utilizado para validar la conexión. Para tener la conexión validada, el handler al que se conecta el payload, debe disponer de acceso al certificado PEM. Además, se tendrá que tener habilitado el chequeo de este certificado, con la opción stagerverifysslcert a TRUE, dentro de los parámetros de Meterpreter avanzados. Esto lo veremos más adelante.

Figura 2: Meterpreter in Paranoid Mode

Una vez que el payload es creado por el script, mediante la herramienta msfvenom a bajo nivel, se debe configurar el handler para crear la conexión utilizando el certificado PEM. Se utilizará un hash SHA1 para la validación. Este es el resumen de la idea, de todo lo que automatiza el script Meterpreter in Paranoid Mode.

Figura 3: Meterpreter Paranoid Mode

Al ejecutar el script, éste solicita la creación de un certificado o importación de éste. Para hacerlo sencillo, se puede 'impersonar' un dominio. Para este ejemplo, se ha utilizado el dominio de Google. El script proporciona algunos pop-ups a la hora de poder seleccionar opciones, lo hace mucho más sencillo de utilizar por parte del usuario.

Figura 4: Creación de un certificado para un dominio suplantado

Una vez que rellenamos la opción del dominio y se lleva a cabo la 'suplantación' del dominio, se genera un nuevo certificado en formato PEM, el cual es almacenado en el directorio output. Más tarde, veremos detalles de dicho certificado almacenado. Lo que hay que entender es que es ese certificado el que será utilizado por el handler para validar la conexión segura con nuestro Meterpreter.

Ahora, nos toca elegir si vamos a utilizar un staged o un stageless. La herramienta nos dará dos opciones, la primera nos generará un .bat, mientras que la segunda nos generará un .exe. En este artículo se ve la perspectiva y diferencias entre un staged y un stageless. Es una lectura totalmente recomendada.

Figura 5: Staged payload

Una vez seleccionado el tipo de stage, se debe indicar el tipo de payload que se quiere utilizar. Para este ejemplo, hemos utilizado un staged, por lo que podemos utilizar los siguientes payloads:

" Windows/meterpreter/reverse_winhttps
" Windows/meterpreter/reverse_https
" Windows/x64/meterpreter/reverse_https

Para este ejemplo, hemos utilizado la opción windows/meterpreter/reverse_https. Ahora tenemos, en la carpeta output, generado un fichero .bat con el código adecuado para lograr la conexión cifrada con el handler. Más abajo veremos parte del código para que entendamos qué utiliza.

Figura 6: Elección del payload

Antes de continuar, vamos a mostrar el certificado generado con la herramienta y la opción 'impersonar'

Figura 7: Fichero PEM del certificado del dominio suplantado

El código que está en el interior del fichero .bat es el que se puede ver en la imagen. Como se puede ver, la automatización utiliza Powershell para ejecutar el Meterpreter con las opciones de la validación del certificado activadas.

Figura 8: Script en powershell a ejecutar

Como se puede ver en la siguiente imagen, desde el handler que Meterpreter Paranoid Mode ha configurado se obtiene la sesión.

Figura 9: Sesión establecida

Además, se pueden ver las opciones que se han configurado, lo cual es importante por si se quiere hacer el procedimiento a mano, en vez de utilizar la herramienta. Las opciones importantes son:

" StagerVerifySSLCert a true. Con esta opción el handler verifica la conexión. 

" EnableUnicodeEncoding a true. 

" HandlerSSLCert apuntando a la ruta del certificado en formato PEM.

Por último, os dejamos un video del proceso para que veáis la automatización y algunos de los detalles que se pueden visualizar.

Figura 10: PoC de Meterpreter Paranoid Mode

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

Fear the FOCA: Descargar FOCA y el plugin de Certificate Transparency Checker para FOCA

Nuestra querida FOCA Final Version sigue siendo una de las herramientas más populares, y las descargas de la misma siguen siendo muchísimas. Si te has leído el libro de Pentesting con FOCA, sabrás que existe la posibilidad de extender la funcionalidad básica de la misma por medio de un sistema de plugins, y esto es lo que desde el laboratorio de ElevenPaths acaban de hacer.

Figura 1: Descargar FOCA Final Version y el plugin de Certificate Transparency Checker para FOCA

Hace poco, desde el equipo de ElevenPaths en Buenos Aires, se lanzó el plugin gratuito Certificate Transparency Checker para Mozilla Firefox, que muchos usuarios han comenzado a utilizar y que permite verificar las opciones de Certificate Transparency de los sitios web que visitas solo con tenerlo activado.

Figura 2: Instalación y uso de Certificate Transparency Checker para Mozilla Firefox

Ahora, se ha incorporado dentro de las características de la FOCA, por lo que si te descargas el Plugin de Certificate Transparency Checker para FOCA y lo instalas, podrás verificar cuáles son las opciones de seguridad de todos los sitios que se son escaneados. 

Una vez que descargues el plugin en una carpeta, verás que hay un librería DLL que deberás cargar dentro de nuestra querida FOCA rosa. Es importante recordar que la librería BouncyCastle.Crypto.dll debe copiarse al mismo directorio que el ejecutable de FOCA Final Version.

Figura 3: Ficherso en el plugin de Certificate Transparency Checker para FOCA

Para ello, vete a la sección de plugins, y dale a añadir uno nuevo. En el cuadro de dialogo que te aparezca deberás seleccionar la librería DLL que se llama CertificateTransparencyChecker.dll y deberás tenerla en la carpeta Plugins para que FOCA pueda extender la funcionalidad que ofrece de serie.

Figura 4: Selección de la DLL del plugin

A partir de ese momento, podrás utilizar la verificación de los SCT de cada sitio web que solicites directamente desde FOCA, tal y como se ve en esta imagen.

Figura 5: Certificate Transparency Checker corriendo en FOCA

Para que veas lo fácil que es extender tu funcionalidad de FOCA y lo sencillo que es utilizarlo, hemos hecho este vídeo de dos minutos. 

Figura 5: Instalación y uso de Certificate Transparency Checker en FOCA

Puedes descargar la FOCA desde la web de ElevenPaths y el plugin Certificate Transparency Checcker para FOCA desde esta URL de la  web del laboratorio de ElevenPaths.  

Fear the FOCA!

Expect-CT: Un nuevo HTTP Header de Google para Certificate Transparency

Hace poco que hemos lanzado desde ElevenPaths nuestro add-on Certificate Transparency Checker para Mozilla Firefox, y es que no quedan muchos meses para que el modelo de Certificate Transparency empujado por Google empiece a ser realidad en Google Chrome. De hecho, a comienzos de este año Google ha empujado también un nuevo HTTP Header para que los servidores vayan reportando a los navegadores si van a estar listos o no para la llevada de Certificate Transparency.

Figura 1: Expect-CT un nuevo HTTP Header de Google para Certificate Transparency

El HTTP Header se llama Expect-CT y su formato está recogido en un draft durante el modo experimental en que está. La idea de este HTTP Header es informarle al navegador si debe esperar o no la entrega de los SCT (Signed Certificated Time-Stamps) que van asociados a los certificados cuando estos están publicados en los logs de los servidores de Certificate Tansparency.

Figura 2: Expect-CT Extension for HTTP draft

Este HTTP Header tiene tres posibles directivas. La primera será la posibilidad de forzar o no forzar el uso de Certificate Transparency. Para ello, si el HTTP Header de Expect-CT lleva la directiva "enforce" el navegador deberá esperar la llegado de los SCT y si no llegan, abortar la conexión.

Expect-CT: enforce

La segunda es el tiempo que debe ser cacheada esta directiva en el navegador, y este es un valor en segundos que se inserta en max-age. Es decir, una vez que un servidor web envíe la política Expect-CT, esta perdurará durante el "max-age" en la caché del navegador.

Expect-CT: enforce; max-age=1440

La tercera y última es "report-URI", es decir, la URL a la que el navegador debería enviar los reportes de fallos en la política Expect-CT. 

Expect-CT: enforce; max-age=1440;
           report-URI= https://misitio.com/CTReport/

Estos "violation reports" los envía el navegador en formato JSON al endpoint que se reporte en la directiva, y tienen esta estructura.

Figura 3: Formato JSON de Violation Report de Expect-CT

Si tu sitio web ya está listo para Certificate Transparency, puedes comenzar a utilizar este HTTP Header en modo "report-URI" sin "enforce", para que vayas viendo cómo se comportan los navegadores. 

Figura 4: Certificate Transparency Checker para Mozilla Firefox

Si quieres, en el blog de ElevenPaths puedes leer más sobre Certificate Transparency, y puedes usar nuestro add-on gratuito Certificate Transparency Checker para Mozilla Firefox.

Saludos Malignos!

Odin, identificando el Shadow IT en la era del Big Data. Parte II: Las búsquedas inversas a implementar

Continuando con la recopilación de conocimiento y lecciones aprendidas durante el desarrollo del proyecto Odin que comenzamos en la entrada anterior donde hablamos de las herramientas y técnicas de footprinting, en esta parte describiremos los nuevos vectores de identificación de activos de una compañía que hemos explorado en el proyecto. Antes de comenzar, el concepto de búsqueda inversa debe quedar claro, ya que todas las técnicas utilizadas se basan en el cruce de información para dotar al servicio de esta capacidad.

Figura 1: ODIN, Identificando el Shadow IT en la era del Big Data. Parte II.

Un ejemplo de búsqueda inversa sería la siguiente: si un dominio tiene asociado un servidor de correo, probablemente los dominios que compartan dicho servidor pertenezcan a la misma compañía así que, ¿qué otros dominios tienen asociado el mismo servidor de correo? Es decir, algo similar a utilizar el servicio IP de Bing para saber qué sitios web comparten la misma dirección IP.

Búsquedas inversas clásicas y nuevas búsquedas

En primer lugar, el proyecto no debía perder funcionalidad en comparación con los servicios de terceros ya citados en la anterior entrada, por lo que de inicio se debía permitir realizar las búsquedas inversas clásicas como son:

• NS compartido, por registro del tipo NS en la configuración DNS o por servidores DNS configurados en el registrador de whois. 

• MX compartido, consultando la información indexada de DNS. 

• Búsqueda de subdominios, ya sea en certificados x509, en DNS o indexados en Internet. 

• Búsquedas inversas de dominios, buscando mediante el correo electrónico en la información almacenada de whois.

En segundo lugar, y con vistas a explorar nuevas técnicas de footprinting, implementamos nuevos métodos no utilizados hasta la fecha por otras herramientas, como son la búsquedas inversas de etiquetas de redes sociales y aplicaciones de Google Analytics, de registros DNSSEC, usando los campos “O” y “OU” de los certificados X.509, y por último, incluimos las búsquedas inversas en base al registro DKIM descrito en la especificación DNS.

Búsqueda inversa mediante redes sociales

El objetivo es relacionar los nombres de usuario corporativos de redes como Twitter, Facebook e Instagram con los dominios y subdominios que los contienen. De esta forma, si una web incluye un enlace con el botón “Follow Me” de Twitter, es posible identificar el usuario corporativo.

Figura 2: Primera búsqueda por Redes Sociales

Una vez almacenada toda la información y su relación, la búsqueda inversa se realiza por el nombre de usuario de la red social y se obtienen otros dominios con el mismo estilo de enlace “Follow Me”, y por lo tanto, pertenecientes a la misma compañía. Un ejemplo de este tipo de búsqueda se muestra en la siguiente captura de pantalla del host “www.simulator-orgeffectiveness.com” que tiene un enlace a su Twitter: “strategyand”.

Figura 3: Búsqueda inversa por Redes Sociales

Una vez obtenido el usuario corporativo de Twitter “strategyand”, en la segunda captura, se puede observar como una web de desarrollo con nombre “strategyand-dev01.atlasworks.com” perteneciente a otro dominio tiene el mismo botón de twitter al mismo usuario “strategyand” y, por lo tanto, es posible relacionarla con la anterior si hiciéramos una búsqueda inversa.

Búsqueda inversa de registros DNSSEC

DNSSEC (del inglés Domain Name System Security Extensions) es la versión segura del servicio de resolución de nombres de dominio DNS. Del mismo modo que con el DNS, dispone de varios registros sobre los que se puede realizar búsquedas inversas, como son el registro DNSKEY y el registro DS:

• El registro DNSKEY contiene la clave pública usada en las operaciones de firma de zonas. 

• El registro DS es usado para identificar la clave de firmado de zonas delegadas.

Tanto la clave pública DNSKEY como los hash de los registros DS son índices de consultas inversas y permiten conocer qué otras zonas utilizan esa misma información.

Figura 4: Búsqueda inversa por información del servicios DNSSEC

En el siguiente ejemplo podemos observar como el registro DNSKEY del dominio “cryptoserver.org” y del dominio “hopfenblatt.de” es el mismo y, por lo tanto, sería posible relacionarlos si hiciéramos una búsqueda inversa.

Búsqueda inversa en certificados x509

Es común el uso de la información que incluyen los certificados en los campos “CN” y “SAN” para identificar subdominios o dominios alojados en una misma dirección IP, como hace FOCA para identificar el nombre de todos los dominios para los que posible utilizar un mismo certificado digital.

Figura 5: Nombres de dominio localizados en FOCA con los certificados digitales

Pero además de estos datos, también es posible realizar búsquedas de otros dominios llevando a cabo consultas de aquellos certificados que comparten los campos O (Organizational) y OU (Organizational Unit) y que juntos identifican a la compañía.

Figura 6: Búsqueda inversa por certificados X.509

En el ejemplo mostrado en la Figura 6 se muestra el certificado de la web “www.upwork.com” y en el que su campo Organizational (O) del certificado es “Upwork Inc”. Si realizamos una búsqueda de ese valor en todos los certificados, se detectaría un nuevo dominio “elance.com” para la misma compañía, tal y como muestra la imagen de la derecha.

Búsqueda inversa por ID de Google Analytics

Al igual que ocurre en las redes sociales, los sistemas de Web Analytics disponen de un código único que se debe insertar, generalmente como javascript, en la página web de la que se desea obtener estadísticas. Por ejemplo, Google Analytics utiliza el formato “UA-XXXXXX-Y” que es un código único por cada uno de sus usuarios:

<script>

(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga'); 

ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
</script>

A continuación se mostrará el ejemplo de búsqueda inversa por el identificador de Google Analytics en las páginas “www.riotgames.com” y “oce.leagueoflegends.com”. En primer lugar si hacemos la búsqueda en el HTML de “www.riotgames.com”, encontramos el identificador “UA-5859958” (se omite el último número ya que identifica el activo concreto de la cuenta de usuario UA-5859958)

Figura 7: Extracto HTML de www.riotgames.com

Si realizamos la misma búsqueda en el HTML de “oce.leagueoflegends.com”, encontramos el mismo identificador “UA-5859958”

Figura 8: Extracto HTML de oce.leagueoflegends.com

Generando una base de datos con todos los dominios y los códigos de este estilo, se puede realizar una búsqueda por el código para obtener un listado de los dominios que la utilizan. Esto mismo es aplicable a otras aplicaciones como Woopra, Google ADs, Yandex Metrica, Piwik, KissMetrics, MixPanel, Bizible, Segment, Amplitude, etcétera.

Búsqueda inversa de registros DKIM de DNS

El registro DKIM (DomainKeys Identified Mail) se utiliza para identificar la legitimidad de los e-mails enviados desde un dominio y contiene la clave pública utilizada para la verificación de la firma digital de dicho dominio en cada uno de los mensajes. No está muy extendido todavía, pero sigue la filosofía de los registros DNSKEY de DNSSEC. 

Figura 9: Firma DKIM de un mensaje enviado desde un servidor de Yahoo!

En el siguiente ejemplo podemos observar como el registro DKIM incluido en los registros TXT del dominio “77covers.com” y del dominio “77vines.com” son el mismo y, por lo tanto, es posible relacionarlos si hiciéramos una búsqueda inversa.

Figura 10: Búsqueda inversa por información DKIM

Finalmente, tras haber identificado estas consultas técnicas no implementadas hasta la fecha por ningún servicio de terceros, se generan dos necesidades en el desarrollo del proyecto Odin:

• Recopilación de toda la información existente en Internet necesaria para cubrir todos los vectores de footprinting descritos. 

• Un desarrollo propio que apoyado en tecnologías Big Data permita la viabilidad del proyecto, siendo completamente independiente de cualquier servicio de terceros para su funcionamiento.

En la siguiente y última entrada abordaremos cómo la solución propuesta para realizar dicho proyecto nos cubrió las dos necesidades comentadas.

***************************************************************************************************

- Odin Parte 1: Técnicas y Herramientas para footprinting
- Odin Parte 2: Las búsquedas inversas a implementar
- Odin Parte 3: El Big Data y el Servicio de investigación

***************************************************************************************************

Autores: Elías Grande (3grander) Alejandro Ramos (@aramosf) escritor de "Hacker Épico"

Los certificados digitales que usa Apple en su CDN son de peor calidad

Estos días hemos estado desplegando nuevos plugins en nuestro servicio de pentesting persistente Faast, y para probarlos decidí revisar algunas partes de la CDN (Content Delivery Network) que utiliza Apple. Le hemos reportado varios pequeños fallos de seguridad estos días en Apple.com, así que para no insistir sobre los mismos servicios, miré la CDN.

Figura 1: Los certificados digitales que usa Apple en su CDN son de peor calidad

Revisando las alertas en Faast, aparecieron algunas que tenían que ver con los algoritmos criptográficos en los certificados digitales que están en uso en los servidores de la CDN, y quise hacer una comprobación manual para ver si era cierto o no. Como podéis ver, aparecen certificados que abre la posibilidad de ataques como Lucky13 o Bart Mitzvah.

Figura 2: Alerta en Faast sobre el certificado usado en un servidor de la CDN de Apple

Para comprobarlo me fui a la web original de AppleID a ver qué aspecto tenía el certificado digital allí a primera vista. Como podéis ver, en la web no aparece ninguna alerta de seguridad en el navegador Google Chrome.

Figura 3: Web de AppleID sin ninguna alerta de seguridad por el certificado digital

Si hacemos el SSL Test de Qualys sobre los certificados digitales de este sitio web, el resultado es una calidad A-, debido a ausencia de Forward Secrecy y el uso de SHA1.

Figura 4: Certificado digital para AppleID.Apple.com de calidad A-

Si vamos a la web de la CDN para AppleID, podemos ver que a priori el certificado es de más o menos la misma calidad a primera vista, ya que no se obtiene ninguna alerta de seguridad.

Figura 5: Web de AppleID en la CDN de Apple sin alerta de seguridad

Sin embargo, si hacemos de nuevo el test SSL de Qualys podemos encontrarnos con que el resultado es de B, debido a que mantiene el uso de RC4, o lo que es lo mismo, es vulnerable a diferentes ataques como el citado Bart Mitzvah.

Figura 6: El certificado soporta RC4 y recibe una calidad de tipo B

Es solo una curiosidad con la criptografía, pero parecería lógico que la calidad de los certificados que se utilizan en las webs debiera ser exactamente la misma a la de los certificados de la CDN. Hay que decir, eso sí, que no pasan por la CDN exactamente los mismos datos por lo que tal vez por eso no le han dado tanta  importancia. De cualquier modo, es una característica de seguridad que conviene tener presente por si pudiera afectar a algún escenario de ataque.

Saludos Malignos!

Revisar la configuración HSTS y HPKP en el navegador de Internet para estar más seguro

Los protocolos HSTS (HTTP Strict Tansport Security) y HPK (HTTP Public Key Pins) dotan a la navegación desde un determinado navegador de Internet a un determinado sitio web de una capa de seguridad extra. El primero de los protocolos, HSTS, le permite indicar a un sitio web que siempre se conecte por HTTPs, evitando que desde el navegador se envíe ninguna petición por HTTP (aunque el usuario o una parte de la aplicación así lo indiquen). El segundo de los protocolos, HPKP el la clave de las tecnologías de Certificate Pinning y le indica al navegador que, no solo debe hacerse la petición vía HTTPs, sino que además el servidor debe tener como clave pública un determinado certificado. Es decir, el servidor web "pinnea" en el navegador el certificado que debe tener el servidor al que se conecta.

Figura 1: Revisar la configuración de HSTS y HPKP en el navegador de Internet

Estas dos tecnologías dificultan sobremanera los ataques de red Man in the Middle, aunque existen algunas limitaciones de la tecnologías que pueden ser aprovechadas por un atacante. Ya vimos como con Delorean se podía hacer caducar una configuración HSTS e incluso un certificado digital "pinneado" con HKPK. Además, ataques como SSLStrip2 pueden aprovecharse de la primera negociación de HSTS para hacer el ataque de man in the middle y robar el tráfico de red.

Figura 2: Cómo ByPassear HSTS con Delorean

Por otro lado, también hemos visto como la configuración de HSTS o de HKPK pueden ser utilizados para dañar la privacidad de los usuarios. En primer lugar, un sitio web malicioso podría aprovecharse del valor de Max-Age de HSTS para crear una supercookie en cada cliente, de igual formar que un atacante podría aprovecharse de la capacidad de HKPK para poner un certificado diferente a cada usuario y saber quién es en cada momento.

Figura 3: PoC que analiza tu historial por la información HSTS almacenada en tu navegador

Por último, haciendo un ataque Time-Based a ciegas, un atacante podría saber cuáles han sido los sitios que se han visitado solo por el tiempo de error al solicitar un recurso vía HTTP de un servidor en el que el tráfico debe ir por HTTPS porque está forzado por HSTS. Saber si el navegador ya tenía la política HSTS configurada o no hace que un atacante remoto pueda conocer su historial de navegación.

Revisar la información HSTS y HPKP de tu navegador

Conociendo las ventajas y los inconvenientes de estas tecnologías, merece la pena saber cómo se pueden consultar las configuraciones HSTS y HPKP que tiene cada uno de nuestros navegadores. Descubrir si te están vigilando o si es posible conectarse a un determinado sitio desde una red WiFi insegura sabiendo que va a ir por HTTPs puede ser de utilidad.

Figura 4: Consulta HSTS y HPKP en Google Chrome para www.Gmail.com

En Google Chrome podemos consultar la información de HSTS y HPKP desde la herramienta net-internals HSTS, tal y como se ve en la imagen superior, donde se ha consultado para Gmail. En Mozilla Firefox, por desgracia no viene nada de serie, pero en el Lab de ElevenPaths hemos creado una herramienta llamada PinPatrol que tenéis disponible en los addons de Mozilla.

Figura 5: PinPatrol para Mozilla Firefox

La herramienta, una vez la instalas, te permite consultar de una vez (mucho más sencillo que andar buscando dominio a dominio) todas las políticas HSTS que están cargadas en tu navegador.

Figura 6: PinPatrol muestra en forma de tabla las entradas HSTS y su información

Además, en el caso de que tengas un certificate pinning con HPKP para cualquier dominio, tendrás también la firma del mismo y la información relevante de él. En este caso, el plugin Calomel del que os hablé para ayudar a conocer detalles de seguridad de un certificado digital.

Figura 7: Entrada HPKP en Mozilla Firefox con datos del certificado "pinneado"

Los campos de la tabla no son complicados de entender, pero en la web del laboratorio los tenéis explicados junto con un enlace para descarga directa.

Figura 8: Plugin PinPatrol en descarga directa con información detallada

Si utilizas Mozilla Firefox para navegar o para tus proyectos de Ethical Hacking, entonces PinPatrol te puede ayudar en todo momento a evaluar cómo están funcionando las políticas HSTS y HPKP de forma sencilla. Además, puedes comprobar esta información con la que obtienes en otro navegador de forma que así sabes si te están instalando una supercookie o no para seguirte.

Saludos Malignos!