Pe 19 iulie 2019, Capital One a primit mesajul de care fiecare companie modernă se teme: a avut loc o scurgere de date. A afectat peste 106 milioane de oameni. 140 de numere de securitate socială din SUA, un milion de numere de securitate socială canadiană. 000 de conturi bancare. Neplăcut, nu ești de acord?
Din păcate, hack-ul nu a avut loc pe 19 iulie. După cum se dovedește, Paige Thompson, a.k.a. Neregulat, a comis-o în perioada 22 martie – 23 martie 2019. Acesta este acum aproape patru luni. De fapt, doar cu ajutorul consultanților externi Capital One a putut descoperi că s-a întâmplat ceva.
Un fost angajat al Amazon a fost arestat și riscă o amendă de 250 de dolari și cinci ani de închisoare... dar încă mai sunt multe negativități. De ce? Pentru că multe companii care au suferit de hack-uri încearcă să-și ridice din umeri responsabilitatea de a-și consolida infrastructura și aplicațiile pe fondul creșterii criminalității cibernetice.
Oricum, poți căuta cu ușurință această poveste pe Google. Nu vom intra în dramă, ci vorbim despre tehnic partea problemei.
În primul rând, ce s-a întâmplat?
Capital One avea aproximativ 700 de găleți S3 în funcțiune, pe care Paige Thompson le-a copiat și le-a sifonat.
În al doilea rând, acesta este un alt caz de politică de bucket S3 configurată greșit?
Nu. Nu acum. Aici a obținut acces la un server cu un firewall configurat incorect și a efectuat întreaga operațiune de acolo.
Stai, cum e posibil?
Ei bine, să începem prin a ne autentifica pe server, deși nu avem multe detalii. Ni s-a spus doar că s-a întâmplat printr-un „paravan de protecție greșit”. Așadar, ceva la fel de simplu precum setările incorecte ale grupului de securitate sau configurarea firewall-ului aplicației web (Imperva) sau firewall-ului de rețea (iptables, ufw, shorewall etc.). Capital One doar și-a recunoscut vinovăția și a spus că a închis gaura.
Stone a spus că Capital One nu a observat inițial vulnerabilitatea firewall-ului, dar a acționat rapid odată ce și-a dat seama de aceasta. Acest lucru a fost cu siguranță ajutat de faptul că hackerul ar fi lăsat informații cheie de identificare în domeniul public, a spus Stone.
Dacă vă întrebați de ce nu aprofundăm această parte, vă rugăm să înțelegeți că, din cauza informațiilor limitate, putem doar specula. Acest lucru nu are sens, având în vedere că hack-ul depindea de o gaură lăsată de Capital One. Și dacă nu ne spun mai multe, vom enumera toate modalitățile posibile prin care Capital One și-a lăsat serverul deschis, în combinație cu toate modurile posibile în care cineva ar putea folosi una dintre aceste opțiuni diferite. Aceste defecte și tehnici pot varia de la neglijențe extrem de stupide până la modele incredibil de complexe. Având în vedere gama de posibilități, aceasta va deveni o saga lungă fără o concluzie reală. Prin urmare, să ne concentrăm pe analizarea părții în care avem fapte.
Deci prima concluzie este: știți ce vă permit firewall-urile.
Stabiliți o politică sau un proces adecvat pentru a vă asigura că este deschis DOAR ceea ce trebuie deschis. Dacă utilizați resurse AWS, cum ar fi grupuri de securitate sau ACL-uri de rețea, evident că lista de verificare de auditat poate fi lungă... dar la fel cum multe resurse sunt create automat (adică CloudFormation), este, de asemenea, posibil să le automatizați auditarea. Fie că este un script de casă care scanează noi obiecte pentru defecte, sau ceva de genul unui audit de securitate într-un proces CI/CD... există multe opțiuni simple pentru a evita acest lucru.
Partea „ amuzantă ” a poveștii este că dacă Capital One ar fi astupat gaura în primul rând... nu s-ar fi întâmplat nimic. Și așa, sincer, este întotdeauna șocant să vezi cum ceva cu adevărat destul de simplu devine singurul motiv pentru ca o companie să fie piratată. Mai ales unul la fel de mare ca Capital One.
Deci, hacker dinăuntru - ce s-a întâmplat mai departe?
Ei bine, după ce a intrat într-o instanță EC2... multe pot merge prost. Practic mergi pe muchia unui cuțit dacă lași pe cineva să meargă atât de departe. Dar cum a ajuns în gălețile S3? Pentru a înțelege acest lucru, să discutăm despre Rolurile IAM.
Deci, o modalitate de a accesa serviciile AWS este să fii utilizator. Bine, acesta este destul de evident. Dar ce se întâmplă dacă doriți să oferiți altor servicii AWS, cum ar fi serverele dvs. de aplicații, acces la compartimentele dvs. S3? Pentru asta sunt rolurile IAM. Ele constau din două componente:
- Politica de încredere - ce servicii sau persoane pot folosi acest rol?
- Politica de permisiuni - ce permite acest rol?
De exemplu, doriți să creați un rol IAM care va permite instanțelor EC2 să acceseze un compartiment S3: În primul rând, rolul este setat să aibă o politică de încredere pe care EC2 (întregul serviciu) sau anumite instanțe pot „prelua” rolul. Acceptarea unui rol înseamnă că pot folosi permisiunile rolului pentru a efectua acțiuni. În al doilea rând, Politica de permisiuni permite serviciului/persoanei/resursei care a „asumat rolul” să facă orice pe S3, fie că este vorba de accesarea unei anumite găleți... sau peste 700, ca în cazul Capital One.
Odată ce vă aflați într-o instanță EC2 cu rolul IAM, puteți obține acreditări în mai multe moduri:
- Puteți solicita metadatele instanței la
http://169.254.169.254/latest/meta-dataPrintre altele, puteți găsi rolul IAM cu oricare dintre cheile de acces la această adresă. Desigur, doar dacă te afli într-o instanță.
- Utilizați AWS CLI...
Dacă AWS CLI este instalat, acesta este încărcat cu acreditările de la rolurile IAM, dacă există. Tot ce rămâne este să lucrezi PRIN instanță. Desigur, dacă politica lor de încredere era deschisă, Paige putea face totul direct.
Deci, esența rolurilor IAM este că acestea permit unor resurse să acționeze ÎN NUMELE DVS. asupra ALTE RESURSE.
Acum că înțelegeți rolurile IAM, putem vorbi despre ceea ce a făcut Paige Thompson:
- Ea a obținut acces la server (instanță EC2) printr-o gaură din firewall
Fie că era vorba de grupuri de securitate/ACL-uri sau propriile firewall-uri pentru aplicații web, gaura a fost probabil destul de ușor de astupat, așa cum se menționează în înregistrările oficiale.
- Odată ajunsă pe server, ea a putut să se comporte „ca și cum” ar fi ea însăși serverul
- Deoarece rolul serverului IAM a permis accesul S3 la aceste peste 700 de compartimente, a putut să le acceseze
Din acel moment, tot ce a avut de făcut a fost să execute comanda List Bucketsiar apoi comanda Sync din AWS CLI...
. Prevenirea unor astfel de daune este motivul pentru care companiile investesc atât de mult în protecția infrastructurii cloud, DevOps și experți în securitate. Și cât de valoroasă și de rentabilă este trecerea la cloud? Atât de mult încât chiar și în fața tot mai multor provocări de securitate cibernetică !
Morala povestirii: verifica-ti siguranta; Efectuează audituri regulate; Respectați principiul cel mai mic privilegiu pentru politicile de securitate.
( Puteți vizualiza raportul juridic complet).
Sursa: www.habr.com