Un ataque demostrado por investigadores de ciberseguridad en la infraestructura cloud de IBM pudo acceder al servidor interno, utilizado para construir imágenes de bases de datos para los despliegues de los clientes.

Investigadores de seguridad han sondeado recientemente la infraestructura DBaaS (base de datos como servicio) de IBM Cloud y han encontrado varios problemas de seguridad que les han permitido acceder al servidor interno, utilizado para construir imágenes de bases de datos para los despliegues de los clientes. El ataque demostrado pone de manifiesto algunos descuidos de seguridad comunes que pueden llevar a comprometer la cadena de suministro en la infraestructura de la nube.

Desarrollado por investigadores de la empresa de seguridad Wiz, el ataque combinaba una vulnerabilidad de escalada de privilegios en el servicio IBM Cloud Databases for PostgreSQL con credenciales en archivo de texto dispersas por el entorno y controles de acceso a la red interna demasiado permisivos que permitían el movimiento lateral dentro de la infraestructura.

PostgreSQL es un objetivo atractivo en entornos de nube

La auditoría de Wiz sobre las bases de datos en la nube de IBM para PostgreSQL formaba parte de un proyecto de investigación más amplio que analizaba los despliegues de PostgreSQL en los principales proveedores de la nube que ofrecen este motor de bases de datos como parte de sus soluciones gestionadas de DBaaS. A principios de este año, los investigadores de Wiz también encontraron y divulgaron vulnerabilidades en las implementaciones de PostgreSQL de Microsoft Azure y Google Cloud Platform (GCP).

El motor de base de datos relacional PostgreSQL de código abierto ha estado en desarrollo durante más de 30 años con un énfasis en la estabilidad, alta disponibilidad y escalabilidad. Sin embargo, esta compleja pieza de software no fue diseñada con un modelo de permisos adecuado para los entornos de nube multitenencia donde las instancias de la base de datos necesitan estar aisladas unas de otras y de la infraestructura subyacente.

PostgreSQL tiene poderosas características a través de las cuales los administradores pueden alterar el sistema de archivos del servidor e incluso ejecutar código a través de consultas a la base de datos, pero estas operaciones no son seguras y necesitan ser restringidas en entornos de nube compartidos. Mientras tanto, otras operaciones de administración como la replicación de la base de datos, la creación de puntos de control, la instalación de extensiones y los activadores de eventos deben estar disponibles para los clientes para que el servicio sea funcional. Por ello, los proveedores de servicios en la nube (CSP) han tenido que idear soluciones y realizar modificaciones en el modelo de permisos de PostgreSQL para permitir estas capacidades, incluso cuando los clientes sólo operan con cuentas limitadas.

Escalada de privilegios mediante inyección SQL

Mientras analizaban la implementación de PostgreSQL de IBM Cloud, los investigadores de Wiz observaron el mecanismo de Replicación Lógica que está disponible para los usuarios. Esta característica fue implementada usando varias funciones de la base de datos, incluyendo una llamada create_subscription que es propiedad y ejecutada por un superusuario de la base de datos llamado ibm.

Cuando inspeccionaron el código de esta función, los investigadores observaron una vulnerabilidad de inyección SQL causada por un saneamiento inadecuado de los argumentos que se le pasaban. Esto significaba que podían pasar consultas SQL arbitrarias a la función, que luego ejecutaría esas consultas como el superusuario ibm. Los investigadores explotaron este defecto a través de la sentencia COPY de PostgreSQL para ejecutar comandos arbitrarios en la máquina virtual subyacente que alojaba la instancia de la base de datos y abrió un shell inverso.

Con un shell de Linux empezaron a hacer algunos reconocimientos para entender su entorno, como la lista de procesos en ejecución, la comprobación de las conexiones de red activas, la inspección del contenido de los archivos /etc/passwd, que enumeran los usuarios del sistema, y la ejecución de un escaneo de puertos en la red interna para descubrir otros servidores. El amplio escaneo de puertos llamó la atención del equipo de seguridad de IBM, que se puso en contacto con el equipo de Wiz para preguntar por sus actividades.

“Después de discutir nuestro trabajo y compartir nuestras ideas con ellos, nos dieron amablemente permiso para continuar nuestra investigación y seguir desafiando los límites de la seguridad, lo que refleja la sana cultura de seguridad de la organización“, dijo el equipo de Wiz.

Las credenciales almacenadas conducen a un ataque a la cadena de suministro

La información recopilada, como las variables de entorno, indicó a los investigadores que se encontraban en un contenedor pod de Kubernetes (K8s) y, tras buscar en el sistema de archivos, encontraron un token de acceso a la API de K8s almacenado localmente en un archivo llamado /var/run/secrets/kubernetes.io/servicecount/token. El token de la API les permitió reunir más información sobre el clúster K8s, pero resultó que todos los pods estaban asociados a su cuenta y operaban bajo el mismo espacio de nombres. Pero esto no era un callejón sin salida.

K8s es un sistema de orquestación de contenedores utilizado para el despliegue de software en el que los contenedores suelen desplegarse a partir de imágenes, es decir, paquetes preconstruidos que contienen todos los archivos necesarios para que un contenedor y sus servicios preconfigurados funcionen. Estas imágenes se almacenan normalmente en un servidor de registro de contenedores, que puede ser público o privado. En el caso de IBM Cloud se trataba de un registro de contenedores privado que requería autenticación.

Los investigadores utilizaron el token de la API para leer las configuraciones de los pods en su espacio de nombres y encontraron la clave de acceso para cuatro registros de contenedores internos diferentes en esos archivos de configuración. La descripción de esta clave recién encontrada en la API de gestión de identidades y accesos (IAM) de IBM Cloud sugería que tenía privilegios de lectura y escritura en los registros de contenedores, lo que habría dado a los investigadores la posibilidad de sobrescribir las imágenes existentes con otras falsas.

Sin embargo, resultó que la descripción de la clave era inexacta y sólo podían descargar imágenes. Este nivel de acceso tenía implicaciones de seguridad, pero no suponía una amenaza directa para otros clientes de IBM Cloud, así que los investigadores siguieron adelante.

Las imágenes de contenedores pueden incluir mucha información sensible que se utiliza durante el despliegue y que posteriormente se elimina, incluyendo el código fuente, los scripts internos que hacen referencia a servicios adicionales en la infraestructura, así como las credenciales necesarias para acceder a ellos. Por ello, los investigadores decidieron descargar todas las imágenes del servicio de registro y utilizar una herramienta automatizada para escanearlas en busca de secretos, como credenciales y tokens de API.

“Para poder escanear de forma exhaustiva en busca de secretos, desempaquetamos las imágenes y examinamos la combinación de archivos que componían cada imagen”, explican los investigadores. “Las imágenes de los contenedores se basan en una o más capas; cada una de ellas puede incluir secretos de forma inadvertida. Por ejemplo, si un secreto existe en una capa pero se elimina de la siguiente, sería completamente invisible desde el contenedor. Por lo tanto, escanear cada capa por separado puede revelar secretos adicionales”.

Los archivos de manifiesto JSON de las imágenes de contenedores tienen una sección de “historial” que enumera los comandos históricos que se ejecutaron durante el proceso de construcción de cada imagen. En varios de estos archivos, los investigadores encontraron comandos que tenían contraseñas pasadas como argumentos de línea de comandos. Entre ellas se encontraban las contraseñas de un servidor FTP interno de IBM Cloud y de un repositorio de artefactos de construcción.

Finalmente, los investigadores probaron si podían acceder a esos servidores desde su contenedor y resultó que sí. Este acceso excesivamente permisivo a la red, combinado con las credenciales extraídas, les permitió sobrescribir archivos arbitrarios en el repositorio de artefactos de construcción que utiliza el proceso automatizado de construcción de IBM Cloud para crear imágenes de contenedores. Esas imágenes se utilizan luego en los despliegues de los clientes, abriendo la puerta a un ataque a la cadena de suministro.

“Nuestra investigación sobre IBM Cloud Databases para PostgreSQL reforzó lo que aprendimos de otros proveedores de la nube, que las modificaciones del motor PostgreSQL introdujeron efectivamente nuevas vulnerabilidades al servicio”, dijeron los investigadores. “Estas vulnerabilidades podrían haber sido explotadas por un actor malicioso como parte de una extensa cadena de explotación que culminara en un ataque a la cadena de suministro de la plataforma”.

Lecciones para otras organizaciones

Aunque todos estos problemas ya han sido comunicados en privado al equipo de IBM Cloud y solucionados por éste, no son exclusivos de IBM. Según el equipo de Wiz, el problema de los “secretos dispersos” es común en todos los entornos de nube.

Los flujos de trabajo automatizados de creación y despliegue suelen dejar secretos en varios lugares, como archivos de configuración, el historial de bash de Linux, archivos de diario, etc., que los desarrolladores se olvidan de borrar cuando se completa el despliegue. Además, algunos desarrolladores suben accidentalmente todos sus archivos de configuración .git y CircleCI a los servidores de producción. Los secretos olvidados que suele encontrar el equipo de Wiz incluyen claves de acceso a la nube, contraseñas, credenciales de CI/CD y tokens de acceso a la API.

Otro problema frecuente que desempeñó un papel crítico en el ataque a IBM Cloud es la falta de controles de acceso estrictos entre los servidores de producción y los sistemas internos de CI/CD. Esto a menudo permite a los atacantes moverse lateralmente y ganar un punto de apoyo más profundo en la infraestructura de una organización.

Por último, los registros de contenedores privados pueden proporcionar una gran cantidad de información a los atacantes que va más allá de las credenciales. Pueden revelar información sobre servidores críticos dentro de la infraestructura o pueden contener código que revele vulnerabilidades adicionales. Las organizaciones deben asegurarse de que sus soluciones de registro de contenedores apliquen los controles de acceso y el alcance adecuados, dijo el equipo de Wiz.