Diario de un perito informático: forense a un WordPress [III]

Continuamos…

Recordando a Lorenzo (@Lawwait): “nos vamos a hinchar a ver logs, Logs, lOgs, loGs, logS, etc” de todas las formas posibles. Así es. Pero también recordando a Manuel Baena (@manuelbaenaf): “los informáticos somos vagos por naturaleza. Por eso, automatizamos todo”. Este artículo es la unión de ambas frases. Buscaremos las pruebas que necesitamos con un script que bautizado como “Web Hunter Forensic“, evidentemente, desarrollado en Python 2.7. Sin embargo, como ya he comentado anteriormente, en un caso real sería importante realizar esa misma línea de investigación de distintas formas, automáticamente y manual para dar mayor garantías a los resultados obtenidos. Disminuyendo la posibilidad de error o falsos positivos.

• Diario de un perito informático: forense a un WP [I]
• Diario de un perito informático: forense a un WP [II]
• Diario de un perito informático: forense a un WP [III]

Línea de tiempo de los logs y su integridad

El problema que se presenta es garantizar la integridad y autenticidad de un registro de Linux. Ya que un usuario o aplicación con privilegios podrá modificarlo o alterarlo. Por ello, os expongo una linea de investigación para demostrar que los registros que estamos analizando no han sido editados.

Por ejemplo, un servidor Ubuntu con Apache:

El log access.log de Apache podría un usuario con privilegios modificar parcialmente o completamente el archivo. Para dar garantias, en este ejemplo,  deberemos buscar en el auth.log para comprobar qué usuarios iniciaron sesión y qué aplicaciones se ejecutaron como usuarios con privilegios. No obstante, este log también es susceptible de ser modificado. Entonces tendríamos que buscar otros registros. No necesariamente en este mismo orden que os planteamos, más adelante, en la imagen de abajo. Por ejemplo,  podemos buscar en el system.log para ver si algún servicio de alguna aplicación de un editor de texto se inicia… Digamos que la ruta de logs dependerá de cada caso. El segundo problema o pregunta que nos puede pasar por la cabeza es: ¿cuándo paramos?

Bajo mi opinión. El perito informático deberá demostrar que el registro no ha sido modificado. Eso se puede hacer con otro log del sistema. Sin embargo, podría ser interminable este loop de “garantias”. Por ello, para hacer un “break” y seguir el hilo de nuestra investigación deberemos siempre terminar respondiendo a la pregunta ¿Qué usuario o aplicaciones tienen accesos a ese log? ¿Qué usuarios y aplicaciones han tocado ese log?

¿Qué es y cómo funciona Web Hunter Forensic?

Para automatizar todo el proceso de los registros de Linux anteriormente comentado, desarrollé un script en python que me facilitará la extracción y análisis. Se podría describir la aplicación como un triaje(triage) de los archivos access.log y auth.log, con sus respectivas copias de seguridad. Además, se conecta con una base de datos MYSQL que podremos configurar desde la propia aplicación. La aplicación nos preguntará qué fecha queremos buscar y nos cruzará los datos. Imprimiendo en rojo las lineas que entienda como peligrosas y en naraja de un nivel de riesgo alto. ¿Para qué todo esto? Porque nos permite saber qué sucedió en una máquina y su aplicación web en un día concreto. La aplicación está diseñada y probada en un entorno con Ubuntu, Apache, MySQL y un WordPress instalados.

Enlace para colaborar y descargar:

https://github.com/Quantika14/Web-Hunter-Forensic

¿Cómo configuramos la conexión MYSQL?

Aun no me ha dado tiempo de crear un archivo de configuración. Sin embargo, es bastante fácil cambiarlos por los de nuestro servidor de base de datos MySQL.

Abrimos WHF.py con nuestro editor de texto favorito y cambiamos las siguientes líneas con los datos de conexión que tengamos:

¿Cómo añadimos más palabras al diccionario de WHF?

Se leerá las lineas que coincidan con la fecha que hayamos puesto. Si aparece alguna de las palabras que aparecen en la siguiente imagen se imprimirán en rojo o naraja. ¿Por qué? Porque de esta forma será más fácil distinguir y analizar entre todas las lineas que quedan registradas.

Por favor, si añades alguna haz un PR al repositorio será bendecido e invitado a una Cruzcampo.

Encontrar plugins eliminados en WordPress

Seguimos con el forense a WordPress. Antes de empezar debemos diferenciar entre desactivar y borrar. La diferencia es que, al borrar un plugin en WP se eliminan los archivos, registros y tablas de la base de datos.  Es posible realizar otras funciones adicionales programandolo. Como por ejemplo un plugin malicioso que quiere cifrar toda la base de datos antes de ser eliminado. Justo todo lo contrario cuando desactivamos; no se eliminan los archivos. Solo dejarán de hacer efectos los “actions” y “filters” del plugin. Excepto que esté programado para eliminar información de la base de datos podremos verificar si estuvo activado en algún momento.

En el anterior artículo vimos que un plugin permite crear CronJobs, ahora vamos a buscar en su código qué funciones utiliza y qué archivos tiene para saber si elimina todos los archivos, o las tablas y registros de la base de datos cuandoes borrado del WordPress:

• Delete_option()
• remove_action() y remove_filter()
• register_uninstall_hook()
• Constante “WP_UNINSTALL_PLUGIN”
• uninstall.php: archivo en la raiz del plugin

Continuara…