Ojo al dato con el Metadato

El viernes pasado, apareció la noticia de un hacker identificado por el FBI, tras haber publicado junto a los datos robados, una fotografía de su novia; más bien de sus pechos; con un cartel alusivo al hackeo; supongo que jactándose de su hazaña.

El FBI, tras analizar la imagen publicada, pudo observar que el individuo en cuestión, no había sido lo suficientemente cuidadoso y no borró los metadatos que van asociados a la imagen, antes de publicarla. A partir de estos metadatos, el FBI pudo saber que la imagen se había hecho con un iPhone y que este había guardado además de otros muchos datos, los datos de geolocalización del teléfono en el momento de realizar la fotografía.

Siguiendo las pistas proporcionadas por la imagen, localizaron cerca de Melbourne, a la señorita de la foto, que figuraba como novia del hacker en su perfil de Facebook.

La noticia apareció en diversos medios, con titulares más o menos "graciosos", como el que yo vi, que rezaba "Hacker acusado gracias a las fotos de los pechos de su novia". Quizá y como prueba definitiva, el FBI comparó los pechos que aparecían en la foto, con los originales de la novia del hacker :-).

Es curioso la cantidad de información, en forma de metadatos, que se asocian a la mayoría de los ficheros, como un documento de Word, un PDF, una imagen, etc. y por lo general, nunca nos preocupamos por revisar o eliminar esta información antes de publicar o enviar un fichero. También es verdad, que en la mayoría de los casos, nos despreocupamos de este aspecto, sencilla y llanamente porque ni estamos cometiendo un delito, ni es información sensible, que pueda tener interés para quien la recibe o la intercepta. Pero no siempre es así.

Además de su uso en los análisis de informática forense, en los procesos de recogida de evidencias; conocido como Information Gathering; el uso de los metadatos es usado también por los "chicos malos", para obtener información acerca de un objetivo, como nombres de usuario, sistema operativo, etc. y que servirán posteriormente para realizar un ataque a ese objetivo.

Hay otros casos en los que pasar inadvertida la información de los metadatos asociados a un documento en el momento de publicarlo, ha puesto en entredicho la veracidad del documento, ha revelado información adicional, que no se pretendía mostrar o información acerca del verdadero autor del documento. En estos casos, sobre todo cuando esos documentos son publicados por organismos oficiales, han supuesto situaciones muy embarazosas y difíciles de explicar, como le ocurrió en 2003 al gobierno británico, cuando publicó como propio un documento acerca de la seguridad de las infraestructuras en Irak y que en realidad era obra de un un investigador del "Monterey Institute of International Studies" y como en el chiste, con error tipográfico incluido, como indicaba el Dr. Glen Rangwala, descubridor del fiasco.

 

La extracción de metadatos de un fichero es muy sencilla y existen numerosos programas, open source y comerciales, para todas las plataformas, que permiten ver, cambiar o liminar estos metadatos.

La mayoría de las cámaras y programas de edición de imagen, utilizan formatos de compresión JPG e incluyen información en forma de metadatos siguiendo el formato EXIF.

Una buena herramienta, libre, que permite leer, escribir y editar metadatos de un gran número de tipos de ficheros y de formatos de metadatos, es ExifTool. Esta herramienta se basa en una librería de PERL y se utiliza en modo línea de comando, aunque existen aplicaciones en forma de ejecutable para Windows y OSX. 

Un ejemplo real de metadatos de una imagen, obtenidos con ExifTool:

ExifTool Version Number         : 8.87
File Name                       : foto2.jpg
Directory                       : .
File Size                       : 1676 kB
File Modification Date/Time     : 2012:04:15 18:23:44+02:00
File Permissions                : rw-r--r--
File Type                       : JPEG
MIME Type                       : image/jpeg
Exif Byte Order                 : Big-endian (Motorola, MM)
Make                            : Apple
Camera Model Name               : iPhone 4
Orientation                     : Horizontal (normal)
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Software                        : 4.1
Modify Date                     : 2010:11:09 17:27:50
Y Cb Cr Positioning             : Centered
Exposure Time                   : 1/15
F Number                        : 2.8
Exposure Program                : Program AE
ISO                             : 100
Exif Version                    : 0221
Date/Time Original              : 2010:11:09 17:27:50
Create Date                     : 2010:11:09 17:27:50
Components Configuration        : Y, Cb, Cr, -
Shutter Speed Value             : 1/15
Aperture Value                  : 2.8
Metering Mode                   : Average
Flash                           : Auto, Did not fire
Focal Length                    : 3.9 mm
Subject Area                    : 1295 967 699 696
Flashpix Version                : 0100
Color Space                     : sRGB
Exif Image Width                : 2592
Exif Image Height               : 1936
Sensing Method                  : One-chip color area
Exposure Mode                   : Auto
White Balance                   : Auto
Scene Capture Type              : Standard
Sharpness                       : Hard
GPS Latitude Ref                : North
GPS Longitude Ref               : West
GPS Time Stamp                  : 17:27:40.45
GPS Img Direction Ref           : True North
GPS Img Direction               : 102.1856287
Compression                     : JPEG (old-style)
Thumbnail Offset                : 844
Thumbnail Length                : 10027
Image Width                     : 2592
Image Height                    : 1936
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
Aperture                        : 2.8
GPS Latitude                    : 43 deg 15' 42.60" N
GPS Longitude                   : 2 deg 55' 40.80" W
GPS Position                    : 43 deg 15' 42.60" N, 2 deg 55' 40.80" W
Image Size                      : 2592x1936
Shutter Speed                   : 1/15
Thumbnail Image                 : (Binary data 10027 bytes, use -b option to extract)
Focal Length                    : 3.9 mm
Light Value                     : 6.9

Los chicos de Informática 64, especialistas en estos temas, han desarrollado una herramienta muy interesante, llamada "FOCA" (Fingerprinting Organizations with Collected Archives); de la cual tienen versiones, FOCA Free, FOCA Pro y Forensic FOCA, con diferentes capacidades.

La versión free, que es la que he revisado, entre otras cosas, es capaz de recorrerse una web en busca de documentos o ficheros de diferentes tipos, descargar y extraer los metadatos de estos documentos, mostrando información relativa al sitio y sus documentos. Del análisis de los metadatos de los ficheros encontrados y de una forma bastante cómoda, se muestran datos de usuarios, carpetas, impresoras, software, Emails, sistema operativo, passwords y servidores, si es que están incluidos estos datos, obviamente.

Como decía en el título del post, ojo con lo que publicamos, aunque sea de forma inconsciente, nunca se sabe quien lo va a utilizar ni con que propósito.

Ataques por SQLInjection, un clásico

Afortunadamente, cada vez es más difícil encontrar una web vulnerable a un ataque por SQLInjection, en realidad solo es cuestión de aplicar buenas prácticas en el desarrollo. Algo tan sencillo como hacer convenientemente un parseo previo de los datos introducidos en nuestra web, nos puede evitar sobresaltos por ataques como SQLInjection o XSS, por ejemplo.

Aunque por lo general, protegerse ante este tipo de ataques es una práctica habitual, como tan habitual es protegerse ante un fallo inesperado de tu programa, sencillamente con instrucciones Try/Catch, por ejemplo, la verdad es que aún podemos encontrar "descuidos". Estos descuidos son muy fáciles de corregir, pero de no hacerlo a tiempo, si los "señores del sombrero negro" lo descubren, a buen seguro lo van a aprovechar, o sencillamente se van a divertir borrando o manipulando nuestros datos.

De vez en cuando, navegando por la red, cuando accedo a un formulario de Usuario/Contraseña, suelo tener la tentación de comprobar si han sido cuidadosos o no, con la diferencia de que cuando lo encuentro; yo, que soy un caballero :-); aviso de la desprotección.

Por lo general, cuando un formulario de Usuario/Contraseña está un poco descuidado de aspecto, es probable que también esté descuidado en protección.

Algo tan sencillo como introducir una comilla [ ' ] en el campo del Usuario y si al Aceptar tenemos algo así como:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]Comilla no cerrada antes de la cadena de caracteres '' AND CLAVE=''.

/xxxx/yyy/login.asp, línea zz

estamos ante uno de estos "descuidos". Ya solo es cuestión de seguir poco a poco para "colarse hasta la cocina". 

En realidad, todo se basa en hacer fallar el procesamiento del formulario y que la información de fallo que nos muestre, nos vaya dando pistas acerca de nombre de tabla, nombres de campos o los propios datos en sí.

No hace falta buscar con demasiado ahínco en la red, para encontrar auténticos manuales de como hacer un SQLInjection. Con esto y unos conocimientos básicos de SQL, en muchos casos es suficiente para colarse en una web, modificar datos o directamente borrarlos, dependiendo de "la mala leche" del que lo encuentre.

No pretendo hacer apología del SQLInjection, ni mucho menos. Cualquiera que tenga el más mínimo interés en el tema, encontrará en la red, información más detallada y precisa de lo que yo pueda mostrar, a modo de ilustración, en este post.  

Como indicaba anteriormente, el proceso consiste en ir provocando sucesivos fallos en cada paso, de forma que cada uno, nos aporte información adicional a usar en los pasos sucesivos.

Veamos un ejemplo:

Para empezar, un primer dato...

Introduciendo como Usuario:  ' HAVING 1=1 -- , el error que se nos muestra, es la punta del ovillo que estábamos buscando:

[Microsoft][ODBC SQL Server Driver][SQL Server]La columna 'CLIENTES.IDCLIENTE' de la lista de selección no es válida, porque no está contenida en una función de agregado y no hay cláusula GROUP BY. 

ya tenemos dos datos, el nombre de la tabla y el primero de sus campos. Ahora a por los siguientes...

Introduciendo como Usuario:  ' GROUP BY CLIENTES.IDCLIENTE HAVING 1=1-- , tenemos el siguiente dato:

[Microsoft][ODBC SQL Server Driver][SQL Server]La columna 'CLIENTES.NOMBRECLIENTE' de la lista de selección no es válida, porque no está contenida en una función de agregado ni en la cláusula GROUP BY.

... y así campo por campo hasta conocer la estructura de toda la tabla.

El siguiente paso es hacer fallar el sistema en la conversión de un tipo de dato, para que nos muestre el valor del dato que no se puede convertir.

Introduciendo como Usuario: ' AND CLIENTES.IDCLIENTE IN (SELECT TOP 1 CLIENTES.NOMBRECLIENTE FROM CLIENTES WHERE CLIENTES.NOMBRECLIENTE LIKE '%A%') -- , tenemos el siguiente dato:

[Microsoft][ODBC SQL Server Driver][SQL Server]Error de sintaxis al convertir el valor varchar 'Mi Nombre de Cliente' para una columna de tipo de datos int.

Este es solamente un ejemplo; que por prudencia no he querido mostrar completo, para ilustrar lo simple que puede ser acceder a unos datos en una web vulnerable a este tipo de ataque. 

Como se puede ver, no hace falta ser un avezado hacker, para realizar este tipo de intrusiones, aunque evidentemente, no todos los casos son tan sencillos como este.