Mga sikretong tumutulo: Isang hakbang patungo sa disaster

Ang pagbibigay ng mga susi ng iyong bahay sa mga kriminal ay tiyak na hindi magandang ideya. Ngunit iyan ang madalas na nangyayari sa karamihan ng mga organisasyon na bumubuo ng mga modernong software.

Sa unang post na ito tungkol sa mga pagtagas ng sikreto, susuriin natin kung bakit ito madalas mangyari, ano ang mga kahihinatnan nito, at anong mga aksyon ang dapat gawin upang maiwasan o mabawasan ang problema at mapangasiwaan ang mga insidente ng pagtagas ng sikreto.

Naku! Na-push ko na ang mga cloud access key ko sa isang pampublikong repository.

Mga sikretong naka-code sa source code o mga configuration file sa mga DevOps tool ay maaaring mauwi sa masasamang kamay. Kung ang sikreto ay commitKung nakalagay sa isang pampublikong imbakan ng mga mapagkukunan, tiyak na mapapahamak ka. Ngunit kahit ang mga pribadong imbakan ay hindi ligtas, dahil ang mga sikreto ay nabubulok din sa pamamagitan ng mga binary ng application, log, o ninakaw na source code.

Sa pagbabalik-tanaw, nakakabahala ito kung gaano kadalas na humantong sa isang malubhang paglabag sa seguridad ang isang simpleng hindi pagpansin. I-google mo na lang"Mga tagas ng susi ng AWS","Mga tagas ng token ng access sa GitHub", at iba pa. Huwag mong ituring ang mga halimbawang ito bilang mga nakatagong rekomendasyon para sa ganito o ganoong vendor. Gamitin ang sarili mong !

Halimbawa, ang (na) sikat Pag-atake ng Codecov noong Abril 2021 ay posible dahil ang imahe ng Codecov Docker ay naglalaman ng mga kredensyal ng git na nagpapahintulot sa isang attacker na makakuha ng access sa mga pribadong git repository ng Codecov at magdagdag ng isang linya sa bash uploader script ng Codecov para sa mga variable ng kapaligiran ng koleksyon at mga URL ng git repository.

Ipaalala na bahagi ng pabuya sa mga pag-atake ay ang mga sikreto upang makakuha ng access sa mga karagdagang sistema, at maraming pag-atake ang labis na namumuhunan sa mga kredensyal, crypto key, at token exfiltration. 

Ang problema ay na karaniwang nangyayari ang mga sikretong nakatagoNoong Marso 2022, ang Lapsus$ APT tumagas na 189GB ng source code ng Samsung at iba pang sensitibong file. Isiniwalat ng pagsusuri na naglalaman ito ng ilan 6,600 na mga sikretong naka-code: 90% para sa mga panloob na sistema, ngunit 10% para sa mga panlabas na serbisyo at tool tulad ng GitHub, AWS o Google. Kasama sa mga sikretong iyon ang mga AWS / Twilio / Google API key, mga string ng koneksyon sa database, at iba pang sensitibong impormasyon. Ito ang makabagong teknolohiya sa karamihan ng mga code base.

Ang mga pagtagas ng sikreto ang pinakamadaling landas sa mga pag-atake sa supply chain

Ang mga dependency sa pakete ang pinakamadalas na kasalukuyang nangyayari, bagama't hindi ito ang natatanging target para sa mga pag-atake sa supply chain. Ang mga kontrabida ay maaaring lumikha ng isang bagong pakete na magtatapos sa pag-install sa software ng mga biktima (gamit ang typosquatting at iba pang mga pamamaraan), ngunit kadalasan ay sinusubukan nilang mahawa ang isang umiiral na pakete sa pamamagitan ng pagdaragdag ng mga pagbabago sa source code sa mga repositoryo ng software (SCM) tulad ng GitHub, GitLab o BitBucket, o sa pamamagitan ng pagdaragdag ng mga malisyosong bersyon sa mga pampublikong rehistro tulad ng NPM, PyPI, RubyGems, Maven Central.

Ngunit ang paglalagay ng malisyosong code o isang malisyosong dependency na nakatago sa isang masalimuot na graph ng dependencies ay nangangailangan ng login mga kredensyal tulad ng username/password, mga token o mga access key (tawagin natin silang “mga susi"sa madaling salita), para sa target na source repository o public registry, ayon sa pagkakabanggit. 

Minsan nakukuha ng mga kontrabida ang mga susi sa pamamagitan ng sosyal na engineering. ang pag-atake sa event-stream Ang sikat na pakete ng NPM ay nagbibigay ng isang magandang halimbawa. Ngunit ang paghahanap ng leaked login Ang mga kredensyal o mga access key ang pinakamadalas na pamamaraan ng pag-atake para sa mga pag-atake sa supply chain ng software.

Ang mga source repository at package registry ay dalawang mahahalagang sistema sa pagbuo ng software. pipelineNgunit maraming mga tool sa DevOps: CI/CD mga sistema, mga tool para sa pagpapatakbo ng mga pagsubok, automation ng configuration at provisioning, o deployment at release. Lahat ng mga ito ay maaaring abusuhin para sa paglalagay ng malisyosong code sa software. Ang pagtagas ng mga wastong key para sa mga tool na ito ay direktang humahantong sa paghihirap at paghihirap. Isipin ang pagtagas ng mga key ng root access key na may ganap na kontrol sa iyong mga pampublikong cloud resources…

Mga karaniwang rekomendasyon

Wala kaming sinasabing bago rito, alam ninyong lahat ito. Pero kumilos na kayo! Tandaan na regular na ini-scan ng mga bot ang lahat ng pampublikong... SCM mga repositoryo. Ilang rekomendasyon, walang partikular na pagkakasunud-sunod.

• Kung ikaw ay may responsibilidad sa pamamahala ng seguridad ng IT, tukuyin kung paano dapat pangasiwaan ang mga sikreto sa patakaran sa seguridad. Ngunit ang mga patakaran ay kasinghusay lamang ng pagpapatupad: tiyaking may ipinapatupad na alituntunin sa paghawak ng mga lihim sa iyong organisasyon—kabilang hindi lamang ang iyong mga DevOps team kundi pati na rin ang iyong mga software supplier, at ang plano ng pagtugon sa insidente ng iyong organisasyon ay naglalaman ng mga probisyon para sa mga insidente ng pagtagas ng mga lihim.
• Ipatupad at ipatupad multi-factor na pagpapatotoo (MFA, 2FA o kahit anong acronym). At walang bawas sa seguridad: sulit ang isang USB security key sa kaunting halaga nito. Kailangan mong i-git-push ang alinman sa iyong libu-libong credentials (madali lang) at pagkatapos ay malasing at iwanan ang iyong mga susi sa isang bar na may naka-link sa iyo (medyo maliit lang ang tsansa, lalo na kung hindi ka umiinom).
• Gumamit ng password manager na may malakas at hindi pa nase-save na password. Para sa paghawak ng mga sikreto sa mga system, gamitin ang Mga Lihim na Vault. CI/CD mga sistema, mga tagapagbigay ng cloud, SCMAng s at iba pang mga tool ng DevOps ay nagbibigay ng serbisyong ito, ngunit maaari kang pumili ng isang generic na solusyon ng Secret Vault.
• Mas gusto maikli ang buhay mga token sa mga pangmatagalang access key. Mas madali ang mga ito bawiin at maglalantad ng mas limitadong pagkakataon sa kasamaan.
• Limitahan ang muling paggamit ng kredensyal: gagamitin muli ng mga umaatake ang mga nakuhang kredensyal para sa isang target papunta sa ibang mga sistema, isa pang punto para sa paggamit ng password manager. Dapat gawing nakaraan ng mga password manager at mga lihim na vault ang muling paggamit ng kredensyal.
• Limitahan at subaybayan ang paggamit ng admin mga password. Ang mga ito ay sapat na makapangyarihan upang mabigyan ng espesyal na pagsubaybay.
• Isakatuparan malakas na hashing at encryptionBalik tayo sa mga USB (cryptographic) key, mahigpit na pamamaraan para sa pagpapadala ng mga kredensyal sa mga kasosyo at katrabaho, at iba pa.
• Gamitin scanner ng mga lihim, halimbawa ay tumatakbo sa isang pre-commit kawitan upang maiwasan ang mga tagas sa mga sistema ng pagkontrol ng bersyon, bilang isang security gate. Bago ang bagay mahalaga rito. Bilang kahalili, gumamit ng mga post-hoc scan upang matukoy ang mga natuklasang sikreto halimbawa bilang pagsusuri bago pull request nagsasama. Paalala: Ang aming Xygeni platform ay may kasamang secrets scanner na nagpapahintulot sa parehong mode ng operasyon. 
• Ang manu-manong alternatibo sa paggamit mga pagsusuri sa code ang paghahanap ng mga sikretong naka-code ay may mas mataas na gastos at gumagana pagkatapos ngcommit (ngunit sana kahit man lang bago pa man matuklasan ng mga tagalabas ang sikreto). Ngunit maaaring matukoy ng mga review ang mga di-konbensyonal na sikreto na maaaring hindi makita ng mga secrets scanner.       
• Iwasan nang hindi sinasadya commitpaglalagay ng mga karaniwang file na may mga sikreto sa pagkontrol ng bersyon gamit ang naaangkop ibukod ang mga pattern (tulad ng template na `gitignore`), isinasaalang-alang ang mga file tulad ng .env, .npmrc, .pypirc, mga pansamantalang file… Isa ngang karagdagang patong sa security onion.
• At ang panghuli sa mahabang listahang ito: hayaan ang mga cloud provider na magsagawa ng mga pag-scan para sa mga tagas ng kanilang mga key, kung mayroon. Hindi bababa sa, ito maaari ipaalam sa iyo ang tungkol sa tagas kung kailan nangyari, ngunit ang seguridad ay kinakailangan para sa mga cloud provider. Ito post-hoc Ang lihim na pag-scan ay hindi gaanong malinaw kung saan at gaano kadalas isinasagawa ang pag-scan, at kadalasang nangangailangan ng tahasang pag-setup, ngunit tiyak na ito ang huling mapagkukunan kapag nabigo ang lahat ng iba pa.

Naku! Na-push ko na ang mga cloud access key ko sa isang pampublikong repo, take #2!

Maaaring mangyari iyan sa pinakamabuti sa atin. Maghanda ka!

I-renew / bawiin / i-disable agad ang nabunyag na sikreto! Kung ang account ay may disenteng MFA, mas mababa ang panganib. Maaaring mas mahirap iyon halimbawa sa mga pribadong susi sa mga website (kailangan mong maglabas ng bagong sertipiko para sa isang bagong pribadong susi at bawiin ang umiiral na), ngunit ang mga modernong kagamitan ay may mabilis na paraan upang i-renew ang mga kredensyal o bawiin ang mga token. 

Sundin ang mga hakbang na inirerekomenda ng provider kapag mayroon, tulad ng AWS sa halimbawang ito.

Tukuyin ang sanhi ng tagas. Ang pag-alam kung paano ito nangyari ay mahalaga para sa pagsisiwalat, pagsusuri, pagpigil, at mga aktibidad na natutunan mula sa mga aral.

Pagkatapos, iulat ang tagas sa mga apektadong partido, at ipaliwanag ang mga aksyon na iyong ginagawa upang matakpan ang tagas at mabawasan ang pinsala. Walang paraan upang mabaliktad ang pinsalang nagawa, ang natagas ay siyang tagas pa rin. Maging malinaw at ipaalam sa iba upang sila ay makagawa ng aksyon. 

Pagkatapos ay magsimula sa Forensics. ang bintana ng pagkakalantad ay ang oras sa pagitan ng pagtagas at ng oras kung kailan hindi wasto ang sikreto. Maghandang magbasa ng mga log at subaybayan ang hindi pangkaraniwang aktibidad sa apektadong account sa loob ng panahong iyon. Alisin ang mga account at key na nabuo gamit ang apektadong account. Paalalahanan na kung ang apektadong account ay may mga pribilehiyong admin, mas kumplikado ang pag-aayos. 

Kasaysayan ng muling pagsusulat (kontrol ng bersyon) ay kumplikado. Kahit ang mga totalitaryong estado ay sinusubukan ito ngunit walang naging resulta (may layuning mag-pun.) At marahil ay walang kaugnayan: maaaring kinopya ng mga hacker o ng mga bot sa mga pampublikong repo ang repo o nakuha na ang ginto, lalo na kung sapat ang laki ng exposure window. 

Kung mahilig ka sa adventure at gusto mong makita kung gaano katagal bago matukoy ng mga bot ang isang leaked na sikreto, mga tripwire tulad ng Mga Token ng Canary hayaan kang mag-eksperimento. Tandaan, ibina-blacklist ng mga bot ang default canarytokens.org dominyo…