El 19 de juliol de 2019, Capital One va rebre el missatge que totes les empreses modernes temen: es va produir una violació de dades. Va afectar més de 106 milions de persones. 140 números de seguretat social dels EUA, un milió de números de seguretat social canadenc. 000 comptes bancaris. Desagradable, no estàs d'acord?
Malauradament, el pirateig no es va produir el 19 de juliol. Com a resultat, Paige Thompson, també conegut com a Erràtic, ho va cometre entre el 22 i el 23 de març de 2019. Això és fa gairebé quatre mesos. De fet, va ser només amb l'ajuda de consultors externs que Capital One va poder descobrir que alguna cosa havia passat.
Un antic empleat d'Amazon va ser arrestat i s'enfronta a una multa de 250 dòlars i cinc anys de presó... però encara queda molta negativitat. Per què? Perquè moltes empreses que han patit pirates informàtics intenten descartar la responsabilitat d'enfortir la seva infraestructura i aplicacions enmig de l'augment de la ciberdelinqüència.
De totes maneres, podeu buscar fàcilment a Google aquesta història. No entrarem en drama, sinó parlar-ne tècnic costat de la qüestió.
En primer lloc, què va passar?
Capital One tenia uns 700 cubs S3 en funcionament, que Paige Thompson va copiar i desviar.
En segon lloc, és aquest un altre cas de política de cub S3 mal configurada?
No, aquesta vegada no. Aquí va accedir a un servidor amb un tallafoc configurat incorrectament i des d'allà va realitzar tota l'operació.
Espera, com és possible?
Bé, comencem per iniciar sessió al servidor, tot i que no tenim molts detalls. Només ens van dir que va passar a través d'un "tallafocs mal configurat". Per tant, una cosa tan senzilla com la configuració incorrecta del grup de seguretat o la configuració del tallafoc de l'aplicació web (Imperva), o el tallafoc de xarxa (iptables, ufw, shorewall, etc.). Capital One només va admetre la seva culpa i va dir que havia tancat el forat.
Stone va dir que Capital One no es va adonar inicialment de la vulnerabilitat del tallafoc, però va actuar ràpidament una vegada que se'n va adonar. Això, sens dubte, va ser ajudat pel fet que el pirata informàtic suposadament va deixar informació clau d'identificació al domini públic, va dir Stone.
Si us pregunteu per què no aprofundim en aquesta part, entengueu que a causa de la informació limitada només podem especular. Això no té sentit atès que el pirateig depenia d'un forat deixat per Capital One. I tret que ens diguin més, només enumerarem totes les maneres possibles en què Capital One va deixar obert el seu servidor juntament amb totes les maneres possibles en què algú podria utilitzar una d'aquestes opcions diferents. Aquests defectes i tècniques poden anar des de descuits estúpids fins a patrons increïblement complexos. Tenint en compte el ventall de possibilitats, es convertirà en una llarga saga sense conclusió real. Per tant, centrem-nos a analitzar la part on tenim fets.
Per tant, el primer punt per emportar és: saber què permeten els vostres tallafocs.
Establir una política o un procés adequat per garantir que NOMÉS s'obri allò que cal obrir. Si utilitzeu recursos d'AWS com ara grups de seguretat o ACL de xarxa, òbviament, la llista de verificació per auditar pot ser llarga... però igual que molts recursos es creen automàticament (és a dir, CloudFormation), també és possible automatitzar-ne l'auditoria. Tant si es tracta d'un script casolà que escaneja nous objectes a la recerca de defectes, com d'una auditoria de seguretat en un procés CI/CD... hi ha moltes opcions fàcils per evitar-ho.
La part "divertida" de la història és que si Capital One hagués tapat el forat en primer lloc... no hauria passat res. I per tant, francament, sempre és impactant veure com alguna cosa realment bastant senzill es converteix en l'únic motiu pel qual una empresa és piratejada. Sobretot un tan gran com Capital One.
Aleshores, pirata informàtic, què va passar després?
Bé, després d'entrar en una instància EC2... moltes coses poden sortir malament. Pràcticament esteu caminant a la vora d'un ganivet si deixeu que algú vagi tan lluny. Però, com va entrar als cubs S3? Per entendre-ho, parlem dels rols d'IAM.
Per tant, una manera d'accedir als serveis d'AWS és ser usuari. D'acord, aquest és bastant obvi. Però, què passa si voleu donar accés a altres serveis d'AWS, com ara els vostres servidors d'aplicacions, als vostres cubs S3? Per això serveixen els rols IAM. Consten de dos components:
- Política de confiança: quins serveis o persones poden utilitzar aquesta funció?
- Política de permisos: què permet aquesta funció?
Per exemple, voleu crear un rol IAM que permeti que les instàncies EC2 accedeixin a un cub S3: en primer lloc, el rol està configurat per tenir una política de confiança que EC2 (tot el servei) o instàncies específiques puguin "assumir" el rol. Acceptar un rol significa que poden utilitzar els permisos del rol per realitzar accions. En segon lloc, la política de permisos permet que el servei/persona/recurs que ha "assumit el paper" pugui fer qualsevol cosa a S3, ja sigui accedir a un cub específic... o més de 700, com en el cas de Capital One.
Un cop us trobeu en una instància EC2 amb la funció IAM, podeu obtenir les credencials de diverses maneres:
- Podeu sol·licitar metadades de la instància a
http://169.254.169.254/latest/meta-dataEntre altres coses, podeu trobar la funció IAM amb qualsevol de les claus d'accés en aquesta adreça. Per descomptat, només si esteu en una instància.
- Utilitzeu AWS CLI...
Si l'AWS CLI està instal·lada, es carrega amb les credencials dels rols IAM, si n'hi ha. Només queda treballar A TRAVÉS de la instància. Per descomptat, si la seva política de confiança estava oberta, Paige podria fer-ho tot directament.
Per tant, l'essència dels rols de l'IAM és que permeten que alguns recursos actuïn EN EL VOSTRE NOM en ALTRES RECURSOS.
Ara que enteneu les funcions d'IAM, podem parlar del que va fer Paige Thompson:
- Va obtenir accés al servidor (instància EC2) a través d'un forat al tallafoc
Tant si es tractava de grups de seguretat/ACL com dels seus propis tallafocs d'aplicacions web, probablement el forat fos bastant fàcil de tapar, tal com s'indica als registres oficials.
- Un cop al servidor, va poder actuar "com si" ella mateixa fos la servidora
- Com que la funció de servidor IAM va permetre l'accés a S3 a aquests més de 700 compartiments, va poder accedir-hi
A partir d'aquell moment, tot el que va haver de fer va ser executar l'ordre List Bucketsi després l'ordre Sync des d'AWS CLI...
. Prevenir aquest dany és el motiu pel qual les empreses inverteixen tant en protecció de la infraestructura del núvol, DevOps i experts en seguretat. I com de valuós i rendible és passar al núvol? Tant és així que fins i tot davant de cada cop més reptes de ciberseguretat !
Moral de la història: comproveu la vostra seguretat; Realitzar auditories periòdiques; Respectar el principi de mínims privilegis per a les polítiques de seguretat.
( Podeu consultar l'informe legal complet).
Font: www.habr.com