Un hacker pide rescates tras secuestrar bases de datos MongoDB desprotegidas

Las instalaciones de MongoDB de cara al público pueden ser todo un riesgo de seguridad en caso de no hacerse bien. Esto en sí mismo es pura lógica, pero si decimos que el experto en seguridad Victor Gevers, de GDI Foundation, ha detectado una gran cantidad de instalaciones de MongoDB que fueron limpiadas para luego pedir un rescate, es que está habiendo un problema de carácter público.

En los últimos tiempos se está detectando que el hacker con pseudónimo Harak1r1 está pidiendo un rescate de 0,2 bitcoins, unos 200 dólares, para restaurar instalaciones de MongoDB limpiadas y secuestradas. Con el fin de asegurarse el cobro, los ciberdelincuentes piden al administrador del sistema que demuestre que es el propietario de la instalación mediante correo electrónico.

Este ataque resulta diferente de otros descubiertos en el pasado. Después de que los hackers hayan accedido a un servidor de bases de datos abierto, Gevers solo ha encontrado una tabla con el nombre de WARNING tras la “limpieza” de los contenidos legítimos, cuyo contenido es el siguiente:

{
 "_id" : ObjectId("5859a0370b8e49f123fcc7da"),
 "mail" : "harak1r1@sigaint.org",
 "note" : "SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE !"
}

Por suerte, los ficheros de acceso (logs) muestran de forma clara la fecha de la primera exportación de las bases de datos y cuando la nueva base de datos con la tabla WARNING fue creada, lo que ha permitido a Gevers avisar a los propietarios. Los hackers no se dedican a explotar ninguna nueva vulnerabilidad, sino que se aprovechan de versiones antiguas de MongoDB que no han sido actualizadas.

Tiempo atrás, el famoso servidor de bases de datos NoSQL (posiblemente la solución más conocida en su segmento) no restringía las conexiones externas a través de Internet en su configuración por defecto, esto ha permitido a muchos hackers acceder a muchos servidores y poder llevar a cabo sus fechorías. MongoDB Inc. la empresa encargada de su desarrollo, decidió cambiar meses después la configuración por defecto para corregir el problema, sin embargo, a día de hoy el 78% de los servidores en AWS de Amazon funcionan con una versión vulnerable de MongoDB, por lo que un porcentaje importante de las instalaciones del software que nos ocupa están en riesgo. De momento, parece que hasta ahora este secuestro ha afectado a unos 1.800 usuarios, de los cuales 11 han decidido pagar para recuperar los datos.

Para comprobar si la base de datos ha sido comprometida, el administrador puede hacer lo siguiente:

• Comprobar las cuentas de usuario de MongoDB y ver si no hay ningún administrador secreto añadido.
• Comprobar GridFS para ver si alguien ha almacenado ficheros ahí.
• Comprobar los ficheros de acceso para ver quién ha accedido al servidor de bases de datos.

Para mejorar la protección del servidor MongoDB se puede hacer lo siguiente:

• Habilitar la autenticación que ofrece “defensa en profundidad” en caso de que la red haya sido comprometida. Para ello hay que acceder al fichero de configuración del servidor y establecer auth = true.
• Utilizar firewalls y desactivar los accesos remotos a MongoDB si es posible. Se recomienda bloquear los accesos a través del puerto 27017.
• Configurar Bind_ip para limitar el acceso al servidor a tan solo unas direcciones IP locales.
• Actualizar MongoDB a la última versión disponible para corregir esta y otras vulnerabilidades que pudieran estar presentes.

Fuentes | BleepingComputer y The Hacker News