El Servicio de notificación simple (AWS SNS) de Amazon Web Services es un servicio de publicación/subversión versátil basado en la nube que facilita la comunicación entre aplicaciones y usuarios.
Si bien sus capacidades de escalabilidad e integración lo convierten en una herramienta poderosa para las organizaciones, su uso indebido por parte de adversarios con fines maliciosos, como la filtración de datos y el phishing, ha generado importantes preocupaciones de seguridad.
Este artículo profundiza en los mecanismos mediante los cuales se puede explotar AWS SNS, explora escenarios de abuso del mundo real y proporciona información práctica sobre estrategias de detección y prevención.
Al comprender las vulnerabilidades inherentes a las configuraciones de SNS y aprovechar metodologías de detección sólidas, las organizaciones pueden mitigar los riesgos y mejorar su postura de seguridad en la nube.
AWS Simple Notification Service (SNS) es un servicio de comunicación pub/sub basado en la nube que permite a los usuarios enviar notificaciones a los suscriptores a través de varios puntos finales, como correo electrónico, SMS o notificaciones push móviles.
Opera en dos flujos de trabajo principales: aplicación a persona (A2P) y aplicación a aplicación (A2A).
Si bien los flujos de trabajo A2P están diseñados para integrarse perfectamente con servicios de AWS como Lambda y SQS, también sirven como vectores potenciales de abuso cuando están mal configurados. Funciones como políticas de filtrado, cifrado del lado del servidor (SSE), reintentos de entrega y colas de mensajes no entregados (DLQ) mejoran la funcionalidad de SNS, pero también pueden ser explotadas por adversarios.
La escalabilidad de SNS le permite manejar volúmenes masivos de mensajes sin intervención manual, lo que lo hace rentable para las organizaciones.
Sin embargo, esta escalabilidad también significa que los adversarios pueden aprovechar el servicio para actividades maliciosas a gran escala, como campañas de phishing o filtración de datos.
A pesar de su sólida arquitectura, AWS SNS es susceptible de sufrir abusos debido a configuraciones erróneas en las funciones de IAM, supervisión insuficiente de las acciones de la API y lagunas en los mecanismos de registro.
Por ejemplo, los adversarios pueden explotar políticas permisivas de IAM para crear temas, suscribir puntos finales externos y publicar datos confidenciales sin activar alarmas.
La falta de visibilidad de determinadas acciones de la API (como solicitudes de publicación fallidas) complica aún más los esfuerzos de detección.
Los mecanismos de cifrado en SNS se centran principalmente en proteger los datos en reposo mediante AWS Key Management Service (KMS).
Si bien esto garantiza la protección de información confidencial, como la información de identificación personal (PII), los adversarios pueden eludir estas salvaguardas explotando las brechas de cifrado durante el tránsito de datos o aprovechando puntos finales no monitoreados.
Los adversarios suelen seguir un flujo de trabajo sistemático para filtrar datos confidenciales a través de AWS SNS:
- Acceso inicial: obtener acceso a una instancia EC2 mediante métodos como explotar aplicaciones web vulnerables o utilizar credenciales robadas.
- Descubrimiento de credenciales: identificación de información confidencial almacenada localmente en archivos como .env o archivos de credenciales de GitHub.
- Creación de temas: uso de credenciales temporales obtenidas de IMDSv2 para crear un tema de SNS.
- Configuración de suscripción: registrar direcciones de correo electrónico externas o números de teléfono móvil como suscriptores del tema.
- Publicación de datos: codificar datos confidenciales en formato Base64 y publicarlos en el tema para su distribución.
Este flujo de trabajo destaca el esfuerzo mínimo necesario para organizar un ataque una vez que se logra el acceso inicial.
Al aprovechar los servicios nativos de AWS, como los comandos CLI y las funciones de IAM, los adversarios pueden combinar sus actividades en patrones de tráfico legítimos.
Una de las aplicaciones más preocupantes del abuso de AWS SNS es su uso en campañas de smishing (phishing por SMS).
La investigación de SentinelOne descubrió casos en los que los adversarios emplearon herramientas basadas en Python como SNS Sender para distribuir mensajes fraudulentos a escala utilizando credenciales de AWS comprometidas.
Estas campañas aprovecharon solicitudes de API autenticadas para eludir las medidas de seguridad y enviar mensajes de phishing haciéndose pasar por entidades confiables.
El éxito de este tipo de campañas depende de la capacidad del adversario para establecer permisos de mensajería a nivel de producción dentro de los servicios de mensajería para el usuario final de AWS.
Esto requiere aprobación regulatoria para las identidades de origen y aprobación previa del operador para mensajes SMS de gran volumen, un obstáculo que los atacantes sofisticados pueden superar comprometiendo cuentas con permisos preexistentes.
Si bien el abuso de AWS SNS presenta importantes ventajas para los adversarios, como integrarse en el tráfico legítimo y eludir el monitoreo de salida, también plantea desafíos:
- Acceso Inicial: Explotar vulnerabilidades en instancias EC2 o adquirir credenciales mediante ingeniería social.
- Persistencia de sesión: mantener sesiones activas en medio de sólidas protecciones de endpoints.
- Configuración de infraestructura: configuración de roles de IAM con políticas permisivas para acciones de SNS.
- Restricciones de Sandbox: superar las limitaciones impuestas por AWS en cuentas nuevas restringidas al modo Sandbox de SMS.
Estos desafíos subrayan la importancia de medidas de seguridad proactivas, como reforzar las políticas de IAM y monitorear los registros de CloudTrail en busca de anomalías.
Los registros de auditoría de CloudTrail sirven como un recurso vital para detectar acciones API inusuales relacionadas con el abuso de SNS.
Al centrarse en los roles asumidos asociados a las instancias EC2, los equipos de seguridad pueden identificar anomalías como la creación de temas poco comunes o eventos de suscripción.
Las reglas de detección se pueden diseñar utilizando la lógica de Nuevos Términos de Elastic para señalar las primeras ocurrencias de actividades sospechosas:
- Creación de temas por parte de un usuario poco común: identificar cuándo un rol asumido crea un tema de SNS de forma inesperada.
- Suscripción con correo electrónico externo: monitoreo de suscripciones que especifican puntos finales externos.
- Picos de publicación de mensajes: detección de aumentos repentinos en la actividad de mensajería directa al teléfono.
Estas reglas permiten a las organizaciones identificar posibles escenarios de abuso y al mismo tiempo minimizar los falsos positivos a través del análisis contextual.
Las consultas de búsqueda de amenazas brindan información más profunda sobre posibles compromisos al analizar los registros de CloudTrail en busca de atributos específicos, como cadenas de agente de usuario o parámetros de solicitud.
Algunos ejemplos:
- Creación de temas poco comunes: agregación de datos basados en regiones e ID de instancias EC2 para identificar actividades inusuales.
- Suscripciones de correo electrónico: filtrado de suscripciones por tipo de protocolo para detectar puntos finales externos no autorizados.
- Picos de mensajería directa: seguimiento de acciones de publicación con números de teléfono en los parámetros de solicitud para descubrir campañas de smishing.
AWS SNS es una potente herramienta de comunicación que ofrece una inmensa utilidad para las organizaciones, pero también presenta riesgos importantes si no se supervisa o se configura mal.
La investigación descrita anteriormente destaca cómo los adversarios pueden explotar sus funciones con fines maliciosos, como la filtración de datos y campañas de phishing.
Al comprender estas vulnerabilidades e implementar estrategias de detección sólidas utilizando registros de CloudTrail y consultas de búsqueda de amenazas, las organizaciones pueden mitigar los riesgos de manera efectiva.
Las recomendaciones clave incluyen:
- Fortalecimiento de las políticas de IAM con el principio de privilegio mínimo (PoLP).
- Habilitar mecanismos de registro integrales en CloudTrail y CloudWatch.
- Elaboración de reglas de detección basadas en anomalías adaptadas a contextos organizacionales.
- Realizar ejercicios periódicos de pruebas de caja blanca para validar los controles de seguridad.
A medida que los entornos de nube continúan evolucionando, ser proactivo en el monitoreo de amenazas emergentes será crucial para mantener posturas de seguridad sólidas contra el abuso de servicios como AWS SNS.
