Escalación de Privilegios en CloudSQL por Dig.Security
Dig.Security publicó en su blog como tomó control de un servidor de google escalando privilegios y tomando control del equipo que hosteaba una instancia de GCP - CloudSQL
Existe un gran consenso en el mundo de las TI que indica que la nube es el futuro, pero siendo el futuro hay que tener en cuenta que ese futuro está en construcción en el presente y existe un sin número de ingenieros trabajando en el mismo proyecto, tal vez en diferentes condiciones, en diferentes horarios y tal vez en diferentes países.
Estas configuraciones laborales y la tarea de desarrollar nuevas aplicaciones en ámbitos altamente complejos llevan a que algunas vulnerabilidades criticas sean pasadas por alto hasta que un grupo de investigadores externo, lo encuentra.
En esta ocasión la vulnerabilidad expuesta fue descubierta por, digamos, los chicos buenos.
Hace un par de días el equipo de dig.security relató en su blog el como identificó una vulnerabilidad critica dentro del servicio CloudSQL service dentro de Google Cloud Platform.
“[CloudSQL] Servicio de bases de datos relacionales completamente administrado para MySQL, PostgreSQL y SQL Server con colecciones de extensiones enriquecidas, marcas de configuración y ecosistemas de desarrolladores.” - Google
Dig.security inicia, según relatan, creando una instancia de SQL server en el servicio GCP. Al crear esta instancia, el usuario por defecto que se crea es agregado a un rol denominado CustomerDbRootRole en el cual se pueden realizar operaciones básicas sobre las bases de datos del cliente.
El equipo de dig.security identificó posteriormente una debilidad en el sistema que le permitió escalar privilegios hacia un role denominado DbRootRole y que no debería ser conocido por el cliente.
Aunque este nuevo rol brindó nuevos vectores de acción, relata dig.security, carecía de privilegios totales sobre la instancia. Al continuar con la investigación se identificó un fallo de configuración en la estructura de permisos y roles, que les permitió escalar a sysadmin y de esta manera mantener el control total sobre la instancia y al utilizando ese nuevo acceso, se pudo interactuar con el sistema operativo.
Dig.Security relata que se identificaron repositorios de imágenes de Docker, información sensible del servidor que hosteaba la instancia de cloudSQL e incluso contraseñas.
Al parecer, el personal de Google se contactó con el equipo de dig.security 8 días después para invitarlos a compartir su experiencia.
Cronología:
- 5 de febrero. El equipo de security identifica la vulnerabilidad dentro de CloudSQL GCP.
- 13 de febrero. El equipo de Google contacta al equipo de dig.security.
- Durante abril. Se resuelve el fallo de seguridad.
- 25 de abril. El equipo de security es recompensado por el programa GCP Vulnerability Reward program.
Fuente: Dig.Scurity