El hackeo de MongoDB y la importancia de las configuraciones seguras predeterminadas

Si tienes una instalación de MongoDB, es momento de verificar que sea segura. Desde justo antes de Navidad, han hackeado más de 28.000 instalaciones públicas de MongoDB. Los atacantes mantienen los datos secuestrados y exigen que las empresas paguen en bitcoins para recuperarlos. Al parecer, al menos 20 empresas ya cedieron y pagaron el rescate. En esta publicación explicamos el hackeo, cómo protegerte y qué podemos aprender de él.

Cómo entender el hackeo

El hackeo en sí es alarmantemente sencillo. En las versiones >= 2.6.0, MongoDB incluye un archivo de configuración predeterminado que vincula MongoDB a 127.0.0.1 de forma predeterminada. Como resultado, la base de datos solo escucha las conexiones locales.

Antes de la versión 2.6.0, no era así. De forma predeterminada, MongoDB quedaba abierto a conexiones remotas. La autenticación tampoco es necesaria de forma predeterminada, por lo que las instalaciones de MongoDB anteriores a la versión 2.6.0 aceptan sin problemas conexiones remotas sin autenticar desde el primer momento.

Los usuarios aún podían restringir el acceso a las conexiones locales si se tomaban el tiempo de configurar la instalación, pero eso implicaba agregar manualmente una línea al archivo mongodb.conf. Como esa no era la configuración predeterminada, muchas instalaciones existentes nunca incluyeron este paso fundamental.

Para empeorar las cosas, es fácil identificar posibles objetivos para atacar MongoDB. El puerto predeterminado de MongoDB es 27017. Con un motor de búsqueda como ZoomEye, puedes buscar instalaciones de MongoDB, ver por qué puerto están disponibles y encontrar alrededor de 100.000 posibles objetivos vulnerables.

La vulnerabilidad en sí no es nueva. El problema se planteó por primera vez en 2012 y se hizo público alrededor de 2015. Además, a principios de 2015, John Matherly hizo ruido al informar que había encontrado alrededor de 30.000 instalaciones inseguras de MongoDB. En otras palabras, es algo que todo el mundo podría haber conocido desde hace tiempo.

El problema de las configuraciones predeterminadas inseguras

La falta de configuraciones predeterminadas seguras no es un asunto menor. Un estudio tras otro estudio ha demostrado que la mayoría de las personas se queda con las opciones predeterminadas que les ofrece un sistema. Las configuraciones predeterminadas importan.

Algunas personas podrían argumentar que ciertas configuraciones predeterminadas inseguras buscan equilibrar la facilidad de uso y la seguridad, y que se basan en suposiciones razonables. Por ejemplo, si se puede suponer con seguridad que, en la gran mayoría de los casos, una base de datos se instalará detrás de un firewall, quizá se decida que no vincular una base de datos a las conexiones locales sería una opción predeterminada razonable.

Pero esas suposiciones son peligrosas porque cuando, no si, alguien hace algo que rompe esa suposición, queda expuesto a ataques y quizá ni siquiera lo sepa. El conocimiento de los posibles riesgos de seguridad que implican estas configuraciones predeterminadas no está precisamente muy extendido. A menos que una empresa cuente con expertos en seguridad que revisen cada decisión (una buena idea, pero no algo garantizado), estas configuraciones inseguras pueden —y suelen— pasar desapercibidas.

Cómo hacer seguimiento de las configuraciones predeterminadas inseguras

El problema de las configuraciones predeterminadas inseguras se agrava.

Supongamos que eres parte de una organización responsable y usas una herramienta como Snyk para analizar tus herramientas y dependencias en busca de vulnerabilidades. Esas herramientas no reportarán este problema porque, por lo general, las configuraciones predeterminadas inseguras no se consideran vulnerabilidades. Esto se debe a que el problema no es un error ni una vulnerabilidad en el código, sino un problema de configuración.

Hasta cierto punto, tiene sentido, pero plantea una pregunta: ¿debería existir un identificador y una base de datos oficiales para las configuraciones predeterminadas inseguras?

Por un lado, un servicio que reporte configuraciones predeterminadas inseguras sin duda generaría cierto ruido. Hay muchas configuraciones predeterminadas inseguras y algunas organizaciones ya las habrán corregido. Estas organizaciones tendrían que determinar si el problema aún las afecta, lo que no siempre es sencillo. Si no es así, podrían ignorarlo sin riesgo y seguir adelante.

Pero reportar las configuraciones predeterminadas inseguras podría ser invaluable para quienes todavía no han identificado estos problemas. Podría alertarlos sobre riesgos de seguridad que, de otro modo, pasarían inadvertidos y seguirían sin resolverse, posiblemente durante años (como en el caso del problema de MongoDB).

Marcar las configuraciones predeterminadas inseguras conocidas en una base de datos de código abierto (del mismo modo que marcamos las vulnerabilidades conocidas) no habría detenido este ataque, pero podría haber evitado que al menos algunas de las bases de datos se vieran afectadas.

¿Qué sigue?

Antes que nada, asegura tu instalación de MongoDB. Te esperamos.

Ahora que volviste, este hackeo demuestra la enorme importancia de las configuraciones predeterminadas seguras. La seguridad es demasiado importante como para dejarla al azar. Así como la industria ha ido aceptando que los sitios deben servirse mediante HTTPS de forma predeterminada, quienes crean paquetes deberían hacer todo lo posible para garantizar que sus paquetes sean seguros de forma predeterminada. Una configuración predeterminada insegura puede causar tanto daño como una vulnerabilidad conocida. Es comprensible que quienes desarrollan estas herramientas quieran ofrecer una instalación con la menor fricción posible, pero si esa opción predeterminada también es insegura, terminamos en situaciones como la que tantas personas enfrentan ahora con MongoDB.

La otra pregunta que plantean estos ataques es si ya es hora de empezar a registrar las configuraciones predeterminadas inseguras en una base de datos de código abierto. En Snyk, conversamos una y otra vez sobre si deberíamos marcar estos defectos como vulnerabilidades, y probablemente seguiremos debatiéndolo durante mucho tiempo. Si tienes una opinión firme al respecto, cuéntanoslo, ya sea por correo electrónico o en Twitter. Mientras tanto, si quieres descubrir si tus dependencias esconden sorpresas de seguridad, analiza tus repositorios rápidamente con Snyk.