Vulnerabilidad crítica en el CMS Drupal

El equipo de seguridad de Drupal anunció una vulnerabilidad de ejecución de código remoto (RCE) sin autenticación previa y sumamente crítica en el núcleo de Drupal CVE-2018-7600. La vulnerabilidad permite a un atacante aprovechar múltiples vectores de ataque y tomar el control completo de un sitio web. El equipo de Drupal estima que, en el momento del anuncio, más de un millón de sitios se ven afectados, alrededor del 9% de los sitios de Drupal. También informaron que, según su conocimiento, no estaba siendo activamente explotado. Esta vulnerabilidad fue descubierta por Jasper Mattsson afecta a Drupal 6-8.

Drupalgeddon2

El equipo de Drupal preanunció los parches la semana pasada cuando dijo que "los exploits podrían desarrollarse en cuestión de horas o días" después de la divulgación de hoy.

Si utilizas un sitio web con el CMS Drupal se recomienda actualizar de inmediato, debido a la gravedad de la vulnerabilidad que permite:

• Acceso ilimitado (sin necesidad de autenticación).
• Se puede activar de forma remota (sin necesidad de acceso local).
• Hace que todos los datos sean accesibles (públicos y no públicos).
• No solo se puede acceder a los datos, sino también modificarlos o incluso eliminarlo.
• Pueden tomar el control del sitio objetivo

Los propietarios del sitio deben actualizar a una versión segura del núcleo de Drupal inmediatamente. Si bien los informes de que no hay exploits activos son reconfortantes, el anuncio atraerá mucha atención de los atacantes. Dada la naturaleza de la vulnerabilidad, habrá literalmente una carrera entre los propietarios del sitio actualizando y los atacantes descubriendo un exploit.

Aquí hay un resumen de alto nivel de las acciones impactadas y recomendadas de las versiones:

• Los sitios que ejecutan Drupal 8.x deben actualizarse a la versión 8.5.1
• Los sitios que ejecutan Drupal 7.x deben actualizarse a la versión 7.58
• Hay parches disponibles para las versiones 8.3.x y 8.2.x
• Los sitios con versiones al final de su vida útil necesitarán actualizarse a una versión compatible de Drupal.
• Drupal también anució los parches de la versión 6.x discontinuada en febrero de 2016.

En Drupal.org, encontrará una descripción más detallada de las recomendaciones de actualización del equipo de seguridad de Drupal. También han publicado preguntas frecuentes detalladas .

Al observar la diferencia de los parches proporcionados por el equipo de Drupal, revelan una nueva clase DrupalRequestSanitizer usada para limpiar la entrada del usuario.

• Detalles técnicos de la vulnerabilidad: https://research.checkpoint.com/uncovering-drupalgeddon-2/
• proof-of-concept (PoC) exploit code para Drupalgeddon2 CVE-2018-7600 en GitHub.

// Sanitize unsafe keys from the request.
require_once DRUPAL_ROOT . '/includes/request-sanitizer.inc';
DrupalRequestSanitizer::sanitize();

  public static function sanitize() {
    if (!self::$sanitized) {
      $whitelist = variable_get('sanitize_input_whitelist', array());
      $log_sanitized_keys = variable_get('sanitize_input_logging', FALSE);

      // Process query string parameters.
      $get_sanitized_keys = array();
      $_GET = self::stripDangerousValues($_GET, $whitelist, $get_sanitized_keys);
      if ($log_sanitized_keys && $get_sanitized_keys) {
        _drupal_trigger_error_with_delayed_logging(format_string('Potentially unsafe keys removed from query string parameters (GET): @keys', array('@keys' => implode(', ', $get_sanitized_keys))), E_USER_NOTICE);
      }

      // Process request body parameters.
      $post_sanitized_keys = array();
      $_POST = self::stripDangerousValues($_POST, $whitelist, $post_sanitized_keys);
      if ($log_sanitized_keys && $post_sanitized_keys) {
        _drupal_trigger_error_with_delayed_logging(format_string('Potentially unsafe keys removed from request body parameters (POST): @keys', array('@keys' => implode(', ', $post_sanitized_keys))), E_USER_NOTICE);
      }

      // Process cookie parameters.
      $cookie_sanitized_keys = array();
      $_COOKIE = self::stripDangerousValues($_COOKIE, $whitelist, $cookie_sanitized_keys);
      if ($log_sanitized_keys && $cookie_sanitized_keys) {
        _drupal_trigger_error_with_delayed_logging(format_string('Potentially unsafe keys removed from cookie parameters (COOKIE): @keys', array('@keys' => implode(', ', $cookie_sanitized_keys))), E_USER_NOTICE);
      }

      $request_sanitized_keys = array();
      $_REQUEST = self::stripDangerousValues($_REQUEST, $whitelist, $request_sanitized_keys);

      self::$sanitized = TRUE;
    }
  }

Esta clase se usa para filtrar valores de la cadena de consulta, el cuerpo del mensaje y las cookies que comienzan con "#".

  protected static function stripDangerousValues($input, array $whitelist, array &$sanitized_keys) {
    if (is_array($input)) {
      foreach ($input as $key => $value) {
        if ($key !== '' && $key[0] === '#' && !in_array($key, $whitelist, TRUE)) {
          unset($input[$key]);
          $sanitized_keys[] = $key;
        }
        else {
          $input[$key] = self::stripDangerousValues($input[$key], $whitelist, $sanitized_keys);
        }
      }
    }
    return $input;
  }

}

Aún no se ha hecho pública una prueba de concepto que demuestre el ataque, pero esperamos que esté disponible pronto.

Este ataque ha recibido el apodo de "Drupalgeddon 2". El Drupalgeddon anterior de 2014 era un SQL tan grave en este aspecto , y tuvo ataques automatizados contra sitios Drupal no reparados en cuestión de horas después de que se realizara el anuncio público de la vulnerabilidad.


Fuente:
https://www.wordfence.com/blog/2018/03/drupalgeddon2/
Traducción: 
https://y2kwebs.com/2018/04/03/la-vulnerabilidad-de-drupal-core/
Vía
https://blog.segu-info.com.ar/2018/04/drupalgeddon2-vulnerabilidad-de-drupal.html