Ni nini kinachoweza kwenda vibaya CI/CD pipelines?

Ujumuishaji endelevu na utoaji endelevu (CI/CD) pipelines ndio msingi wa shirika lolote la programu linalounda programu kwa njia ya "kisasa". Otomatiki hutoa nguvu kubwa, lakini watengenezaji wengi hukosa jukumu linalohusika.

Developer: Ndiyo, tunachukua CI/CD usalama kwa umakini na udhibiti mkubwa kwa watunzaji wa misimbo, hakiki commitkabla ya kuunganishwa kwa makampuni; kazi na pipelines zinatunzwa na wafanyakazi wakuu, wanajali kutovuja siri katika pipelineNa kifaa hicho kiliwekwa na wafanyakazi wanaojua jambo hilo. Ni nini kinachoweza kwenda vibaya?

Mpendwa msanidi programu, CI/CD mifumo ni changamano. Uso wake mpana wa mashambulizi ulivutia wahalifu wabaya. Afadhali kuwa mwangalifu na kamwe usijiamini kupita kiasi.

Usanidi chaguo-msingi wakati mwingine huhifadhiwa na kuwa rafiki bora kwa wadukuzi. Makosa muhimu yanaweza kuwepo katika CI/CD pipeline vyanzo, katika usanidi wa mfumo, au karibu na mchakato na muktadha wa pipeline na jinsi inavyosababishwa.

Katika chapisho hili tutajiweka katika nafasi ya waigizaji wabaya. Hebu fikiria kwamba tulikuwa tunasoma mawazo ya M3M3N70 (Memento Mori?) na Hasira ya Kinamasi mahali fulani kwenye mtandao mweusi, labda katika lugha isiyo ya kimagharibi, lakini usikose kamwe kwamba uovu umeenea duniani kote.

 

Zamani ilikuwa rahisi sana…

M3M3N70: Kurudi kwenye nyakati nzuri za zamani biashara yetu ilikuwa rahisi sana… Siku zisizo na kikomo zilikuwa matunda ya chini, programu zilikuwa wazi na rahisi kutumia vulns, na tungeweza kusonga mbele kwa haraka.

Hasira ya Kinamasi: Fu#@Jahannamu! Baadhi ya watu wenye akili kama sungura bado, lakini mambo yalibadilika. Wazee wakubwa walitoa maoni mengi mabaya kuhusu upuuzi huo wa AppSec.

M3M3N70: Ndiyo. Lakini wapumbavu wapya ndio watengenezaji. Kwetu sisi, imekuwa rahisi zaidi kutumia zana ambazo hawa watu hutumia. CI, haswa, ni mgodi wa dhahabu! Tokeni za ufikiaji wa wingu, SCM vitambulisho, manenosiri ya hifadhidata ya uzalishaji, funguo za kibinafsi za SSH, vitambulisho vya watumiaji wengine wa CI… Kuruka kutoka kwa mambo ya uundaji yanayochosha hadi kwenye ukweli halisi ilikuwa jambo dogo sana.

Otomatiki kwa ajili ya kujenga, kupima na kusambaza programu kwa kutumia CI/CD Chombo hiki mara nyingi huhitaji kupitisha siri kwa amri hatua kwa hatua. Na mara nyingi huvuja, na matokeo yake ni mabaya.

Pipelinetunahitaji siri ambazo wakati mwingine huvuja

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

Labda nyakati nzuri za zamani zilikuwa ni kupata katika historia ya Git .env faili (msanidi programu alisahau kuiongeza kwenye .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

ambayo ilitumika katika mtiririko wa kazi wa GitHub .github/deploy.yaml ambayo ilikuwa na kitu kama hiki:

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: wow! Funguo hizo za aws zilikuwa zikifanya kazi! Tulijaribu kwanza mabadiliko ya chanjo kwenye programu, kisha tukaongeza uchungu kwani wale jamaa walionekana kutojua. Bingo! Kampeni nzuri sana…

Mhusika mbaya alitumia tu vitufe vya AWS kupakia programu iliyorekebishwa yenye programu hasidi kisha akaendesha amri ya kupeleka yenye sifa kama hizo. Siri zilizovuja, pamoja na taarifa zilizomo katika pipeline"Kampeni iliyoje!" labda inamaanisha kwamba Memento iliharibu uharibifu kwa mwathiriwa maskini.

Kile ambacho Memento inatuambia hapa ni kwamba mara tu uvujaji wa siri utakapotokea, kama vile funguo za ufikiaji za AWS katika mfano, lazima ufute siri hiyo (zungusha funguo zilizo hapo juu) mara mojaDaima kuna dirisha la kufichua kati ya uvujaji commit na ubatilishaji wa siri; kuandika upya historia ya Git ni vigumu (hata dola ngumu zaidi ya kimabavu ilijaribu kuandika upya historia kama hiyo, bila mafanikio) na pengine haikufanikiwa (marafiki zetu huenda waliiga kabla ya hazina kwa uvujaji wa siri commitZungusha vitufe mara moja, na uombe unaposoma kumbukumbu za shughuli kwa akaunti inayolengwa wakati wa dirisha la kufichua!

Labda mashirika yanapaswa kupiga marufuku matumizi ya siri za muda mrefu katika CI/CD pipelines, na ubadilishe na vitambulisho vya muda. Katika mfano uliopita na funguo za AWS katika vitendo vya GitHub, ni salama zaidi kutumia Mtoa huduma wa OpenID Connect (OIDC) kupata sifa za muda mfupi zinazohitajika kwa vitendo.

Hasira ya Kinamasi: Ulikuwa na bahati sana! Kuvuja kwa hati zenye funguo ngumu ilikuwa kawaida katika siku za zamani, hata kwenye ndoo za S3 zinazoweza kufikiwa hadharani. Unachohitaji kufanya ni kupitia vitu vilivyo kwenye ndoo na kufanya grepping ili kupata vitu vya kuvutia.

Wakati mwingine eneo lililotumika kwa ajili ya kusambaza (ndoo ya AWS S3 katika mfano huu) lilikuwa wazi kwa ajili ya kusomwa na watu wa nje, kwa sababu ya hitilafu ya usanidi (ambayo haikugunduliwa). Hasira ya Kinamasi kutumika ilikuwa kitu kama hiki:

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

Ndoo labda iliundwa katika kiolezo cha utoaji ambacho kinaweza kuchanganuliwa kiotomatiki kwa dosari za usalama.

Usanidi chaguo-msingi wa zana ulikuwa toy kwetu

Ili kutoa mifano halisi hebu tuzungumzie Jenkins, mojawapo ya zana maarufu za CI.

Hasira ya Kinamasi: Je, unakumbuka kisanduku cha kuteua cha "Wezesha Usalama" huko Jenkins, na ni mashirika mangapi yaliyochagua kutoyaamilisha kwa ajili ya urahisi? Na wale "Mtu yeyote anaweza kufanya chochote"michanganyiko ya ruhusa kama chaguo-msingi?" Na programu-jalizi hizo za Jenkins zenye utata, kama vile Programu-jalizi ya GitHub OAuthMtu aliyeisanidi alichagua "Ruhusu ruhusa za KUSOMA kwa Watumiaji Wote Waliothibitishwa" na "Tumia ruhusa za hazina ya GitHub", na kutupatia ufikiaji wa miradi yao yote.

(Samahani, Jenkins, kwa kukuweka kama mfano 😉

Endelea kuwa mtaalamu (hata mraibu) wa kanuni za usalama. Mojawapo ni Linda kwa chaguo-msingi kanuni: vidhibiti vinapaswa kuwa katika mipangilio salama zaidi iwezekanavyo. Usalama unapaswa kujengwa ndani yake CI/CD zana na pipelines kutoka chini kabisa, badala ya kuwa wazo la baadaye. Lakini urahisi wa mtumiaji na urahisi mara nyingi hugongana na usalama.

Kwa kesi ya Jenkins, uthibitishaji uliojengewa ndani ni dhaifu sana: Usitumie kamwe mifumo ya uthibitishaji iliyojengewa ndani huko Jenkins. Ni bora kuchagua utaratibu wa wahusika wengine (SAML, LDAP, Google …), wenye programu-jalizi ya Mkakati wa Uidhinishaji Unaotegemea Majukumu (“RBAC”). Na uwe mwangalifu sana na admin akaunti.

Jihadhari na jinsi ya kufanya kazi na pipeline faili katika Jenkins zinashughulikiwa. Vivyo hivyo na Programu-jalizi ya Usanidi-kama-Msimbo na faili zake za usanidi, ambazo zinatumika kwa usanidi wa Jenkins.

Kuhama kutoka kujipangia mwenyewe CI/CD mifumo hadi ile ya SaaS inayotegemea wingu huondoa baadhi ya hatari zinazoweza kuruhusu harakati za pembeni ndani ya mtandao wa shirika, lakini imeongeza zingine, kama vile kulazimika kufungua miunganisho ya nje kati ya mifumo ya ndani iliyopo na mifumo ya nje. CI/CD chombo.

Mashirika yanapaswa kufanya mazoezicisuangalifu unaofaa katika kuimarisha CI/CD mfumo, kuanzia na mipangilio yenye vikwazo zaidi na kufungua hatua kwa hatua kwa ruhusa ndogo zinazohitajika kwa pipeline hatua.

Kusanidi usalama katika CI/CD Zana zinaweza kuwa ngumu sana. Nyingi zina programu-jalizi au viendelezi ambavyo vina udhaifu mwingi na vinahitaji kusasishwa.

Vichanganuzi vya usanidi usiofaa wa usalama kwa zana ngumu kama hizo, au vipimo vya upimaji vinaweza kusaidia.

Inaingiza msimbo ndani pipeline amri za kujifurahisha na faida

M3M3N70: Je, umewahi kutumia Untrusted Code Checkouts, ambazo vitendo na hati zinaweza kuathiriwa na amri?

Sehemu hii inaonyesha kwamba pipeline yenyewe inaweza kuwa na makosa ya usimbaji ambayo yanawawezesha watendaji wabaya kuingiza utekelezaji wa msimbo kiholela katika pipeline bila kubadilisha pipeline chanzo chenyeweKwa mfano kutumia PR

Mfano wa kwanza wa mtiririko wa kazi wa GitHub usio na furaha:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

Kuchanganya pull_request_target Kichocheo cha mtiririko wa kazi kwa kuangalia waziwazi PR isiyoaminika ni kitendo hatari ambacho kinaweza kusababisha maelewano ya hazina. Katika mfano, mchanganyiko mbaya wa:

• pull_request_target tukio, ambalo kwa chaguo-msingi lina ruhusa ya kuandika kwa hazina lengwa na siri za hazina lengwa, hata kutoka kwa uma za nje, na huendeshwa katika muktadha wa hazina lengwa ya PR,
• angalia msimbo wa PR kutoka kwa chanzo, repo isiyoaminika,
• kuanzisha hati yoyote ambayo inaweza kufanya kazi kwenye maudhui yanayodhibitiwa na PR, kama ilivyo katika kesi ya npm install, na
• kutotumia sharti kwenye kichocheo pull_request_target Tukio hilo litaendeshwa tu ikiwa aina fulani ya lebo ya 'PR hii ilikaguliwa' imepewa PR (watumiaji wa nje hawawezi kugawa lebo kwa PR).

Mfano wa pili unachukua ingizo lisiloaminika (kutoka kwa tatizo, maoni au pull requestkama chanzo cha hoja zilizopitishwa kwa pipeline amri kupitia misemo. Hii ndiyo pipeline toleo la udhaifu wa kuingiza amri ya OS.

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

Operesheni ya kukimbia hutoa hati ya muda ya ganda kulingana na kiolezo, na $ badala yake, na kuifanya iwe katika hatari ya kuingizwa kwa amri ya ganda. Mshambuliaji mwenye akaunti bandia ya GitHub anaweza kusababisha tatizo na kichwa a"; bad_code_goes_here;#, na boom! 

Hasira ya Kinamasi: Loo, wale jamaa walikuwa wakifungua mlango wa kuingiza amri kwa kufungua tu tatizo…

Kulikuwa na udhaifu wa utekelezaji wa msimbo katika vitendo vya GitHub, kama vile maoni ya gajira, sasa imerekebishwa. Tafadhali soma "Ingizo lisiloaminika katika mtiririko wa kazi wa GitHub" kwa maelezo kamili.

Maadili ya hadithi: Kamwe usiwahi kulipa na kutengeneza PR kutoka kwa vyanzo visivyoaminika bila kwanza kukagua PR. 'Haiaminiki' hapa, isipokuwa chini ya uthibitishaji wa kidikteta wa asili, inaweza kumaanisha akaunti yoyote ya msanidi programu iliyotekwa nyara.

 

Utekelezaji wa programu hasidi usiokusudiwa hapa!

Usambazaji unaoendelea ni kilele cha otomatiki, lakini kilele hicho kinaweza kukasirishwa na ukosefu wa udhibiti unaofaa wa idhini kwenye pipeline mtiririko.

Hatari za kupelekwa kiotomatiki kikamilifu kutoka chanzo commit kwa mifumo ya uzalishaji ni pamoja na uwezekano wa msimbo hasidi kutumwa kwenye mazingira ya uzalishaji bila kugunduliwa, pamoja na uwezekano wa makosa katika mchakato wa kutumwa kusababisha usumbufu au kukatika kwa kazi.

Ili kupunguza hatari hizi, mara nyingi inashauriwa kwamba mashirika yatekeleze "mkataba mgumu" katika mchakato wao wa kupeleka watu kwenye mtandao, ambao unahitaji kibali cha binadamu kabla ya kutolewa kusambazwa katika mazingira ya mwisho.

Wanafunga milango

Hasira ya Kinamasi: Manenosiri hayo ya furaha chaguo-msingi katika CI/CD zana zinafutwa. Kufikia /var/lib/jenkins/secrets/initialAdminPassword sasa ni njia isiyo na mwisho. Zana nyingi sasa zinatoa 2FA, ambayo Covid ilifanya iwe maarufu, na hata nyani mzembe zaidi wa msimbo huko nje anaitumia!

M3M3N70: Tunapambana na 2FA, lakini si rahisi hivyo. Ni vigumu kuwadanganya watu hao, kama "Scatter Swine" ilifanya na TwilioKwa funguo za WebAuthn ni vigumu zaidi. Angalau, tunaweza kujaribu kuiba vidakuzi ili kuepuka MFA, lakini ninahitaji kuingia kwenye kisanduku cha msanidi programu.

Uthibitishaji wa Vipengele Vingi ni hatua nzuri katika mwelekeo sahihi wa kupunguza hatari ya uvujaji wa siri za uthibitishaji. Zana nyingi za kisasa za DevOps zinaunga mkono MFA. Na funguo za uthibitishaji chini ya WebAuthn / U2F (tazama Mradi wa FIDO2) labda ndio chaguo bora zaidi kwa MFA katika DevOps, ikiwa inasimamiwa ipasavyo.

Hasira ya Kinamasi: Vijana wa DevOps wanaamka. Wana kitu cha "haki ndogo" katika damu yao. Na si nyani wa kificho tena. Sasa tunanaswa na wakaguzi.

Kwa kweli, pipelines sasa ni imara zaidi kuliko miaka michache iliyopita, huku vitendo na hati dhaifu zikiondolewa, na hatua za ziada za upimaji wa usalama ambazo hata ziligundua vitone vyetu vilivyofichwa kwa siri commitvifurushi na vifurushi tulivyoteka nyara.

Swali kwa msomaji: je, mchakato wa kujenga programu kutoka vyanzo na kuipeleka katika uzalishaji ni biashara hatari? Je, unaweza kuona DevOps zako zikiwa katika hatua ya nyakati nzuri kwa ajili ya watu wabaya?

Mapendekezo ya Mwisho

Wapi pa kuanzia CI/CD pipelines?

Pendekezo la kwanza ni rahisi hapa: Kwa uangalifu mapitio ya pipelines (wao ni muhimu rasilimali) kwa masuala ya usalama. Mapitio ni ghali lakini ni muhimu, na yanapaswa kufanywa ipasavyo. Wakaguzi wanapaswa kufahamu cha kuangalia. Kila hatua lazima ichunguzwe kwa dosari.

Labda mchanganyiko wa wakaguzi wataalamu walio na vichanganuzi vya misimbo hasidi kiotomatiki unaweza kusaidia.

Pendekezo la pili ni wafunze watengenezaji wanaoandika pipelinena kuzidumisha katika usalamaMambo ya kuzingatia:

• Jinsi ya kushughulikia ipasavyo uthibitishaji kwa kutumia huduma za ndani na wingu, kuepuka usumbufu wa kushughulikia vitambulisho vya muda mrefu.
• Jinsi ya kuweka kikomo pipelines kwa seti kamili ya rasilimali inayohitaji ufikiaji. Kanuni ya upendeleo mdogo inang'aa tena.
• Jinsi ya kuandika hatua za kutengeneza pipelines inayoweza kurudiwa kama kubandika toleo, na kuepuka udhaifu wa kuingiza amri.
• Jinsi ya kuidhinisha uwekaji kutoka kwa mtazamo wa usalama (ni wengine!): ni usalama gani standards zinapaswa kulinganishwa na jinsi ya kuongeza hundi/malango yanayolingana katika pipelines.

Pendekezo la tatu ni sanidi CI/CD mfumo kwa uangalifu unaofaa. Uthibitishaji imara, hakuna manenosiri chaguo-msingi au mipangilio isiyo salama, marupurupu machache... Tunza udhaifu katika programu-jalizi na viendelezi vilivyosakinishwa. Hili linaweza kuwa lengo la machapisho yafuatayo, tafadhali endelea kufuatilia.

Pendekezo la nne ni kujiinua CI/CD pipelines kwa ajili ya otomatiki ya usalamaUchambuzi wa msimbo chanzo (SAST), uchambuzi wa muundo wa chanzo (SCA), siri za uvujaji wa siri, zana za kupambana na programu hasidi, vitambuzi vya usalama wa kontena, au vigunduzi otomatiki vya muda wa utekelezaji (DAST na programu hasidi) vinaweza kuendeshwa mara kwa mara kwenye pipelineNa shirika lako linaweza kutekeleza standardkuhusu chanjo kwenye uchanganuzi wa usalama katika CI/CD.

Kumbuka, zana hizi haziondoi mapitio ya kitaalamu kutoka kwa mlinganyo, vinginevyo unaweza kuwa na hisia ya uwongo ya usalama.

Kama una uzoefu wa OWASP top-tens, mradi mzuri wa hivi karibuni ni OWASP Juu 10 CI/CD Hatari ya Usalama.

Dokezo la Kanusho

(1) Mifano katika chapisho hili inatumia GitHub kama SCM, AWS kama mtoa huduma wa wingu, na Vitendo vya GitHub au Jenkins kama CI/CD zana. Sio dhaifu / salama zaidi kuliko njia mbadala zao. Hakuna nia mbaya ya vyombo vya habari! Zana hizi zina nguvu na zinahitaji kutumika ipasavyo.

(2) M3M3N70 na Hasira ya Kinamasi ni wahusika wa kubuni. Kufanana kokote na watu au vikundi, wanaoishi au kifo, ni bahati tu ... au sivyo?

Kusoma zaidi

• Haymore, A. na wenzake. "Hadithi 10 za ulimwengu halisi za jinsi tulivyokubaliana CI/CD pipelines ”Kundi la NCC, Januari 2022.
• configure-aws-credentials Kitendo cha GitHub na Kusanidi OpenID Connect katika Huduma za Wavuti za Amazon kwa maelezo zaidi kuhusu jinsi ya kuendesha amri za AWS kwa ajili ya utekelezaji katika mtiririko wa kazi wa GitHub.
• Lobacevski J. "Kuweka Vitendo na mtiririko wako wa kazi wa GitHub salama Sehemu ya 1: Kuzuia maombi ya pwn"Maabara ya Usalama ya GitLab, Desemba 2020.
• Lobacevski J. "Kuweka Vitendo na mtiririko wako wa kazi wa GitHub salama Sehemu ya 2: Ingizo lisiloaminika"Maabara ya Usalama ya GitLab, Januari 2021.
• OWASP. "OWASP 10 Bora CI/CD Hatari za Usalama”Julai 2022.
• Saltzer J. na Schroeder M. "Ulinzi wa Taarifa katika Mifumo ya Kompyuta"Aprili 1975. Kanuni za usalama zilibadilika kulingana na teknolojia, lakini miaka 47 baadaye mawazo mengi ya S&S yanabaki kuwa na nguvu.
• NCSC ya Uingereza. "Linda ujenzi na uwekaji pipeline"Kituo cha Kitaifa cha Usalama Mtandaoni cha Uingereza, Februari 2019.