Yuzi download

Parece que no ha pasado el tiempo desde que empecé a jugar con los metadatos en documentos Microsoft Office y los metadatos en documentos Open Office. De aquellos juegos surgió la idea de comenzar a desarrollar FOCA, que culminó en la publicación del Whitepaper titulado "Disclosing Private information from metadata, hidden info and lost data" que publicamos para la edición de BlackHat Europa 2009, de hace ya siete años. Todos aquellos trabajos culminaron en una herramienta de protección llamada MetaShield Protector, que era útil para evitar fugas de información en la empresa y cumplir la legislación, por ejemplo el Esquema Nacional de Seguridad, y que incluso llegó a recibir un premio a la innovación.

Aún así, para los sistemas Apache, Web Clean-Up y OS X estamos desarrollando un módulo especial que tendremos en el futuro, así que es posible que próximamente vuelva a hablar de este proyecto de investigación personal que surgió de un trabajo en un blog por aquí.

Saludos Malignos!

Una de las partes que se revisa en detalle cuando se hace un pentesting a una compañía es el servidor DNS. Los registros que allí se encuentran pueden dar mucha información. Desde conocer la infraestructura del Active Directory - buscando los registros que genera este servicio - o la infraestructura de la red - buscando los registros PTR, SRV, WPAD o el Primary Name Server -, hasta llegar a conocer información sobre la versión del DNS, el software sobre el que está construido el servicio, dónde navegan sus usuarios, el software de los clientes - inluidos los antivirus -,  etcétera. Y entre otras, las opciones de seguridad en los servicios de correo electrónico.

Es en este último servicio de correo electrónico, donde más información se puede obtener sobre la seguridad del mismo. Desde información de la infraestructura con los servicios MX y SPF, hasta las políticas antispoofing y antispam con la información de las políticas en las configuraciones DKIM, SPF o SenderID o DMARC (y en el futuro con los registros de SMTP STS). Todos ellos permiten saber a un atacante si va a poder realizar con facilidad o dificultad un ataque de Spear Phishing a la organización.

A todos ellos, hay que añadir un par de registros DNS que pueden ayudar a un atacante a reconcoer que la empresa está utilizando Microsoft Office365 o Windows Live Mail. Los registros son de tipo TXT y son necesarios para validar el dominio de la organización.

Esta validación es obligada por Microsoft cuando contratas un dominio nuevo personalizado para Office365, para evitar que nadie suplante el dominio y basta con hacer una búsqueda de registros TXT en el dominio objetivo para ver si están allí. Son los que comienzan por "MS=XXXXXXXX"

Esta es la forma en la que Microsoft valida el dominio. En el caso de que sea un dominio del antiguo Windows Live Mail, el registro tiene un aspecto como "v=msv1 t=XXXXXXXXX", pero también indica la existencia del backend de Microsoft. 

Para detectar Gmail, basta con mirar el DNS y fijarse en dos registros TXT. El primero el de "Google-Site-Verification", que indica que se ha validado el dominio con Google - pero no es concluyente porque se puede validar el domino sin tene el correo en Gmail - y el registro SPF, donde debe aparecer incluido el valor _spf.google.com como uno de los enviadores de correo autorizados, ya que ese registro de Google es el que incluye las direcciones IP utilizadas por Gmail para enviar los mensajes de e-mail.

Por supuesto, que estén los registros DNS ahí puede no significar nada si el administrador del servidor DNS los dejó allí olvidados después de validar los dominios o configurar el servicio, pero es un indicio más que útil en la mayoría de los casos. ¿Conoces algún otro registro DNS de validación que obligue a crear algún sistema en los DNS de las organizaciones?

Conocer que una organización tiene como plataforma Office365 o Gmail es útil para aquellos ataques de Spear Apps que se quieran realizar contra una organización, como ya os contamos en la serie de artículos de SAPPO: Spear Apps to stealth OAuths Tokens. Es necesario, ya que dependiendo de cuál sea el ID Provider, la app maliciosa y la API que habrá que utilizar será distinta y, con solo mirar estos registros se puede saber qué utiliza la organización.

Saludos Malignos!