martes, agosto 23, 2011

Manipulando metadatos para engañar a la FOCA

Los metadatos de un documento se pueden modificar, al igual que el banner de un servidor web o la versión de un servidor DNS (como hacen los chicos de RedHat). De hecho, para ocultar la información a las técnicas de fingerprinting básicas, esos datos se modifican para intentar engañar a los usuarios menos experimentados. Sin embargo, cuando se hace un pentesting, los datos importantes se revisan y confirman manualmente para detectar las técnicas de deception y sacar la información correcta.

Así, cuando se lee el banner de un servidor web, si algo suena raro con él, se le pasa una herramienta de fingerprinting al servidor que evalúe el tipo de respuesta, el orden de la misma, y el comportamiento ante determinadas situaciones para poder garantizar la versión del servidor web.

Manipulación de metadatos

Con los metadatos la manipulación es igualmente posible. Cuando en el año 2008 pensamos en para qué podría ser útil modificar los metadatos se nos ocurrierron varios escenarios posibles:

- Antiforensics: Alguien que quisiera incriminar a otra persona haciendo creer que el documento lo había escrito otro para engañara a un analista forense en una investigación.

- Metadata HoneyPot: Alguien que quisiera detectar si se estaban utilizando los metadatos para atacar su sitio, es decir, el artículo que publicamos en el congreso IADIS 2008 sobre Metadata Honeypot - ya os lo publicaré por aquí, que nunca lo hice y solo os dejé la referencia al mismo -.

- Imagen corporativa: por supuesto, para lo que lo usamos en MetaShield Protector y OOMetaextactor, es decir, quitar todos los datos sensibles y establecer valores en metadatos que sean corporativos, como poner el nombre de la compañía,

Sin embargo, intentar manipular los metadatos para engañar a un usuario en un proceso de pentesting es más bien inútil. De hecho, ya nos encontramos con este problema en la primera versión de la FOCA, allá por el año 2008, en el que nos preocupaba no el encontrar datos manipulados, sino inútiles por ser documentos incorporados a la web del proceso de pentesting que habían llegado allí por casualidad, por ejemplo unas diapositivas de una presentación de un ponente invitado a unas conferencias. En ese caso, los metadatos serán de la red donde trabaje el speaker y no de la web que publica el documento, por lo tanto había que quitarlo del proyecto.

Para solucionar este problema, añadimos, en la primera versión de FOCA una herramienta para el traceo de metadatos. Es decir, cuando se hace el análisis de metadatos, averiguar de qué documento proviene ese metadato. Si la cosa suena "rara" o "manipulada" o simplemente es inútil, basta con abrir el documento (botón derecho desde FOCA) revisarlo, y si no es válido, es decir, es falso o ha sido manipulado, eliminarlo con el botón derecho de la lista de documentos y volver a analizar el sitio. Esto está publicado en el primer manual de la FOCA de aquel año.

Para ello, cuando aparece un metadato, con el botón derecho se accede a la opción de "documentos donde aparece este valor", que lleva al documento del que procede el metadato. Así el auditor puede revisar bien el documento, y descartarlo si fuera falso.

Figura 1: Opciones de traceo de origen de metadato

Ahora bien, si una empresa tiene 2.000 documentos y quiere protegerse de FOCA... ¿alguien cree que es útil manipular un documento y dejar los 1.999 con datos reales? Si lo hiciera sería de necios, ya que estaría dejando datos públicos de su empresa en Internet por engañar a FOCA. Además, si solo hay un documento con información sensible, el analista haría una revisión manual y concienzuda para saber si es falsa o no esa info.

Es por eso que las empresas utilizan plantillas de valores corporativos, con soluciones como MetaShield Protector, que cambia todos los metadatos, pero no para engañar a un pentester, sino directamente para proteger la imagen de la compañía.

Indicio o Prueba

Hay que tener presente que un metadato, un fichero de log en formato txt, un banner de un servidor web, o incluso el valor devuelto por un registro de un DNS son todos indicios, ya que pueden haber sido manipulados para pretender engañar al auditor. Es por eso que no pueden ser tomados como pruebas. Un log que no esté firmado digitalmente y que refleje que una dirección IP se conectó a un servidor a una determinada hora no es una prueba irrefutable, pero sí un indicio que debe ser investigado.

En el caso de los metadatos sucede lo mismo, una fuga de información que diga que un usuario manipuló un documento en una hora y lugar es un indicio que debe ser investigado, llegando a realizar un análisis forense del equipo donde trabaja habitualmente el usuario, etc... Al final, los peritos determinarán si ese dato ha podido ser manipulado o no, y su opinión hará que ese dato tenga más o menos valor.

Sin embargo, en un proceso de pentesting, para un auditor da igual si es un indicio o una prueba. Si se encuentra una dirección IP en un documento, se prueba, se analiza, y se mira a ver si puede ser utilizada para atacar el sitio. ¿Que no se puede porque el dato es antiguo o ha sido manipulado? Pues mala suerte, a por otro posible camino de entrada en la red.

Por todo eso, cuando en España se aprobó el Esquema Nacional de Seguridad, se tomó especial cuidado con el tema de los metadatos, recomendando que estos se borrasen de los archivos públicos.

Conclusiones

¿Se pueden manipular los metadatos de los documentos? Evidentemente, como los valores de un log, o las cabeceras de un mensaje de correo electrónico. ¿Eso quiere decir que sean inútiles para un proceso de pentesting? No. De hecho estamos hablando de una de las fugas de información más importantes de muchas empresas, con lo que es muy fácil sacar información jugosa de objetivos de pentesting. ¿Es probable que alguien haya manipulado un metadato en un documento? La probabilidad es muy baja en un proceso de pentesting de una web con 300 documentos, pero por supuesto, toda información extraída por FOCA siempre debe ser contrastada, como se hace con la info que devuelve cualquier scanner de seguridad.

Saludos Malignos!

12 comentarios:

Anónimo dijo...

Saludos en cuanto a ¿Es probable que alguien haya manipulado un metadato en un documento? La probabilidad es muy baja en un proceso de pentesting de una web con 300 documentos


La verdad es que yo diria que la probabilidad depende mas de donde y a quien se realiza el pentesting y de acuerdo al expertise de los usuarios,teniamos un problema algo similar en un caso el cual tendia a que los simples usuarios eran habilidosos y muy cautelosos ...

Anónimo dijo...

algo parecido aqui tambien
http://jbyte-security.blogspot.com/2011/07/enganando-la-foca.html

saludos

Chema Alonso dijo...

@Anónimo (que ya podías firmar que es fácil saber quién eres). Las conclusiones de ese artículo que has linkado son una chorrada. Lo único seguro es limpiar los metadatos. Si metes un doc falso, un pentester lo va a localizar y lo va a quitar.

Saludos!

666 dijo...
Este comentario ha sido eliminado por el autor.
Anónimo dijo...

QUE pasa si son varios documentos como metadata falsa y como saber que metadatos son falsos o nop?

Anónimo dijo...

En tu post tu dices que se tienen que contrarrestar contra otra información para saber si es verdadera o no con lo cual seria mejor usar los otros métodos de contrarrestar información para buscar metadatos que usar la foca y perder tiempo contrarrestando información para saber si es verdadera o no.

Chema Alonso dijo...

@JBYTE, pones un comentario que dice que no eres el anónimo y al minuto vienen dos comentarios anónimos ???

A ver, si a una empresa le preocupa la seguridad de los metadatos, dejar 1890 documentos con metadatos reales y meter 2 con metadatos falsos es una cagada, ya que se detecten esos 2 con metadatos falsos o no, la empresa está dejando miles de metadatos importantes.

Si solo hay 2 documentos con metadatos y ambos son falsos, entonces cuando audites lo comprobarás. Si aparece una IP la chequearas, si hay un supuesto puerto o una intranet, la comprobarás. Así es como se hace con todos los escanners de vulnerabilidades y recogida de información.

Así, como en ambos casos las opciones son malas, lo que te encuentras es:

a) Empresas que limpian metadatos.
b) Empresas que no limpian metadatos.

Saludos!

WiNSoCk dijo...

Viendo el panorama y con sueños de maldad, anda que no molaría ahora llenar esto de comentarios iniciando un flame como anónimo }:)
Y si, llevo retraso en mi rss... Lindas vacaciones :D.

Una vez, puestas las chorradas. Pondré algo útil. ¿Qué pasaría si metes varios documentos, "prácticamente correctos", destinados a llevarte a una honeyIP? De esta manera, si lo dejas en plan caramelito, puedes estar avisado con tiempo.

Quiza no siempre, sea interesante para una empresa (viable, economico, etc), comprar una aplicación que limpie los metadatos, pero si, el poder estar sobre aviso de "que algo ocurre".

Chema Alonso dijo...

@WinSock, como pone en el artículo, nosotros lo hicimos para un Metadata Honeypot, pero nunca dejábamos datos reales, y el objetivo era saber si había usuarios que los usaban. Lógicamente, al final el pentester se da cuenta de que es un honeypot, pero ya sabíamos que se usaban los metadatos.

Saludos!

Anónimo dijo...

¿Alguien ha probado a modificar los metadatos y meter código javascript malicioso? }:)

Desconozco el funcionamiento interno de la FOCA, qué wrappers usáis para los datos, pero es un vector 'maligno' muy cachondo. ;)

Chema Alonso dijo...

@Anónimo, en la FOCA Online @Tayoken le cascó un XSS en un metadato a @FILEMASTER y no le hizo gracia... }XD

Saludos!

Lucho dijo...

No he entendido muy bien como se hizo el XSS a @FILEMASTER... Si se hizo a través de la FOCA online, significa que la que es vulnerable es la aplicación online, no???

Entrada destacada

Desde HOY es BlackFriday en 0xWord.com Cupón 10% descuento: BLACKFRIDAY2024 y descuentos con Tempos de MyPublicInbox @0xWord @mypublicinbox

Pues este año tenemos el  BlackFriday  durante  7 días , y poco más que decir en el artículo que lo que he puesto en el título del artículo....

Entradas populares