Nuestro equipo de InfraSec constantemente implementa mejoras sobre nuestra infraestructura interna. En este artículo vamos a contarles sobre la profundidad de uso que se puede otorgar al servicio de AWS Organizations para realizar hardening a través de Service Control Policies. Pero sobre todo, cómo lo hemos implementado con éxito en Pomelo con el fin de minimizar el uso indebido de recursos que quedan fuera del alcance de nuestra administración directa. Nuestro enfoque se centró en fortalecer la seguridad y mitigar los riesgos potenciales asociados con la escalada de privilegios, por parte de actores maliciosos, en nuestra infraestructura de AWS.
Esta iniciativa tiene como objetivo proporcionar una capa adicional de seguridad y reducir el potencial riesgo de escalación de privilegios por un actor malicioso, dentro de la infraestructura implementada en Amazon.
Un poco de contexto para comenzar
Cada día se registran cientos de intentos de ataques en infraestructuras implementadas en AWS por malas configuraciones, como consecuencia de permisologías débiles que pueden resultar en una explotación de privilegios.
Para garantizar la seguridad de las infraestructuras, Amazon ofrece una gran variedad de features, como el servicio IAM (Identity and Access Management), que provee control granularidad sobre AWS. IAM permite especificar quién accede a qué servicios y recursos bajo ciertas condiciones.
AWS organizations service control policies (SCPs) asegura que las cuentas de AWS se mantengan alineadas a los controles de acceso a nivel organizacional, de forma preventiva y de detección en todas sus capas incluyendo escalabilidad. Es decir que podríamos limitar los permisos y accesos IAM a nivel Organization para usuarios finales, si tenemos los recaudos necesarios para no afectar los accesos programáticos entre nuestro workload.
Descripción general de la arquitectura de SCP
En el siguiente diagrama se ve de forma genérica cómo se aplica una SCP a una OU (Contenedor o Grupo de Cuentas de Amazon). A su vez, es posible aplicarla o desaplicarla de forma excepcional.
Ahora que entendemos cómo funcionan las SCP y, sabiendo que queremos limitar los permisos y accesos IAM globalmente para nuestros usuarios finales, podemos abarcar los siguientes casos. Estos fueron explotados cuando se captura una cuenta por un externo o cuando un insider quiere tratar de escalar privilegios para cumplir con su ataque.
Se incluyen los links que hacen referencia a la explotación en vivo para dimensionar el impacto de no tomar contramedidas a nivel seguridad en la plataforma, lo cual puede concluir para nuestro negocio en:
- Downtime (Indisponibilidad de nuestro servicio o Incuplimiento de SLA)
- Breach de Datos (Código Fuente o de información sensible)
- Pérdida de Reputación
Primero veremos los cuatro casos a nivel BestPractices que nos recomienda cubrir AWS, y por último, uno sobre otros ataques “in the wild”.
1-Limitar regiones geográficamente
En caso que se opere en regiones de Amazon específicas, es recomendable aplicar una policy que lo fuerce y límite dónde se pueden lanzar y deployar recursos. Denegando deploys en regiones no autorizadas, lo cual puede otorgar a un tercero la posibilidad de persistencia y movimiento lateral dentro de la plataforma para no ser detectado.
{
"Version": "2012-10-17",
"Statement": [
{
"NotAction": [
"iam:*",
"organizations:*",
"sts:*"],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": "your-region"
},
"ArnNotLike": {
"aws:PrincipalARN": "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_YourExceptionSSOrole_*"
}
}
}
]
}2- Prevenir cambios en los Controles de Seguridad
Asegurar que los controles no sean deshabilitados o manipulados para que el logeo y monitoreo permanezca funcional. Ante un potencial ataque, de esta manera evitaremos que el atacante borre sus rastros y huellas evitando ser detectado.
Denegar el borrado de VPC Flow Logs
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ec2:DeleteFlowLogs",
"guardduty:DeleteDetector",
"cloudtrail:DeleteTrail",
"cloudtrail:StopLogging",
"config:StopConfigurationRecorder"
],
"Resource": "*"
}
]
}3- Prevenir que una Cuenta deje la Organización.
Asegurar el gobierno y billing de las cuentas de la organización. Esta acción de pérdida de relación de confianza puede afectar directamente los controles de detección y el corte de servicio.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "organizations:LeaveOrganization",
"Resource": "*",
"Effect": "Deny"
}
]
}4- Prevenir VPC sin Internet que lo obtengan.
Este tipo de acciones no pueden quedar sin control ya que permitiría ganar una persistencia en un ataque desde alguna instancia.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ec2:AttachInternetGateway",
"ec2:CreateInternetGateway",
"ec2:CreateEgressOnlyInternetGateway",
"ec2:CreateVpcPeeringConnection",
"ec2:AcceptVpcPeeringConnection",
"globalaccelerator:Create*",
"globalaccelerator:Update*"
],
"Resource": "*"
}
]
}5- Desarrollar SCP Propias para mitigar la escalación de privilegios 🚨
La explotación de esta permisología puede validarse aquí y su potencial impacto en el hipervínculo citado en cada permiso a limitar.
A- Permisos IAM sobre otros IAM-Users y EC2.
Limitar quiénes pueden crear keys, perfiles de login, iam-users, adjuntar políticas a iam-users y groups.
“ec2:AssociateIamInstanceProfile”
“rolesanywhere:CreateTrustAnchor”
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"iam:CreateUser",
"iam:CreateAccessKey",
"iam:DeleteUser",
"iam:DeleteAccessKey",
"iam:UpdateAccessKey",
"iam:CreateLoginProfile",
"iam:UpdateLoginProfile",
"iam:AddUserToGroup",
"iam:AttachUserPolicy",
"iam:AttachGroupPolicy",
"iam:PutUserPolicy",
"iam:PutGroupPolicy",
"ec2:CreateKeyPair",
"ec2:GetPasswordData",
"ec2:AssociateIamInstanceProfile",
"rolesanywhere:CreateTrustAnchor"
],
"Resource": "*",
"Effect": "Deny",
"Condition": {
"ForAnyValue:ArnNotLike": {
"aws:PrincipalARN": "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_YourExceptionSSOrole_*"
}
}
}
]
}B-Permisos sobre IAM-Policies.
Limitar quiénes pueden modificar roles a versiones anteriores y adjuntar políticas.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"iam:CreatePolicyVersion",
"iam:DeleteRole*",
"iam:SetDefaultPolicyVersion",
"iam:AttachRolePolicy",
"iam:PutRolePolicy",
"iam:DetachRolePolicy"
],
"Resource": "*",
"Effect": "Deny",
"Condition": {
"ForAnyValue:ArnNotLike": {
"aws:PrincipalARN": "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_YourExceptionSSOrole_*"
}
}
}
]
}C- Permisos para asumir un rol o shares con externos.
Limitar quiénes pueden asumir roles y modificar snapshots a versiones vulnerables o súper privilegiadas.
“rds:ModifyDBSnapshotAttribute”
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"sts:AssumeRole",
"iam:UpdateAssumeRolePolicy",
"ec2:ModifySnapshotAttribute",
"rds:ModifyDBSnapshotAttribute"
],
"Resource": "*",
"Effect": "Deny",
"Condition": {
"ForAnyValue:ArnLike": {
"aws:PrincipalARN": "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_YourExceptionSSOrole_*"
}
}
}
]
}D- Pasar/Delegar un IAM-role.
Limitar quiénes pueden delegar roles en los siguientes servicios.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "iam:PassRole",
"Resource": [
"arn:aws:lambda:*",
"arn:aws:dynamodb:*",
"arn:aws:cloudformation:*",
"arn:aws:ec2:*",
"arn:aws:glue:*",
"arn:aws:datapipeline:*"
],
"Effect": "Deny",
"Condition": {
"ForAnyValue:ArnLike": {
"aws:PrincipalARN": "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_YourExceptionSSOrole_*"
}
}
}
]
}E- Actualizar el código de una Lambda existente o invocarlo.
Limitar quiénes pueden cambiar código o ver variables en Lambdas.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"lambda:UpdateFunctionCode",
"lambda:InvokeFunction"
],
"Resource": "*",
"Effect": "Deny",
"Condition": {
"ForAnyValue:ArnLike": {
"aws:PrincipalARN": "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_*"
}
}
}
]
}F- Denegar adjuntar policies default privilegiados.
Limitar quiénes pueden adjuntar políticas super privilegiadas prefabricadas por AWS.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"iam:AttachUserPolicy",
"iam:AttachGroupPolicy",
"iam:AttachRolePolicy",
"iam:PutRolePolicy"
],
"Resource": "*",
"Effect": "Deny",
"Condition": {
"ArnEquals": {
"iam:PolicyArn": [
"arn:aws:iam::aws:policy/AWSSSODirectoryAdministrator",
"arn:aws:iam::aws:policy/AWSSSOMasterAccountAdministrator",
"arn:aws:iam::aws:policy/AWSSSOMemberAccountAdministrator",
"arn:aws:iam::aws:policy/AdministratorAccess",
"arn:aws:iam::aws:policy/IAMFullAccess",
"arn:aws:iam::aws:policy/IAMUserSSHKeys",
"arn:aws:iam::aws:policy/IAMSelfManageServiceSpecificCredentials",
"arn:aws:iam::aws:policy/IAMUserChangePassword"
]
}
}
}
]
}Conclusiones
Lo primero a destacar es que mitigamos los errores avanzando en una implementación progresiva, comenzando con la asignación por cuentas de testing y luego por ambientes, hasta finalizar con la asignación por Organizational Units. Durante este proceso, hemos tenido en cuenta todas las excepciones necesarias para garantizar un despliegue adecuado y adaptado a nuestras necesidades.
El uso de Service Control Policies ha sido fundamental para fortalecer nuestra seguridad en AWS, proporcionando una capa adicional de protección contra amenazas internas y externas. También han facilitado la aplicación de políticas de cumplimiento y normativas internas, asegurando que nuestra infraestructura cumpla con los estándares de seguridad establecidos.
¡Esperamos que les haya gustado y les entusiasme aplicarlo! 🚀