Primer articulo redactado para el blog jfabello.es por Norberto Gonzalez (@Nicky69es), en el se centra en el mundo del peritaje informático, de como tratar las evidencias digitales y seguir la cadena de custodia de las mismas.
Creo que todos tenemos claro como realizar una copia bit a bit de un disco duro que podemos extraer con seguridad de un ordenador y posteriormente precintar ese disco duro e iniciar una cadena de custodia sobre el mismo para, en caso de que se tenga que realizar una nueva copia, quede intacta. Terminando con la obtención del hash que más nos guste para comprobar la integridad posterior de la evidencia obtenida.
Se ha escrito mucho sobre el tema y se dan varias indicaciones en los múltiples cursos sobre pericias informáticas ofertados, pero al final queda una extraña sensación sobre la integridad de la prueba. Los problemas surgen cuando se hace la copia digital de equipos vivos o de discos duros sólidos (SSD), de estos últimos sabemos que cambia el checksum cada vez que lo obtenemos, por motivos que no son de este artículo, de los primeros cambia según ya estamos obteniendo la evidencia.
Voy a intentar aportar mi visión y proponer un método que, aunque no es infalible, sirve como las contraseñas complejas, dificulta su “eliminación”.
En sí, las pruebas, digitales o no, se basan en diferentes criterios. Si somos expertos en una materia nuestra palabra prevalecerá sobre la del resto, pero si hay un segundo experto que nos contradice, habrá que buscar el criterio de un tercero para ver quién se acerca más a lo reconocido en la comunidad. Si no somos expertos, basta con que sea creíble y posible, y si tenemos el testimonio de un tercero fiable, mejor. Al final, de una u otra forma, la validez dependerá de que teniendo la suma de nuestra exposición y la de la parte contraria, sea más válida para el juez la nuestra.
Cuando creamos una evidencia digital, siempre nos hemos preocupado de que los cheksum de origen y destino coincidieran. En realidad lo que tenemos que comprobar y dejar constancia es el hash de la evidencia que hemos obtenido, la evidencia sobre la que vamos a trabajar, porque de esa evidencia vamos a sacar los datos que a la parte que nos ha pedido el informe le servirán para acusar o librerar de la causa a su cliente.
Normalmente tenemos un archivo evidencia con un md5sum&sha1sum y presentamos algunos de los archivos que contiene y que sirven de prueba. De estas ‘pruebas’ que extraemos de la evidencia tenemos que obtener el cheksum individual antes de manipularlos y para que conste en nuestro informe. El fin es conseguir que si otro perito realiza nuestros pasos, obtenga los mismos resultados: partiendo de un archivo con un cheksum dado, extrae las mismas evidencias cuyo cheksum también coincidiría con el que nosotros hemos obtenido. Por tanto podemos olvidarnos del cheksum del dispositivo origen porque ha quedado constancia en el informe del volcado. Pero siempre que el origen haya quedado precintado, puede comprobarse que ambos cheksums coinciden.
La integridad del archivo de evidencia obtenida la corroboramos con nuestro informe como expertos, y en todo caso, con el testimonio de quien estuviera en el momento de la obtención, que debería declarar que “tras una copia de datos de un soporte origen, hemos obtenido un archivo con un tamaño de n bytes y que ha arrojado un sum md5 y sha1 X”.
Cuando realizamos una copia de un sistema en vivo, de una parte de un sistema, de un disco sólido; bastaría con que la parte contraria sembrase la duda sobre si la evidencia sobre la que hemos trabajado es realmente la que obtuvimos o es otra que hemos creado como expertos y que nos arroja el mismo checksum.
Por lo tanto, para tener un archivo evidencia desde dispositivos origen cuyo cheksum cambie o equipos que deban continuar funcionales, y que esta evidencia contenga una mayor validez probatoria propongo hacerlo de la siguiente forma:
1.- Obtenemos el volcado por el sistema que mejor conozcamos y por tanto, mejor podamos defender en un juzgado. P.E.(dd if=/particion of=/evidencia.dd)
2.- Obtenemos las funciones hash de nuestra elección de la evidencia obtenida. (md5 && shasum ./evidencia.dd)
3.- Extraemos un número determinado de archivos desde la evidencia, obteniendo el cheksum de cada uno de ellos.
4.- Obtenemos el cheksum de los mismos archivos del punto anterior, pero en el origen, y comparamos con los extraídos de la evidencia para validarlos.
5.- Uno o mas de los archivos a obtener el checksum en origen y evidencia, debería ser archivos que no se vean alterados por actualizaciones del sistema.
Con estos pasos hemos conseguido tener un archivo de evidencia con una firma que lo identifica, además de una certificación extra del contenido de la misma con las firmas de los archivos en origen y evidencia, corroborada por los presentes en el momento de la obtención, de lo cual quedará copia en el informe pertinente.
A partir de ese momento ya es cuestión de trabajar con nuestros métodos habituales de “trabajo sobre copia”, manteniendo evidencia inalterable.
En mi opinión, la cadena de custodia se realiza sobre “algo” que nos entregan para guarda o estudio, no se puede mantener sobre algo que no tenemos el almacenaje, pero sí sobre cómo estaba un sistema en el momento en que hemos obtenido la copia. Es decir, comprobamos el estado de lo que nos entregan para custodia, lo hacemos constar y lo mantenemos en el mismo estado, anotando cada cambio que pudiera sufrir bajo nuestra custodia.
En resumen. Certificamos con otras personas la imagen que obtenemos del sistema y aumentamos la validez de la copia certificando que algunos archivos de la copia son los mismos que los que se encuentran en el sistema.
Espero que os haya sido de utilidad.
Autor: Norberto González @Nicky69es