O 19 de xullo de 2019, Capital One recibiu a mensaxe de que todas as empresas modernas temen: produciuse unha violación de datos. Afectou a máis de 106 millóns de persoas. 140 números de seguridade social dos EUA, un millón de números de seguridade social canadense. 000 contas bancarias. Desagradable, non estás de acordo?
Desafortunadamente, o hack non se produciu o 19 de xullo. Polo que resulta, Paige Thompson, tamén coñecido como Errático, cometido entre o 22 e o 23 de marzo de 2019. É dicir hai case catro meses. De feito, foi só coa axuda de consultores externos que Capital One puido descubrir que algo sucedera.
Un antigo empregado de Amazon foi detido e enfróntase a unha multa de 250 dólares e cinco anos de prisión... pero aínda queda moita negatividade. Por que? Porque moitas empresas que sufriron pirateos informáticos intentan descartar a responsabilidade de reforzar a súa infraestrutura e aplicacións no medio do aumento da ciberdelincuencia.
De todos os xeitos, podes buscar facilmente esta historia en Google. Non entraremos no drama, senón que falamos técnico lado do asunto.
En primeiro lugar, que pasou?
Capital One tiña uns 700 baldes S3 en funcionamento, que Paige Thompson copiou e desviou.
En segundo lugar, é outro caso de política de balde S3 mal configurada?
Non, esta vez non. Aquí accedeu a un servidor cun firewall configurado incorrectamente e realizou toda a operación desde alí.
Espera, como é posible?
Pois empecemos por iniciar sesión no servidor, aínda que non temos moitos detalles. Só nos dixeron que ocorreu a través dun "firewall mal configurado". Entón, algo tan sinxelo como a configuración incorrecta do grupo de seguridade ou a configuración do firewall da aplicación web (Imperva), ou o firewall da rede (iptables, ufw, shorewall, etc.). Capital One só admitiu a súa culpa e dixo que pechou o burato.
Stone dixo que Capital One inicialmente non se decatou da vulnerabilidade do firewall, pero actuou rapidamente unha vez que se decatou. Isto foi certamente axudado polo feito de que o hacker supostamente deixou información clave de identificación no dominio público, dixo Stone.
Se estás a preguntar por que non afondamos nesta parte, entende que, debido á información limitada, só podemos especular. Isto non ten sentido dado que o hack dependía dun buraco deixado por Capital One. E a menos que nos digan máis, enumeraremos todas as formas posibles nas que Capital One deixou o seu servidor aberto en combinación con todas as formas posibles de que alguén poida usar unha destas diferentes opcións. Estes defectos e técnicas poden ir desde descoidos tremendamente estúpidos ata patróns incriblemente complexos. Dado o abano de posibilidades, esta converterase nunha longa saga sen conclusión real. Polo tanto, centrémonos na análise da parte onde temos feitos.
Polo tanto, a primeira conclusión é: sabe o que permiten os teus firewalls.
Establece unha política ou un proceso axeitado para garantir que SÓ se abre o que hai que abrir. Se estás usando recursos de AWS como grupos de seguridade ou ACL de rede, obviamente a lista de verificación para auditar pode ser longa... pero do mesmo xeito que moitos recursos se crean automaticamente (é dicir, CloudFormation), tamén é posible automatizar a súa auditoría. Tanto se se trata dun script caseiro que escanea novos obxectos en busca de fallos, ou como unha auditoría de seguridade nun proceso CI/CD... hai moitas opcións sinxelas para evitar isto.
A parte "divertida" da historia é que se Capital One tapase o burato en primeiro lugar... non pasaría nada. E así, francamente, sempre é impactante ver como algo realmente é bastante sinxelo convértese no único motivo para que unha empresa sexa pirateada. Especialmente un tan grande como Capital One.
Entón, hacker dentro - que pasou despois?
Ben, despois de entrar nunha instancia EC2... moitas cousas poden saír mal. Practicamente estás camiñando ao filo dun coitelo se deixas que alguén vaia tan lonxe. Pero como entrou nos cubos S3? Para entendelo, imos falar sobre os roles de IAM.
Polo tanto, unha forma de acceder aos servizos de AWS é ser usuario. Vale, este é bastante obvio. Pero que pasa se queres dar acceso aos teus depósitos S3 a outros servizos de AWS, como os servidores de aplicacións? Para iso están os roles de IAM. Constan de dous compoñentes:
- Política de confianza: que servizos ou persoas poden usar este rol?
- Política de permisos: que permite este rol?
Por exemplo, quere crear un rol de IAM que permita que as instancias de EC2 accedan a un depósito de S3: en primeiro lugar, o rol está configurado para que teña unha política de confianza que EC2 (todo o servizo) ou instancias específicas poidan "asumir" o rol. Aceptar un rol significa que poden usar os permisos do rol para realizar accións. En segundo lugar, a Política de permisos permite que o servizo/persoa/recurso que "asumiu o papel" faga calquera cousa en S3, xa sexa acceder a un depósito específico... ou máis de 700, como no caso de Capital One.
Unha vez que esteas nunha instancia EC2 co rol de IAM, podes obter as credenciais de varias maneiras:
- Podes solicitar metadatos de instancia en
http://169.254.169.254/latest/meta-dataEntre outras cousas, podes atopar o rol IAM con calquera das claves de acceso neste enderezo. Por suposto, só se estás nunha instancia.
- Usar AWS CLI...
Se a AWS CLI está instalada, cargarase coas credenciais dos roles de IAM, se está presente. Só queda traballar A TRAVÉS da instancia. Por suposto, se a súa política de confianza estivese aberta, Paige podería facer todo directamente.
Polo tanto, a esencia dos roles de IAM é que permiten que algúns recursos actúen NO TEU NOME OUTROS RECURSOS.
Agora que entendes as funcións de IAM, podemos falar do que fixo Paige Thompson:
- Obtivo acceso ao servidor (instancia EC2) a través dun burato no firewall
Tanto se se trataba de grupos de seguridade/ACL como dos seus propios firewalls de aplicacións web, o buraco probablemente fose bastante fácil de tapar, como se indica nos rexistros oficiais.
- Unha vez no servidor, puido actuar "como se" fose a propia servidora
- Dado que o rol de servidor IAM permitía a S3 acceder a estes máis de 700 depósitos, puido acceder a eles
A partir dese momento, o único que tivo que facer foi executar o mando List Bucketse despois o comando Sync desde AWS CLI...
. Para evitar tales danos, as empresas invisten tanto en protección da infraestrutura na nube, DevOps e expertos en seguridade. E canto de valioso e rendible é pasar á nube? Tanto é así que mesmo ante cada vez máis retos de ciberseguridade !
Moral da historia: comproba a túa seguridade; Realizar auditorías periódicas; Respectar o principio de mínimos privilexios para as políticas de seguridade.
( Podes ver o informe xurídico completo).
Fonte: www.habr.com