28 de noviembre de 2009

Firma Digital (in) Segura

¡Hola!

En el día de hoy vamos a cambiar de tercio hablando de una de las aplicaciones prácticas que la tecnología ha llevado a nuestros hogares / empresas para facilitarnos la vida, la firma electrónica. Esta firma está contemplada en nuestra legislación bajo la Ley 59/2003 de firma electrónica (que tenéis aquí) y cuyo mayor impacto es equiparar la firma manuscrita con la firma digital. Ahora bien existen distintos tipos de firma que la ley contempla:

1. La firma electrónica es el conjunto de datos en forma electrónica, consignados junto a otros o asociados con ellos, que pueden ser utilizados como medio de identificación del firmante.
2. La firma electrónica avanzada es la firma electrónica que permite identificar al firmante y detectar cualquier cambio ulterior de los datos firmados, que está vinculada al firmante de manera única y a los datos a que se refiere y que ha sido creada por medios que el firmante puede mantener bajo su exclusivo control.
3. Se considera firma electrónica reconocida la firma electrónica avanzada basada en un certificado reconocido y generada mediante un dispositivo seguro de creación de firma.
4. La firma electrónica reconocida tendrá respecto de los datos consignados en forma electrónica el mismo valor que la firma manuscrita en relación con los consignados en papel.

Esto es, tenemos 3 tipos de firma. La 1) que es la más sencilla garantizará el no-repudio. La 2) garantizará el no-repudio y la integridad del documento firmado, esto es, que no ha sido alterado por terceras partes. La 3) que garantiza a través de dispositivos seguros de creación de firma todo lo anterior haciendo a esta firma equiparable a la manuscrita en términos jurídicos y legales.

Claro está si se aprovecha el marco legal que esta Ley nos brinda esto puede facilitar trámites a ciudadanos y ahorrar chorros de tinta a las empresas, el Gobierno sabiendo esto enmarcó la factura electrónica dentro del Plan Avanza y presentó el portal Factura-e donde se explica lo que es una factura digital y se proporcionan utilidades a las pymes para que trabajen con ella, ejemplos de facturas electrónicas, etc. Una de las aplicaciones generadas por el ministerio es Facturae, que pinta así:

Interfaz de FacturaE

Incluye tu propio gestor de facturas, envío de las mismas desde servidores SMTP con SSL, listado de servidores OCSP para validar certificados X.509, etc. Parece una buena aplicación, ¿no creéis?

En el mismo marco este verano el Ministerio de Industria, Comercio y Turismo lanzó la EcoFirma, otra aplicación de firma digital de extrema sencillez que acerca la firma digital a ciudadanos y pymes, permitiendo firmar casi cualquier tipo de archivo, desde .doc a imágenes pasando por PDF a los que se pueden incrustar marcas de agua, etc. EcoFirma tiene el siguiente interfaz:

EcoFirma, tan sencillo como esto.

Puede importar certificados de nuestros exploradores habituales (IE, Mozilla) facilitándonos enormemente los procesos de firma y validación de otras firmas.

Todo esto está muy bien pero no puedo evitar lanzarme unas cuantas preguntas, y es aquí cuando viene el verdadero motivo de esta entrada, ¿las firmas que realiza el software que provee el ministerior, son firmas reconocidas? Supongamos que utilizamos los certificados de nuestro DNI electrónico (si tenéis curiosidad por todas las cosas que lleváis en la cartera cuando tenés dentro el DNI electrónico echad un ojo aquí) para firmar un archivo, estos son certificados reconocidos tal como marca la Ley, ¿es el software un dispositivo seguro de creación de firmas? Indagando sobre ello vemos que en Kriptópolis ya se hicieron la misma pregunta, llegando a conclusiones negativas. Repasemos la Ley:

2. Un dispositivo de creación de firma es un programa o sistema informático que sirve para aplicar los datos de creación de firma.
3. Un dispositivo seguro de creación de firma es un dispositivo de creación de firma que ofrece, al menos, las siguientes garantías:
a) Que los datos utilizados para la generación de firma pueden producirse sólo una vez y asegura razonablemente su secreto.
b) Que existe una seguridad razonable de que los datos utilizados para la generación de firma no pueden ser derivados de los de verificación de firma o de la propia firma y de que la firma está protegida contra la falsificación con la tecnología existente en cada momento.
c) Que los datos de creación de firma pueden ser protegidos de forma fiable por el firmante contra su utilización por terceros.
d) Que el dispositivo utilizado no altera los datos o el documento que deba firmarse ni impide que éste se muestre al firmante antes del proceso de firma.

Luego SI, el software (un programa informático) puede considerarse un dispositivo seguro. Ahora bien, ¿quien me lo garantiza?, ¿los estándares internacionales?, ¿como se que no hay gato encerrado?. Simple y llanamente: no lo se y no podré saberlo. En última instancia siempre hay que confiar en alguien, el estado, las autoridades de certificación, la Ley. En mi opinión un software NUNCA debería estar considerado un dispositivo seguro, una combinación Sotware + Hardware SI, ¿por qué? Por que una appliance siempre será una combinación más robusta que código y más código (Maria José Caro de INTECO ofreció una ponencia sobre la seguridad de estos dispositivos bastante interesante). Más robusta y más cara claro, de ahí que se haya optado por la vía cómoda.

Lector de DNI Electronico

En un proceso judicial estas dudas que aquí nos surgen pueden ser indicadas a los jueces quienes inevitablemente tendrán que apoyarse en Peritos para que una firma electrónica no sea impugnada. Esto podría ser un grave problema si no fuese por que la Ley recoge que las partes pueden acordar previamente el sistema de firma electrónica a utilizar, si ese acuerdo se alcanza (y firma) no habrá apelación que valga. Ahora bien, ¿cuantos de vosotros habéis revisado los sistemas de factura electrónica de vuestros proveedores de telecomunicaciones, internet, banca, etc.?, ¿está el ciudadano indefenso viéndose obligado a aceptar y confiar en sistemas que desconoce? Parece que en parte, Si.

Una pequeña reflexión de fin de semana.

Salu2!

23 de noviembre de 2009

Sandboxie

Hoy presentamos una sencilla aplicación que hará las delicias de los muchas veces sufridos usuarios de máquinas virtuales. Una de las aplicaciones de estas últimas es disponer de un entorno “basura” en el que realizar nuestros experimentos, bajarnos esos archivos sospechosos o directamente analizar malware. Es probable que os pase como a mí, juntando fácilmente 4 o 5 de estas máquinas nuestro disco duro baja vertiginosamente, además se necesita mucha memoria RAM para que vayan decentemente ligeras.

Con SandBoxie se puede ahorrar bastante tiempo y recursos en maquinas virtuales, esta aplicación genera un entorno de virtual donde todo lo que se ejecute estará aislado del sistema operativo. Se integra en Windows perfectamente como una opción más del “botón derecho – click” y su complejidad es mínima:

Podemos trabajar con ficheros en un entorno virtual, darle los permisos que queramos sobre el entorno real, ubicar un espacio para almacenar aquellos archivos que querramos extraer de la cajita de arena, disponer de más de una sandbox, etc. Y todo esto de forma gratuita :)

Un detalle que me ha gustado es que no es trivial "salirse" de la sandbox, a pesar de que los procesos nuevos te aparezcan si haces un pslist lo que ellos generan está controlado y sus permisos restringidos. Por ejemplo, probad a ejecutar un cmd.exe en la sandbox y desde ahí un notepad, word, etc. No podréis grabarlos en la unidad física, casi casi como un appliance vmware. En la página de los autores hay un buen tutorial que os dejo por aquí , espero que os guste.

Happy Week!

21 de noviembre de 2009

El café está servido,,,

Microsoft’s Computer Online Forensic Evidence Extractor , COFEE () para los amigos, está circulando por Internet, o eso dicen multitud de blogs desde hace unos días. Y tiene que ser verdad aunque haya investigadores como Robert Graham que anuncien en su blog que la versión disponible solo aloja 45 utilidades / comandos, en lugar de los 150 que Microsoft anunció.

Pero, ¿Qué es Cofee? Bueno, en la primavera del año pasado surgieron comentarios y especulaciones como setas cuando Microsoft informaba al mundo de que entregaba COFEE a los cuerpos de policía y seguridad del mundo como herramienta de análisis forense, esto es, no había nada más que llegar con un pen drive a la escena del crimen, enchufarla y ella sola obtenía todos los datos de auditoría del equipo, se rumoreaba que aprovechaba puertas traseras desconocidas, que utilizaba algoritmos criptográficos avanzados para obtener las contraseñas de los usuarios (¿?¿?¿?), etc. Teoría conspiratoria al poder vamos.

Pues haciendo unas cuentas búsquedas en los corrillos de seguridad, descargando algún que otro torrent, etc. Efectivamente, damos con la herramienta en su versión 1.12. La misma incluye un completo manual de uso, instalación, configuración, generación de informes, etc. Su funcionamiento es sencillo, se instala en el equipo del investigador, generas un pen-drive personalizado con las herramientas asociadas a la investigación que se pretende realizar (puedes meter las 150, aunque se requerirá un USB de 2 GB para recolectar tanta evidencia), te vas al ordenador de la víctima y descarga todos los registros de auditoría y salida de los principales comandos de Windows y Sysinternals, también hace volcados de memoria por lo que está principalmente pensada para análisis forense en caliente. Una vez hecho esto se extrae el pen drive, el investigador vuelve a su “laboratorio” feliz y contento. Lo introduce en su equipo y,,, Cofee te genera un informe XML con todo lo que ha encontrado. Es decir, análisis forense for dummys.

A priori no hay “comandos secretos”, utilidades desconocidas, puertas traseras, etc. Solo una aplicación amigable que hace todo el trabajo de obtención de evidencias por nosotros, si esto es así, ¿Por qué Microsoft no la libera? Parece no tener mucho sentido por lo que dejo la pregunta en el aire. Ahora bien, no os emocionéis de sobremanera, tras bajar COFEE de distintas fuentes puedo constatar que la versión que se ha fugado es una 1.12 que, lamentablemente no he conseguido instalar y correr en un Windows 7, en un Windows Vista o en un XP. Parece que el instalador está corrupto (¿?), lo que sí se he podido ojear es el manual de la aplicación que confirma datos como, solo funciona en Windows XP con Framework 3.5 (es decir, que tiene que ser XP SP2), los comandos disponibles son conocidos y su principal beneficio es que proporciona la confianza de que las herramientas utilizadas no han sido comprometidas por un rootkit o similares, ya que cada una de ellas tiene su checksum una vez instalada en el dispositivo, si es alterada COFEE lo detectará.

Os dejo algunos pantallazos y la desilusión de no haber encontrado una versión que funcionase correctamente, será cuestión de tiempo supongo:


Interfaz de COFEE

Las herramientas secretas :-p

Recolectando evidencias...

Y nuestro informe XML.

Ahora copa y puro ;-)

Salu2!

Nota 26/11/2009 --> Por fin he conseguido solucionar el problema del instalador, si os lo bajáis y os ocurre lo que a mí probad con esta herramienta. Por cierto, ahora sí puedo corroborar todo lo contado :-D


17 de noviembre de 2009

La experiencia puede ser un riesgo

Disclaimer: Esta entrada es fruto exclusivo de las divagaciones personales del autor, no dispone de base científica y las opiniones vertidas no son siquiera demostrables, si piensas que el título de la entrada es un disparate quizás no debas seguir leyendo.

Tengo un colega dedicado al comercio de combustible, empresario él conoce todos los factores que pueden afectar a su negocio, que márgenes y umbrales son aceptables en sus negociaciones o cual es la tendencia actual del mercado. Como yo no tengo ni idea de por qué el gasoleo sube cuando hay un puente, o por qué si un día se enfada Chavez, al otro baja el barril de brent (o no) le propuse lo siguiente:

Quiero que me digas a cuanto va a estar el barril de petróleo mañana, dentro de una semana y dentro de un mes. Otros dos amigos míos tan ignorantes como yo hicieron sus apuestas, quedando el Excel de la siguiente forma:

Clark

Use

Pablo

GigA

Real

28-oct

77.93

77.86

77.22

76

77.74

04-nov

79.50

80.15

78.24

70

80.27

28-nov

82.69

85.06

77.77

85

El experto se aloja bajo el pseudónimo de Clark, hay que decir que ninguno de nosotros sabíamos las predicciones que el resto iban a hacer (si no estaríamos condicionados y Clark sería nuestra referencia). A día de hoy el brent ha bajado de nuevo a los 79$ el barril y salvo sorpresa no se prevé que se anime tanto como para llegar a los 85$ (mi apuesta). Hasta ahora nuestro experto (Clark) ha acertado 2 previsiones, igual que ha hecho Use, Pablo acertó 1 y yo (nunca fui bueno en las apuestas) ninguna. Sin embargo tenemos ya una conclusión: el experto no parece que vaya a acertar mucho más que el resto de ignorantes, en el mejor caso puede acertar todo (Use 2, Pablo1, yo 0), en el peor puede acertar menos que Use y 1 más que Pablo y que yo, en el normal Pablo Use y Clark tendrán 2 aciertos y yo ninguno.

Estaréis conmigo en que la muestra es pequeña, el valor real del experto quizás se podría apreciar mejor conforme pasa el tiempo, a 2 meses, 3 meses, 1 año, ¿verdad? Pues en opinión del experto esto no es así, la incertidumbre se dispara a futuro y el pasado cada vez es una referencia menos válida, si bien para el precio del crudo las variables económicas que interfieren son bien conocidas, podríamos decir que ocurre lo mismo exactamente en otros mercados como la Bolsa, el precio del Oro, el valor de las pipas o la posibilidad de que mi empresa cierre el año que viene.

Día a día me enfrento en el trabajo a análisis de riesgos, se detectan las amenazas sobre un sistema (que cubre una necesidad de negocio), se acotan, se mapean unas medidas compensatorias, se establecen controles de seguridad, se ofrecen indicadores sobre los controles, etc. Cuando has revisado 30 arquitecturas distintas riesgos, medidas, controles, etc. te van saliendo como churros. TODO ES SEGURO.

Mientras tanto el sol sigue saliendo por las mañanas, con un poco de suerte nuestra nómina va engordando poquito a poco, asumimos que todo va más o menos bien, hay Seguridad, la vamos manteniendo, los procesos de negocio se van ofreciendo con confianza, el barco avanza viento en popa a toda vela. Entonces un día algo hace “crack”, estalla la guerra en Pakistán, el precio del petroleo sube a 200 $ por barril (como vaticinaba cierto presidente 1 mes antes de comenzar la crisis), o quizás un miembro del Cuerpo Directivo ha estado aprovechando sus poderes para manejar cientos de millones en la sombra hacia ciertas áreas de interés, también es posible que nuestro Active Directory se infecte por un virus y tengamos cientos de usuarios que no pueden trabajar, además como ese virus es muy maligno se replica a servidores, puestos de trabajo, etc. Mierda, y el plan de continuidad de negocio desfasado, ¿Qué hacemos, a quien llamamos?, ¿Dónde estaremos mañana?

Yo no se vosotros pero yo veo muy relacionado el precio del barril de crudo, la economía de Mongolia y que mi CPD no se caiga, llámalo efecto mariposa, llámalo Cisne Negro:

Pero la realidad es que todo va bien, exactamente igual que un pavo estamos 300 días seguidos siendo alimentados 3 veces al día, sin sospechar que el día 301 es el “Thanks Giving Day” entonces nuestro cuello es cortado, nos rellenan de Dios sabe qué y “al horno”. Es muy oportuno hablar de estos cambios en “tiempos de crisis”, cuando hace 18 meses no había Crisis (por activa y por pasiva) y hoy en día todos corren por salir los primeros de ella, los analistas hacen sus estimaciones económicas a 1 año (se equivocan), los Directivos establecen su plan de negocio para los siguientes 2 – 3 años (se vuelven a equivocar) y los más ávidos se imaginan como serán su negocio dentro de 5 años o estiman que la jubilación en el 2030 será a los 67 años por que la economía no será sostenible para entonces (supongo que por que ahora si es sostenible). Todos se equivocan y no pasa nada, ¡nadie puede predecir el futuro!, y es verdad, nosotros no somos una excepción. Estamos hechos para pensar de pasado a presente, en base a ello definir un futuro “probable” o no. Pasábamos el relajado verano de 2008 viendo cómo Kaminsky anunciaba una vulnerabilidad en los DNS a todo el mundo, y todos estuvimos esperando que los fabricantes sacaran los respectivos parches y auditando si éramos vulnerables (efectivamente, lo éramos), quizás el verano que viene se publique una nueva que comprometa seriamente (aun más) el HTTP – SSL, y veremos que tenemos que tocar todos nuestros servidores web o cambiar el paradigma de seguridad en los frontend ya que nos hacen un deface (en el mejor de los casos) día si y día también. Pero estos serían casos menores, es posible que el CPD de google se hunda por que han decidido dejarlo en alta mar y llegó un maremoto, un avión se puede estrellar contra nuestros edificios o la Gripe A que ya a nadie preocupa ha mutado y no vamos a quedar nadie para contarlo, ¿quien sabe?

Los sucesos inesperados a la par que improbables son (vaya paradoja) periódicos, esto también ocurre en nuestro mundo acotado a protocolos y tecnologías, sin embargo se olvida. No se si a vosotros os pasa pero a mi sí, se comienzan a suponer cosas, el SSL cifra muy bien, las VPN nos proporcionan acceso seguro a través de redes inseguras, mis certificados no caducan hasta el 2020 así que no hay prisa, al final es todo SOTA, CABALLO y REY. Entonces surge el riesgo (muy pocas veces materializado) de que aparezca el JOKER y se ría de nosotros, puede tener cualquier cara (es un JOKER) y no nos lo esperaremos, pero cuando se haga realidad su impacto negativo será enorme. También es posible que ocurra al revés, que un día os hagáis en vuestra casa una herramienta para hablar con vuestros colegas, no se, algo como “Facebook”, y resulta que empieza a extenderse como un reguero de pólvora y en 4 años estás tomando copas con Larry Page , Bill Gates, Linus Torvalds y Chad Harley (curiosa fiesta).

En fin, este es un tema sobre el que me gusta debatir mucho, la experiencia es sin duda un buen aliado pero nunca podemos suponer en exceso, siempre hay gente por ahí que se olvida de todo lo que hay y crea algo nuevo, que nadie preveía, ese alguien podemos ser nosotros, y ese algo puede ser maravilloso, pero también puede ser terrible.

¿Y vosotros, os arriesgáis por vuestra experiencia?

Salu2

PD: ¿A cuanto estará el brent el 28/11?

14 de noviembre de 2009

Joomla SQL Injector & Bruteforce

Los sitios Web basados en el gestor de contenidos Joomla se han extendido como moscas, los éxitos en Internet son así. Hace 4 años nadie apostaba un duro por una compañía llamada youtube y hoy sus creadores nadan en piscinas de oro, con joomla ha ocurrido algo parecido, apareció en el 2005, gustó y triunfó. Ahora cualquiera tiene su sitio web basado en joomla (Powered with Joomla!).

Actualmente corre una versión estable 1.5, lo que significa que en 4 años no han existido grandes revoluciones en su motor, eso sí, las plantillas existentes se cuentan por miles. Basado en PHP Joomla también tiene sus “cositas” de Seguridad, RFI, SQL Injection, XSS, etc. concretamente ayer me encontré con un SQL Injector escrito en Python muy sencillo de usar, incluye las alrededor de 123 vulnerabilidades de este tipo disponibles, en la página de descarga van actualizando el script a medida que se hacen públicas más vulnerabilidades, lo ejecutamos indicándole que cargue la lista de sitios web de list.txt y:

|---------------------------------------------------------------|

| beenudel1986[@]gmail[dot]com |

| Joomla Sql Injection Scanner 2.5.6 |

| 11/2008 joomsq.py |

| Do Visit www.BeenuArora.com & darkc0de.com |

| Total: 123 Vulns |

|---------------------------------------------------------------|

Enter the DB prefix or press Enter to use default

Do you think target has salted or unsalted version ! press y for yes or n for n o y

[+] JoomlaPath: www.*********gital.es

[+] Vuln. Loaded: 123

[+] Testing...

[-] Done

[+] JoomlaPath: www.p******o.com

[+] Vuln. Loaded: 123

[+] Testing...

Decepción, no me encuentra nada. Y es que a no ser que encontréis una página desarrollada con un Joomla antiguo (anterior 1.5) no funcionará. Desanimado pruebo un Joomla BruteForce Cracker también disponible en el sitio de “Dark Codes”, me descargo un pequeño diccionario (23000 palabras), ejecuto y:

|----------------------------------------------|

| rsauron[@]gmail[dot]com v1.0 |

| 7/2008 joomlabrute.py |

| - Joomla Administrator Panel BruteForcer |

| Usage: joomlabrute.py [options] |

| -h help darkc0de.com |

|----------------------------------------------|

[+] Proxy Not Given

[+] BruteForcing:http://www.p*********.com/administrator/

[+] Username:pluks

[+] Words Loaded: 213560

[+] [12:10:47]

[!] Login Successfull: pluks:aa

[-] [12:10:49]

[-] Total URL Requests 1

[-] Done

¿Suerte? No lo creo, confirmo la sospecha, es un “falso positivo”. ¿Cómo puede ser?, bueno los mensajes de error en Joomla son configurables, el script solo busca en la página web si aparece la palabra “username”, si no está supone que hay autenticación exitosa (un poco cutre quizás), sustituimos esa palabra por nuestro mensaje de error, ejecutamos nuevamente y:

|----------------------------------------------|

| rsauron[@]gmail[dot]com v1.0 |

| 7/2008 joomlabrute.py |

| - Joomla Administrator Panel BruteForcer |

| Usage: joomlabrute.py [options] |

| -h help darkc0de.com |

|----------------------------------------------|

[-] Proxy Not Given

[+] BruteForcing: http://www.p**********o.com/administrator/

[+] Username: pluks

[+] Words Loaded: 213560

[+] [13:28:04]

[-] Login Failed: aa

[-] Login Failed: aal

[-] Login Failed: aalii

Esto tiene mejor pinta, ahora es solo cuestión de tiempo. Como vemos los administradores de sitios web basados en Joomla tampoco pueden relajarse en términos como robustez de contraseñas, actualización de parches, etc. Si no pueden encontrarse fácilmente con un deface :-p

Buen fin de semana!

9 de noviembre de 2009

reCAPTCHA

Creo que la medida de seguridad que hoy voy a presentar a pesar de ser bien conocida -a la par que odidada en algunas ocasiones- añadirá un puntito adicional a su favor que otras soluciones parecidas no disponen: bajo coste y robustez. Hablábamos hace un par de entradas de “encuestas seguras”, su cada vez mayor presencia y relevancia en los medios de comunicación que pueden (y no es erróneo decirlo) engañar a la opinión pública. Pues bien, una aplicación práctica de reCAPTCHA es la protección contra ataques por repetición en las encuestas. Claro está a alguno le puede parecer exagerado para una encuesta, es solo un ejemplo, seguro que se os ocurren otras muchas aplicaciones.
Entrando en detalle, reCAPTCHA es un servicio que puede incrustarse de forma gratuita en cualquier aplicación web, incluye 2 palabras distintas que deben escribirse separadas, lo cual añade un puntito más de robustez. Además incluye compatibilidad para discapacitados permitiendo la emisión de CAPTCHAs en forma de sonido. Para instalarlo es necesario darse de alta en el sistema con el dominio que se vaya a utilizar, con esto se nos proporcionarán dos claves, una pública y una privada. Al incrustar el siguiente código javascript en nuestro frontal web:

Se hará una llamada a los servidores de recaptcha y se incrustará el desafío en el frontal, lo que vayamos a hacer con él ya es nuestra decisión. Ahora bien dependiendo del lenguaje de nuestra aplicación web deberemos acudir aquí para obtener los recursos que analicen y verifiquen el CAPTCHA, por ejemplo en ASP deberemos añadir una librería a nuestro proyecto que contiene una serie de llamadas para verificar el CAPTCHA, este proceso se realiza nuevamente contra servidores externos, para mayor claridad:

Es decir, en 1) el usuario carga la página web que tiene incrustado el CAPTCHA, en 2) el browser solicita a los servidores de reCAPTCHA el reto, esta petición la hace con la clave publica del servidor. Después en 3) el usuario soluciona el reto y esa solución es enviada al servidor de aplicaciones (o el frontal web dependiendo de la arquitectura), en 4) este servidor contacta con el API Server, aquí es cuando se utiliza la clave privada para verificar que efectivamente la petición no ha sido manipulada en su recorrido, el API server devuelve el resultado del desafio, esto lo recogerá el servidor de aplicaciones proporcionando una respuesta dependiendo de si se ha superado el desafió o no.


¿Sencillo? A mi me parece que sí, como detalle final añadir que el API Server detecta las IP de los clientes que solucionan “muchos” CAPTCHA en pocos minutos, evitando así que en caso de que el desafío se haya visto comprometido se realicen ataques por repetición bloqueando la IP origen temporalmente.


Bueno, bonito y barato, lo ideal para comenzar la semana :)

Salu2


PD: Entrada relacionada de Breaking CAPTCHAS.

6 de noviembre de 2009

Data Carving Challenger

Al hilo de nuestra anterior entrada sobre zombies, en otra de esas maniobras de parecidos razonables hoy vamos a coger la pala y cavar, cavar y cavar hasta que saquemos los cuerpos del delito, aunque los ingleses tienen un verbo algo más extraño para estas tareas, se llama carving (trinchar), Data Carving.

En el reto forense de hoy nos han proporcionado un raw de aproximadamente 41 MB, esto es un archivo binario cuyo contenido es desconocido, podemos imaginar que ha sido extraído de un disco corrompido o formateado, nuestra labor es extraer el contenido del disco y descubrir de forma inequívoca lo que en el había. Antes de ponernos los guantes de manipular cadáveres, vamos a repasar algunos conceptos necesarios:

La magia de los números

Como es sabido, los ficheros no son más que un conjunto binario que, agrupado por ciertos patrones diferencia a unos de otros. Por ejemplo, si esos números en binario forman la combinación 25 50 44 46 al comienzo de un archivo sabremos que estamos delante de un PDF (además que la traducción a hexadecimal es %PDF). Bien, los sistemas operativos se basan en los conocidos como “magic numbers” para identificar los archivos y saber que acciones puede ejecutar con ellos. En Linux el comando file es el encargado de identificar los magic numbers al principio y final de un archivo para saber qué es, si hacemos un man file:

“file tests each argument in an attempt to classify it. There are three sets of tests, performed in this order: filesystem tests, magic number tests, and language tests. The first test that succeeds causes the file type to be printed. The type printed will usually contain one of the words text (the file contains only printing characters and a few common control characters and is probably safe to read on an ASCII terminal), executable (the file contains the result of compiling a program in a form understandable to some UNIX kernel or another), or data meaning anything else (data is usually `binary’ or non-printable). Exceptions are well-known file formats (core files, tar archives) that are known to contain binary data. When adding local definitions to /etc/magic, preserve these keywords. People depend on knowing that all the readable files in a directory have the word “text” printed. Don’t do as Berkeley did and change “shell commands text” to “shell script”. Note that the file /usr/share/file/magic is built mechanically from a large number of small files in the subdirectory Magdir in the source distribution of this program.”

Comprobamos que “file” hace 3 test, 1º pregunta al filesystem para saber como lo identifica, 2º comprueba los números mágicos, 3º hace comprobaciones de lenguaje. Es sencillo engañar al comando file. Podemos manipular el directorio /usr/share/file/magic y dejar el file con cara de poker ya que en ese archivo está el repositorio que asocia números y formatos de archivo:

O podemos cogernos un editor hexadecimal, hacer unos cambios aquí y allá y encontrarnos con que un script es realmente,,, ¡un ejecutable MS-DOS!:

File System

Ahora que sabemos cómo identificar a los archivos tenemos que saber que no todos los sistemas operativos los guardan de igual forma, dependerá exactamente del formato que tenga el file system, FAT 16/32, NTFS o UFS /JFS son algunos de los formatos que rigen la arquitectura de los file sytem. Desde una perspectiva forense debemos saber que dependiendo de varios factores nuestros archivos se pueden encontrar fragmentados (es decir, divididos en regiones de memoria distintas), además esa fragmentación no tiene por qué ser consecutiva, puede haber trozos que han sido sobrescritos por otros (por ejemplo, tras un borrado y escritura) y se han perdido o incluso el archivo puede estar comprimido (compresión NTFS), esto puede complicar mucho las cosas,,, a priori.

Manos a la obra

Ahora que tenemos conocimientos básicos sobre los archivos y su estructura de almacenamiento es momento de abordar el “DFRWS Forensic Challenge Images”. Para este reto aconsejo bajar una distribución forense, la que he utilizado yo es Helix 2008 RC1, disponible aquí como appliance de máquina virtual. Dentro de esta distribución descargamos y descomprimimos el raw y ejecutamos foremost . Esta herramienta es la llave inglesa del Data Carving, si hacemos un foremost –h vemos todas las opciones:

foremost version 1.5 by Jesse Kornblum, Kris Kendall, and Nick Mikus.

$ foremost [-v|-V|-h|-T|-Q|-q|-a|-w-d] [-t ] [-s ] [-k]

[-b ] [-c ] [-o] [-i]

-V - display copyright information and exit

-t - specify file type. (-t jpeg,pdf ...)

-d - turn on indirect block detection (for UNIX file-systems)

-i - specify input file (default is stdin)

-a - Write all headers, perform no error detection (corrupted files)

-w - Only write the audit file, do not write any detected files to the disk

-o - set output directory (defaults to output)

-c - set configuration file to use (defaults to foremost.conf)

-q - enables quick mode. Search are performed on 512 byte boundaries.

-Q - enables quiet mode. Suppress output messages.

-v - verbose mode. Logs all messages to screen

Con el archive de configuración por defectoy y sin habilitar la opción de detección de indirección de bloques es capaz de recuperarnos 25 archivos:

Foremost started at Wed Oct 28 11:22:24 2009

Invocation: foremost dfrws-2006-challenge.raw -o forensic.txt

Output directory: /home/bagside/Desktop/forensic.txt

Configuration file: /etc/foremost.conf

------------------------------------------------------------------

File: dfrws-2006-challenge.raw

Start: Wed Oct 28 11:22:24 2009

Length: 47 MB (49999872 bytes)

Num Name (bs=512) Size File Offset Comment

0: 00003868.jpg 280 KB 1980416

1: 00008285.jpg 594 KB 4241920

2: 00011619.jpg 199 KB 5948928

3: 00012222.jpg 6 MB 6257664

4: 00027607.jpg 185 KB 14134784

5: 00031475.jpg 206 KB 16115200

6: 00036292.jpg 174 KB 18581504

7: 00040638.jpg 292 KB 20806656

8: 00041611.jpg 1 MB 21304832

9: 00045566.jpg 630 KB 23329792

10: 00094846.jpg 391 KB 48561152

11: 00000009.htm 17 KB 4691

12: 00004456.htm 22 KB 2281535

13: 00027496.htm 349 KB 14078061

14: 00028244.htm 50 KB 14460928

15: 00029529.htm 183 KB 15118957

16: 00032837.doc 282 KB 16812544

17: 00045964.doc 71 KB 23533568

18: 00028439.zip 157 KB 14560768

19: 00030050.zip 697 KB 15385752

20: 00045015.zip 274 KB 23047680

21: 00007982.png 6 KB 4086865 (1408 x 1800)

22: 00033012.png 69 KB 16902215 (1052 x 360)

23: 00035391.png 19 KB 18120696 (879 x 499)

24: 00035431.png 72 KB 18140936 (1140 x 540)

Finish: Wed Oct 28 11:23:19 2009

25 FILES EXTRACTED

jpg:= 11

htm:= 5

ole:= 2

zip:= 3

png:= 4

Sin embargo el resultado no es satisfactorio siempre, por ejemplo en algunas imágenes nos encontramos:

Existen herramientas alternativas como photorec y testdisk capaces de detectar más archivos, el problema es que el número de falsos positivos es altísimo (a mí me ha detectado unos 3000 archivos, 20950 de ellos falsos xd). Si habilitamos las opciones de búsqueda avanzada de foremost, o buscamos algunas extensiones en concreto encuentra exactamente lo mismo, tampoco es capaz de recomponer las imágenes fragementadas, ¿qué podemos hacer en este caso?

Vamos a centrarnos por ejemplo en nuestro amigüito el puercoespín, archivo 5 de los listados anteriormente. Si lo abrimos veremos que sale partido, se reconoce el tamaño de la imagen correctamente pero hay algunos bits que están en otro sector así que no puede formarla completamente. Sabemos que el tamaño del archivo son 206 KB, sin embargo descubrimos (esta imagen la obtiene photorec, mientras que foremost no la detecta) que existe un archivo con una foto de Marte en la posición 31532, es decir, 57 Kb después, ¿Dónde están los demás? La foto de Marte comienza cuando la anterior todavía no ha finalizado, quedando ambas corrompidas. Aquí debemos fijarnos en qué posición comienza cada fotografía y el Offset, esto es 31475-31532 para el puercoespín y 31533-32836 para marte. En primer lugar extraemos esos 57 KB del puercoespín a un archivo con el comando dd:

bagside@bagvapp:~/Desktop$ dd if=dfrws-2006-challenge.raw skip=31475 count=`expr 31532 - 31475 + 1` > hedgehog1.jpg

58+0 records in

58+0 records out

29696 bytes (30 kB) copied, 0.0176145 s, 1.7 MB/s

Luego añadimos el trozo que falta a partir del trozo que sí que conocemos de marte:

bagside@bagvapp:~/Desktop$ dd if=dfrws-2006-challenge.raw skip=31753 count=`expr 32836 - 31753 + 1` > hedgehog1.jpg

1084+0 records in

1084+0 records out

Y podemos ver a Rizo:

Una vez que la foto ha sido reconstruida podemos utilizar photorec para obtener los datos exactos del archivo, a partir de ellos recomponer la foto de marte y el resto de fotos detectadas es trivial. Claro está, ese proceso puede ser largo y arduo, además puede diferir según el tipo de archivo.

En el post de hoy hemos visto técnicas de Data Carving y la forma en que trabajan estas herramientas, también hemos visto como el componente humano sigue siendo fundamental, os animo a que practiquéis por ejemplo, con una carpeta en la que habéis borrado todo (sin borrado seguro, obviamente) o un pendrive formateado y reescrito.

Salu2.