Op 19 Julie 2019 het Capital One die boodskap ontvang wat elke moderne maatskappy vrees - 'n data-oortreding het plaasgevind. Dit het meer as 106 miljoen mense geraak. 140 000 Amerikaanse sosiale sekerheidsnommers, een miljoen Kanadese sosiale sekerheidsnommers. 80 000 bankrekeninge. Onaangenaam, stem jy nie saam nie?
Ongelukkig het die hack nie op 19 Julie plaasgevind nie. Soos dit blyk, het Paige Thompson, a.k.a. wisselvallige, het dit tussen 22 Maart en 23 Maart 2019 gepleeg. Dit is amper vier maande gelede. Trouens, dit was net met die hulp van eksterne konsultante dat Capital One kon ontdek dat iets gebeur het.
'n Voormalige Amazon-werknemer is in hegtenis geneem en staar 'n boete van $250 XNUMX en vyf jaar tronkstraf in die gesig... maar daar is nog baie negatiwiteit oor. Hoekom? Omdat baie maatskappye wat aan hacks gely het, probeer om die verantwoordelikheid vir die versterking van hul infrastruktuur en toepassings te onttrek te midde van die toename in kubermisdaad.
In elk geval, jy kan hierdie storie maklik google. Ons gaan nie in drama in nie, maar praat oor tegnies kant van die saak.
Eerstens, wat het gebeur?
Capital One het sowat 700 S3-emmers aan die gang gehad, wat Paige Thompson gekopieer en afgehaal het.
Tweedens, is dit nog 'n geval van verkeerd gekonfigureerde S3-emmerbeleid?
Nee, nie hierdie keer nie. Hier het sy toegang tot 'n bediener met 'n verkeerd gekonfigureerde firewall gekry en die hele operasie daarvandaan uitgevoer.
Wag, hoe is dit moontlik?
Wel, kom ons begin deur by die bediener aan te meld, hoewel ons nie baie besonderhede het nie. Ons is net meegedeel dat dit gebeur het deur 'n "verkeerd gekonfigureerde firewall." Dus, iets so eenvoudig soos verkeerde sekuriteitsgroepinstellings of konfigurasie van die webtoepassing-firewall (Imperva), of netwerk-firewall (iptables, ufw, shorewall, ens.). Capital One het net sy skuld erken en gesê hy het die gat toegemaak.
Stone het gesê Capital One het aanvanklik nie die brandmuurkwesbaarheid opgemerk nie, maar het vinnig opgetree sodra hy daarvan bewus geword het. Dit is beslis aangehelp deur die feit dat die kuberkraker na bewering sleutel-identifikasie-inligting in die publieke domein gelaat het, het Stone gesê.
As jy wonder hoekom ons nie dieper in hierdie deel gaan nie, verstaan asseblief dat ons weens beperkte inligting net kan spekuleer. Dit maak geen sin nie, aangesien die hack afhanklik was van 'n gat wat Capital One gelaat het. En tensy hulle ons meer vertel, sal ons net al die moontlike maniere lys waarop Capital One hul bediener oopgelaat het in kombinasie met al die moontlike maniere waarop iemand een van hierdie verskillende opsies kan gebruik. Hierdie gebreke en tegnieke kan wissel van wild dom oorsig tot ongelooflik komplekse patrone. Gegewe die verskeidenheid moontlikhede, sal dit 'n lang sage word met geen werklike gevolgtrekking nie. Kom ons fokus dus op die ontleding van die deel waar ons feite het.
Die eerste wegneemete is dus: weet wat jou firewalls toelaat.
Stel 'n beleid of behoorlike proses vas om te verseker dat SLEGS wat oopgemaak moet word, oopgemaak word. As jy AWS-hulpbronne soos Security Groups of Network ACL's gebruik, kan die kontrolelys om te oudit natuurlik lank wees ... maar net soos baie hulpbronne outomaties geskep word (d.w.s. CloudFormation), is dit ook moontlik om hul ouditering te outomatiseer. Of dit nou 'n tuisgemaakte skrif is wat nuwe voorwerpe vir foute skandeer, of iets soos 'n sekuriteitsoudit in 'n CI/CD-proses ... daar is baie maklike opsies om dit te vermy.
Die "snaakse" deel van die storie is dat as Capital One die gat in die eerste plek toegestop het... sou niks gebeur het nie. En so, eerlik, dit is altyd skokkend om te sien hoe iets werklik redelik eenvoudig word die enigste rede waarom 'n maatskappy gekap word. Veral een so groot soos Capital One.
So, hacker binne - wat het volgende gebeur?
Wel, nadat daar by 'n EC2-instansie ingebreek is... kan baie verkeerd loop. Jy loop feitlik op 'n mespunt as jy iemand so ver laat gaan. Maar hoe het dit in S3-emmers beland? Om dit te verstaan, kom ons bespreek IAM-rolle.
Dus, een manier om toegang tot AWS-dienste te verkry, is om 'n gebruiker te wees. Goed, hierdie een is redelik voor die hand liggend. Maar wat as jy ander AWS-dienste, soos jou toepassingsbedieners, toegang tot jou S3-emmers wil gee? Dit is waarvoor IAM-rolle is. Hulle bestaan uit twee komponente:
- Trustbeleid - watter dienste of mense kan hierdie rol gebruik?
- Toestemmingsbeleid - wat laat hierdie rol toe?
Byvoorbeeld, jy wil 'n IAM-rol skep wat EC2-instansies sal toelaat om toegang tot 'n S3-emmer te kry: Eerstens is die rol ingestel om 'n Trustbeleid te hê dat EC2 (die hele diens) of spesifieke instansies die rol kan "oorneem". Om 'n rol te aanvaar, beteken dat hulle die rol se toestemmings kan gebruik om handelinge uit te voer. Tweedens laat die Toestemmingsbeleid die diens/persoon/hulpbron wat “die rol geneem het” toe om enigiets op S3 te doen, of dit nou toegang tot een spesifieke emmer is ... of meer as 700, soos in die geval van Capital One.
Sodra jy in 'n EC2-instansie met die IAM-rol is, kan jy geloofsbriewe op verskeie maniere verkry:
- Jy kan instansie metadata versoek by
http://169.254.169.254/latest/meta-dataU kan onder andere die IAM-rol met enige van die toegangsleutels by hierdie adres vind. Natuurlik net as jy in 'n geval is.
- Gebruik AWS CLI...
As die AWS CLI geïnstalleer is, word dit gelaai met geloofsbriewe van die IAM-rolle, indien teenwoordig. Al wat oorbly is om DEUR die instansie te werk. Natuurlik, as hul Trustbeleid oop was, kon Paige alles direk doen.
Die essensie van IAM-rolle is dus dat hulle sekere hulpbronne toelaat om namens jou op ANDER HULPBRONNE op te tree.
Noudat jy die rolle van IAM verstaan, kan ons praat oor wat Paige Thompson gedoen het:
- Sy het toegang tot die bediener (EC2-instansie) verkry deur 'n gat in die firewall
Of dit nou sekuriteitsgroepe/ACL's of hul eie webtoepassing-firewalls was, die gat was waarskynlik redelik maklik om te prop, soos in die amptelike rekords vermeld.
- Sodra sy op die bediener was, kon sy optree “asof” sy self die bediener was
- Aangesien die IAM-bedienerrol S3 toegang tot hierdie 700+ emmers toegelaat het, kon dit toegang daartoe verkry
Van daardie oomblik af moes sy net die opdrag uitvoer List Bucketsen dan die opdrag Sync van AWS CLI...
. Om sulke skade te voorkom, is hoekom maatskappye soveel in wolkinfrastruktuurbeskerming, DevOps en sekuriteitskundiges belê. En hoe waardevol en kostedoeltreffend is dit om na die wolk te beweeg? Soveel so dat selfs in die lig van meer en meer kuberveiligheidsuitdagings !
Moraal van die storie: kyk na jou veiligheid; Voer gereelde oudits uit; Respekteer die beginsel van die minste voorreg vir sekuriteitsbeleide.
( U kan die volledige regsverslag sien).
Bron: will.com