Geheime lek: Een stap na die disaster

Om die sleutels van jou huis aan misdadigers te gee is beslis nie die beste idee nie. Maar dit is wat dikwels gebeur in die meeste organisasies wat moderne sagteware ontwikkel.

In hierdie eerste plasing oor geheimlekkasies, sal ons ontleed waarom dit so gereeld gebeur, wat die gevolge is, en watter stappe geneem moet word om die probleem te voorkom of te verminder en voorvalle van geheimlekkasies te hanteer.

OMG! Ek het my wolktoegangsleutels na 'n publieke databasis gestoot

Hardgekodeerde geheime in bronkode of konfigurasielêers in DevOps-gereedskap kan in slegte hande beland. As die geheim is commitAs jy dit in 'n openbare bronbewaarplek stoor, is jy verseker gedoem. Maar selfs private bewaarplekke is nie veilig nie, aangesien geheime ook deur toepassingsbinêre lêers, logboeke of gesteelde bronkode uitgelek word.

Terugskouend is dit ontstellend hoe gereeld 'n eenvoudige oorsig tot 'n ernstige sekuriteitsbreuk gelei het. Google net “AWS-sleutellekkasies","GitHub-toegangstokenlekkasies", ensovoorts. Moenie hierdie voorbeelde as versteekte aanbevelings vir hierdie of daardie verkoper beskou nie. Gebruik jou eie!

Byvoorbeeld, die (berugte) Codecov-aanval van April 2021 was moontlik omdat die Codecov Docker-beeld git-geloofsbriewe bevat het wat 'n aanvaller toegelaat het om toegang tot Codecov se private git-bewaarplekke te verkry en 'n enkele reël in Codecov se bash-oplaaierskrip vir versamelingsomgewingveranderlikes en git-bewaarplek-URL's by te voeg.

Onthou dat 'n deel van die oorvloed in aanvalle die geheime is om toegang tot bykomende stelsels te verkry, en baie aanvalle belê swaar op geloofsbriewe, kripto-sleutels en token-onttrekking. 

Die probleem is dat Hardgekodeerde geheime is algemeenIn Maart 2022 het die Lapsus$ APT 189GB uitgelek van Samsung se bronkode en ander sensitiewe lêers. Analise het aan die lig gebring dat dit sommige bevat het 6 600 hardgekodeerde geheime90% vir interne stelsels, maar 10% vir eksterne dienste en gereedskap soos GitHub, AWS of Google. Daardie geheime het AWS / Twilio / Google API-sleutels, databasisverbindingsstringe en ander sensitiewe inligting ingesluit. Dit is die nuutste tegnologie in die meeste kodebasisse.

Geheimlekkasies is die maklikste pad na voorsieningskettingaanvalle

Pakketafhanklikhede is tans die mees algemene, maar nie die unieke teiken vir voorsieningskettingaanvalle nie. Die slegte ouens kan 'n nuwe pakket skep wat uiteindelik in slagoffers se sagteware geïnstalleer word (met behulp van 'n Typosquatting en ander tegnieke), maar tipies probeer hulle 'n bestaande pakket besmet deur wysigings aan die bronkode in sagtewarebewaarplekke by te voeg (SCM) soos GitHub, GitLab of BitBucket, of deur kwaadwillige weergawes by openbare registers soos NPM, PyPI, RubyGems, Maven Central te voeg.

Maar die inspuiting van kwaadwillige kode of 'n kwaadwillige afhanklikheid wat in 'n ingewikkelde afhanklikheidsgrafiek versteek is, vereis login geloofsbriewe soos gebruikersnaam/wagwoord, tokens of toegangsleutels (kom ons noem hulle "sleutels” (kortweg), vir die teikenbronbewaarplek of openbare register, onderskeidelik. 

Die slegte ouens kry soms die sleutels via sosiale ingenieurswese. Die aanval op die event-stream gewilde NPM-pakket bied 'n goeie voorbeeld. Maar soek na uitgelek login Geloofsbriewe of toegangsleutels is die mees algemene aanvalstegniek vir sagteware-voorsieningskettingaanvalle.

Bronbewaarplekke en pakketregisters is twee noodsaaklike stelsels in die sagtewarebou. pipelineMaar daar is baie gereedskap in DevOps: CI/CD stelsels, gereedskap vir die uitvoering van toetse, konfigurasie- en voorsieningsoutomatisering, of ontplooiing en vrystelling. Almal kan misbruik word om kwaadwillige kode in sagteware in te spuit. Die lek van geldige sleutels vir hierdie gereedskap lei direk tot ellende en pyn. Stel jou voor dat jy worteltoegangsleutels lek met volle beheer oor jou publieke wolkbronne...

Die gewone aanbevelings

Ons sê niks nuuts hier nie, julle almal weet dit. Maar tree op! Onthou dat robotte gereeld alle publieke inligting skandeer. SCM bewaarplekke. 'n Paar aanbevelings, in geen spesifieke volgorde nie.

• As jy verantwoordelik is vir IT-sekuriteitsbestuur, definieer hoe geheime hanteer moet word in die sekuriteitsbeleid. Maar beleide is net so goed soos afdwinging: maak seker dat 'n riglyn vir die hantering van geheime in jou organisasie afgedwing word - insluitend nie net jou DevOps-spanne nie, maar ook jou sagtewareverskaffers, en dat jou organisasie se voorvalreaksieplan bepalings vir geheimlekvoorvalle bevat.
• Implementeer en afdwing multi-faktor verifikasie (MFA, 2FA of watter akroniem ook al). En geen besnoeiings in sekuriteit nie: 'n USB-sekuriteitsleutel is die paar rand werd wat dit kos. Jy moet enige van jou duisende geloofsbriewe git-push (maklik) en dan dronk word en jou sleutels in 'n kroeg los met iets wat na jou skakel (die kanse is net 'n bietjie kleiner, veral as jy geheelonthouer is).
• Gebruik 'n wagwoordbestuurder met 'n sterk, ongestoorde wagwoord. Vir die hantering van geheime in stelsels, gebruik Geheime Kluise. CI/CD stelsels, wolkverskaffers, SCMs en ander DevOps-gereedskap bied hierdie diens, maar jy kan kies vir 'n generiese Geheime Kluis-oplossing.
• verkies kortstondige tokens na langdurige toegangsleutels. Hulle is makliker om te herroep en stel 'n meer beperkte venster bloot aan die bose.
• Beperk hergebruik van geloofsbrieweAanvallers sal versamelde geloofsbriewe vir 'n teiken in ander stelsels hergebruik, nog 'n punt vir die gebruik van 'n wagwoordbestuurder. Wagwoordbestuurders en geheime kluise behoort die hergebruik van geloofsbriewe iets van die verlede te maak.
• Beperk en monitor die gebruik van admin wagwoorde. Hulle is kragtig genoeg om spesiale dophou te verdien.
• Implementeer sterk hashing en enkripsieTerug na USB (kriptografiese) sleutels, streng prosedures vir die oordrag van geloofsbriewe met vennote en kollegas, ensovoorts.
• Gebruik geheime skandeerder, byvoorbeeld hardloop in 'n pre-commit haak om lekkasies in weergawebeheerstelsels te vermy, as 'n sekuriteitshek. Voor die ding is hier belangrik. Alternatiewelik, gebruik post-hoc skanderings om uitgelekde geheime op te spoor, byvoorbeeld as 'n kontrole voor pull request saamsmelt. Let wel: Ons Xygeni-platform sluit 'n geheimskandeerder in wat beide werkingsmodusse toelaat. 
• Die handmatige alternatief vir die gebruik kode resensies om na hardgekodeerde geheime te soek, het hoër koste en werk na-commit (maar hopelik ten minste voordat die geheim vir buitestaanders beskikbaar is). Maar resensies mag dalk onkonvensionele geheime opspoor wat geheimskandeerders kan ontduik.       
• Vermy per ongeluk commitalgemene lêers met geheime vir weergawebeheer met toepaslike sluit patrone uit (soos `gitignore` sjabloon), met inagneming van lêers soos .env, .npmrc, .pypirc, tydelike lêers… 'n Bykomende laag in die sekuriteitsui inderdaad.
• En die laaste in hierdie lang lys: laat die wolkverskaffers skanderings uitvoer vir hul sleutellekkasies, wanneer beskikbaar. Ten minste, hierdie mag laat weet van die lek wanneer dit gebeur het, maar sekuriteit is 'n moet vir wolkverskaffers. post-hoc geheime skandering is nie baie deursigtig oor waar en hoe gereeld die skandering uitgevoer word nie, en benodig dikwels eksplisiete opstelling, maar is beslis die laaste hulpbron wanneer alles anders misluk.

OMG! Ek het my wolktoegangsleutels na 'n publieke bewaarplek gestoot, neem #2

Dit kan met die beste van ons gebeur. Rol jou moue op!

Hernu / herroep / deaktiveer die gelekte geheim onmiddellik! As die rekening ordentlike MFA het, is die risiko baie laer. Dit kan moeiliker wees met bv. privaat sleutels op webwerwe (jy moet 'n nuwe sertifikaat vir 'n nuwe privaat sleutel uitreik en die bestaande herroep), maar moderne gereedskap het 'n vinnige manier om geloofsbriewe te hernu of tokens te herroep. 

Volg die stappe wat deur die verskaffer aanbeveel word wanneer beskikbaar, soos AWS in hierdie voorbeeld.

Identifiseer die oorsaak van die lek. Om te weet hoe dit gebeur het, is noodsaaklik vir openbaarmaking, analise, inperking en aktiwiteite om lesse te leer.

Rapporteer dan die lek aan die betrokke partye en verduidelik die stappe wat jy neem om die lek te stop en skade te verminder. Daar is geen manier om die skade wat aangerig is, om te keer nie; wat uitgelek het, is uitgelek. Wees deursigtig en stel ander in kennis sodat hulle aksie kan neem. 

Begin dan met die forensiese. Die blootstellingsvenster is die tyd tussen die lek en die tyd wanneer die geheim nie geldig was nie. Wees gereed om logs te lees en op te spoor vir ongewone aktiwiteit met die betrokke rekening gedurende daardie venster. Verwyder rekeninge en sleutels wat met die betrokke rekening gegenereer is. Onthou dat as die betrokke rekening administrateurregte het, die regstelling baie meer kompleks is. 

Herskryf (weergawebeheer) geskiedenis is kompleks. Selfs totalitêre state probeer dit tevergeefs (woordspeling bedoel.) En waarskynlik irrelevant: die hackers of die robotte op openbare bewaarplekke het dalk die bewaarplek gekloon of die goud reeds onttrek, veral as die blootstellingsvenster groot genoeg is. 

As jy avontuurlustig is en self wil sien hoe lank dit neem vir robotte om 'n uitgelek geheim op te spoor, kan struikeldrade soos Kanariese Tekens laat jou eksperimenteer. Onthou, botte swartlys die verstekwaarde canarytokens.org domein…