Ne gibi sorunlar ortaya çıkabilir? CI/CD pipelines?

Sürekli entegrasyon ve sürekli teslimat (CI/CD) pipelineOtomasyon, "modern" bir şekilde yazılım geliştiren her yazılım kuruluşunun temelini oluşturur. Otomasyon büyük bir güç sağlar, ancak çoğu geliştirici bunun getirdiği sorumluluğu gözden kaçırır.

GeliştiriciEvet, alıyoruz. CI/CD güvenlik Kodun bakımını yapan kişileri ciddiye alın ve sıkı bir şekilde denetleyin, gözden geçirin. commitbirleştirmelerden önce; işler ve pipelineGüvenlik önlemleri kıdemli personel tarafından sağlanır ve bu sayede sırların sızmaması sağlanır. pipelineVe alet, bu konuda bilgisi olan personel tarafından kuruldu. Ne yanlış gidebilir ki?

Sayın geliştirici, CI/CD Sistemler karmaşıktır. Geniş saldırı yüzeyi kötü niyetli aktörleri cezbetmiştir. Dikkatli olmak ve asla aşırı özgüvenli olmamak gerekir.

Varsayılan yapılandırma bazen korunur ve bilgisayar korsanları için en iyi dost haline gelir. Kritik güvenlik açıkları mevcut olabilir. CI/CD pipeline Sistemin yapılandırmasında veya süreç ve bağlam çevresinde yer alan kaynaklar pipeline ve nasıl tetiklendiği.

Bu yazımızda kendimizi kötü niyetli kişilerin yerine koyacağız. Şöyle hayal edin: M3M3N70 (Memento Mori?) ve Bataklık Öfkesi Karanlık ağın bir yerinde, muhtemelen Batı dışı bir dilde, ama kötülüğün dünya çapında yayıldığını asla gözden kaçırmayın.

 

Eski güzel günlerde her şey çok kolaydı…

M3M3N70Eski güzel günlere geri dönelim, işlerimiz çok kolaydı... Sıfır gün açıklarından faydalanmak çok kolaydı, uygulamalar kolayca istismar edilebilecek güvenlik açıklarıyla doluydu ve anında yatay geçiş yapabiliyorduk.

Bataklık ÖfkesiKahretsin! Hala aklı havada olanlar var ama işler değişti. Büyük firmalar bu uygulama güvenliği saçmalığına çok şüpheyle yaklaşıyor.

M3M3N70Evet. Ama yeni aptallar geliştiriciler. Bizim için bu adamların kullandığı araçları kullanmak daha kolay oldu. Özellikle CI, altın madeni! Bulut erişim belirteçleri, SCM Kimlik bilgileri, üretim veritabanı şifreleri, SSH özel anahtarları, diğer CI kullanıcılarının kimlik bilgileri… Sıkıcı geliştirme işlerinden asıl önemli konulara geçmek oldukça kolaydı.

Yazılım geliştirme, test etme ve dağıtma süreçlerinde otomasyon. CI/CD Bir araç genellikle gizli bilgilerin adım adım komutlara aktarılmasını gerektirir. Ve bu bilgiler sıklıkla sızdırılır ve bunun da kötü sonuçları olur.

Pipelineİnsanların bazen sızdırılan sırları olması gerekiyor.

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.

Belki de eski güzel günler, Git tarihinde bir şeyler bulmaktı. .env dosya (geliştirici eklemeyi unuttu) .gitignore):

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

GitHub iş akışında kullanılan .github/deploy.yaml İçinde buna benzer bir şey bulunan:

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: Vay canına! Bu AWS anahtarları işe yaradı! Önce uygulamada zararsız bir değişiklik denedik, sonra da adamlar farkında değilmiş gibi göründükleri için saldırı kodunu ekledik. Bingo! Ne kampanya ama…

Kötü niyetli kişi, AWS anahtarlarını kullanarak kötü amaçlı yazılım içeren değiştirilmiş bir uygulamayı yükledi ve ardından bu kimlik bilgileriyle dağıtım komutunu çalıştırdı. Sızdırılan gizli bilgiler, içerdiği bilgilerle birlikte... pipeline“Ne kampanya ama!” ifadesi muhtemelen Memento’nun zavallı kurbana büyük zarar verdiğini kastediyor.

Memento'nun burada bize söylediği şey, AWS erişim anahtarları örneğinde olduğu gibi bir sır sızıntısı meydana geldiğinde, sırrı geri almanız (yukarıdaki anahtarları döndürmeniz) gerektiğidir. hemenHer zaman bir tane vardır. pozlama penceresi sızıntılar arasında commit ve gizli geçersiz kılma; Git geçmişini yeniden yazmak zordur. (En katı otoriter devlet bile böyle bir tarih yeniden yazımını denedi, ama başaramadı) ve muhtemelen etkisiz (arkadaşlarımız gizli sızıntının olduğu depodan önce klonlama yapmış olabilirler) commitTuşları hemen değiştirin ve maruz kalma süresi boyunca hedef hesabın etkinlik kayıtlarını okurken dua edin!

Muhtemelen kuruluşlar şunları yapmalıdır uzun vadeli sırların kullanımını yasaklamak CI/CD pipelinesve bunları geçici kimlik bilgileriyle değiştirin. GitHub Actions'da AWS anahtarlarıyla ilgili önceki örnekte, bir AWS anahtarı kullanmak daha güvenlidir. OpenID Connect (OIDC) sağlayıcısı İşlemler için gerekli olan kısa süreli kimlik bilgilerini edinmek.

Bataklık ÖfkesiÇok şanslıydınız! Eskiden, herkese açık S3 kovalarında bile, sabit kodlanmış anahtarlarla komut dosyaları sızdırmak yaygın bir uygulamaydı. Tek yapmanız gereken kovadaki nesneleri dolaşmak ve ilginç şeyler bulmak için grep komutu kullanmaktı.

Bazen dağıtım için kullanılan alan (bu örnekte bir AWS S3 kovası), bir yapılandırma hatası nedeniyle (ve bu hata fark edilmediği için) dışarıdan erişime açıktı. Bataklık Öfkesi Kullanılan şey aşağı yukarı şöyleydi:

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>'"

Bu depolama alanı muhtemelen, güvenlik açıkları açısından otomatik olarak taranabilen bir tedarik şablonu kullanılarak oluşturulmuştur.

Aracın varsayılan yapılandırması bizim için bir oyuncaktı.

Somut örnekler vermek gerekirse, şunlardan bahsedelim: JenkinsEn popüler CI araçlarından biri.

Bataklık ÖfkesiJenkins'teki "Güvenliği Etkinleştir" onay kutusunu ve kaç kuruluşun kolaylık olsun diye bunu etkinleştirmemeyi tercih ettiğini hatırlıyor musunuz? Ve o "Herkes her şeyi yapabilir."Varsayılan olarak izin kombinasyonları mı?" Ve şu sinir bozucu Jenkins eklentileri, mesela... GitHub OAuth eklentisiYapılandırmayı yapan kişi hem "Tüm Kimliği Doğrulanmış Kullanıcılara OKUMA izni ver" hem de "GitHub deposu izinlerini kullan" seçeneklerini işaretleyerek bize tüm projelerine erişim sağladı.

(Özür dilerim Jenkins, seni örnek gösterdiğim için 😉)

Güvenlik ilkelerine hakim olun (hatta bağımlı hale gelin). Bunlardan biri şudur: Varsayılan olarak güvenli İlke: Kontroller varsayılan olarak mümkün olan en güvenli ayarlara getirilmelidir. Güvenlik, sistemin içine entegre edilmelidir. CI/CD araçları ve pipelineEn baştan itibaren tasarlanmalı, sonradan düşünülmemelidir. Ancak kullanıcı dostu ve kullanışlılık genellikle güvenlikle çatışır.

Jenkins örneğinde, yerleşik kimlik doğrulama mekanizması çok kırılgan: Jenkins'in yerleşik kimlik doğrulama mekanizmalarını asla kullanmayın.Üçüncü taraf bir mekanizma (SAML, LDAP, Google…) ve Rol Tabanlı Yetkilendirme Stratejisi (“RBAC”) eklentisi kullanmak daha iyidir. Ve şu konularda son derece dikkatli olun: admin hesap.

İşinize ve hayatınıza nasıl özen göstereceğinize dikkat edin. pipeline Jenkins'teki dosyalar işlenir. Aynı şekilde, Kod Olarak Yapılandırma eklentisi ve Jenkins yapılandırmasına uygulanan yapılandırma dosyaları.

Kendi sunucunuzda barındırılan sistemden geçiş CI/CD Sistemleri bulut tabanlı SaaS sistemlerine dönüştürmek, kuruluş ağı içinde yatay hareket imkanı sağlayarak bazı potansiyel riskleri ortadan kaldırırken, mevcut dahili sistemler ile dışa aktarılan sistemler arasında harici bağlantılar açılması gibi başka riskler de ekliyor. CI/CD aracı.

Organizasyonlar çaba göstermelidircissertleştirme işleminde gereken özeni göstermek CI/CD Sistem, en kısıtlayıcı ayarlardan başlayarak, kademeli olarak gerekli minimum izinlere kadar açılır. pipeline adım.

Güvenliği yapılandırma CI/CD Bu araçlar karmaşık bir iş olabilir. Birçoğunun, güvenlik açıklarının çoğunu barındıran ve güncellenmesi gereken eklentileri veya uzantıları vardır.

Bu tür karmaşık araçlar için güvenlik yapılandırma hatası tarayıcıları veya kıyaslama testleri yardımcı olabilir.

Kod enjekte etme pipeline eğlence ve kazanç için komutlar

M3M3N70Hiç güvenilmeyen kod kontrol noktalarını kullandınız mı? Bu noktalar, komut enjeksiyonuna karşı savunmasız eylemler ve komut dosyaları içeriyor.

Bu bölüm şunu gösteriyor ki pipeline Kendi içinde, kötü niyetli kişilerin rastgele kod yürütme işlemini gerçekleştirmesine olanak tanıyan kodlama hataları olabilir. pipeline değiştirmeden pipeline kaynağın kendisiÖrneğin, bir PR kullanarak.

İlk örnek olarak talihsiz GitHub iş akışı:

# 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 ...

birleştirme pull_request_target Güvenilmeyen bir çekme isteğinin açıkça kontrol edilmesiyle tetiklenen iş akışı, depo güvenliğinin tehlikeye atılmasına yol açabilecek tehlikeli bir uygulamadır. Örnekte, şu talihsiz kombinasyon söz konusudur:

• pull_request_target Varsayılan olarak hedef depoya ve hedef depo sırlarına harici çatallardan bile yazma iznine sahip olan ve PR'nin hedef deposu bağlamında çalışan olay,
• Güvenilmeyen kaynak koddan PR kodunu kontrol edin,
• PR tarafından kontrol edilen içerikler üzerinde işlem yapabilecek herhangi bir komut dosyasını tetiklemek, örneğin şu durumda olduğu gibi: npm install, ve
• tetiklemeye bir koşul kullanmamak pull_request_target Bu etkinlik yalnızca, çekme isteğine 'bu çekme isteği incelendi' şeklinde bir etiket atanmışsa çalışır (harici kullanıcılar çekme isteğine etiket atayamaz).

İkinci bir örnekte ise güvenilmeyen girdiler (bir sorundan, yorumdan veya pull request) bir fonksiyona iletilen argümanlar için kaynak olarak pipeline Komut, ifadeler aracılığıyla verilir. Bu, şudur: pipeline İşletim sistemi komut enjeksiyonu güvenlik açığının bir sürümü.

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

Çalıştırma işlemi, şablona dayalı geçici bir kabuk betiği oluşturur. $ Yerine başka bir şey yazılması, kabuk komut enjeksiyonuna karşı savunmasız hale gelmesine neden oldu. Sahte bir GitHub hesabına sahip bir saldırgan, başlığı "..." olan bir sorun oluşturabilir. a"; bad_code_goes_here;#Ve işte! 

Bataklık Öfkesi: Ah, o adamlar sadece bir sorun kaydı açarak komut enjeksiyonuna kapı açmışlardı...

GitHub Actions'da kod yürütme güvenlik açıkları vardı, örneğin: gajira-yorumSorun çözüldü. Lütfen okuyun. “GitHub iş akışlarında güvenilmeyen girdiler” Tüm ayrıntılar için.

Hikayenin ahlaki: Güvenilmeyen kaynaklardan gelen pull request'leri (PR'ları) incelemeden asla oluşturmayın ve indirmeyin. Burada "güvenilmez" ifadesi, menşeinin kesin olarak doğrulanması gibi katı kurallar uygulanmadığı sürece, potansiyel olarak ele geçirilmiş herhangi bir geliştirici hesabını ifade edebilir.

 

Burada istenmeyen kötü amaçlı yazılım yayılımı gerçekleşti!

Sürekli dağıtım Otomasyonun doruk noktası burası, ancak bu doruk noktası, uygun onay kontrollerinin eksikliği nedeniyle engellenebilir. pipeline akış.

Kaynaktan tam otomatik dağıtımın riskleri commit Üretim sistemlerine yönelik riskler arasında, kötü amaçlı kodların tespit edilmeden üretim ortamlarına dağıtılması olasılığı ve dağıtım sürecindeki hataların aksamalara veya kesintilere neden olma olasılığı yer almaktadır.

Bu riskleri azaltmak için, kuruluşların dağıtım süreçlerinde "kesin bir kırılma" uygulaması genellikle önerilir; bu da şunları gerektirir: insan onayı Sürümler son kullanıcı ortamlarına dağıtılmadan önce.

Kapıları kapatıyorlar.

Bataklık Öfkesi: O neşeli varsayılan şifreler CI/CD Araçlar siliniyor. Erişime izin verilmiyor. /var/lib/jenkins/secrets/initialAdminPassword Artık geçerliliğini yitirmiş bir konu. Birçok araç artık Covid'in popülerleştirdiği 2FA (iki faktörlü kimlik doğrulama) hizmeti sunuyor ve en tembel kod yazıcısı bile bunu kullanıyor!

M3M3N70İki faktörlü kimlik doğrulamaya karşı mücadele ediyoruz, ancak bu o kadar kolay değil. Bu tür dolandırıcılıkları hedef almak zor, çünkü “Scatter Swine” Twilio ile birlikte yapıldı.WebAuthn anahtarlarıyla bu çok daha zor. En azından denemeye çalışabiliriz. Çok faktörlü kimlik doğrulamayı atlatmak için çerezleri çalmakAma geliştiricinin kutusuna girmek gerekiyor.

Çok Faktörlü Kimlik Doğrulama, kimlik doğrulama sırlarının sızması riskini sınırlamak için doğru yönde atılmış iyi bir adımdır. Modern DevOps araçlarının çoğu MFA'yı desteklemektedir. Ve WebAuthn / U2F altında kimlik doğrulama anahtarları (bkz. FIDO2 projesi(Doğru şekilde yönetildiği takdirde) DevOps'ta çok faktörlü kimlik doğrulama için belki de en iyi seçenektir.

Bataklık ÖfkesiDevOps ekibi uyanıyor. Kanlarında o lanet olası "en az ayrıcalıklı olma" anlayışı var. Ve artık sadece kod yazan maymunlar değiller. Artık gözden geçirenler tarafından suçüstü yakalanıyoruz.

Aslında, pipelineGüvenlik önlemlerimiz, zayıf eylemlerin ve komut dosyalarının kaldırılması ve gizlice saklanan zararlı yazılımlarımızı bile tespit eden ek güvenlik test adımları sayesinde, birkaç yıl öncesine göre biraz daha sağlam hale geldi. commitEle geçirdiğimiz e-postalar ve paketler.

Okuyucuya soru: Yazılımı kaynak koddan derleyip üretime dağıtma süreci riskli bir iş midir? DevOps ekibinizi bu aşamada görebiliyor musunuz? eski güzel zamanlar Kötü adamlar için mi?

Son Tavsiyeler

Nereden başlamalı CI/CD pipelines?

İlk öneri oldukça basit: Dikkatlice yorum pipelines (bunlar kritik Güvenlik sorunları için kaynaklar (ve maliyetler) gereklidir. İncelemeler maliyetlidir ancak gereklidir ve doğru şekilde yapılmalıdır. İnceleyiciler neye bakmaları gerektiğini bilmelidir. Her adımda kusurlar kontrol edilmelidir.

Belki de otomatik kötü amaçlı kod tarayıcılarıyla donatılmış uzman inceleyicilerin bir araya gelmesi yardımcı olabilir.

İkinci öneri ise şudur: eğitim geliştiricileri yazıyor pipelineve bunları güvenli bir şekilde muhafaza edin.Dikkate alınması gerekenler:

• Uzun süreli kimlik bilgilerini saklama zahmetinden kaçınarak, dahili ve bulut servisleriyle kimlik doğrulamasını doğru şekilde nasıl yöneteceğinizi öğrenin.
• Nasıl sınırlandırılır? pipelineİhtiyaç duyduğu kaynaklara tam olarak erişim imkanı sağlar. En az ayrıcalık ilkesi burada bir kez daha kendini gösterir.
• Yapım aşamalarını nasıl yazabilirim? pipelineSürüm sabitleme gibi tekrarlanabilir yöntemler ve komut enjeksiyonu güvenlik açıklarından kaçınma gibi özellikler.
• Güvenlik açısından dağıtımları nasıl onaylayabilirsiniz (başka seçenekler de var!): hangi güvenlik standards'lerin nasıl eşleştirilmesi gerektiği ve ilgili kontrollerin/geçitlerin nasıl ekleneceği pipelines.

Üçüncü öneri ise şudur: yapılandır CI/CD sistem gerekli özenleGüçlü kimlik doğrulama, varsayılan parola veya güvensiz ayarlar yok, minimum ayrıcalıklar… Yüklenen eklenti ve uzantılardaki güvenlik açıklarına dikkat edin. Bu, sonraki yazılarımızın odak noktası olabilir, lütfen takipte kalın.

Dördüncü öneri şudur: kaldıraç CI/CD pipelinegüvenlik otomasyonu içinKaynak kod analizi (SAST), kaynak bileşimi analizi (SCA), gizli bilgi sızıntısı taraması, kötü amaçlı yazılım önleme araçları, konteyner güvenlik tarayıcıları veya otomatik çalışma zamanı dedektörleri (DAST ve kötü amaçlı yazılım) rutin olarak çalıştırılabilir. pipelineVe kuruluşunuz bunu uygulayabilir. standardgüvenlik taramasıyla ilgili kapsama alanına ilişkin bilgiler CI/CD.

Unutmayın, bu araçlar uzman değerlendirmesini denklemden çıkarmaz, aksi takdirde yanlış bir güvenlik duygusuna kapılabilirsiniz.

OWASP ilk on listelerine aşina iseniz, yakın zamanda yapılmış güzel bir proje şu olabilir: OWASP Top 10 CI/CD Güvenlik Riski.

Sorumluluk Reddi Notu

(1) Bu gönderideki örnekler GitHub'ı kullanıyor SCMBulut sağlayıcı olarak AWS ve GitHub Actions veya Jenkins. CI/CD Bu araçlar güçlüdür ve uygun şekilde kullanılmalıdır. Alternatiflerinden daha zayıf veya daha güvenli değillerdir. Kötü bir niyetimiz yok!

(2) M3M3N70 hem de Bataklık Öfkesi Bunlar kurgusal karakterlerdir. Yaşayan veya ölü kişiler veya gruplarla herhangi bir benzerlik tamamen tesadüftür… yoksa değil mi?

Daha fazla okumak için

• Haymore, A. ve diğerleri. “Taviz verdiğimiz 10 gerçek hayat hikayesi” CI/CD pipelines ”NCC Grubu, Ocak 2022.
• configure-aws-credentials GitHub eylemi hem de Amazon Web Services'ta OpenID Connect'i Yapılandırma GitHub iş akışlarında dağıtım için AWS komutlarının nasıl çalıştırılacağına dair ayrıntılar için.
• Lobacevski J. “GitHub Actions ve iş akışlarınızı güvende tutmanın 1. Bölümü: Saldırı isteklerini önleme”GitLab Güvenlik Laboratuvarı, Aralık 2020.
• Lobacevski J. “GitHub Actions ve iş akışlarınızı güvende tutmanın 2. Bölümü: Güvenilmeyen girdiler”GitLab Güvenlik Laboratuvarı, Ocak 2021.
• OWASP. “OWASP İlk 10” CI/CD Güvenlik Riskleri””Temmuz 2022.
• Saltzer J. ve Schroeder M. “Bilgisayar Sistemlerinde Bilginin Korunması”Nisan 1975. Güvenlik prensipleri teknolojiyle birlikte gelişti, ancak 47 yıl sonra güvenlik ve güvenlik fikirlerinin çoğu hala geçerliliğini koruyor.
• Birleşik Krallık NCSC. "Derleme ve dağıtımı güvenli hale getirin." pipelinebaşlıklı bir kılavuz yayınladıBirleşik Krallık Ulusal Siber Güvenlik Merkezi, Şubat 2019.