Buenas a todos, la pasada semana publicamos el 9º reto de Flu Project, al que titulamos "Catástrofe Aérea". En este reto os encontrábais ante "un trozo" del disco duro de un servidor clonado mediante "dd". En ese disco duro se encontraba instalado un servidor web Apache que servía una aplicación web de la empresa JKNM Technologies y desde la que sus empleados descargaban documentos confidenciales de los aviones que fabricaba previa autenticación con un usuario y contraseña válidos. Hasta aquí ninguna novedad, pero a lo largo de este artículo descubriremos como un problema de código, una simple línea, ha sido la culpable de la muerte de varias personas. Muchos me diréis, ¡es que le echáis mucha imaginación, eso en la realidad no pasa! Por suerte, este reto es ficticio, pero os aseguro y es algo que la gente que leeis éste y otros blogs del gremio ya sabéis, los problemas de seguridad que sufren robots y autómatas en empesas de fabricación, sistemas scada en infraestructuras críticas, software de control aéreo, incluso servidores vulnerados como en el caso del presente reto, pueden costar vidas. Son largas las conversaciones que mantuve con mi buen amigo y antiguo profesor Javier Garzás, sobre la Calidad del Software que se fabrica en las Factorías de Software y de todas ellas acabábamos sacando las mismas conclusiones, programar mal software sale caro, y cuando hablamos de vidas humanas, no hay forma monetaria de valorarlo.
Tras la chapa de inicio, pongámonos manos a la obra con el reto.
Normalmente en un análisis forense os entregarán una copia física del disco duro a analizar, siempre que no os toque directamente realizarla vosotros mismos. Nosotros ya os proporcionamos directamente el clonado del disco duro, y además, os limpiamos todos los archivos que no eran de interés en el pericial, facilitando la resolución del reto.
Ahora deberíamos comprobar los hashes del disco duro para verificar que no nos han dado gato por liebre. Para ello podríamos utilizar por ejemplo las utilidades "md5sum" y "sha1sum":
Cómo ya hemos explicado en la cadena Herramientas Forense para ser un buen CSI, una vez que tenéis un disco duro clonado mediante dd podéis abrirlo con alguna utilidad como FTK Imager o Autopsy, para esta ocasión nosotros nos decantamos por este segundo, por su posibilidad de parsear y recopilar los archivos localizados en función de su tipología.
Nada mas abrir el disco duro vemos que se trata de un sistema de ficheros NTFS. Lo primero que llama la atención es que Autopsy localiza casi 300 cuentas de correo electrónico. Más adelante veremos de donde salen estas cuentas, pero ya os adelantamos que provienen de un archivo añadido para despistar:
Además de las cuentas de correo electrónico nos localiza varias imágenes y un archivo eliminado que luego analizaremos.
Un tema importante cuando analizamos un disco duro es que nos fijemos en los metadatos con las fechas de creación y modificación de los archivos. Por ejemplo, en la siguiente captura podéis ver cuando diseñamos el reto, aunque no aportaba valor para su resolución, es un dato importante a tener en cuenta en una pericial:
Si abrimos la sección imágenes de Autopsy podremos enumerar las imagenes localizadas en el disco duro, como vemos todas se encuentran en la carpeta servida por el servidor Apache hacia Internet o hacia la Intranet, luego lo descubriremos:
Bien, una vez que hemos visualizado la información en función de su formato, vamos a abrir las carpetas del disco duro en busca de posibles logs que puedan darnos más información sobre lo que pasó el día fatídico:
Como vemos existen cinco logs con información sobre los accesos, errores PHP, bbdd mysql, etc.
Por otro lado nos encontramos con la carpeta www, desde la que un Apache está sirviendo una aplicación web y en la cual se encuentra el archivo "zip" que identificamos anteriormente que había sido eliminado:
Una vez recopilada toda la información, vamos a analizarla archivo por archivo. Como vemos, existen archivos con tamaño 0, por lo que directamente los descartaremos.
Otro log existente y que tampoco nos aportará ningún valor en esta investigación será el mysql.log, ya que la aplicación web publicada no hace uso de BBDD:
Otro log que encontraréis y que tampoco nos aportará mucho valor (aunque sí algo) es el apache_error.log:
El archivo access.log ya es otro cantar, ya que en él se registran los accesos a la aplicación:
Cómo su tamaño es bastante grande, analizarlo desde Autopsy es incómodo, por lo que lo extraremos a nuestro equipo:
Nada más abrirlo veremos como el día 23 de Octubre un usuario desde la IP 134.0.11.133 realizó un ataque de tipo "fuzzing", intentando localizar páginas web que colgasen del dominio de JKNM Technologies a través de un diccionario que contenía palabras tan curiosas como "Goku", "Vegeta", etc. Esta IP (pública) era inventada y parece ser que está localizada por algún lugar céntrico de Madrid :). Además nos indica que la aplicación se estaba sirviendo a Internet)
Si alguno sois usuario de nuestra herramienta ANUBIS, os habréis dado cuenta que la muestra del log se corresponde con el diccionario que viene incluido en Anubis para integrar los ataques de fuzzing con la aplicación "wfuzz".
En la línea 58, se puede ver como finaliza dicho ataque, sin éxito (todas las peticiones GET son respondidas con un error 404 NOT FOUND):
Inmediatamente después, el mismo usuario carga varias veces la página de autenticación, por lo que podemos suponer que está intentando autenticarse en el sistema y está fallando, y la aplicación le está redireccionando automáticamente a la página de login (podremos contrastar nuestra hipótesis más adelante analizando el código fuente de la aplicación web). Es posible que el usuario esté intentando realizar algún tipo de inyección de código, pero como veremos más adelante en la aplicación, se realiza por POST, y con los medios que contaban nuestros amigos de JKNM, no era posible registrar dicha información.
En la línea 104 del log vemos como el usuario malicioso logra autenticarse, y acceder a "menuPrincipal.php":
Y más adelante, casi al final del log, vemos como el usuario descarga un archivo ZIP del servidor:
Tras analizar los logs iremos a la carpeta www. Aquí nos encontraremos, entre otros, con el archivo "planes.txt", que aunque por el nombre algo confuso por el doble significado de la palabra en inglés y español, solo contenía una colección de dibujos ascii de aviones con licencia GPL que podéis descargar gratuitamente desde Internet. En ese documento se encuentran los nombres y correos electrónicos de las personas que realizaron los diseños de los aviones, y por ello Autopsy recopilaba tantos emails del disco duro:
A continuación abriremos el código fuente de la aplicación, en busca de algún bug que pueda padecer el aplicativo y por el que el usuario malicioso ha logrado acceder al sistema. Como vemos, uno de los primeros fallos importantes que vemos es que todos los usuarios de la empresa compartían el usuario administrador, por tanto, de haber sido un empleado el ladrón de los datos, no sabriamos identificar quien es:
Pero en este caso el fallo no se encontraba en el usuario, sino en una vulnerabilidad de inyección "XPath" y que ya analizamos en un reto hacking pasado. Gracias a ello, el usuario malvado "pudo acceder" a "menuPrincipal.php" aunque no podemos descartar que conociese previamente el usuario y la contraseña, al no haber registro de las inyecciones de código:
Como vemos en la captura anterior, este PHP nos mostraba un link para descargar un "zip". Que si lo buscamos en el disco duro vemos que ha sido eliminado, por lo que es posible que más adelante alguien desde dentro de la organización haya accedido para eliminarlo, bien con intenciones de borrar rastros o bien para impedir que ese archivo sea descargado por otros usuarios ampliando las posibilidades de que vuelvan a caer en malas manos. Estas conclusiones se intentarían responder en un caso real solicitando las cámaras de acceso al CPD, logs capturados por herramientas SIEM desplegadas por la red, logs de los firewall, etc.
Desde el propio autopsy podremos ver como dentro del zip hay un fichero llamado "programa.txt". Vamos a extraer el archivo al equipo para abrirlo:
Una vez abierto, aparte de una "interesante charla entre colegas" vemos que uno de los usuarios le indica a otro de la organización que no ha podido subir los planos al servidor corporativo por algún tipo de problema, y se los ha dejado en otro servidor (algo más público):
Si descargábamos el PDF podíamos ver los planos (catalogados como "Difusión Limitada") del modelo del avión siniestrado, mostrando un punto débil en la zona en la que los supervivientes del accidente oyeron la explosión. Visto esto, imagino que a la mayoría se nos pasa por la cabeza la posibilidad de un atentado terrorista, aunque esto será investigado por los peritos encargados de analizar los restos del avión. Y seguro, que los más frikis han identificado que el problema de seguridad mostrado en el plano, es el mismo que padeció la Estrella de la Muerte en la película de Star Wars :-)
El PDF con los datos confidenciales se encontraba en un servidor independiente del que nosotros hemos investigado, por lo que en una investigación "normal" deberíamos ampliar el alcance y solicitar a quien corresponda el disco duro de dicho servidor para analizar sus logs, y comprobar si el usuario malicioso descargó realmente el PDF con los planos (aunque las hipótesis apunten a que sí) o simplemente sabía donde estaba pero no se atrevió a descargarlo.
Una vez finalizada la investigación llega la hora de realizar nuestro informe pericial y en el que básicamente copiaremos todos los datos que os acabamos de mostrar, dandole un toque más profesional y menos paródico.
Cuando realizo un informe pericial me gusta basarme en estándares internacionales o nacionales, primero, porque contienen la experiencia y buenas prácticas adquiridas durante años por expertos en el sector, y segundo, porque nos permite indicar al juez/cliente/abogado, etc. que nos basamos en un modelo y/o metodología que ha sido definida y contrastada por una entidad de confianza, como por ejempo las normas ISO o UNE. Una de esas normativas es la UNE 197001_2011_Criterios Generales para la elaboración de informes y dictámenes periciales. Otra normativa interesante es la UNE 71506:2013 y que en su ANEXO A nos muestra un interesante “Modelo de informe pericial”. Por razones de derechos de autor no os puedo facilitar dicho Anexo, pero si que puedo enumerar los apartados más importantes que vuestro informe debería contener:
- Asunto
- Evidencias/muestras recibidas
- Resolución o estudios efectuados sobre las evidencias/muestras
- Situación final de las evidencias/muestras
- Conclusiones finales
- Anexos del informe
En lo referente al fichero de cadena de custodia que os pedíamos, deberíais haber redactado algo parecido al siguiente:
Y eso es todo por hoy, como veis era un reto muy sencillo, y la dificultad radicaba en ver la línea temporal de acciones realizadas sobre el servidor y en documentar adecuadamente toda la investigación.
Nos vemos en el próximo post,
Saludos!
English
Buenas a todos,
