A pesar de que el descubrimiento de vulnerabilidades que son directamente responsabilidad del proveedor cloud no son frecuentes en el caso de AWS, la identificación de APIs no documentadas está siendo cada vez más utilizada para comprometer los servicios más utilizados por los clientes. Hace unos días fue el turno de CloudTrail, y en esta publicación te contamos los detalles.
El pasado 17 de enero los investigadores del equipo Datadog Security descubrieron, navegando en la consola de AWS, una llamada a una API no documentada que posteriormente les permitiría la evasión de uno de los servicios más conocidos de AWS: CloudTrail.
Antes de nada, para quienes no estén muy familiarizados con este proveedor de servicios en la nube, AWS CloudTrail permite a sus clientes mantener un registro de las acciones realizadas por los usuarios, roles o servicios de la cuenta en la que el servicio se encuentra habilitado. Estas acciones se conocen como «eventos».
Lo primero que llamó la atención de los investigadores fue una serie de peticiones a un servicio llamado «iamadmin».
Fuente de la imagen: Datadog Security Labs
¿En qué se diferencia este servicio del de IAM? La respuesta está en el endpoint al que se realiza la petición. Mientras que en el caso de IAM la llamada se hace a «https[://]console.aws.amazon.com/iamv2/api/iam«, en el caso de «iamadmin» dicha URL cambia su parte final: «https[://]console.aws.amazon.com/iamv2/api/iamadmin«.
A raíz de esto, otra cosa reseñable que detectada por los investigadores es que la cabecera X-Amz-Target era inusualmente larga y hacía uso del servicio «AWSIdentityManagementAdminService» (la cabecera X-Amz-Target se usa para especificar la versión de la API y la operación que se está solicitando, y se forman concatenando la versión de la API con el nombre de esta mediante un punto entre ambos valores).
Lo último que vieron fue que los nombres de los métodos eran similares a otros del servicio IAM, pero no exactamente iguales, acabando por deducir que con la API «iamadmin» se podían hacer peticiones optimizadas en el navegador, como por ejemplo enviar 50 nombres de usuario a través de una sola petición en lugar de mandarlas individualmente.
En el proceso de descubrimiento y verificación de la vulnerabilidad, el primer paso que los investigadores dieron fue firmar la petición con formato SigV4:
Fuente de la imagen: Datadog Security Labs
Con esto pudieron ejecutar el script que tenían preparado y, a través de una serie de errores que les fueron devueltos como respuesta, pudieron confirmar lo habían teorizado anteriormente: en el caso del método «ListMFADevicesForMultipleUsers» de la API «iamadmin», se trataba de un wrapper de «iam:ListMFADevices» que permitía, mediante una sola llamada, especificar múltiples usuarios IAM para recibir los resultados de «iam:ListMFADevices» de una sola vez.
Para sorpresa de los investigadores, ninguna de sus acciones se vio reflejada en CloudTrail, independientemente de si hacían uso o no de los permisos necesarios. Además, fueron capaces de obtener resultados de la API sin que esto, nuevamente, se viese reflejado en el servicio de monitorización:
Fuente de la imagen: Datadog Security Labs
Para confirmar los resultados, posteriormente hicieron una llamada a la API «iam:ListMFADevices», en cuyo caso la acción sí se vio reflejada en CloudTrail.
En total fueron capaces de descubrir 13 métodos de «iamadmin» a los que podían hacer llamadas. En la siguiente lista se encuentran dichos métodos y sus equivalentes métodos de IAM:
- ListPoliciesForGroups – iam:ListGroupPolicies
- ListAttachedPoliciesForGroups – iam:ListAttachedGroupPolicies
- GetGroupMembershipCounts – iam:GetGroup
- ListGroupsForUsers – iam:ListGroupsForUser
- ListAccessKeysForMultipleUsers – iam:ListAccessKeys
- ListAccessKeyLastUsedForMultipleAccessKeys – iam:GetAccessKeyLastUsed
- GetLoginProfilesForMultipleUsers – iam:GetLoginProfile
- ListDescriptionsForPolicies – iam:ListPolicies
- BatchGetRoleLastUsed – iam:GetRole
- ListMFADevicesForMultipleUsers – iam:ListMFADevices
- ListSigningCertificatesForMultipleUsers – iam:ListSigningCertificates
- ListServiceLinkedRoleDeletionAttempts – iam:GetServiceLinkedRoleDeletionStatus
- GetServiceLinkedRoleTemplate – iam:GetServiceLinkedRoleTemplate
Entre estos métodos detectaron que algunos de ellos no proporcionaban la respuesta esperada, lo cual se debía a la necesidad de incluir permisos para ciertas llamadas, como por ejemplo «iamadmin:BatchGetRoleLastused», que necesita que se tenga asignado el permiso «iam:GetRole» ya que parte de la respuesta que da contiene información que viene de «iam:GetRole».
Impacto de la vulnerabilidad
Ser capaz de evadir la monitorización de CloudTrail para obtener resultados sin que dichas llamadas queden registradas supone un alto riesgo para las empresas, ya que al equipo encargado de la seguridad no le sería posible identificar las acciones llevadas a cabo por potenciales atacantes.
Además, los investigadores también indicaban que esta técnica hacía posible evadir GuardDuty en el caso de algunos resultados, como IAMUser/AnomalousBehavior, ya que GuardDuty utiliza CloudTrail como fuente de información.
Respuesta de AWS
La vulnerabilidad ha quedado corregida actualmente y las llamadas al servicio «iamadmin» se registran correctamente en CloudTrail.
Más información
La entrada Evasión de CloudTrail en AWS a través de API no documentada se publicó primero en Una al Día.