DIARIO DE UN PERITO INFORMÁTICO: FORENSE A UN WORDPRESS [II]

¿Has llegado a este enlace pero no has leído la primera parte? Este artículo es una continuación de “Diario de un perito informático: forense a un WordPress [I]“. En él hablamos sobre cuáles son los procesos y fases iniciales que realicé para autentificar la modificación un post de una web creada en WordPress. Al final me hacía las siguientes preguntas:

  • ¿La web es vulnerable? ¿Ha sufrido alguna intrusión?
  • ¿Qué personas tienen acceso al FTP?
  • ¿La base de datos tiene acceso remoto? ¿Cómo?
  • ¿Qué usuarios han accedido en la base de datos en los últimos meses? ¿Y qué han hecho?
  • ¿El servidor tiene acceso remoto por SSH u otra aplicación?
  • ¿Qué usuarios han accedido al servidor en los últimos meses? ¿Y qué han hecho?

Acceso al servidor en el proceso laboral en la Ley Reguladora de la Jurisdicción Social

Todo lo que se expuso antes y lo que viene tiene un handicap de nivel estratosférico. La práctica de la prueba en cualquier tipo de juicio tiene como objetivo probar los hechos controvertidos, es decir, aquellos hechos que son discutidos entre las partes. Es una de las cuestiones más importantes. Únicamente se presentan pruebas sobre aquellas cuestiones que nos discute la parte contraria, y por lo tanto, podrán ser rechazado por el juez la práctica de una prueba que no sirva para dicho fin. Ahora bien, en un juicio laboral,  no se presentan hasta el momento del juicio. 

Entonces ¿cómo podemos presentar una prueba digital si requiero acceso al servidor?

En definitiva, los medios de prueba se aportaran en el momento de la vista, pero si no está bajo nuestro control el poder aportarla, porque necesitamos acceso al servidor. La abogada o el abogado tendrá que solicitar al juzgado que sea requerida de la forma correspondiente y el informe se entregará siempre con al menos cinco días de antelación a la fecha del juicio.

¿La web es vulnerable? ¿Ha sufrido alguna intrusión?

Seguramente el lector pensó que en este apartado hablaremos de una auditoria de seguridad sobre la web. Sin embargo, también debemos añadir a la lista las siguientes incógnitas que deberemos responder en nuestro informe:

  • ¿La web es vulnerable y ha sufrido alguna intrusión? Bien. Pero debemos pensar en la dimensión tiempo. Debemos responder a una situación pasada. Que la web sea en el momento de la auditoría vulnerable, es un posible indicio de serlo en el pasado. Pero deberemos comprobarlo. Además de investigar en el pasado.
  • No solo deberemos mirar la web. Una intrusión en el servidor también podría comprometer la base de datos y el WP.

¿Cómo era antes la web?

Para conseguir saber cómo era la página web en las fechas que vamos a analizar, podemos analizar cuándo son las fechas de modificación y creación de los archivos. Sin embargo, una forma que puede ser más fácil; es buscar una copia de seguridad, y verificar que fue creado y contiene los archivos con esas fechas. Para ello buscaremos aplicaciones de copias de seguridad:

En Linux:

En las distribuciones RPM, como OpenSuse o Fedora y después para Arch y sus derivadas:

Encontramos que existe una aplicación instalada llamada “Deja dup” que viene por defecto instalado en Ubuntu.

Tras identificar la ubicación de los archivos de copia de seguridad que se realizan todos los días, pedimos la key para descifrar los archivos que están cifrados con GPG. En las periciales, podemos tener la suerte de pedir las claves, pero en muchos otras, no ,y deberá ingeniarse el perito para encontrarlo o saltarse las medidas de seguridad.

Desciframos las copias de seguridad de varios días cercanas a la fecha que encontramos en la base de datos del WP. Los importamos en una maquina virtual y navegamos por los diferentes directorios hasta localizar dónde se almacena el WordPress. ¿Qué versión, theme y plugin tendría en esas fechas?

Yo prefiero hacer los procesos manuales, sin embargo, recomiendo que en las diferentes fases de una investigación y pericial informática se realice tanto de forma manual como con una aplicación de forma automática. Para dar mayor garantía a los resultados extraídos.

¿Cómo podemos saber si los archivos del core de WP han sido modificados?

La API de WordPress.org (https://api.wordpress.org/core/checksums/1.0/?version={var}) nos permite consultar los hash de los archivos del core y comprobar si han sido modificados. Es una forma fácil de detectar aplicaciones maliciosas. Un ejemplo de consulta a la API sería:

Para la auditoria nuestro mayor aliado será WPscan Vulnerability Database. Una de las webs más completa de vulnerabilidades en plugins, themes y core de WordPress. También podemos instalar el WP en local e instalar el plugin WordPressA Security Plugin, aunque tenía su propia base de datos vulnerabilidades, actualmente usa la misma base de datos. Para descargar WordPressA Security Plugin pincha en el siguiente enlace: http://wordpressa.quantika14.com/wsp/

La aplicación selecta es WPscan. También usa la base de datos anteriormente mencionada, es mas, son las mismas personas las que gestionan las base de datos que las creadoras de esta aplicación. Un ejemplo para enumerar los usuarios de un WordPress sería:

Buscando accesos y modificaciones en archivos del WP

Tras no encontrar ningún plugin y theme vulnerable con WordPressA Security Plugin y WPScan nos llama atención un plugin Diqus pero decidimos investigar antes otra cosa.

No todo es Autopsy. Encontrar accesos y modificaciones en archivos del WordPress es posible hacerlo de diversas formas. Si alguien insertó algún virus informático o código malicioso podemos usar el antivirus ClamAV. Vamos a usar Exiftool y Grep (de nuevo ;P)

  • -json: para que nos retorne los resultados en un formato json. También podemos poner xml, csv, etc
  • -r: para analizar de forma recursiva en todos los subdirectorios
  • -ext: la extensión que vamos analizar es PHP pero también deberemos buscar en otros formatos como JS

Analizando el Cron Jobs de WordPress

Anteriormente encontramos indicios que nos hacían pensar que es posible que el WordPress tuviese alguna tarea programada maliciosa. Ya que vimos varios archivos de modificados que concuerdan con nuestras fechas.

****

Siento que no haya añadido imágenes con los resultados (y en muchos otros) pero estoy escribiendo basándome en el informe que escribí y recrear un entorno me llevaría mucho tiempo. Pido disculpas, porque quizás a veces sea complicado seguir el hilo. Intentó detallar lo máximo posible para que sea beneficioso a peritos que se vean en la misma situación.

****

Al igual que en nuestro cuerpo, es el bulbo raquídeo el que controla la respiración y los latidos del corazón, en backgroud, sin ser nosotros conscientes, en un servidor, esa tarea la realizan las tareas programadas o cron.

En el archivo “wp-cron.php” la primera función que nos encontramos es:

Configura que la desconexión de un usuario no interrumpa la ejecución del script. Esta línea es realmente importante, ya que el cron de WordPress, se ejecuta únicamente cuando un usuario accede a nuestra web. De ahí que reciba la consideración de cron virtual, en lugar de cron real o de servidor.

Es fundamental que el perito informático conozca como funciona los cron jobs al milímetro. Y como me llevaría varios artículos hablando únicamente de este tema, os comparto un enlace donde encontré gran información que os he trasladado de gran utilidad: fuente -> enlace.

Instalando el plugin WP-control

Como tenemos un clonado del WordPress y montado en local, ahora vamos a instalar un plugin que nos ayudará analizar de forma muy fácil que cron jobs tenía la web programada.

El plugin WP-control nos expondrá una lista:

¿Quién accedió y añadió un evento backdoor?

Continuará…

Add a Comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *