Primero la zanahoria, luego el palo: por qué Google decidió no pagar a un cazador de bugs por una vulnerabilidad crítica

En los servicios en la nube surgen cada vez más disputas no solo sobre las vulnerabilidades en sí, sino sobre si conviene considerar un problema encontrado como una vulnerabilidad. Precisamente en esa situación se vio envuelto cazador de errores Justin O'Liri, que informó de una deficiencia crítica en Google Cloud y recibió de Google dos respuestas contradictorias.

Según O'Liri, el problema afecta al componente de código abierto Config Connector, que permite gestionar recursos de Google Cloud a través de Kubernetes. El investigador descubrió un mecanismo denominado ConfigConfusion. Según su descripción, un usuario con acceso solo a un único espacio de nombres de Kubernetes podía escalar privilegios hasta el nivel de propietario de toda la organización en la nube y obtener control sobre proyectos, secretos, facturación y otros recursos.

Tras recibir el informe, los empleados de Google reconocieron inicialmente el hallazgo como serio. La solicitud obtuvo los niveles máximos de prioridad y criticidad P1/S1, y se encargó al equipo de producto que investigara el problema. Al investigador también le comunicaron que la cuestión de la recompensa sería evaluada en el marco del programa Bug Bounty.

Sin embargo, al cabo de unos días la postura de la compañía cambió. Google afirmó que el software funciona según la lógica de diseño y no contiene una vulnerabilidad. La empresa explicó que, para explotar el escenario, un atacante primero tendría que obtener acceso a la infraestructura de la organización y además usar una cuenta de servicio de Config Connector con privilegios elevados. Dicho nivel de privilegios, según Google, contraviene el principio de los privilegios mínimos necesarios y las recomendaciones de la propia compañía.

O'Liri no estuvo de acuerdo con esa interpretación. El investigador sostiene que el problema no radica en la existencia de una cuenta privilegiada, sino en la falta de verificación de los permisos del usuario antes de ejecutar acciones en su nombre. En una demostración publicada, para obtener control administrativo sobre la organización bastaron apenas unas pocas líneas de configuración de Kubernetes.

También genera preguntas el estado de la propia solicitud. A pesar de la denegación del pago y de la declaración de que no existe una vulnerabilidad, el informe sigue marcado como aceptado y en curso. Google no explicó por qué la solicitud no fue cerrada definitivamente, ni publicó una corrección ni asignó a la incidencia un identificador CVE.

O'Liri señaló que se había encontrado con una situación similar anteriormente. A principios de año Microsoft rechazó su notificación sobre una elevación de privilegios en Azure Backup for AKS, tras lo cual solucionó el problema sin publicar un aviso de seguridad independiente.

Además, la situación también recuerda al conflicto reciente entre AMD y el investigador conocido como MrBruh. Entonces la compañía también se negó a pagar una recompensa por el problema encontrado, pese a corregirlo posteriormente. Casos como este generan con más frecuencia debates sobre la transparencia de los programas Bug Bounty y sobre la coherencia con la que las grandes empresas tecnológicas valoran los informes de errores potencialmente peligrosos.