A CircleCI – kódépítő szolgáltatás teljes hitelesítő adatokkal sérül

Ha Ön programozó, akár hobbiból, akár professzionálisan kódol, tudni fogja, hogy a projekt új verziójának létrehozása – egy hivatalos „kiadási” verzió, amelyet Ön, barátai vagy ügyfelei telepítenek. és a használata – mindig egy kis fehér csülkös út.

Végül is a kiadási verzió az összes kódtól függ, az összes alapértelmezett beállításra támaszkodik, csak a közzétett dokumentációval együtt jelenik meg (de nem bennfentes tudás), és még olyan számítógépeken is működnie kell, amelyeket még soha nem látott, beállított olyan konfigurációkat, amelyeket soha nem is képzelt, más szoftverek mellett, amelyek kompatibilitását soha nem tesztelte.

Egyszerűen fogalmazva: minél összetettebbé válik egy projekt, minél több fejlesztő dolgozik rajta, és annál több különálló komponens, amelyeknek zökkenőmentesen kell működniük az összes többivel…

…annál valószínűbb, hogy az egész sokkal kevésbé lesz lenyűgöző, mint a részek összege.

Nyers hasonlatként vegyük figyelembe, hogy a leggyorsabb egyéni 100 méteres sprinterekkel rendelkező pályacsapat nem mindig nyeri meg a 4x100 méteres váltót.

CI a megmentésre

Az egyik kísérlet arra, hogy elkerüljük ezt a fajta „de jól működött a számítógépemen” válsághelyzetet, a szakzsargonban ismert technika Folyamatos integrációvagy CI röviden.

Az ötlet egyszerű: minden alkalommal, amikor valaki megváltoztatja a projekt saját részét, ragadja meg az illető új kódját, és keverje át őt és az új kódját egy teljes építési és tesztelési cikluson, akárcsak a végső kiadás létrehozása előtt. változat.

Építs korán, építs gyakran, építs mindent, építs mindig!

Nyilvánvaló, hogy ez egy olyan luxus, amelyet a fizikai világ projektjei nem viselhetnek el: ha mondjuk egy Sydney Harbour Bridge-et építesz, nem építhetsz újra egy teljes tesztidőszakot teljesen új nyersanyagokkal minden alkalommal, amikor döntsön úgy, hogy módosítja a szegecselési folyamatot, vagy megnézi, elfér-e nagyobb zászlórudak a csúcson.

Még akkor is, ha egy számítógépes szoftverprojektet egy csomó forrásfájlból kimeneti fájlok gyűjteményévé „épít fel”, értékes erőforrásokat fogyaszt, például elektromosságot, és hirtelen megugrott a számítási teljesítmény, hogy a fejlesztők által használt összes számítógép mellett működjön. maguk is használják.

Végül is a CI-t használó szoftverfejlesztési folyamatokban nem az az elképzelés, hogy megvárjuk, amíg mindenki készen áll, majd mindenki visszalép a programozástól, és megvárja a végleges összeállítást.

Az építések egész nap, minden nap történnek, így a kódolók jóval előre jelezhetik, ha véletlenül olyan „fejlesztéseket” hajtottak végre, amelyek mindenki mást negatívan érintenek – az építmény megtörése, ahogy a zsargon mondhatja.

Az ötlet a következő: kudarc korai, gyors javítás, minőség javítása, kiszámítható előrehaladás, és időben történő szállítás.

Persze még egy sikeres tesztfelépítés után is előfordulhatnak hibák az új kódban, de legalább nem érsz a fejlesztési ciklus végére, és akkor azt tapasztalod, hogy mindenkinek vissza kell térnie a rajztáblához a szoftvert egyáltalán meg kell építeni és dolgozni, mert a különböző összetevők kicsúsztak az összhangból.

A korai szoftverfejlesztési módszereket gyakran úgy emlegették, hogy a vízesés modell, ahol mindenki harmonikusan, de függetlenül dolgozott, miközben a projekt finoman lefelé sodródott a verziók határideje között, mígnem a ciklus végén minden összeállt, hogy létrejöjjön egy új kiadás, amely készen áll arra, hogy átugorjon a verziófrissítés viharos vízesésén, hogy aztán egy másikba emelkedjen. szelíd, tiszta víz alatti időszak a további tervezés és fejlesztés érdekében. Az egyik probléma azonban ezekkel a „vízesésekkel” az volt, hogy gyakran csapdába esett egy végtelennek tűnő kör alakú örvényben, közvetlenül a vízesés szélén, a gravitáció ellenére, és egyáltalán nem tudott átjutni a szakadék peremén, amíg hosszas csapkodások és módosítások (és az ezzel járó túlfutások) lehetővé tették a továbbutazást.

Csak a felhő feladata

Elképzelhető, hogy a CI bevezetése azt jelenti, hogy egy csomó nagy teljesítményű, használatra kész szerver áll a rendelkezésére, valahányszor valamelyik fejlesztője összeállítási és tesztelési eljárást indít el, hogy elkerülje a visszasodródást, hogy „elakadjon a nagyon a vízesés szája” helyzetet.

Ez úgy hangzik, mint egy munka a felhő számára!

És valóban, számos úgynevezett CI/CD felhőszolgáltatással (ez CD nem lejátszható zenei lemez, hanem a folyamatos szállítás).

CircleCI egy ilyen felhő alapú szolgáltatás…

…de ügyfeleik sajnos csak ezt teszik megszegést szenvedett.

Technikailag, és ahogy az manapság általánosnak tűnik, a cég valójában sehol sem használta a „betörés”, „behatolás” vagy „támadás” szavakat a hivatalos közleményében: eddig csak egy biztonsági esemény.

Az eredeti értesítés [2023-01-04] egyszerűen közölte, hogy:

Szeretnénk tudatni Önnel, hogy jelenleg egy biztonsági incidens kivizsgálása folyik, és a vizsgálatunk folyamatban van. Amint elérhetővé válnak, tájékoztatjuk Önt erről az incidensről és a válaszunkról. Jelenleg biztosak vagyunk abban, hogy nincsenek illetéktelen szereplők a rendszereinkben; azonban rendkívüli óvatosságból szeretnénk biztosítani, hogy minden vásárló megtegyen bizonyos megelőző intézkedéseket az Ön adatainak védelme érdekében.

Mit kell tenni?

Azóta a CircleCI rendszeres frissítésekkel és további tanácsokkal látja el, amelyek többnyire a következőkből állnak: „Kérjük, forgassa el a CircleCI-ben tárolt összes titkot."

Amint azt korábban kifejtettük, a zsargon szó forog itt rosszul választották ki, mert ez egy veszélyes múlt öröksége, ahol az emberek szó szerint „forgatták” a jelszavakat és titkokat kis számú előrelátható döntés révén, nemcsak azért, mert akkoriban nehezebb volt nyomon követni az újakat, hanem azért is, mert a kiberbiztonság t olyan fontos, mint ma.

A CircleCI azt jelenti, hogy minden jelszavát, titkát, hozzáférési tokenjét, környezeti változóját, nyilvános-privát kulcspárját és így tovább meg kell MÓDOSÍTANI, feltehetően azért, mert a hálózatot feltörő támadók vagy ellopták a tiédet, vagy nem bizonyítható, hogy nem. hogy ellopta őket.

A társaság rendelkezik a listát adott a különböző típusú privát biztonsági adatokról, amelyeket a jogsértés érintett, és létrehozott egy praktikus szkriptet CircleCI-Env-Inspector amellyel exportálhat egy JSON-formátumú listát az összes olyan CI-titkot tartalmazó listáról, amelyet meg kell változtatnia a környezetben.

Ezenkívül a kiberbűnözők mostantól hozzáférési tokenekkel és kriptográfiai kulcsokkal is rendelkezhetnek, amelyek visszajuthatnak a saját hálózatukba, különösen azért, mert a CI-építési folyamatoknak néha „haza kell hívniuk”, hogy olyan kódot vagy adatokat kérjenek, amelyeket Ön nem tud vagy nem akar. feltölteni a felhőbe (azokat a szkripteket, amelyek ezt teszik, a szakzsargonban úgy ismerik, mint futók).

Tehát a CircleCI azt tanácsolja:

Azt is javasoljuk az ügyfeleknek, hogy 2022-12-21-től kezdődően [2023-01-04-ig], vagy a [titkok megváltoztatása] befejezése után tekintsék át a rendszerük belső naplóit az illetéktelen hozzáférésre.

Érdekes módon, ha érthető, néhány ügyfél észrevette, hogy a CircleCI által megjelölt dátum, amikor ez a jogsértés elkezdődött [2022-12-21], véletlenül egybeesik egy blogbejegyzéssel, cég közzétette a legújabb megbízhatósági frissítésekről.

Az ügyfelek azt akarták tudni, hogy „az incidens az ebben a frissítésben bevezetett hibákhoz kapcsolódott?”

Tekintettel arra, hogy a vállalat megbízhatósági frissítéseit tartalmazó cikkek gördülő hírösszefoglalóknak tűnnek, nem pedig az egyes dátumokon végrehajtott változtatások bejelentései, a kézenfekvő válasz: „Nem”…

…és a CircleCI kijelentette, hogy a megbízhatósági blogbejegyzés egybeeső dátuma, 2022. december 12., ez volt: véletlen.

Boldog kulcsújítást!

---

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• Platoblockchain. Web3 metaverzum intelligencia. Felerősített tudás. Hozzáférés itt.
• Forrás: https://nakedsecurity.sophos.com/2023/01/09/circleci-code-building-service-suffers-total-credential-compromise/