La explotación del error Drupalgeddon2 comienza después de la publicación del código PoC

La explotación del error Drupalgeddon2 comienza después de la publicación del código PoC

La explotación de una vulnerabilidad Drupal muy peligrosa comenzó después de la publicación del código de prueba de concepto (PoC).

El código, alojado en GitHub, fue creado por Vitalii Rudnykh, un investigador de seguridad ruso. El código se basa en un desglose de la vulnerabilidad Drupalgeddon2 publicada por Check Point y los investigadores de Dofinity.

Todo sucedió en unas pocas horas entre el blog de Check Point, el PoC de Rudnykh, y el inicio de los intentos de explotación, primero detectado por la firma de seguridad web Sucuri.

"Todavía no veo muchos intentos, solo un par de direcciones IP", dijo Daniel Cid, vicepresidente de ingeniería en GoDaddy y CTO/fundador de Sucuri.

Daniel Cid dijo que la mayoría de los intentos de explotación están "basados en el PoC compartido en GitHub", pero otros atacantes también podrían estar trabajando en su propio código.

La vulnerabilidad Druppalgeddon2 (CVE-2018-7600) permite a un atacante ejecutar cualquier código que desee contra uno de los componentes principales del CMS, tomando el control de un sitio. Ver la explicación de Check Point y Dofinity a continuación:

En resumen, Drupal no contaba con suficiente información sobre las solicitudes AJAX de Form API (FAPI). Como resultado, esto permitió a un atacante inyectar potencialmente una carga maliciosa en la estructura de formulario interno. Esto hubiera causado que Drupal lo ejecute sin autenticación de usuario. Al aprovechar esta vulnerabilidad, un atacante podría haber llevado a cabo una toma de posesión completa de cualquier cliente de Drupal.

El equipo de seguridad de Drupal parcheó Drupalgeddon2 el 28 de marzo con el lanzamiento de Drupal 7.58 y Drupal 8.5.1. El equipo de Drupal dijo que esperaba que "los exploits se desarrollen en cuestión de horas o días".

Pasaron dos semanas para que se publicara el primer PoC exploit, principalmente porque el equipo de Drupal retuvo todos los detalles posibles sobre la vulnerabilidad del público para retrasar la creación del PoC y permitir a los propietarios del sitio el tiempo para actualizar sus sitios.
No hay adquisiciones de sitios todavía. Solo un montón de pruebas PoC.

Kevin Liston, un investigador de seguridad de SANS ISC, también ha detectado intentos de explotación en contra de los honeypots de su organización. Los comandos que los atacantes intentan ejecutar a través del PoC son actualmente inofensivos y ninguno está intentando hacerse cargo del servidor subyacente (consulte la lista a continuación).

echo `whoami`
phpinfo ()
echo 123
quién soy
toque 1.html
echo "xiokv"

Estas son instrucciones que son específicas para los atacantes que prueban la efectividad del PoC. Teniendo en cuenta el escaso número de escaneos que ha observado Sucuri, la naturaleza intrusiva de la vulnerabilidad y el historial de intentos anteriores de explotación de vulnerabilidades, es solo cuestión de tiempo antes de que los números de explotación suban y los ladrones reemplacen estas instrucciones con malware basado en web o inyección de spam SEO mecanismos.

"Supongo que esta noche y mañana por la mañana se reanudará", Cid nos habló de la escala y la complejidad de estos intentos de explotación. "Es una pequeña carrera armamentista para ver quién puede obtener los sitios primero".

Sitio de noticias capturado usando Drupalgeddon2 PoC

Liston ya comenzó a rastrear algunas de las fuentes de estos escaneos. El que pudo identificar esta mañana se relacionó con un sitio de noticias de seguridad chino.

"El servidor de nombres autorizado para 'ceye.io' es ns[12].hackernews.cc, que parece pertenecer a un sitio de noticias de seguridad chino", dijo Liston hoy en una publicación en el foro.

"Tal vez están trabajando en una historia para publicar cuántos sistemas vulnerables hay, pero la explotación real de una vulnerabilidad, aunque sea algo benigna, puede ser un paso demasiado lejos para una noticia".

Si ejecuta un sitio de Drupal, estas pueden ser sus últimas horas para parchear antes de que corra un serio riesgo de perder el control de su sitio.

Artículo Relacionado