22/02/2016 Actualizaciones de seguridad en Drupal

Antes de entrar en como Drupal gestiona problemas de seguridad e incorpora actualizaciones, deberíamos preguntarnos (y hagámoslo por un momento desde la irreverencia, poniendo en duda las bases): ¿por qué se necesitan actualizaciones de seguridad? ¿Por qué no se plantea una buena estrategia y diseño de la aplicación pensando desde el primer momento en asegurarla? La respuesta a estas preguntas requiere al menos que introduzcamos de forma muy simple y esquemática algunos de los aspectos del funcionamiento de la computación.

Todos los dispositivos electrónicos utilizan circuitos integrados de mas o menos complejidad. En los inicios de la computación, esta complejidad era relativamente baja. Conforme avanzaba la técnica, el uso de los circuitos es convertía en una tediosa tarea, cada vez había un mayor grado miniaturización, paralelismo y complejidad. Para solucionarlo, los ingenieros decidieron empaquetar ciertas operaciones que a menudo tenían los mismos pasos, en "manuales de instrucciones" que los circuitos integrados supieran interpretar. El objetivo que se buscaba era facilitar su uso por las personas.

En ese momento nació el software y los desarrolladores. Sin embargo, con el tiempo y conforme aumentaba la demanda de nuevas funcionalidades, ingenieros y desarrolladores se encontraron con el mismo problema: no era suficiente empaquetar en "manuales de instrucciones", seguía siendo demasiado complejo. Así pues, decidieron crear "manuales de manuales". Conforme la complejidad y la demanda de funcionalidades aumentaba iban creando capas y capas de abstracción, cada una de ellas especializada en resolver y facilitar la interacción con las predecesoras y con el usuario.

¿Dónde se suelen presentar las fisuras de seguridad en Drupal?

A estas alturas te puedes estar preguntando: ¿Y que tiene que ver esto con la seguridad? Pues que cada una de las agrupaciones de "manuales de instrucciones" en su esencia está hecha por una o varias personas y por definición todos los humanos son falibles y cometemos errores. A veces no son errores garrafales, a veces no son ni siquiera errores, sino omisiones de comprobación, buena fé de que no intentará nada extraño, etc.

Muchas veces estos errores pasan desapercibidos durante años, las causas pueden ser múltiples y muy complejas y se van acumulando entre las capas de abstracción y así, un error en la capa de nivel inferior puede provocar uno o varios en una capa más alta, o podemos tener errores introducidos directamente en una capa alta que no afecten a las capas inferiores, pero sean igualmente destacables.

Drupal es una capa software de las más altas, por encima suyo sólo tiene el usuario (nos referimos a ti que estás leyendo este post ahora mismo y lo haces gracias a un Drupal creado por nosotros), pero internamente y dado la gran complejidad del proyecto Drupal (casi medio millón de instrucciones en su versión 8) éste, se disecciona aún más en múltiples capas que permiten a empresas como la nuestra parametrizarlo, y moldear al gusto para ofrecer soluciones altamente específicas.

Entre tanta abstracción y modularidad aparecen los errores o problemas de seguridad y podemos decir que los sospechosos habituales en relación a problemas de seguridad, Drupal son el core y los módulos. El core es el núcleo de Drupal y es un conjunto de funcionalidades (framework) que permite a los desarrolladores de Avellana Digital realizar tareas típicas de una forma correcta y relativamente segura; los módulos por otra parte son añadidos que incorporan nuevas características o funcionalidades que por diversos motivos no se añaden al core pero que ayudan, extienden o facilitan las funcionalidades que este no provee (a veces tan sólo modifican el comportamiento natural de Drupal para mejorar -el para una tarea específica).

Las vulnerabilidades en los módulos

En relación a la seguridad, diremos que los módulos son el vector más común de problemas, pues normalmente estos son creados por personas desconocidas (con buena fé) que durante un tiempo determinado lo mantienen pero que (habitualmente) no tienen ninguna relación contractual ni con el implementador (Avellana Digital por ejemplo) ni con el cliente (tú). En estos módulos (y en casi todos) se cometen errores, que en menor o mayor medida afectan a la seguridad, a la estabilidad o el rendimiento de la solución. Normalmente la corrección de estos errores corre de la mano del propio desarrollador del módulo y este es el encargado (si quiere) de publicar la corrección (o venderla).

Esto deja una vía abierta a que errores y fisuras de seguridad perduren en el tiempo preparadas para ser explotadas por desconocidos remotos, ávidos de dudosas intenciones o de agrandamiento del propio ego. Estos motivos y en especial también los de estabilidad y rendimiento, nos llevaron a nosotros, Avellana Digital, a confeccionar de forma habitual módulos propios para nuestros clientes que sustituyeran y ampliaran las funcionalidades que otros módulos brindaban (o no) aumentando la seguridad (como expertos en Drupal que somos), estabilidad y rendimiento de las aplicaciones que entregamos a nuestros clientes.

Las vulnerabilidades del core

Queda pendiente hablar del core, el core de Drupal a diferencia de los módulos es un componente muy sólido (en honor a la verdad diremos que el core integra también funcionalidades en módulos, pero estos están tan entrelazados que es mas práctico hablar del core como un todo ), muy maduro, donde intervienen desarrolladores independientes, empresas y organizaciones, que mueve un volumen de negocio y capital suficiente para llamar la atención a nivel mundial. En que se traduce esto? Está más controlado, vigilado y probado, pero aún así no libre de errores y dado su popularidad y gran implantación, continuamente bombardeado por individuos u organizaciones (hacker teams) en la búsqueda de agujeros por donde explotar vulnerabilidades.

Las vulnerabilidades del core de Drupal suelen ser más importantes no porque las técnicas para obtenerlas sean más ingeniosas (que también), sino por que al ser una capa de abstracción mas cercana a su inmediata antecesora, las posibilidades de mal uso y explotación de recursos de forma fraudulenta son mucho mas grandes y devastadoras.

Drupal Security Team

Hace ya muchos años se creó el Security Team, un equipo de personas que vela para detectar y sobre todo corregir los problemas de seguridad que pueda tener el core de Drupal (entre otras tareas). Este mismo grupo es el responsable de la anunciamos público el descubrimiento de nuevas fisuras de seguridad y de las instrucciones o actualizaciones necesarias para paliar o disminuir el impacto. Todas las publicacionsdel equipo de seguridad, las encontramos periódicamente expuestas drupal.org/security

Dentro de todo este entramado aún tenemos un detalle interesante a comentar que es la catalogación de los errores, lo que se llama severity (la severidad) o el «cuánto daño puede hacer» o «hasta dónde llega un determinado problema». ¿Es una fuga de información? ¿Puede tumbar el sitio? ¿Puede reescribir parte del código y colocar elementos que infecten a nuestros visitantes?

Vemos la mesa de severidades que el Security Team ideó en su día, donde se ordenan de menor a mayor criticidad y desgraciadamente tenemos que decir que son conceptos bastante técnicos, así que si tienes alguna duda puedes contactar en el siguiente enlace.

Not Critical
(No crítica)
  • Clasificación utilizada para las vulnerabilidades de escalada de privilegios limitados y denegaciones de servicio locales (DOS). La integridad del core y los módulos no está en peligro. Requiere muchas veces de acceso como usuario del sitio.
Less Critical
(Menos crítica)
  • Se utiliza para las vulnerabilidades de cross-site (solicitud falsificación), así como la vulnerabilidad de elevación de privilegios que requieren complejas cadenas de eventos. Esta clasificación incluye también las vulnerabilidades que podrían exponer los datos confidenciales de los usuarios locales.
Moderately Critical
(Moderada-mente crítica)
  • Vulnerabilidades explotables de forma remota que pueden comprometer el sistema. La interacción (por ejemplo, un administrador visualiza una página en particular) se requiere para que esta exploit pueda tener éxito. La explotación requiere que el usuario esté registrado en el sitio y tenga algún permiso no predeterminado, como la creación de contenido.
Critical
(Crítica)
  • Explotable remotamente, incluye vulnerabilidades de denegación de servicio (DoS) que pueden comprometer el sistema, pero no se requiere del usuario (puede ser cualquier conectado a Internet). Vulnerabilidades que pueden permitir a los usuarios anónimos iniciar la sesión como usuario de la web o tomar acciones administrativas. Para la explotación puede ser requerido o no algún desencadenado por parte de un usuario registrado, o en los casos en que no se requiera la interacción el problema puede producir daños de menor severidad.
Highly Critical
(Muy crítica)
  • Vulnerabilidades explotables de forma remota que pueden comprometer el sistema. Cualquier atacante remoto (no hace falta que sea usuario registrado) puede realizar el procedimiento de explotación. Lo que llamamos coloquialmente "entrar hasta la cocina".

 

Dada la tabla anterior parece que los tipos de errores que más deberían preocuparnos son aquellos catalogados como críticos o muy críticos, nada más lejos de la verdad. Las severidades no separan en sí mismas el grado de afectación de una vulnerabilidad sobre el proyecto desarrollado en Drupal, sino más bien cuantifican la dificultad o resistencia que tiene el sistema hacia un atacante para lograr su objetivo. Así pues, dado el individuo adecuado con los conocimientos necesarios y el tiempo suficiente, una vulnerabilidad moderada o menos crítica puede causar un daño potencial real.

¿Cómo puedo minimizar estos riesgos?

Ante esto los profesionales en Drupal con Avellana Digital, tenemos previsto y empaquetamos soluciones de actualizaciones periódicas para core y mòdulos no tanto para evitar que nunca se convierta en un ataque (que es imposible para nadie ni por ninguna organización), sino para minimizar la probabilidad de éxito, y de que éste nunca venga de un problema con soluciones publicadas y no aplicadas, explotadas por terceros con el consecuente deterioro de la imagen corporativa, la funcionalidad, la estabilidad o el rendimiento de dichas aplicaciones.

Estas actualizaciones por desgracia y dado a que normalmente el comportamiento de Drupal es adaptado y parametrizado para cada cliente de una forma muy concreta puede derivar en el mal-funcionamiento de la web, y sí, tendremos un Drupal "seguro", pero que no hace lo que queremos que haga de la forma en que debería hacerlo, por eso es importante que las actualizaciones es realicen con las mayores garantías y por profesionales solventes que aseguren que el tráfico de versiones y correcciones no sea traumático.