Blog Post

La más reciente actualización de seguridad de Dupal 7 (SA-CORE-2014-005) fue lanzada el 5 de octubre 2014. Cualquier sitio Drupal que esté funcionando con Drupal 7.31 o inferior debe ser actualizado a la versión 7.32 o aplicar inmediatamente el último  parche.

Aquí están algunos consejos para actualizar su sitio Drupal 7!

Opcion 1: Parche

Esto es cuando piensas, Dios mío! “No tengo tiempo para actualizar el Core de Drupal ahora”.  Usted necesitará realizar la actualización más tarde! Esto es solo un arreglo temporal. Te protege del hueco de seguridad, pero todavía tendrás que actualizar el core de Drupal para garantizar que se realizaron todos los ajustes o correcciones necesarios.
Sólo se debe modificar un solo un archivo en esta actualización de seguridad y parcharlo es bastante sencillo. Esto es una buena opción, si usted está tratando de actualizar de forma rápida muchos sitios  que administra y no tienen tiempo para hacer una actualización completa a la versión 7.32.

Asegúrese que esté en el directorio raiz de Drupal.
Ejecute este comando:

curl https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch | patch -p1

1. No olvide separar un espacio en su calendario para realizar la verdadera actualización.

Opción 2: Utilice drush para actualizar el Core Drupal

Esta es una buena opción para sitios que no son de producción, como servidores locales o de desarrollo. Usted puede poner la actualización en  producción, usando git u otros prácticas habituales.

Vaya a la raiz de Drupal usando la terminal (u otra interfaz de línea de comandos) (o use un alias  de drush, si lo tiene)

Ejecute el comando:
drush up drupal
Listo!

Opción 3: Actualice el Core Drupal manualmente

Esta opción toma mucho tiempo pero en última instancia, es la forma más segura de hacerlo.

Sin embargo, si le está costando mucho tiempo realizarlo. Vea la opción 1 y aplique el parche!

Recomiendo el siguiente recurso para conocer más sobre como actualizar Drupal 7 manualmente Update Drupal Core (documentación oficial de  drupal.org)

Opción 4: Simple pero eficaz, cambie una línea

Puede actualizar una simple línea en el archivo database.inc Este archivo se encuentra en la  ruta  /includes/database/database.inc. El  código vulnerable está a partir de la línea 735:

Modifique el archivo con el  código nuevo y seguro empezando aproximadamente en la línea 735:

Así que sólo reemplace la siguiente  línea en el database.inc:
foreach ($data as $i => $value) {

Con ésta línea:
foreach (array_values($data) as $i => $value) {

Elijas lo que elijas, actualiza hoy!
Esto es una actualización de seguridad súper importante. Todos debemos actualizar tengamos tiempo o no. No debe ser una opción actualizar… Actualiza tu sitio de Drupal hoy!!!

Usando Drupalgeddon para verificar si el sitio fue atacado

Esto no es un módulo, es un comando de Drush que permite comprobar o verificar,  si hay indicios que su sitio ha sido atacado explotando las vulnerabilidades corregidas en la actualización SA-CORE-2014-005.

Ver también

1. SA-CORE-2014-005 FAQ
2. Greg Knaddison’s «Your Drupal site got hacked. Now what?»
3. Bevan Rudge’s workflow chart

Instalación con Site Audit

Como su principal objetivo es verificar la seguridad lograra una mejor revisión con la  instalación de Site Audit.
En su directorio home (Instálelo en ~/ .drush haciéndolo disponible para todos sus sitios)

drush dl site_audit
drush dl drupalgeddon
drush cache-clear drush

Luego, úselo (En los directorios del sitio o use un alias de Drush)
drush asec

Siguiente paso: Explore los informes que ofrece Site Audit!

Sólo usando Drupalgeddon
En su directorio home ejecute el siguiente comando:

drush dl drupalgeddon
drush cache-clear drush

Luego, úselo (En los directorios del sitio o use un alias Drush)
drush @example.org drupalgeddon-test

Análisis de resultados

Usted obtendrá una salida de resultados como esta (Los ejemplos muestran un sitio hackeado)
Drupalgeddon, verifica un grupo de alias Drush y muestra los resultados de las pruebas de seguridad de forma masiva, un gran ahorro de tiempo.

You are about to execute ‘drupalgeddon-test’ non-interactively (–yes forced) on all of the following targets:
sites.abcd-d6.example.or  >> Site is not Drupal 7.                  [ok]
sites.abcde.example.org   >> Site did not test positive. Good luck! [ok]
sites.abcdef.example.org  >> Site did not test positive. Good luck! [ok]
sites.abcdefg.example.org >> Site did not test positive. Good luck! [ok]

Verificación de un solo sitio usando site audit:

$ drush asec
Security: 25%
Drupalgeddon users
The following users have been detected: #3: configure [error]
Delete the offending users from your site and check for other malicious activity.
Drupalgeddon roles
The following roles have been detected: #4: megauser [error]
Delete the offending roles from your site and check for other malicious activity.
Drupalgeddon suspicious files
The following suspicious files have been detected: [error]
– /path/to/malicious/file.php
Restore your codebase from a backup if possible. If not, delete the offending files from your site and check for other malicious activity.

Reporte de Site Audit para todas las secciones usando HTML y bootstrap:

¿Qué hacer si mi sitio de Drupal 7 está comprometido?

Los ataques automatizados a los sitios de Drupal 7 iniciaron horas después que se anunciara la vulnerabilidad de seguridad SA-CORE-2014-005. Usted debe proceder bajo la suposición que cada sitio web en Drupal 7 esta comprometido a menos que hubiese actualizado antes de Octubre 15, 11 pm UTC, eso es 7 horas después del anuncio.

Solo con actualizar no se remueven los backdoors u otras entradas que pudieron crear cuando hackearon el sitio.

Si usted no ha actualizado o aplicado este parche es mejor que lo haga tan pronto como sea posible. Este corregirá la vulnerabilidad de seguridad reportada en SA-CORE-2014-005  pero no corregirá los huecos de seguridad creados por terceros en un sitio ya comprometido. Si usted encuentra que su sitio ya fue parchado pero que usted no lo realizo, esto es un síntoma que su sitio fue atacado — Algunos hackers aplican el parche como forma de garantizar que ellos son los únicos atacantes que controlan el sitio web.

Control de daños

Los atacantes tal vez copien todos los datos de su sitio y los usen con fines maliciosos.
Recomendamos revisar la documentación de Drupal que aborda este tema de forma extensiva: ”Your Drupal site got hacked, now what”

Recuperación

Los atacantes tal vez crearon puntos de acceso para ellos (Comúnmente llamados “backdoors”) en la base de datos, en el código, archivos en directorios y otras localizaciones. Los atacantes pueden llegar a comprometer otros servicios en el servidor para escalar su nivel de acceso.

Remover los backdoors de sitios web es difícil porque no es posible asegurar que todos los backdoors fueron encontrados.

El equipo de seguridad recomienda que usted consulte con su proveedor de hosting. Si ellos no han parchado Drupal por usted o bloquearon los ataques de SQL Injection una horas después del anuncio de Octubre 15. También, recomendamos que restaure su backup antes del 15 Octubre 2014.

1. Ponga el sitio web fuera de línea y reemplácelo con una página web de HTML estático.
2. Notifique a los administradores de los servidores enfatizando que otros sitios o aplicaciones hospedadas en el mismo servidor pueden estar comprometidas mediante backdoors instalados cuando atacaron el sitio o sitios en Drupal 7.
3. Considere obtener un nuevo servidor o de lo contrario remueva todos los archivos del sitio web y las bases de datos del servidor. (Preserve una copia seguridad para una análisis posterior)
4. Restaure el sitio web (archivos de Drupal, archivos cargados y la base de datos) del backup antes del 15 de Octubre del 2014.
5. Actualice o parche el Core de Drupal en el sitio restaurado
6. Coloque el sitio web restaurado, parcheado y/o actualizado de nuevo en línea
7. Manualmente restaure cualquier cambio hecho al sitio web desde la fecha del backup restaurado.
8. Audite cualquier cosa que tenga fusionar del sitio comprometido, como código custom, configuración, archivos o artefactos para confirmar que son correctos y que no han sido manipulados por terceros.

Restaurar sin la copia de seguridad es posible, pero no es recomendable porque pueden quedar backdoors extremadamente difíciles de encontrar. La recomendación es restaurar desde el backup o reconstruir desde 0.
Para más información recomiendo revisar FAQ on SA-CORE-2014-005.