Op 19 juli 2019 ontving Capital One het bericht waar elk modern bedrijf bang voor is: er heeft zich een datalek voorgedaan. Het trof meer dan 106 miljoen mensen. 140 Amerikaanse burgerservicenummers, één miljoen Canadese burgerservicenummers. 000 bankrekeningen. Onaangenaam, nietwaar?
Helaas vond de hack niet plaats op 19 juli. Het blijkt dat Paige Thompson, a.k.a. Erratic, pleegde het tussen 22 maart en 23 maart 2019. Dat is bijna vier maanden geleden. Sterker nog, het was alleen met de hulp van externe adviseurs dat Capital One kon ontdekken dat er iets was gebeurd.
Een voormalige Amazon-werknemer werd gearresteerd en riskeert een boete van $250 en vijf jaar gevangenisstraf... maar er is nog steeds veel negativiteit. Waarom? Omdat veel bedrijven die te lijden hebben onder hacks, proberen de verantwoordelijkheid voor het versterken van hun infrastructuur en applicaties van zich af te schuiven te midden van de toename van cybercriminaliteit.
Hoe dan ook, je kunt dit verhaal gemakkelijk googlen. We gaan niet in op drama, maar praten erover technisch kant van de zaak.
Allereerst: wat is er gebeurd?
Capital One had ongeveer 700 S3-buckets in gebruik, die Paige Thompson kopieerde en overhevelde.
Ten tweede: is dit weer een geval van verkeerd geconfigureerd S3-bucketbeleid?
Nee niet deze keer. Hier kreeg ze toegang tot een server met een verkeerd geconfigureerde firewall en voerde van daaruit de hele operatie uit.
Wacht, hoe is dat mogelijk?
Laten we beginnen met inloggen op de server, ook al hebben we niet veel details. Er werd ons alleen verteld dat het gebeurde via een ‘verkeerd geconfigureerde firewall’. Dus zoiets simpels als onjuiste beveiligingsgroepinstellingen of configuratie van de firewall van de webapplicatie (Imperva), of netwerkfirewall (iptables, ufw, shorewall, etc.). Capital One gaf alleen zijn schuld toe en zei dat het het gat had gedicht.
Stone zei dat Capital One de kwetsbaarheid van de firewall aanvankelijk niet had opgemerkt, maar snel handelde zodra het zich ervan bewust werd. Dit werd zeker geholpen door het feit dat de hacker naar verluidt belangrijke identificerende informatie in het publieke domein had achtergelaten, zei Stone.
Als u zich afvraagt waarom we niet dieper op dit deel ingaan, begrijp dan dat we vanwege de beperkte informatie alleen maar kunnen speculeren. Dit heeft geen zin aangezien de hack afhankelijk was van een gat dat door Capital One was achtergelaten. En tenzij ze ons meer vertellen, vermelden we alleen alle mogelijke manieren waarop Capital One hun server open heeft gelaten, in combinatie met alle mogelijke manieren waarop iemand een van deze verschillende opties zou kunnen gebruiken. Deze fouten en technieken kunnen variëren van enorm domme vergissingen tot ongelooflijk complexe patronen. Gezien het scala aan mogelijkheden zal dit een lang verhaal worden zonder echte conclusie. Laten we ons daarom concentreren op het analyseren van het gedeelte waar we feiten hebben.
De eerste afhaalmogelijkheid is dus: weet wat uw firewalls toestaan.
Stel een beleid of een goed proces vast om ervoor te zorgen dat ALLEEN wat geopend moet worden, wordt geopend. Als u AWS-bronnen zoals beveiligingsgroepen of netwerk-ACL's gebruikt, kan de checklist voor audits uiteraard lang zijn... maar net zoals veel bronnen automatisch worden aangemaakt (bijvoorbeeld CloudFormation), is het ook mogelijk om hun auditing te automatiseren. Of het nu een zelfgemaakt script is dat nieuwe objecten op fouten scant, of iets als een beveiligingsaudit in een CI/CD-proces... er zijn veel eenvoudige opties om dit te voorkomen.
Het "grappige" deel van het verhaal is dat als Capital One het gat überhaupt had gedicht... er niets zou zijn gebeurd. En dus is het, eerlijk gezegd, altijd schokkend om te zien hoe iets werkelijk werkt best makkelijk wordt de enige reden waarom een bedrijf wordt gehackt. Vooral één zo groot als Capital One.
Dus, hacker binnen - wat gebeurde er daarna?
Nou, na inbraak in een EC2-instantie... kan er veel misgaan. Je loopt praktisch op het scherp van de snede als je iemand zo ver laat gaan. Maar hoe kwam het in de S3-buckets terecht? Laten we, om dit te begrijpen, IAM-rollen bespreken.
Eén manier om toegang te krijgen tot AWS-services is dus door gebruiker te zijn. Oké, deze is vrij duidelijk. Maar wat als u andere AWS-diensten, zoals uw applicatieservers, toegang wilt geven tot uw S3-buckets? Daar zijn IAM-rollen voor. Ze bestaan uit twee componenten:
- Vertrouwensbeleid - welke diensten of mensen kunnen deze rol gebruiken?
- Machtigingsbeleid: wat staat deze rol toe?
U wilt bijvoorbeeld een IAM-rol maken waarmee EC2-instanties toegang kunnen krijgen tot een S3-bucket: eerst wordt de rol ingesteld op een vertrouwensbeleid dat EC2 (de gehele service) of specifieke instanties de rol kunnen 'overnemen'. Het accepteren van een rol betekent dat ze de machtigingen van de rol kunnen gebruiken om acties uit te voeren. Ten tweede staat het Permissiebeleid toe dat de dienst/persoon/bron die “de rol op zich heeft genomen” alles kan doen op S3, of het nu gaat om toegang tot één specifieke bucket... of meer dan 700, zoals in het geval van Capital One.
Zodra u zich in een EC2-instantie bevindt met de IAM-rol, kunt u op verschillende manieren inloggegevens verkrijgen:
- U kunt instance-metadata opvragen op
http://169.254.169.254/latest/meta-dataOp dit adres vindt u onder andere de IAM-rol met een van de toegangssleutels. Uiteraard alleen als u zich in een situatie bevindt.
- Gebruik AWS CLI...
Als de AWS CLI is geïnstalleerd, worden deze geladen met inloggegevens van de IAM-rollen, indien aanwezig. Het enige dat overblijft is om DOOR de instantie te werken. Als hun vertrouwensbeleid open was, zou Paige natuurlijk alles rechtstreeks kunnen doen.
De essentie van IAM-rollen is dus dat ze het mogelijk maken dat sommige resources NAMENS UW BEDRIJFSVOERING kunnen gebruiken op ANDERE MIDDELEN.
Nu je de rollen van IAM begrijpt, kunnen we praten over wat Paige Thompson deed:
- Ze kreeg toegang tot de server (EC2-instantie) via een gat in de firewall
Of het nu beveiligingsgroepen/ACL's waren of hun eigen webapplicatie-firewalls, het gat was waarschijnlijk vrij eenvoudig te dichten, zoals vermeld in de officiële documenten.
- Eenmaal op de server kon ze doen alsof ze zelf de server was
- Omdat de IAM-serverrol S3 toegang tot deze meer dan 700 buckets toestond, kon het er toegang toe krijgen
Vanaf dat moment hoefde ze alleen maar het commando uit te voeren List Bucketsen dan het commando Sync van AWS CLI...
. Het voorkomen van dergelijke schade is de reden waarom bedrijven zoveel investeren in de bescherming van cloudinfrastructuur, DevOps en beveiligingsexperts. En hoe waardevol en kosteneffectief is de overstap naar de cloud? Zelfs in het licht van steeds meer uitdagingen op het gebied van cyberbeveiliging !
Moraal van het verhaal: controleer uw veiligheid; Regelmatig audits uitvoeren; Respecteer het principe van de minste privileges voor het beveiligingsbeleid.
( U kunt het volledige juridische rapport bekijken).
Bron: www.habr.com