Den 19. Juli 2019 krut Capital One de Message datt all modern Firma fäert - eng Dateverletzung ass geschitt. Et huet méi wéi 106 Millioune Leit betraff. 140 US Sozialversécherungsnummeren, eng Millioun kanadesch Sozialversécherungsnummeren. 000 Bankkonten. Desagréabel, sidd Dir net averstanen?
Leider ass den Hack net den 19. Juli geschitt. Wéi et vläit, Paige Thompson, a.k.a. Onregelméisseg, huet et tëscht dem 22. Mäerz an dem 23. Mäerz 2019 engagéiert. Dat ass viru bal véier Méint. Tatsächlech war et nëmme mat der Hëllef vun externe Beroder datt Capital One konnt entdecken datt eppes geschitt ass.
E fréiere Amazon Employé gouf festgeholl a riskéiert eng Geldstrof vun 250 Dollar a fënnef Joer Prisong ... awer et bleift nach vill Negativitéit. Firwat? Well vill Firmen, déi ënner Hacks gelidden hunn, probéieren d'Verantwortung ofzezéien fir hir Infrastruktur an Uwendungen ze stäerken amgaang vun der Erhéijung vun der Cyberkriminalitéit.
Wéi och ëmmer, Dir kënnt dës Geschicht ganz einfach google. Mir ginn net an Drama, mee schwätzen iwwer technesch Säit vun der Saach.
Éischtens, wat ass geschitt?
Capital One hat ongeféier 700 S3 Eemer lafen, déi Paige Thompson kopéiert a siphonéiert huet.
Zweetens, ass dëst en anere Fall vu falsch konfiguréierter S3 Eemer Politik?
Nee, net dës Kéier. Hei krut si Zougang zu engem Server mat enger falsch konfiguréierter Firewall an huet déi ganz Operatioun vun do aus gemaach.
Waart, wéi ass dat méiglech?
Gutt, loosst eis ufänken op de Server aloggen, obwuel mir net vill Detailer hunn. Mir goufe just gesot datt et duerch eng "falschkonfiguréiert Firewall" geschitt ass. Also, eppes sou einfach wéi falsch Sécherheetsgrupp Astellungen oder Konfiguratioun vun der Webapplikatioun Firewall (Imperva), oder Netzwierk Firewall (iptables, ufw, shorewall, etc.). Capital One huet nëmmen seng Schold zouginn a gesot datt et d'Lach zougemaach huet.
Stone sot, datt Capital One am Ufank net d'Firewall Schwachstelle gemierkt huet, awer séier gehandelt huet nodeems se sech bewosst gouf. Dëst gouf sécherlech gehollef vun der Tatsaach datt den Hacker angeblech Schlësselidentifikatiounsinformatioun am ëffentleche Domain hannerlooss huet, sot Stone.
Wann Dir Iech frot firwat mir net méi déif an dësen Deel goen, da verstitt w.e.g. datt mir wéinst limitéierter Informatioun nëmme spekuléiere kënnen. Dëst mécht kee Sënn, well den Hack hänkt vun engem Lach of, deen vum Capital One hannerlooss ass. An ausser si soen eis méi, mir lëschte just all méiglech Weeër wéi Capital One hire Server opgemaach huet a Kombinatioun mat all méigleche Weeër wéi een eng vun dësen verschiddenen Optiounen benotze kéint. Dës Mängel an Technike kënne vu vill domm Iwwersiicht bis onheemlech komplex Mustere variéieren. Duerch d'Gamme vu Méiglechkeeten wäert dëst eng laang Saga ginn ouni richteg Conclusioun. Dofir konzentréiere mir eis op d'Analyse vum Deel wou mir Fakten hunn.
Also déi éischt Takeaway ass: wësse wat Är Firewalls erlaben.
Etabléiert eng Politik oder e richtege Prozess fir sécherzestellen datt NËMMEN wat opgemaach muss ginn opgemaach gëtt. Wann Dir AWS Ressourcen benotzt wéi Sécherheetsgruppen oder Network ACLs, selbstverständlech kann d'Checklëscht fir Audit laang sinn ... awer grad wéi vill Ressourcen automatesch erstallt ginn (dh CloudFormation), ass et och méiglech hir Audit ze automatiséieren. Egal ob et en hausgemaachte Skript ass, deen nei Objete fir Mängel scannt, oder eppes wéi e Sécherheetsaudit an engem CI/CD Prozess ... et gi vill einfach Optiounen fir dëst ze vermeiden.
De "witzegen" Deel vun der Geschicht ass datt wann Capital One d'Lach iwwerhaapt zougestoppt hätt ... näischt geschitt wier. An dofir, éierlech gesot, et ass ëmmer schockéiert ze gesinn wéi eppes wierklech flott einfach gëtt deen eenzege Grond fir eng Firma gehackt ze ginn. Besonnesch een esou grouss wéi Capital One.
Also, Hacker bannen - wat ass duerno geschitt?
Gutt, nodeems se an eng EC2 Instanz agebrach sinn ... ka vill falsch goen. Dir gitt praktesch op engem Messerkant, wann Dir een esou wäit léisst. Awer wéi ass et an d'S3 Eemer komm? Fir dëst ze verstoen, loosst eis IAM Rollen diskutéieren.
Also, ee Wee fir Zougang zu AWS Servicer ass e Benotzer ze sinn. Okay, dësen ass zimlech offensichtlech. Awer wat wann Dir aner AWS Servicer wëllt ginn, wéi Ären Applikatiounsserver, Zougang zu Äre S3 Eemer? Dat ass wat IAM Rollen sinn fir. Si besteet aus zwee Komponenten:
- Vertrauenspolitik - wéi eng Servicer oder Leit kënnen dës Roll benotzen?
- Permissiounen Politik - wat erlaabt dës Roll?
Zum Beispill wëllt Dir eng IAM Roll erstellen déi EC2 Instanzen Zougang zu engem S3 Eemer erlaabt: Éischtens ass d'Roll gesat fir eng Vertrauenspolitik ze hunn datt EC2 (de ganze Service) oder spezifesch Instanzen d'Roll "iwwerhuelen". Eng Roll akzeptéieren heescht datt se d'Permissioune vun der Roll benotze kënnen fir Aktiounen auszeféieren. Zweetens, erlaabt d'Permissiounen Politik de Service / Persoun / Ressource déi "d'Roll geholl" huet alles op S3 ze maachen, egal ob et Zougang zu engem spezifeschen Eemer ass ... oder iwwer 700, wéi am Fall vun Capital One.
Wann Dir an enger EC2 Instanz mat der IAM Roll sidd, kënnt Dir Umeldungsinformatiounen op verschidde Weeër kréien:
- Dir kënnt Instanz Metadaten ufroen op
http://169.254.169.254/latest/meta-dataËnner anerem fannt Dir d'IAM Roll mat engem vun den Zougangsschlësselen op dëser Adress. Natierlech, nëmmen wann Dir an enger Instanz sidd.
- Benotzt AWS CLI ...
Wann den AWS CLI installéiert ass, gëtt et mat Umeldungsinformatiounen aus den IAM Rollen gelueden, wa präsent. Alles wat bleift ass DUERCH d'Instanz ze schaffen. Natierlech, wann hir Vertrauenspolitik oppe war, kéint Paige alles direkt maachen.
Also d'Essenz vun IAM Rollen ass datt se e puer Ressourcen erlaben fir ÄREM NËMMEN op ANER RESOURCES ze handelen.
Elo datt Dir d'Roll vun IAM versteet, kënne mir schwätzen iwwer wat Paige Thompson gemaach huet:
- Si krut Zougang zu de Server (EC2 Instanz) duerch e Lach an der Firewall
Egal ob et Sécherheetsgruppen / ACLs waren oder hir eege Webapplikatiouns Firewalls, d'Lach war wahrscheinlech zimlech einfach ze pluggen, wéi et an den offiziellen Opzeechnungen steet.
- Eemol um Server, si konnt "wéi wann" si de Server selwer wier
- Zënter datt d'IAM Server Roll S3 Zougang zu dësen 700+ Eemer erlaabt huet, konnt se Zougang zu hinnen kréien
Vun deem Moment un huet si just de Kommando ausgefouert List Bucketsan dann de Kommando Sync vun AWS CLI...
. Esou Schued verhënnert ass firwat Firmen sou vill an Cloud Infrastruktur Schutz, DevOps a Sécherheetsexperten investéieren. A wéi wäertvoll a kascht-effikass plënnert op d'Wollek? Sou vill esou datt och am Gesiicht vun ëmmer méi Cybersecurity Erausfuerderunge !
Moral vun der Geschicht: kontrolléieren Är Sécherheet; Reegelméissegen Audit maachen; Respektéiert de Prinzip vum mannsten Privileg fir Sécherheetspolitik.
( Dir kënnt de komplette legale Bericht gesinn).
Source: will.com