Op 19 july 2019 krige Capital One it berjocht dat elk modern bedriuw benaud is - in gegevensbreuk barde. It beynfloede mear as 106 miljoen minsken. 140 Amerikaanske sosjale feiligensnûmers, ien miljoen Kanadeeske sosjale feiligensnûmers. 000 bankrekken. Onaangenaam, binne jo it net iens?
Spitigernôch kaam de hack net op 19 july. As it docht bliken, Paige Thompson, a.k.a. Unregelmjittich, begien it tusken 22 maart en 23 maart 2019. Dat is hast fjouwer moanne lyn. Eins koe Capital One allinnich mei help fan adviseurs fan bûten ûntdekke dat der wat bard wie.
In eardere Amazon-meiwurker waard arresteare en krijt in boete fan $ 250 en fiif jier finzenisstraf ... mar d'r is noch in protte negativiteit oer. Wêrom? Om't in protte bedriuwen dy't lêst hawwe fan hacks besykje de ferantwurdlikens te skodzjen foar it fersterkjen fan har ynfrastruktuer en applikaasjes te midden fan 'e opkomst fan cyberkriminaliteit.
Hoe dan ek, jo kinne dit ferhaal maklik googleje. Wy geane net yn drama, mar prate oer technysk kant fan de saak.
Earst fan alles, wat is der bard?
Capital One hie sa'n 700 S3-emmers rinnen, dy't Paige Thompson kopiearre en sifonearre.
As twadde, is dit in oar gefal fan ferkeard konfigureare S3-emmerbelied?
Nee, dizze kear net. Hjir krige se tagong ta in server mei in ferkeard ynstelde brânmuorre en fierde de hiele operaasje dêrwei út.
Wachtsje, hoe is dat mooglik?
No, lit ús begjinne troch yn te loggen op de tsjinner, hoewol wy net folle details hawwe. Wy waarden allinich ferteld dat it barde fia in "miskonfigureare firewall." Dat, wat sa ienfâldich as ferkearde ynstellings foar befeiligingsgroepen of konfiguraasje fan 'e webapplikaasje-firewall (Imperva), of netwurk-firewall (iptables, ufw, shorewall, ensfh.). Capital One joech allinich syn skuld ta en sei dat it it gat ticht hie.
Stone sei dat Capital One yn earste ynstânsje de kwetsberens fan 'e brânmuorre net opmurken, mar rap hannele as it derfan bewust waard. Dit waard grif holpen troch it feit dat de hacker nei alle gedachten wichtige identifisearjende ynformaasje yn it publike domein liet, sei Stone.
As jo jo ôffreegje wêrom't wy dit diel net djipper yngeane, begryp dan asjebleaft dat wy fanwege beheinde ynformaasje allinich kinne spekulearje. Dit makket gjin sin jûn dat de hack ôfhinklik wie fan in gat oerlitten troch Capital One. En útsein as se ús mear fertelle, sille wy gewoan alle mooglike manieren listje wêrop Capital One har server iepen liet yn kombinaasje mei alle mooglike manieren wêrop immen ien fan dizze ferskillende opsjes koe brûke. Dizze gebreken en techniken kinne fariearje fan wyld domme tafersjoch oant ongelooflijk komplekse patroanen. Sjoen it oanbod fan mooglikheden sil dit in lange saga wurde sûnder echte konklúzje. Litte wy dêrom fokusje op it analysearjen fan it diel wêr't wy feiten hawwe.
Dus de earste takeaway is: wit wat jo firewalls tastean.
Fêststelle in belied of goed proses om te soargjen dat ALLEEN wat moat wurde iepene wurdt iepene. As jo AWS-boarnen brûke lykas Feiligensgroepen of Netwurk-ACL's, kin fansels de checklist om te kontrolearjen lang wêze ... mar krekt lykas in protte boarnen wurde automatysk oanmakke (dus CloudFormation), is it ek mooglik om har kontrôle te automatisearjen. Oft it no in selsmakke skript is dat nije objekten scant foar gebreken, of soksawat as in feiligenskontrôle yn in CI/CD-proses ... d'r binne in protte maklike opsjes om dit te foarkommen.
It "grappige" diel fan it ferhaal is dat as Capital One it gat yn it foarste plak ferstoppe hie ... neat bard wie. En sa, earlik sein, is it altyd skokkend om te sjen hoe't iets echt is moai simpel wurdt de ienige reden foar in bedriuw wurde hacked. Benammen ien sa grut as Capital One.
Dat, hacker binnen - wat barde dernei?
No, nei it ynbrekken fan in EC2-eksimplaar ... kin in protte mis gean. Jo rinne praktysk op in mes as jo ien sa fier gean litte. Mar hoe kaam it yn S3-bakken? Om dit te begripen, litte wy de IAM-rollen beprate.
Dat, ien manier om tagong te krijen ta AWS-tsjinsten is in brûker te wêzen. Okee, dizze is frij dúdlik. Mar wat as jo oare AWS-tsjinsten wolle jaan, lykas jo applikaasjeservers, tagong ta jo S3-bakken? Dat is wêr't IAM-rollen foar binne. Se besteane út twa komponinten:
- Trustbelied - hokker tsjinsten of minsken kinne dizze rol brûke?
- Fergunningsbelied - wat lit dizze rol ta?
Jo wolle bygelyks in IAM-rol meitsje wêrmei EC2-eksimplaren tagong krije ta in S3-emmer: Earst is de rol ynsteld om in Trustbelied te hawwen dat EC2 (de heule tsjinst) of spesifike eksimplaren de rol kinne "oernimme". It akseptearjen fan in rol betsjut dat se de tagongsrjochten fan 'e rol brûke kinne om aksjes út te fieren. Twads lit it tastimmingsbelied de tsjinst / persoan / boarne dy't "de rol" hat nommen om alles te dwaan op S3, of it no tagong is ta ien spesifike bak ... of mear dan 700, lykas yn it gefal fan Capital One.
As jo ienris yn in EC2-eksimplaar binne mei de IAM-rol, kinne jo bewiisbrieven op ferskate manieren krije:
- Jo kinne bygelyks metadata oanfreegje by
http://169.254.169.254/latest/meta-dataUnder oare dingen kinne jo de IAM-rol fine mei ien fan 'e tagongskaaien op dit adres. Fansels, allinich as jo yn in eksimplaar binne.
- Brûk AWS CLI ...
As de AWS CLI is ynstalleare, wurdt it laden mei bewiisbrieven fan 'e IAM-rollen, as oanwêzich. Alles wat oerbliuwt is om it eksimplaar te wurkjen. Fansels, as har Trustbelied iepen wie, koe Paige alles direkt dwaan.
Dat de essinsje fan IAM-rollen is dat se guon boarnen tastean om YN JOU NACHT te hanneljen op ANDERE RESOURCES.
No't jo de rollen fan IAM begripe, kinne wy prate oer wat Paige Thompson die:
- Se krige tagong ta de tsjinner (EC2-eksimplaar) troch in gat yn 'e brânmuorre
Oft it no feiligensgroepen / ACL's wiene as har eigen firewalls foar webapplikaasjes, it gat wie wierskynlik frij maklik te pluggen, lykas sein yn 'e offisjele records.
- Ien kear op 'e tsjinner koe se hannelje "as oft" se sels de tsjinner wie
- Sûnt de IAM-tsjinner rol tastien S3 tagong ta dizze 700+ bakken, it koe tagong ta harren
Fan dat momint ôf hoegde se allinnich it kommando út te fieren List Bucketsen dan it kommando Sync fan AWS CLI...
. It foarkommen fan sokke skea is de reden wêrom bedriuwen safolle ynvestearje yn beskerming fan wolkynfrastruktuer, DevOps en feiligenseksperts. En hoe weardefol en rendabel is it ferpleatsen nei de wolk? Safolle dat sels yn it gesicht fan mear en mear útdagings foar cybersecurity !
Moraal fan it ferhaal: kontrolearje jo feiligens; Regelmjittige audits útfiere; Respektearje it prinsipe fan minste privileezje foar feiligensbelied.
( Jo kinne it folsleine juridyske rapport besjen).
Boarne: www.habr.com