Last updated
Atlantis, temel olarak terraform'ı git sunucunuzdaki Pull Request'lerden çalıştırmanıza yardımcı olur.
https://github.com/runatlantis/atlantis/releases adresindeki atlantis sürümleri sayfasına gidin ve size uygun olanı indirin.
Github kullanıcınızın repo erişimi olan bir kişisel jeton oluşturun.
./atlantis testdrive komutunu çalıştırın ve atlantis ile iletişim kurabileceğiniz bir demo repo oluşturacaktır.
Web sayfasına 127.0.0.1:4141 adresinden erişebilirsiniz.
Atlantis, Github, Gitlab, Bitbucket ve Azure DevOps gibi birçok git sunucusunu destekler. Ancak, bu platformlardaki depolara erişmek ve işlemler gerçekleştirmek için biraz ayrıcalıklı erişime ihtiyaç duyar (en azından yazma izinleri). Dökümantasyon, Atlantis için özel olarak bir kullanıcı oluşturmanızı önerir, ancak bazı insanlar kişisel hesapları kullanabilir.
Her durumda, bir saldırganın bakış açısından, Atlantis hesabı çok ilginç bir şekilde ele geçirilebilir.
Atlantis, Webhook gizliliklerini (seçimli olarak) kullanarak, Git sunucunuzdan aldığı webhook'ların geçerli olduğunu doğrular.
Bunu doğrulamanın bir yolu, yalnızca Git sunucunuzun IP'lerinden gelen isteklere izin vermek olabilir, ancak daha kolay bir yol Webhook Gizliliği kullanmaktır.
Dikkat edin, özel bir github veya bitbucket sunucusu kullanmadıkça, webhook uç noktalarını İnternet'e açmanız gerekecektir.
Atlantis, git sunucusunun ona bilgi gönderebilmesi için webhook'ları açığa çıkaracak, bu nedenle bir saldırganın onunla mesaj gönderebileceğini bilmek ilginç olabilir.
Atlantis, Terraform'ı sadece terraform plan ve apply komutlarını Atlantis'in barındırıldığı sunucuda çalıştırarak çalıştırır. Yerel olarak Terraform çalıştırdığınızda olduğu gibi, Atlantis, belirli sağlayıcınız için kimlik bilgilerine ihtiyaç duyar.
Sağlayıcınıza özgü kimlik bilgilerini Atlantis'e nasıl sağlayacağınıza siz karar verirsiniz:
Atlantis Helm Chart ve AWS Fargate Modülü sağlayıcı kimlik bilgileri için kendi mekanizmalarına sahiptir. Belgelerini okuyun.
Atlantis'i bir bulutta çalıştırıyorsanız, birçok bulut, üzerinde çalışan uygulamalara bulut API erişimi sağlama yollarına sahiptir, örn:
AWS EC2 Roller (Arama yapın "EC2 Rolü")
Birçok kullanıcı, Atlantis'in çalıştığı yerde olduğu gibi ortam değişkenleri ayarlar, örn. AWS_ACCESS_KEY.
Diğerleri gerekli yapılandırma dosyalarını oluşturur, örn. ~/.aws/credentials, Atlantis'in çalıştığı yerde.
Sağlayıcı kimlik bilgilerini elde etmek için HashiCorp Vault Sağlayıcısını kullanın.
Atlantis'in çalıştığı konteynerde, Atlantis'in Terraform aracılığıyla yönettiği sağlayıcılara (AWS, GCP, Github...) ait ayrıcalıklı kimlik bilgileri bulunması muhtemeldir.
Atlantis varsayılan olarak localhost'ta 4141 numaralı bağlantı noktasında bir web sayfası çalıştırır. Bu sayfa, atlantis uygulamasını etkinleştirmenize/devre dışı bırakmanıza, depoların plan durumunu kontrol etmenize ve kilidini açmanıza olanak tanır (şeyleri değiştirmenize izin vermediği için çok kullanışlı değildir).
Muhtemelen internete açık bulamazsınız, ancak varsayılan olarak erişmek için kimlik bilgisi gerektirmediği gibi görünüyor (ve gerekiyorsa atlantis:atlantis varsayılan olanlardır).
atlantis server yapılandırması, komut satırı bayrakları, ortam değişkenleri, bir yapılandırma dosyası veya üçünün karışımı yoluyla belirtilebilir.
Atlantis sunucusu tarafından desteklenen bayrakların listesini burada bulabilirsiniz
Bir yapılandırma seçeneğini nasıl bir ortam değişkenine dönüştüreceğinizi burada bulabilirsiniz
Değerler şu sırayla seçilir:
Bayraklar
Ortam Değişkenleri
Yapılandırma Dosyası
Yapılandırmada, jetonlar ve parolalar gibi ilginç değerler bulabilirsiniz.
Bazı yapılandırmalar, depoların nasıl yönetileceğini etkiler. Bununla birlikte, her depo için farklı ayarlar gerekebilir, bu nedenle her depoyu belirtmenin yolları vardır. Bu, öncelik sırasıdır:
Depo /atlantis.yml dosyası. Bu dosya, atlantis'in depoyu nasıl işleyeceğini belirtmek için kullanılabilir. Ancak, bazı anahtarlar varsayılan olarak belirtilmedikçe burada belirtilmesi mümkün olmayabilir.
Muhtemelen allowed_overrides veya allow_custom_workflows
Atlantis, PR'nin başka biri tarafından onaylanmasını (bu, dal korumasında ayarlanmamış olsa bile) ve/veya uygulanmadan önce birleştirilebilir olmasını (dal korumaları geçildi) belirtmenize olanak tanır. Güvenlik açısından, her iki seçeneği de ayarlamak önerilir.
allowed_overrides True olarak ayarlandığında, bu ayarlar her projede /atlantis.yml dosyasıyla üzerine yazılabilir.
Repo yapılandırması, bir iş akışı yürütüldükten sonra önce (ön iş akışı kancaları) ve sonra (son iş akışı kancaları) çalıştırılacak komut dosyalarını belirtebilir.
Repo /atlantis.yml dosyasında bu komut dosyalarını belirtme seçeneği yoktur.
Repo yapılandırmasında (sunucu tarafı yapılandırma) yeni bir varsayılan iş akışı belirtebilir veya yeni özel iş akışları oluşturabilirsiniz. Ayrıca, yeni oluşturulanların hangi repo'ların erişebileceğini belirtebilirsiniz. Daha sonra, her repo'nun atlantis.yaml dosyasının hangi iş akışını kullanacağını belirlemesine izin verebilirsiniz.
Sunucu tarafı yapılandırma bayrağı allow_custom_workflows True olarak ayarlandığında, iş akışları her repo'nun atlantis.yaml dosyasında belirtilebilir. Ayrıca, allowed_overrides'ın aynı zamanda kullanılacak iş akışını geçersiz kılamayı da belirtmesi gerekebilir.
Bu, temel olarak, o repo'ya erişebilen herhangi bir kullanıcıya Atlantis sunucusunda RCE sağlar.
Atlantis, plan çıktısına karşı sunucu tarafında conftest politikalarını çalıştırmayı destekler. Bu adımı kullanmanın yaygın kullanım durumları şunları içerir:
Bir modül listesinin kullanımını reddetmek
Bir kaynağın oluşturma zamanında özniteliklerini doğrulamak
Kazara kaynak silmelerini yakalamak
Güvenlik risklerini önlemek (örneğin, güvenli bağlantı noktalarını halka açmak)
Bunu nasıl yapılandıracağınızı belgelerde kontrol edebilirsiniz.
Atlantis'i çalıştırmak için kullanabileceğiniz seçenekleri belgelerde bulabilirsiniz.
Eğer saldırı sırasında şu hata ile karşılaşırsanız: Error: Error acquiring the state lock
Bunu düzeltmek için şunu çalıştırabilirsiniz:
Eğer bir depoya yazma erişiminiz varsa, üzerinde yeni bir dal oluşturabilir ve bir PR (Pull Request) oluşturabilirsiniz. Eğer atlantis plan komutunu çalıştırabilirseniz (veya otomatik olarak çalıştırılıyorsa), Atlantis sunucusu içinde RCE gerçekleştirebilirsiniz.
Bunu yapmak için Atlantis'ın harici bir veri kaynağı yüklemesini sağlayabilirsiniz. Sadece aşağıdaki gibi bir payload'ı main.tf dosyasına yerleştirin:
Bu saldırıyı daha gizli bir şekilde gerçekleştirebilirsiniz, aşağıdaki önerileri takip ederek:
Terraform dosyasına doğrudan ters kabuk eklemek yerine, ters kabuğu içeren harici bir kaynağı yükleyebilirsiniz:
Rev shell kodunu https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules adresinde bulabilirsiniz.
Dış kaynakta, ref özelliğini kullanarak terraform rev shell kodunu bir repo içindeki bir dalda gizleyin, örneğin: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b
Atlantis'i tetiklemek için master'a PR oluşturmak yerine, 2 dal (test1 ve test2) oluşturun ve birinden diğerine bir PR oluşturun. Saldırıyı tamamladığınızda, sadece PR ve dalları kaldırın.
atlantis plan (terraform plan) komutunu çalıştırarak terraform tarafından kullanılan gizli bilgileri dökümleyebilirsiniz. Bunun için terraform dosyasına şunu ekleyin:
Bir depoya yazma erişiminiz varsa, üzerinde yeni bir dal oluşturabilir ve bir PR (Pull Request) oluşturabilirsiniz. atlantis apply komutunu çalıştırabiliyorsanız, Atlantis sunucusu içinde RCE gerçekleştirebilirsiniz.
Ancak genellikle bazı korumaları aşmanız gerekecektir:
Birleştirilebilir (Mergeable): Eğer Atlantis'te bu koruma ayarlanmışsa, atlantis apply komutunu yalnızca PR birleştirilebilir (mergeable) olduğunda çalıştırabilirsiniz (bu, dal korumasının aşılmış olması gerektiği anlamına gelir).
Potansiyel dal korumalarını aşma yöntemlerini kontrol edin.
Onaylı (Approved): Eğer Atlantis'te bu koruma ayarlanmışsa, atlantis apply komutunu çalıştırmadan önce başka bir kullanıcının PR'yi onaylaması gerekmektedir.
Varsayılan olarak, bu korumayı aşmak için Gitbot token'ını kötüye kullanabilirsiniz.
Kötü niyetli bir Terraform dosyasında terraform apply komutunu çalıştırarak local-exec** özelliğini kullanabilirsiniz**.
Sadece aşağıdaki gibi bir payload'ın main.tf dosyasında yer aldığından emin olmanız yeterlidir:
Önceki teknikteki önerileri takip ederek bu saldırıyı daha gizli bir şekilde gerçekleştirin.
atlantis plan veya atlantis apply komutlarını çalıştırırken terraform altında çalıştırılırken, atlantis üzerinden terraform'a komutlar iletebilirsiniz. Bunun için aşağıdaki gibi bir yorum satırı ekleyebilirsiniz:
Bazı korumaları atlamak için yararlı olabilecek ortam değişkenlerini geçebilirsiniz. Terraform ortam değişkenlerini https://www.terraform.io/cli/config/environment-variables adresinde kontrol edin.
atlantis.yaml dosyasında belirtilen zararlı özel derleme komutlarını çalıştırma. Atlantis, atlantis.yaml dosyasını çekme isteği dalından alır, ana dalın değil.
Bu olasılık bir önceki bölümde belirtilmiştir:
Eğer sunucu tarafı yapılandırma bayrağı allow_custom_workflows True olarak ayarlanmışsa, iş akışları her repo'nun atlantis.yaml dosyasında belirtilebilir. Ayrıca, kullanılacak olan iş akışını geçersiz kılmak için allowed_overrides'ın da workflow'u belirtmesi gerekebilir.
Bu, Atlantis sunucusunda RCE'ye (Uzaktan Kod Çalıştırma) sahip herhangi bir kullanıcıya erişebilen repo verir.
Eğer sunucu tarafı yapılandırma bayrağı allowed_overrides ayarlanmışsa ve apply_requirements yapılandırılmışsa, bir depo bu korumaları atlatmak için plan/apply'yi değiştirebilir.
Eğer biri geçerli pull requestlerinize atlantis plan/apply yorumları gönderirse, istemediğiniz bir zamanda terraform çalıştırılabilir.
Ayrıca, branch korumasında yeni bir commit itildiğinde her PR'nin yeniden değerlendirilmesini istemek için yapılandırma yapmadıysanız, birisi terraform yapılandırmasına zararlı yapılandırmalar (önceki senaryoları kontrol edin) yazabilir, atlantis plan/apply çalıştırabilir ve RCE elde edebilir.
Bu, Github branch korumalarındaki ayardır:
Eğer webhook secret'ı çalmayı başarırsanız veya hiçbir webhook secret kullanılmıyorsa, Atlantis webhook'unu çağırabilir ve doğrudan atlantis komutlarını çağırabilirsiniz.
Bitbucket Cloud webhook secret'ı desteklememektedir. Bu, saldırganların Bitbucket'ten gelen istekleri taklit etmelerine izin verebilir. Sadece Bitbucket IP'lerine izin verdiğinizden emin olun.
Bu, bir saldırganın, Bitbucket'ten geliyormuş gibi görünen sahte istekler yapabileceği anlamına gelir.
--repo-allowlist belirtiyorsanız, sadece bu depolarla ilgili sahte istekler yapabilirler, bu yüzden yapabilecekleri en büyük zarar kendi depolarınızda plan/apply yapmaktır.
Bunu önlemek için, Bitbucket'in IP adreslerini (Outbound IPv4 adreslerini görün) izin verin.
Eğer sunucuya erişim sağlamayı başardıysanız veya en azından bir LFI elde ettiyseniz, okumaya çalışmanız gereken bazı ilginç şeyler vardır:
/home/atlantis/.git-credentials VCS erişim kimlik bilgilerini içerir
/atlantis-data/atlantis.db Daha fazla bilgi içeren VCS erişim kimlik bilgilerini içerir
/atlantis-data/repos/<org_name>/<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate Terraform durum dosyası
Örnek: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
/proc/1/environ Ortam değişkenleri
/proc/[2-20]/cmdline atlantis server'ın komut satırı (hassas veri içerebilir)
Herkes genel pull requestlere yorum yapabilir, mevcut tüm güvenlik önlemleri olsa bile, güvenlik ayarlarının doğru yapılandırılmadan genel depolarda Atlantis'i çalıştırmak tehlikelidir.
--allow-fork-prs KullanmayınÖnerilmeyen bir genel depoda çalışıyorsanız (--allow-fork-prs varsayılan olarak false olarak ayarlanır), başka biri çatalınızdan kendi depolarına bir pull request açabilir.
--repo-allowlistAtlantis, --repo-allowlist bayrağı aracılığıyla web kancalarını kabul edeceği depoların bir izin listesini belirtmenizi gerektirir. Örneğin:
Belirli depolar: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
Tüm organizasyonunuz: --repo-allowlist=github.com/runatlantis/*
GitHub Enterprise kurulumunuzdaki tüm depolar: --repo-allowlist=github.yourcompany.com/*
Tüm depolar: --repo-allowlist=*. Korumalı bir ağda kullanışlıdır, ancak bir webhook secret belirlemeden tehlikelidir.
Bu bayrak, Atlantis kurulumunuzun kontrolünüz dışındaki depolarla kullanılmadığından emin olur. Daha fazla ayrıntı için atlantis server --help'i kontrol edin.
Saldırganların zararlı Terraform koduyla pull request göndermesi tehdit modelinizde ise, terraform apply onayları yeterli değildir. Zararlı bir kodu terraform plan'da external veri kaynağı veya zararlı bir sağlayıcı belirterek çalıştırmak mümkündür. Bu kod, kimlik bilgilerinizi dışarı çıkarabilir.
Bunu önlemek için şunları yapabilirsiniz:
Sağlayıcıları Atlantis görüntüsüne yerleştirin veya üretimde çıkışı reddedin.
Sağlayıcı kayıt defteri protokolünü dahili olarak uygulayın ve genel çıkışı reddedin, böylece kimin kayıt defterine yazma erişimine sahip olduğunu kontrol edersiniz.
Sunucu tarafı repo yapılandırmanızı plan adımı, yasaklanmış sağlayıcıların veya veri kaynaklarının kullanımına veya izin verilmeyen kullanıcılardan gelen PR'lere karşı doğrulamak için değiştirin. Bu noktada ek doğrulama da ekleyebilirsiniz, örneğin plan'a devam etmeden önce PR üzerinde "thumbs-up" gerektirme. Burada Conftest kullanışlı olabilir.
Atlantis, $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET ortam değişkenleri aracılığıyla Webhook secret'larının ayarlanmasını gerektirir. --repo-allowlist bayrağı ayarlı olsa bile, webhook secret olmadan saldırganlar, izin verilen bir depo gibi davranarak Atlantis'e istek yapabilirler. Webhook secret'lar, webhook isteklerinin gerçekten VCS sağlayıcınızdan (GitHub veya GitLab) geldiğini sağlar.
Azure DevOps kullanıyorsanız, webhook secret'lar yerine temel bir kullanıcı adı ve parola ekleyin.
Azure DevOps, tüm webhook olaylarında temel kimlik doğrulama başlığı göndermeyi destekler. Bunun için webhook konumunuz için bir HTTPS URL kullanmanız gerekmektedir.
Webhook secret'larını kullanıyorsanız ancak trafiğiniz HTTP üzerinden gerçekleşiyorsa, webhook secret'lar çalınabilir. --ssl-cert-file ve --ssl-key-file bayraklarını kullanarak SSL/HTTPS'yi etkinleştirin.
Web hizmetinde kimlik doğrulamasını etkinleştirmek çok önerilir. --web-basic-auth=true bayra
