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.
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:
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.
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”.
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:
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.
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.
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:
Si realizamos la misma búsqueda en el HTML de “oce.leagueoflegends.com”, encontramos el mismo identificador “UA-5859958”
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.
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.
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:
***************************************************************************************************
Autores: Elías Grande (3grander) Alejandro Ramos (@aramosf) escritor de "Hacker Épico"
 |
| 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');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)
ga('send', 'pageview');
</script>
 |
| 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"
Excelente ya era hora.
ResponderEliminar