Durante las revisiones de configuración de AWS, cuando se utilizan Virtual Private Cloud (VPC) endpoints, observamos con frecuencia que están configurados con políticas predeterminadas demasiado permisivas. Estas políticas permiten todas las acciones, principales y recursos, lo que puede ser aprovechado para exfiltrar datos del entorno AWS con facilidad. En este artículo mostramos cómo configurar los endpoints de VPC para proteger tu entorno AWS frente a atacantes malintencionados.
Qué son los VPC endpoints
Los VPC endpoints son una característica de red de AWS que permite conexiones privadas entre los recursos dentro de una VPC y los servicios compatibles de AWS, usando la red troncal de AWS y las API privadas de cada servicio.
Esta configuración garantiza que los recursos de una VPC no necesiten conexión a internet ni VPN para comunicarse con otros servicios de AWS, favoreciendo la implementación de redes seguras y aisladas que no dependen de infraestructuras públicas potencialmente inseguras.
Ejemplo de política predeterminada de VPC Endpoint
Bloque de código de la política de endpoint VPC predeterminada
{
«Statement»: [
{
«Action»: «*»,
«Effect»: «Allow»,
«Principal»: «*»,
«Resource»: «*»
}
]
}
Como ejemplo, un servicio en una instancia EC2 puede usar un VPC endpoint para solicitar datos a la API privada de un bucket S3. Si no existe un endpoint configurado para el servicio S3, el tráfico necesitará pasar por un Internet Gateway u otro dispositivo similar hacia la API pública de S3, exponiéndolo a posibles ataques.
Varios tipos de endpoints permiten definir políticas que restringen las comunicaciones entre los recursos y los servicios asociados de AWS. Sin embargo, si no se define una política al crear el endpoint, AWS aplica una política predeterminada que otorga acceso completo e irrestricto al servicio, incluso a principales de otras cuentas AWS.
Este comportamiento implica que, si un actor malintencionado obtiene acceso a una subred privada dentro de la VPC, podría aprovechar la configuración para extraer datos del entorno AWS o escribirlos en otro servicio bajo su control.
Ejemplos de exfiltración de datos mediante endpoints mal configurados
S3
Un endpoint de S3 con la política predeterminada de acceso total permite el uso de las API privadas de S3 sin restricciones. Un atacante podría aprovecharlo para extraer información sensible hacia un bucket S3 en una cuenta bajo su control.
Esto se consigue de varias formas. Una de las más comunes es cuando un usuario malicioso con acceso a una instancia EC2 en la VPC sube las claves de acceso de un usuario IAM con permisos de escritura a un bucket S3 de su cuenta, utilizando luego esos permisos para exfiltrar datos a través del endpoint.
Además, herramientas como S3Backdoor pueden utilizarse para establecer canales de comando y control encubiertos que permiten mantener el acceso y extraer información confidencial.
SSM
Otro ejemplo más elaborado implica el uso del servicio Systems Manager (SSM). Un endpoint de SSM excesivamente permisivo puede permitir a un atacante acceder a instancias EC2 en una cuenta bajo su control mediante los comandos send-command y start-session.
En este caso, el atacante que ya tiene acceso a una instancia EC2 comprometida en una subred privada crea otra instancia EC2 en su propia cuenta, con la política AmazonSSMManagedInstanceCore asociada a su perfil de instancia y el agente de SSM instalado. Luego, sube las claves IAM de un usuario con la política AmazonSSMFullAccess y las utiliza en la instancia comprometida para ejecutar los comandos start-session y send-command a través del endpoint de SSM, copiando así datos hacia su propia instancia.
Recomendaciones
Para asegurar los endpoints de VPC, te recomendamos:
– Crear endpoints de VPC para cada servicio compatible dentro de cada VPC, reduciendo la necesidad de conectividad a Internet y proporcionando acceso seguro a los servicios de AWS.
– Definir una política personalizada basada en el principio de menor privilegio para todos los endpoints configurados en el entorno AWS.
– Asegurar que las conexiones de red hacia los servicios de AWS solo sean accesibles desde los recursos internos de la cuenta u organización.
– Restringir el acceso a recursos individuales mediante su nombre o Amazon Resource Name (ARN) y minimizar el uso de comodines (wildcards), que podrían otorgar acceso no intencionado.
Tipos de endpoints
Interface endpoints
Son un tipo de interfaz de red que ofrece acceso a la red PrivateLink para conectarse con servicios. Estos endpoints admiten el uso de security groups para restringir el tráfico, aunque se recomienda combinarlos con políticas de endpoint para aplicar un enfoque de defensa en profundidad y un control de acceso más granular.
Gateway endpoints
Actúan como tablas de enrutamiento y no admiten security groups. Por ello, es esencial implementar una política restrictiva de endpoint que limite el tráfico hacia recursos externos.
Ejemplo de política segura de endpoint:
{
«Statement»: [
{
«Action»: «S3:*»,
«Effect»: «Allow»,
«Resource»: [«*:*:*:*:xxxxxxxxxxxx:*», «*:*:*:*:yyyyyyyyyyyy:*»],
«Principal»: «*»,
«Condition»: {
«StringEquals»: {
«aws:PrincipalOrgID»: «o-zzzzzzzzzz»
}
}
}
]
}
Esta política garantiza que los recursos de la red aislada solo puedan usar el endpoint de S3 para interactuar con buckets S3 controlados por cuentas específicas (xxxxxxxxxxxx y yyyyyyyyyyyy) y únicamente si el principal pertenece a tu organización (o-zzzzzzzzzz). En este caso, un atacante no podría acceder a buckets bajo su control.
Si quieres saber más sobre cómo proteger tu infraestructura en la nube, contacta con uno de nuestros expertos.
