Bases de datos. ¡EXPUESTO! (Redis)

Publicado el 19.09.2022

Parte 1. Redis Redis

Para llevar

• Hay 39.405 servicios Redis no autenticados de un total de 350.675 servicios Redis en la Internet pública.
• Casi el 50% de los servicios Redis no autenticados en Internet muestran signos de un intento de compromiso.

Prefacio

En esta nueva serie de posts, hemos decidido responder a la pregunta: "¿Cuál es el estado de las bases de datos en Internet?". Podemos responder a esta pregunta con extremo detalle utilizando nuestro conjunto de datos.

Este informe es el primero de varios. En los próximos meses, publicaremos un análisis detallado de varias tecnologías de bases de datos diferentes, y comenzaremos nuestro viaje a las "Bases de datos. EXPOSED!" con la popular base de datos en memoria Redis

Pero antes de ir mucho más lejos, hablemos de lo que significa que una base de datos esté "expuesta" en Internet. Nuestro escáner intentará hablar el lenguaje nativo de cualquier servicio que estemos intentando enumerar. Por ejemplo, nuestro escáner construirá un paquete que sólo un servidor MySQL sabe cómo manejar, y a cambio, obtenemos una respuesta que nos da más información sobre ese servicio en ejecución.

Respuesta del servidor MySQL.

Censys nunca intentará autenticarse con ninguno de los servicios de bases de datos que encontremos. Establecemos un "apretón de manos" con el servidor remoto utilizando el protocolo nativo y parseamos las respuestas en un conjunto de campos, lo que facilita la búsqueda.

En el momento de escribir estas líneas, había 220.010.967 hosts con uno o más servicios de Internet expuestos. De ellos, 5.889.954 hosts (el 2,6% del total) ejecutan una o más de las doce tecnologías de bases de datos que analizaremos a lo largo de esta serie. A continuación se muestra un gráfico con las principales bases de datos ordenadas por número de servicios.

(Servicios de bases de datos encontrados por Censys)

Notas:

• Cuando decimos "host" o "host único", nos referimos a una única dirección IP.
• Cuando decimos "servicio" o "servicios", nos referimos a uno o más servicios en un host.

Introducción.

Redis es el cuarto motor de base de datos más utilizado que consideramos en esta serie. A diferencia de las bases de datos relacionales tradicionales, Redis no se diseñó pensando en la seguridad, con la expectativa de que siempre debería ser sólo para comunicaciones internas y privadas (es decir, no conectado directamente a Internet y sentado detrás de un firewall). La siguiente cita procede de la propia documentación de Redis al respecto:

Redis está diseñado para ser accedido por clientes de confianza dentro de entornos de confianza. Esto significa que normalmente no es una buena idea exponer la instancia de Redis directamente a Internet o, en general, a un entorno en el que clientes no fiables puedan acceder directamente al puerto TCP o al socket UNIX de Redis.

En versiones más recientes (a partir de la versión 3.0.0), Redis ha abordado el creciente problema de los servidores sin contraseña expuestos a Internet ejecutándose en un "modo protegido" si se encuentra utilizando la configuración por defecto. Este modo protegido sólo responderá a peticiones en la interfaz loopback y bloqueará las peticiones procedentes de Internet. Aunque como veremos más adelante en este post, el problema persiste.

Los servicios de Redis no permiten la autenticación por defecto, y es debido a esta falta de seguridad que Censys puede ver decenas de miles de despliegues de Redis sin autenticar en Internet.

Exposición.

(Mapa de calor geográfico de los hosts Redis en Internet)

En el momento de redactar este documento, Censys observó 350.675 servicios Redis accesibles desde Internet en 260.534 hosts únicos. Aunque la mayoría de estos servicios requieren autenticación, el 11% (39.405) no la requieren.

"El 11% de los servicios Redis en Internet no requieren autenticación".

A continuación se muestran los diez primeros países con servidores Redis expuestos a Internet ordenados por el número total de servicios. China ocupa el primer puesto con 130.839 servicios Redis accesibles por Internet, de los cuales el 15% (20.011 servicios) no requieren autenticación. Mientras que Estados Unidos ocupa el puesto número dos con 96.904 servicios Redis totales, sólo el 5% (5.108 servicios) quedan abiertos sin autenticación.

Observando los países con más de 100 servicios Redis, podemos visualizar qué regiones del mundo tienen el mayor porcentaje de instalaciones de Redis mal configuradas. En el siguiente gráfico, vemos que mientras que el país de Israel sólo tiene 187 servicios Redis, más del 72% de ellos carecen de autenticación. Israel es una de las únicas regiones en las que el número de servidores Redis mal configurados supera al de los correctamente configurados.

Por defecto, el servicio Redis se ejecutará en el puerto TCP 6379. Aún así, Censys ha observado que se ejecuta en más de otros dos mil puertos, desde el puerto TCP 6380 con 10.143 hosts únicos hasta el TCP 24491 con un único host. A continuación se muestran los cinco puertos principales en los que hemos observado que se ejecuta Redis.

Redis mantiene todos sus datos enteramente en memoria, y cuando nuestro escáner emite un comando no intrusivo `INFO` al servicio (que nos da una visión general del estado operativo actual) podemos ver cuánta memoria está en uso, y a su vez, cuántos datos están siendo expuestos a la Internet pública. Aunque nunca solicitamos ni vemos el contenido de los datos de un servicio Redis expuesto, un usuario malintencionado podría volcar fácilmente todos los datos almacenados del servicio.

Agregando el campo de búsqueda "services.redis.used_memory" de Censys , podemos calcular que del total de 39.405 servidores Redis no autenticados que observamos, la exposición potencial de datos supera los 300 gigabytes.

Servicios Redis no autenticados por AS	Datos de Redis expuestos por AS

TENCENT-NET-AP (AS45090) tiene el mayor número de despliegues Redis no autenticados, con 13.359 servicios y unos 48 gigabytes de datos expuestos. Pero ALIBABA-CN-NET (AS37963), aunque sólo tiene 2.377 servicios Redis no autenticados, tiene la mayor cantidad de datos expuestos a Internet, con algo más de 60 gigabytes (62.341.142.583 bytes) de datos.

Desde la perspectiva de un atacante, un menor número de servicios mal configurados con una mayor exposición de datos es más valioso que un mayor número de servicios mal configurados con pocos o ningún dato expuesto.

Curiosamente, descubrimos que el host con mayor exposición de datos ejecutaba ocho servidores Redis en ocho puertos diferentes, revelando más de 6 gigabytes de datos en total. Lo interesante de este host es que dos de los ocho servicios Redis en ejecución requerían autenticación. Esto significa que los administradores del host eran conscientes y tenían los conocimientos suficientes para activar la autenticación en algunos servicios Redis, pero pasaron por alto seis de los ocho. El motivo podría atribuirse a una mala configuración, un error de implementación o una regla permisiva del cortafuegos. Pero no importa la razón subyacente, una cosa es muy probable: los propietarios del host no entienden su superficie de ataque externa.

Y esta no es una circunstancia única; descubrimos que 406 hosts que ejecutaban múltiples instancias de Redis tenían una mezcla de servicios autenticados y no autenticados en diferentes puertos del mismo host. Esto da crédito al hecho de que algunas cosas siempre se cuelan a través de las grietas, y la comprensión de su huella de Internet es fundamental para la seguridad continua de una organización.

En cuanto a la cantidad de datos expuestos por país, el gráfico anterior muestra los diez primeros países ordenados por la cantidad total de datos expuestos por servicios Redis mal configurados. China domina con 146 gigabytes de datos expuestos, y Estados Unidos le va a la zaga con unos 40 gigabytes.

Versiones.

En la introducción de este post, dijimos que los desarrolladores de Redis han intentado acabar con el problema de los servidores sin contraseña en Internet introduciendo un "modo protegido", a partir de la versión 3.0.0. Cuando Redis escucha en todas las interfaces (0.0.0.0), y no se ha configurado una contraseña, este modo protegido sólo responderá a las peticiones de la interfaz loopback (127.0.0.1) y rechaza las peticiones externas. Un administrador puede desactivar manualmente este modo ejecutando el siguiente comando de Redis: config set protected-mode no.

Una pequeña cosa a tener en cuenta es que la imagen docker oficial de Redis no parece tener la configuración de modo protegido activada por defecto. A continuación se muestra un ejemplo de iniciar el servicio oficial de Docker Redis y obtener el valor de la configuración de modo protegido. Como podemos ver, este modo protegido está deshabilitado cuando se ejecuta bajo Docker.

Lamentablemente, nuestros hallazgos muestran que este modo protegido no es una solución milagrosa, ya que la mayoría de los servicios Redis no autenticados ejecutan versiones superiores a la 3.0.0. Por ejemplo, en China hay 3.989 servicios Redis no autenticados que ejecutan la versión 6.2.6 y 3.730 servicios que ejecutan la 3.0.504. El siguiente gráfico muestra las veinte principales versiones de Redis que hemos encontrado sin autenticación, desglosadas por países, todas las cuales utilizan versiones capaces de funcionar en modo protegido.

A continuación se muestra una tabla de las 10 versiones principales (total en todas las regiones) de Redis encontradas en línea sin autenticación habilitada. Podemos ver un número bastante amplio de versiones utilizadas en la naturaleza, pero la mayoría de estos servidores no autenticados están ejecutando v6.2.6 (con 5.791) y v3.0.504 (con 5.781).

Encontrar Redis abusados

Después de revisar los problemas conocidos para el servidor Redis en GitHub, el problema #4791 llamó nuestra atención. Este usuario informó de que su servidor Redis accesible desde Internet tenía varias claves que contenían un valor con formato crontab que intentaba ejecutar un script de shell obtenido de un servidor remoto que no habían configurado ellos mismos. Preocupado por la posibilidad de que existiera una vulnerabilidad desconocida, el usuario solicitó ayuda a los desarrolladores. Un segundo usuario intervino y confirmó que su servidor había sido afectado por algo similar.

Resulta que los atacantes han estado utilizando una técnica menos conocida para engañar a los servidores Redis para que escriban datos en archivos arbitrarios durante años. Esta técnica, conocida únicamente como "Redis Unauthorized Access Vulnerability",vuelve el sistema de configuración en tiempo de ejecución de Redis contra sí mismo. Este ataque es bastante sencillo.

En primer lugar, debemos entender que Redis tiene un mecanismo para almacenar los datos en memoria en el disco para sobrevivir a un reinicio o fallo. La configuración predeterminada para estos se puede encontrar en la configuración de Redis:

Lo que puede resultar sorprendente es que estos valores de configuración también se pueden establecer de forma remota en tiempo de ejecución utilizando el protocolo de mensajería de Redis. La idea general detrás de esta técnica de explotación es configurar Redis para que escriba su base de datos basada en archivos en un directorio que contenga algún método para autorizar a un usuario (como añadir una clave a ".ssh/authorized_keys"), o iniciar un proceso (como añadir un script a /etc/cron.d), por ejemplo,

Lo anterior le diría al servicio Redis que escriba el contenido de la memoria en el archivo "/root/.ssh/authorized_keys". El objetivo es escribir el valor de la clave "backup1" en este archivo, con la esperanza de que el servicio SSH ignore cualquier dato binario que Redis pueda añadir al archivo, y acepte clientes que utilicen esta clave SSH.

Nota: El archivo authorized_keys en SSH permite a un usuario utilizar su clave pública SSH en lugar de la autenticación local basada en contraseña. El servidor SSH aceptará un inicio de sesión sin comprobar la contraseña local si posee el lado privado de cualquier clave pública definida en $USER/.ssh/authorized_keys.

No fueron sólo los dos usuarios de la mencionada incidencia de GitHub los que sufrieron un ataque de este tipo. Encontramos indicadores de que alguien intentó este ataque contra decenas de miles de servidores Redis no autenticados en Internet. No tenemos la capacidad de decir si los ataques tuvieron éxito, pero podemos informar sobre los artefactos sobrantes que estos intentos dejan tras de sí.

Descubrimos que este intento concreto utilizaba varias claves de Redis con el prefijo "backup" para almacenar entradas crontab maliciosas en el archivo "/var/spool/cron/root" utilizando los siguientes comandos de Redis:

Este comando borra todos los datos del servidor Redis. Esto se hace para que el contenido de las siguientes claves/valores se escriba lo más cerca posible del principio del archivo de base de datos.

Esto establece la clave "backup1" para contener un trabajo crontab que buscará y ejecutará este script init.sh desde un servidor remoto cada cuatro minutos.

Esto establece el directorio de datos de Redis en el directorio "/var/spool/cron/" del sistema; el directorio por defecto donde se encuentran los crontabs individuales de usuario y son ejecutados por el proceso "crond".

Esto establece el nombre de archivo de datos de Redis en "root", lo que significa que el contenido de la base de datos se almacenará en "/var/spool/cron/root", es decir, el archivo crontab individual del usuario root.

Finalmente, esto le dice al servidor Redis que sincronice la memoria con el disco, y si tiene éxito, el contenido de "/var/spool/cron/root" será leído y ejecutado por el proceso crontab.

Este script "init.sh" (como se ve en el comando "SET backup1") todavía estaba accesible y podía descargarse y visualizarse en el momento de escribir este artículo. Este script, cuando se ejecuta, incluye muchas acciones nefastas, incluyendo

• Detiene y desactiva cualquier proceso relacionado con la seguridad que se esté ejecutando.
• Detiene y desactiva cualquier proceso de monitorización del sistema en ejecución.
• Elimina y purga todos los archivos de registro relacionados con el sistema y la seguridad, incluidos los historiales de shell (por ejemplo, .bash_history).
• Añade una nueva clave SSH al archivo authorized_keys del usuario root.
• Desactiva el cortafuegos iptables
• Instala varias herramientas de hacking y escaneo como "masscan".
• Instala y ejecuta la aplicación de minería de criptomoneda XMRig

Nota: En el caso de que este script haya sido purgado de Internet, hemos creado un gist que es una copia del original que el lector puede encontrar aquí.

Utilizando la lista más reciente de servicios Redis no autenticados que se ejecutan en el puerto TCP 6379, realizamos un escaneo único que simplemente buscaba la existencia de la clave "backup1" (nota: no obtuvimos el valor) en cada host. Descubrimos que de los 31.239 servidores Redis no autenticados de la lista, 15.526 tenían esta clave. Esto significa que alguien intentó el ataque descrito en esta sección en más del 49% de los servidores Redis no autenticados conocidos en Internet.

Aún así, esto no significa que haya más de 15.000 hosts comprometidos. Es improbable que las condiciones necesarias para que esta vulnerabilidad tenga éxito se den en cada uno de estos hosts. La razón principal por la que muchos de estos intentos fallarán es que el servicio Redis necesita ejecutarse como un usuario con los permisos adecuados para escribir en el directorio "/var/spool/cron" (es decir, root). Aunque, este puede ser el caso cuando se ejecuta Redis dentro de un contenedor (como docker), donde el proceso podría verse a sí mismo ejecutándose como root y permitir al atacante escribir estos archivos. Pero en este caso, sólo el contenedor se ve afectado, no el host físico.

Una vez más, sólo podemos determinar si se intentó este ataque, no si tuvo éxito.

¿Qué se puede hacer?

Redis es un producto fantástico. Pero también está pensado para ejecutarse en infraestructuras internas, no en servidores públicos. Los administradores deben asegurarse de que las entidades externas no pueden acceder a sus instancias Redis de ninguna manera. Un buen primer paso es leer la documentación de Redis sobre la seguridad de Redis. Pero en resumen:

• Active la autenticación de cliente en su archivo de configuración de Redis.
• Configure Redis para que sólo se ejecute en interfaces de red internas.
• Desactiva el comando "CONFIG" ejecutando 'renombrar-comando CONFIG ""' para evitar abusos en la configuración.
• Configura tu cortafuegos sólo para aceptar conexiones Redis desde hosts de confianza.

Los administradores de redes y hosts también deben supervisar constantemente qué servicios exponen sus hosts a Internet. La mejor manera de hacerlo es utilizar la herramienta de búsqueda gratuita Censys para ver cómo ve el público sus hosts conectados a Internet. Si tienes una red grande o no estás seguro de tu inventario de activos, Censys Attack Surface Management es un producto que puede encontrar automáticamente hosts de tu propiedad y alertarte sobre cualquier servidor Redis no autenticado o mal configurado.