El 19 de julio de 2019, Capital One recibió el mensaje que toda empresa moderna teme: se produjo una violación de datos. Afectó a más de 106 millones de personas. 140 números de seguridad social estadounidenses, un millón de números de seguridad social canadienses. 000 cuentas bancarias. Desagradable, ¿no estás de acuerdo?
Desafortunadamente, el hackeo no ocurrió el 19 de julio. Resulta que Paige Thompson, también conocida como. Errático, lo cometió entre el 22 y 23 de marzo de 2019. Eso es hace casi cuatro meses. De hecho, sólo con la ayuda de consultores externos Capital One pudo descubrir que algo había sucedido.
Un ex empleado de Amazon fue arrestado y enfrenta una multa de 250 dólares y cinco años de prisión... pero todavía queda mucha negatividad. ¿Por qué? Porque muchas empresas que han sufrido ataques están tratando de hacer caso omiso de la responsabilidad de fortalecer su infraestructura y aplicaciones en medio del aumento del cibercrimen.
De todos modos, puedes buscar fácilmente en Google esta historia. No entraremos en dramas, pero hablaremos de tecnico lado del asunto.
Primero que nada, ¿qué pasó?
Capital One tenía alrededor de 700 depósitos S3 en funcionamiento, que Paige Thompson copió y extrajo.
En segundo lugar, ¿es este otro caso de política de depósito S3 mal configurada?
No, no esta vez. Aquí obtuvo acceso a un servidor con un cortafuegos configurado incorrectamente y desde allí realizó toda la operación.
Espera, ¿cómo es eso posible?
Bueno, comencemos iniciando sesión en el servidor, aunque no tenemos muchos detalles. Sólo nos dijeron que ocurrió a través de un "firewall mal configurado". Entonces, algo tan simple como una configuración incorrecta del grupo de seguridad o la configuración del firewall de la aplicación web (Imperva), o del firewall de la red (iptables, ufw,shorewall, etc.). Capital One se limitó a admitir su culpabilidad y dijo que había cerrado el agujero.
Stone dijo que Capital One no notó inicialmente la vulnerabilidad del firewall, pero actuó rápidamente una vez que se dio cuenta de ella. Esto ciertamente fue ayudado por el hecho de que el hacker supuestamente dejó información de identificación clave en el dominio público, dijo Stone.
Si se pregunta por qué no profundizamos en esta parte, comprenda que debido a la información limitada solo podemos especular. Esto no tiene sentido dado que el hackeo dependió de un agujero dejado por Capital One. Y a menos que nos digan más, simplemente enumeraremos todas las formas posibles en que Capital One dejó abierto su servidor en combinación con todas las formas posibles en que alguien podría usar una de estas diferentes opciones. Estos defectos y técnicas pueden variar desde descuidos tremendamente estúpidos hasta patrones increíblemente complejos. Dado el abanico de posibilidades, esto se convertirá en una larga saga sin una conclusión real. Por tanto, centrémonos en analizar la parte donde tenemos hechos.
Entonces, la primera conclusión es: sepa qué permiten sus firewalls.
Establezca una política o un proceso adecuado para garantizar que SÓLO se abra lo que se debe abrir. Si está utilizando recursos de AWS como grupos de seguridad o ACL de red, obviamente la lista de verificación para auditar puede ser larga... pero al igual que muchos recursos se crean automáticamente (es decir, CloudFormation), también es posible automatizar su auditoría. Ya sea un script casero que escanea nuevos objetos en busca de fallas, o algo así como una auditoría de seguridad en un proceso CI/CD... hay muchas opciones fáciles para evitar esto.
La parte "divertida" de la historia es que si Capital One hubiera tapado el agujero en primer lugar... nada habría pasado. Y, francamente, siempre es impactante ver cómo algo realmente bastante simple se convierte en la única razón para que una empresa sea pirateada. Especialmente uno tan grande como Capital One.
Entonces, hacker interno, ¿qué pasó después?
Bueno, después de irrumpir en una instancia EC2... muchas cosas pueden salir mal. Prácticamente estás caminando sobre el filo de un cuchillo si dejas que alguien llegue tan lejos. Pero, ¿cómo llegó a los depósitos S3? Para entender esto, analicemos los roles de IAM.
Entonces, una forma de acceder a los servicios de AWS es ser Usuario. Bien, este es bastante obvio. Pero, ¿qué sucede si desea brindarles a otros servicios de AWS, como sus servidores de aplicaciones, acceso a sus depósitos S3? Para eso están los roles de IAM. Constan de dos componentes:
- Política de confianza: ¿qué servicios o personas pueden utilizar este rol?
- Política de permisos: ¿qué permite este rol?
Por ejemplo, desea crear una función de IAM que permitirá que las instancias EC2 accedan a un depósito de S3: primero, la función está configurada para tener una política de confianza para que EC2 (todo el servicio) o instancias específicas puedan "asumir" la función. Aceptar un rol significa que pueden usar los permisos del rol para realizar acciones. En segundo lugar, la Política de Permisos permite que el servicio/persona/recurso que ha “asumido el rol” haga cualquier cosa en S3, ya sea acceder a un depósito específico... o a más de 700, como en el caso de Capital One.
Una vez que esté en una instancia EC2 con el rol de IAM, podrá obtener credenciales de varias maneras:
- Puede solicitar metadatos de instancia en
http://169.254.169.254/latest/meta-dataEntre otras cosas, podrás encontrar el rol de IAM con cualquiera de las claves de acceso en esta dirección. Por supuesto, sólo si estás en una instancia.
- Utilice la CLI de AWS...
Si la AWS CLI está instalada, se carga con las credenciales de los roles de IAM, si están presentes. Todo lo que queda es trabajar A TRAVÉS de la instancia. Por supuesto, si su Política de Confianza estuviera abierta, Paige podría hacer todo directamente.
Entonces, la esencia de los roles de IAM es que permiten que algunos recursos actúen EN SU NOMBRE sobre OTROS RECURSOS.
Ahora que comprende las funciones de IAM, podemos hablar sobre lo que hizo Paige Thompson:
- Obtuvo acceso al servidor (instancia EC2) a través de un agujero en el firewall
Ya fueran grupos de seguridad/ACL o sus propios firewalls de aplicaciones web, el agujero probablemente fue bastante fácil de tapar, como se indica en los registros oficiales.
- Una vez en el servidor, pudo actuar "como si" ella misma fuera el servidor.
- Dado que la función del servidor IAM permitió a S3 acceder a estos más de 700 depósitos, pudo acceder a ellos.
A partir de ese momento, todo lo que tuvo que hacer fue ejecutar el comando List Bucketsy luego el comando Sync desde AWS CLI...
. Prevenir tales daños es la razón por la que las empresas invierten tanto en protección de la infraestructura de la nube, DevOps y expertos en seguridad. ¿Y qué tan valioso y rentable es pasar a la nube? Tanto es así que incluso ante cada vez más desafíos de ciberseguridad !
Moraleja de la historia: comprueba tu seguridad; Realizar auditorías periódicas; Respetar el principio de privilegio mínimo para las políticas de seguridad.
( Puedes consultar el informe jurídico completo).
Fuente: habr.com