Cómo limpiar un sitio web Drupal hackeado

13/04/2019
Enviado por pepem el Dom, 16/09/2018 - 16:16

En este post contaré sobre mi experiencia de haber limpiado sitios web, especialmente con Drupal, y una pequeña guía de como detectar y limpiar el sitio:

¿Qué es el ataque y cómo se realiza?

El ataque a sitios web se realiza o bien alterando el código fuente o la base de datos, permitiendo acceso o control remoto por el atacante, o accediendo a datos sensibles (protegidos con contraseña), o ejecutando en segundo plano y de forma invisible malware de minado de criptomonedas. ¿Cómo se consigue esto? Aprovechando vectores de ataque, que son vías para lograr subir un archivo con código malicioso al sitio. o modificar los existentes.

Los principales vectores suelen ser:

  • cualquier entrada de datos en la web, como un buscador mal configurado o que no filtre correctamente los datos que inserte el usuario, o un formulario
  • un sitio desatendido o desactualizado
  • usuarios con una password de acceso muy débil
  • url maliciosas, no filtrar adecuadamente lo que el usuario inserta por la url del navegador

¿Cómo saber si hemos sido atacados?

Depende de lo discreto, sofisticado que sea el atacante y el vector de ataque. Los sintomas pueden ser los siguientes:

- Caída generalizada del sitio por corrupción de archivos.
- Aparición de nuevos ficheros desconocidos con nombres aleatórios, o modificación de los archivos del sitio.
- Comportamiento inusual de usuarios, nombres de usuario extraños o poco frecuentes.
- Manipulación del contenido del sitio o las plantillas, habiendo insertado código malicioso, normalmente en javascript.

Si disponemos de git en el sitio web, hacer un git status desde el sitio infectado puede ser muy revelador acerca de los archivos que han sido modificados.

También nos puede ayudar a detectar el ataque e infección buscar patrones. En los sitios Drupal que he desinfectado, he podido comprobar que se cumplen ciertos patrones. Uno de ellos es el código malicioso usado para construir la puerta trasera, todos ellos con una encriptación en base64 o similares, y suelen usar funciones de este tipo:

  • base64
  • str_rot13
  • gzuncompress
  • gzinflate
  • eval
  • exec
  • create_function
  • location.href
  • curl_exec
  • stream
  • system
  • assert
  • stripslashes
  • preg_replace (with /e/)
  • move_uploaded_file
  • strrev
  • file_get_contents
  • encodeuri
  • wget

En otro tipo de infecciones, han logrado subir ficheros ¡ejecutables! y dejarles nombres como php5. ¿Qué pinta un fichero ejecutable en la carpeta default/sites/files? Si, muy sospechoso.

No hay que olvidar revisar el html que genera el sitio web, buscando código javascript sospechoso, como que trate de cargar scripts u otros recursos de alguna url que no corresponde ni tiene relación con el sitio. Podemos ayudarnos de herramientas online como sucuri.net que hace un análisis rápido del html del sitio buscando código sospechoso.

¿Cómo desinfectar el sitio?

¡Que no cunda el pánico!
Es muy recomendable dejar el sitio en modo mantenimiento para empezar.

¿Tenemos backup?
Si disponemos de backup y tenemos la certeza de que esta limpio, es la vía más rápida y sencilla de eliminar el código malicioso, pero hay que tener en cuenta que quizas el backup contenga modulo o core que no está al día con actualizaciones, y aunque recuperemos el sitio limpio, sería de nuevo vulnerable. Si podemos recuperar de backup sin perder datos e inmediatamente realizar actualización, mucho mejor.

Trabaja mejor en local
Al tener que realizar una actualización del core y no saber muy bien si todo va a ser compatible al 100%, es muy recomendable hacerse de una copia y trabajar en local. Es muy arriesgado hacer esto directamente en producción.

Search & Destroy
Si no disponemos de backup y nos toca limpiar el sitio a mano, podemos tratar de buscar estas llamadas, sobre todo muy sospechosas base64, eval, exec, curl_exec, system, entre los archivos de nuestro proyecto, con un "grep -r -n 'base64'" por ejemplo. Obtendremos un listado con los archivos que contengan ese string, y podremos analizar si el código es legitimo de Drupal, es decir, confiable (muy útil contrastarlo con el código del repositorio oficial), o han colado algun "troyanito" entre los archivos. En ocasiones basta con eliminar el fichero, otras veces puede estar mezclado con código propio de drupal, por ejemplo, en el index.php y similares. Así que cuidado.

Conviene revisar tambíén el fichero de cron. He encontrado algún caso en el que para asegurarse la persistencia de la infección aunque borrase los archivos, había escritas unas lineas en el cron para descargar unos bash script , posteriormente ejecutarlos y hacer prácticamente lo que quiera con la máquina infectada.

Cambia las claves de acceso
Al no poder conocer con exactitud el alcance del ataque, y sospechamos que han tenido acceso incluso a la base de datos, es muy recomendable cambiar toda clave que implique acceso a contenido restringido o al mismo sitio.

Actualiza y reestablece el sitio

Actualiza! Actualiza!
Uno de los principales vectores de ataque y causas de una infección es por software desactualizado. Por eso, debemos actualizar inmediatamente tanto el core como los módulos. Es recomendable usar drush para esto. Con un "drush update". Después de la actualización, nos aseguraremos de que el sitio sigue operativo y no se ha roto ninguna funcionalidad. Por este motivo indicaba antes que es muy recomendable hacer esto en local.

No debemos olvidarnos de correr el archivo update.php desde el navegador, para ejecutar posibles actualizaciones de base de datos, y probar de nuevo que todo funciona correctamente. Debemos realizar la misma operación una vez subamos el código, ya limpio, a producción, y ya con la seguridad de que todo debería funcionar correctamente.

Ya solo nos queda volver a poner el sitio en producción, quitar el modo mantenimiento y probar el sitio web.