Noong Hulyo 19, 2019, natanggap ng Capital One ang mensahe na kinakatakutan ng bawat modernong kumpanya—naganap ang isang paglabag sa data. Naapektuhan nito ang higit sa 106 milyong tao. 140 US social security number, isang milyong Canadian social security number. 000 bank account. Hindi kanais-nais, hindi ka ba sumasang-ayon?
Sa kasamaang palad, hindi nangyari ang hack noong ika-19 ng Hulyo. Sa lumalabas, si Paige Thompson, a.k.a. Masama, ginawa ito sa pagitan ng Marso 22 at Marso 23, 2019. Yan ay halos apat na buwan na ang nakalipas. Sa katunayan, sa tulong lamang ng mga consultant sa labas na natuklasan ng Capital One na may nangyari.
Isang dating empleyado ng Amazon ang inaresto at nahaharap sa $250 na multa at limang taon sa bilangguan... ngunit marami pa ring negatibong natitira. Bakit? Dahil maraming mga kumpanya na nagdusa mula sa mga hack ay sinusubukang i-shrug off ang responsibilidad para sa pagpapalakas ng kanilang mga imprastraktura at mga aplikasyon sa gitna ng pagtaas ng cybercrime.
Anyway, madali mong i-google ang kwentong ito. Hindi tayo magda-drama, kundi pag-usapan panteknikal panig ng usapin.
Una sa lahat, ano ang nangyari?
Ang Capital One ay may humigit-kumulang 700 S3 bucket na tumatakbo, na kinopya at sinipsip ni Paige Thompson.
Pangalawa, ito ba ay isa pang kaso ng maling pagkaka-configure ng patakaran sa bucket ng S3?
Hindi, hindi sa pagkakataong ito. Dito siya nakakuha ng access sa isang server na may hindi wastong na-configure na firewall at isinagawa ang buong operasyon mula doon.
Teka, paano ito posible?
Buweno, magsimula tayo sa pamamagitan ng pag-log in sa server, kahit na wala kaming maraming mga detalye. Sinabi lang sa amin na nangyari ito sa pamamagitan ng "misconfigured firewall." Kaya, isang bagay na kasing simple ng hindi tamang mga setting ng grupo ng seguridad o configuration ng firewall ng web application (Imperva), o network firewall (iptables, ufw, shorewall, atbp.). Inamin lamang ng Capital One ang kasalanan nito at sinabing isinara na nito ang butas.
Sinabi ni Stone na hindi unang napansin ng Capital One ang kahinaan ng firewall ngunit mabilis itong kumilos nang malaman ito. Ito ay tiyak na nakatulong sa katotohanan na ang hacker ay umano'y nag-iwan ng pangunahing impormasyon sa pagkakakilanlan sa pampublikong domain, sabi ni Stone.
Kung nagtataka ka kung bakit hindi na kami lumalalim sa bahaging ito, mangyaring unawain na dahil sa limitadong impormasyon maaari lamang kaming mag-isip-isip. Ito ay walang kahulugan dahil ang hack ay nakadepende sa isang butas na iniwan ng Capital One. At maliban na lang kung sasabihin pa nila sa amin, ililista lang namin ang lahat ng posibleng paraan na pinabayaan ng Capital One na bukas ang kanilang server kasama ang lahat ng posibleng paraan na magagamit ng isang tao ang isa sa iba't ibang opsyong ito. Ang mga kapintasan at diskarteng ito ay maaaring mula sa napakagandang mga oversight hanggang sa hindi kapani-paniwalang kumplikadong mga pattern. Dahil sa hanay ng mga posibilidad, ito ay magiging isang mahabang alamat na walang tunay na konklusyon. Samakatuwid, tumuon tayo sa pagsusuri sa bahagi kung saan mayroon tayong mga katotohanan.
Kaya ang unang takeaway ay: alamin kung ano ang pinapayagan ng iyong mga firewall.
Magtatag ng isang patakaran o tamang proseso upang matiyak na LAMANG ang dapat buksan ang mabubuksan. Kung gumagamit ka ng mga mapagkukunan ng AWS tulad ng Mga Grupo ng Seguridad o Mga ACL ng Network, malinaw na maaaring mahaba ang checklist na i-audit... ngunit tulad ng maraming mga mapagkukunan ay awtomatikong nilikha (ibig sabihin, CloudFormation), posible ring i-automate ang kanilang pag-audit. Isa man itong gawang bahay na script na nag-scan ng mga bagong bagay para sa mga depekto, o tulad ng isang pag-audit sa seguridad sa isang proseso ng CI/CD... maraming madaling opsyon para maiwasan ito.
Ang "nakakatawa" na bahagi ng kuwento ay kung ang Capital One ay nagsaksak sa butas sa unang lugar ... walang mangyayari. At kaya, sa totoo lang, palaging nakakagulat na makita kung gaano talaga ang isang bagay simple lang nagiging tanging dahilan para ma-hack ang isang kumpanya. Lalo na ang isang kasing laki ng Capital One.
Kaya, hacker sa loob - ano ang sumunod na nangyari?
Well, pagkatapos pumasok sa isang EC2 instance... marami ang maaaring magkamali. Halos maglalakad ka sa dulo ng kutsilyo kung hahayaan mo ang isang tao na pumunta nang ganoon kalayo. Ngunit paano ito napunta sa mga balde ng S3? Upang maunawaan ito, talakayin natin ang Mga Tungkulin ng IAM.
Kaya, ang isang paraan upang ma-access ang mga serbisyo ng AWS ay ang pagiging isang User. Okay, ito ay medyo halata. Ngunit paano kung gusto mong magbigay ng ibang mga serbisyo ng AWS, gaya ng iyong mga server ng application, ng access sa iyong mga S3 bucket? Iyan ay para sa mga tungkulin ng IAM. Binubuo sila ng dalawang sangkap:
- Patakaran sa Pagtitiwala - anong mga serbisyo o tao ang maaaring gumamit ng tungkuling ito?
- Patakaran sa Mga Pahintulot - ano ang pinapayagan ng tungkuling ito?
Halimbawa, gusto mong gumawa ng tungkulin ng IAM na magbibigay-daan sa mga instance ng EC2 na ma-access ang isang S3 bucket: Una, nakatakda ang tungkulin na magkaroon ng Patakaran sa Pagtitiwala na maaaring "kunin" ng EC2 (ang buong serbisyo) o mga partikular na pagkakataon ang tungkulin. Ang pagtanggap ng isang tungkulin ay nangangahulugan na maaari nilang gamitin ang mga pahintulot ng tungkulin upang magsagawa ng mga aksyon. Pangalawa, pinapayagan ng Patakaran sa Mga Pahintulot ang serbisyo/tao/resource na "nagsagawa ng tungkulin" na gumawa ng anuman sa S3, ito man ay nag-a-access sa isang partikular na bucket... o higit sa 700, tulad ng sa kaso ng Capital One.
Kapag ikaw ay nasa isang EC2 instance na may tungkuling IAM, maaari kang makakuha ng mga kredensyal sa ilang paraan:
- Maaari kang humiling ng instance metadata sa
http://169.254.169.254/latest/meta-dataSa iba pang mga bagay, mahahanap mo ang tungkulin ng IAM sa alinman sa mga access key sa address na ito. Siyempre, kung ikaw ay nasa isang pagkakataon.
- Gamitin ang AWS CLI...
Kung naka-install ang AWS CLI, ni-load ito ng mga kredensyal mula sa mga tungkulin ng IAM, kung naroroon. Ang natitira na lang ay magtrabaho sa PAMAMAGITAN ng instance. Siyempre, kung bukas ang kanilang Trust Policy, maaaring gawin ni Paige ang lahat nang direkta.
Kaya't ang kakanyahan ng mga tungkulin ng IAM ay pinapayagan nila ang ilang mga mapagkukunan na kumilos ON YOUR BEHALF sa OTHER RESOURCES.
Ngayong naiintindihan mo na ang mga tungkulin ng IAM, maaari nating pag-usapan ang ginawa ni Paige Thompson:
- Nakakuha siya ng access sa server (halimbawa ng EC2) sa pamamagitan ng isang butas sa firewall
Kung ito man ay mga grupo ng seguridad/ACL o kanilang sariling mga web application firewall, ang butas ay malamang na madaling isaksak, gaya ng nakasaad sa mga opisyal na talaan.
- Sa sandaling nasa server, nagawa niyang kumilos na "parang" siya mismo ang server
- Dahil pinayagan ng tungkulin ng server ng IAM ang S3 na ma-access ang 700+ bucket na ito, na-access nito ang mga ito
Mula sa sandaling iyon, ang kailangan lang niyang gawin ay patakbuhin ang utos List Bucketsat pagkatapos ay ang utos Sync mula sa AWS CLI...
. Ang pag-iwas sa naturang pinsala ang dahilan kung bakit namumuhunan ang mga kumpanya sa proteksyon ng imprastraktura ng ulap, DevOps, at mga eksperto sa seguridad. At gaano kahalaga at cost-effective ang paglipat sa cloud? Kaya't kahit na sa harap ng parami nang paraming mga hamon sa cybersecurity !
Moral ng kuwento: suriin ang iyong kaligtasan; Magsagawa ng mga regular na pag-audit; Igalang ang prinsipyo ng hindi bababa sa pribilehiyo para sa mga patakaran sa seguridad.
( Maaari mong tingnan ang buong legal na ulat).
Pinagmulan: www.habr.com