Credenciales que salen por el servicio de metadatos

El servicio de metadatos de instancia vive en una dirección interna fija, alcanzable solo desde dentro de la propia máquina. Entre otras cosas, entrega las credenciales temporales del rol que la instancia tiene asignado: unas claves que sirven para actuar como ese rol en la nube. Mientras solo procesos legítimos de la máquina lo consulten, es un mecanismo sano y hasta más seguro que guardar una clave fija. El problema aparece cuando algo que no es la máquina consigue que la máquina haga esa consulta por él.

Entender que el servicio de metadatos reparte credenciales del rol es lo que explica por qué robar una petición hacia él equivale a robar la identidad de la máquina.

Hay dos versiones del servicio. La primera responde a cualquier petición que llegue a su dirección interna, sin más. La segunda exige que quien pregunte obtenga antes un vale de sesión con una petición especial que un simple reenvío desde fuera no puede hacer. La instancia de Cobalto usa la primera. Con ella, si la aplicación tiene un fallo que permite pedirle que traiga una dirección arbitraria —y esa dirección es la del servicio de metadatos—, la respuesta con las credenciales vuelve al atacante. Es robo de credenciales por el servicio de metadatos de instancia: no se explota el servicio, se explota que la máquina lo consulte de parte de otro.

La versión que responde sin exigir un vale de sesión es la que convierte un fallo de la aplicación en un robo de las credenciales de la máquina.

Robar las credenciales de la instancia solo vale lo que esas credenciales permitan hacer. La instancia de Cobalto tiene asignado un rol amplio —puede leer varios almacenamientos y tocar la base de datos— cuando la aplicación que corre allí solo necesita leer un almacenamiento de imágenes. Así, un robo por metadatos no se queda en la máquina: hereda todo lo que el rol puede hacer en la cuenta. Es la misma lección del permiso de más, ahora combinada con la ventana de los metadatos: la exposición y el privilegio se multiplican, no se suman. Cerrar solo una de las dos deja la mitad del problema.

Un rol de instancia recortado al mínimo hace que, incluso si las credenciales se filtran, sirvan para muy poco.

El arreglo cierra las dos piezas a la vez. Primero, obligar a la versión del servicio que exige el vale de sesión, de modo que un reenvío desde fuera ya no obtenga respuesta — en AWS es requerir la versión 2 del servicio en la instancia; en Azure, el servicio de metadatos ya exige una cabecera equivalente, y se comprueba que la aplicación no la reenvíe. Segundo, recortar el rol de la instancia al mínimo que la aplicación usa. Con la ventana cerrada y el rol recortado, ni se roban las credenciales fácilmente ni sirven de mucho si se roban. Hacer solo lo primero deja un rol amplio esperando; solo lo segundo, una ventana abierta.

Requerir el vale de sesión y recortar el rol son un solo arreglo en dos mitades: quitar la vía y quitarle el valor a lo que saldría por ella.

Abre el laboratorio de instancias de Cobalto. Lee la configuración de la instancia de la web —la versión de su servicio de metadatos y el rol que lleva adjunto— y después el informe de la revisión, que cierra con el código del hallazgo.