Atlantis Security
Last updated
Last updated
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Atlantis, temel olarak git sunucunuzdan Pull Request'lerden terraform ç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 için bir kişisel token (repo erişimi ile) oluşturun.
./atlantis testdrive komutunu çalıştırın ve atlantis ile konuşmak için kullanabileceğ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 birkaç git sunucusunu destekler. Ancak, bu platformlardaki repo'lara erişmek ve işlemler gerçekleştirmek için bazı ayrıcalıklı erişimlerin verilmesi gerekir (en azından yazma izinleri). Belgeler, Atlantis için bu platformlarda özel bir kullanıcı oluşturulmasını teşvik eder, ancak bazı insanlar kişisel hesaplar kullanabilir.
Her durumda, bir saldırgan perspektifinden, Atlantis hesabı çok ilginç bir hedef olacaktır.
Atlantis, Git sunucunuzdan aldığı webhook'ların geçerli olduğunu doğrulamak için isteğe bağlı olarak Webhook gizli anahtarları kullanır.
Bunu doğrulamanın bir yolu, isteklerin yalnızca Git sunucunuzun IP'lerinden gelmesine izin vermek olacaktır, ancak daha kolay bir yol Webhook Gizli Anahtarı kullanmaktır.
Özel bir github veya bitbucket sunucusu kullanmadığınız sürece, webhook uç noktalarını internete açmanız gerekecektir.
Atlantis, git sunucusunun bilgi gönderebilmesi için webhook'ları açacak. Bir saldırgan perspektifinden, ona mesaj gönderip gönderemeyeceğinizi bilmek ilginç olacaktır.
Atlantis, Atlantis'in barındırıldığı sunucuda terraform plan ve apply komutlarını çalıştırarak Terraform'u çalıştırır. Terraform'u yerel olarak çalıştırdığınızda olduğu gibi, Atlantis'in belirli sağlayıcınız için kimlik bilgilerine ihtiyacı vardır.
Atlantis'e belirli sağlayıcınız için kimlik bilgilerini nasıl sağladığınız size bağlıdır:
Atlantis Helm Chart ve AWS Fargate Modülü kendi kimlik bilgileri 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 Rolleri (Arama "EC2 Rolü")
Birçok kullanıcı, Atlantis'in çalıştığı yerde ortam değişkenleri ayarlar, örn. AWS_ACCESS_KEY.
Diğerleri, Atlantis'in çalıştığı yerde gerekli yapılandırma dosyalarını oluşturur, örn. ~/.aws/credentials.
Sağlayıcı kimlik bilgilerini elde etmek için HashiCorp Vault Provider kullanın.
Atlantis'in çalıştığı konteyner, muhtemelen Atlantis'in Terraform aracılığıyla yönettiği sağlayıcılara (AWS, GCP, Github...) ait ayrıcalıklı kimlik bilgilerini içerecektir.
Varsayılan olarak Atlantis, localhost'ta 4141 portunda bir web sayfası çalıştıracaktır. Bu sayfa, yalnızca atlantis apply'i etkinleştirip devre dışı bırakmanıza ve repo'ların plan durumunu kontrol etmenize ve kilidini açmanıza izin verir (şeyleri değiştirmeye izin vermez, bu yüzden çok faydalı değildir).
Muhtemelen internete açılmış olarak bulamayacaksınız, ancak varsayılan olarak erişim için kimlik bilgisi gerekmediği görünmektedir (ve eğer 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 bunların bir karışımı aracılığıyla belirtilebilir.
Atlantis sunucusu tarafından desteklenen bayrakların listesini burada bulabilirsiniz
Bir yapılandırma seçeneğini bir ortam değişkenine dönüştürmenin yolunu burada bulabilirsiniz
Değerler bu sırayla seçilir:
Bayraklar
Ortam Değişkenleri
Yapılandırma Dosyası
Yapılandırmada, tokenlar ve şifreler gibi ilginç değerler bulabileceğinizi unutmayın.
Bazı yapılandırmalar, repo'ların nasıl yönetildiğini etkiler. Ancak, her repo'nun farklı ayarlar gerektirmesi mümkündür, bu nedenle her repo'yu belirtmenin yolları vardır. Öncelik sırası şudur:
Repo /atlantis.yml dosyası. Bu dosya, atlantis'in repo'yu nasıl ele alması gerektiğini belirtmek için kullanılabilir. Ancak, varsayılan olarak bazı anahtarların burada belirtilmesine izin verilmez.
Muhtemelen allowed_overrides veya allow_custom_workflows gibi bayraklarla izin verilmesi gerekir.
Sunucu Tarafı Yapılandırması: --repo-config bayrağı ile geçirebilirsiniz ve bu, her repo için yeni ayarları yapılandıran bir yaml'dır (regex desteklenir).
Varsayılan değerler.
PR Koruma
Atlantis, PR'nin başka biri tarafından onaylanmasını (bu, dal korumasında ayarlanmamış olsa bile) ve/veya birleştirilebilir (dal korumaları geçildi) olmasını belirtmenize izin verir apply çalıştırmadan önce. Güvenlik açısından, her iki seçeneği de ayarlamak önerilir.
allowed_overrides True olduğunda, bu ayarlar her projede /atlantis.yml dosyası ile üstü kapatılabilir.
Betikler
Repo yapılandırması, bir iş akışı yürütülmeden önce çalıştırılacak betikleri (ön iş akışı kancaları) ve sonrasında (son iş akışı kancaları) belirleyebilir.
Bu betikleri repo /atlantis.yml dosyasında belirlemeye izin veren herhangi bir seçenek yoktur.
İş Akışı
Repo yapılandırmasında (sunucu tarafı yapılandırması), yeni bir varsayılan iş akışı belirtebilirsiniz veya yeni özel iş akışları oluşturabilirsiniz. Ayrıca, hangi repo'ların oluşturulan yeni iş akışlarına erişebileceğini de belirtebilirsiniz. Daha sonra, her repo'nun atlantis.yaml dosyasının kullanılacak iş akışını belirtmesine izin verebilirsiniz.
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 belirlenebilir. Ayrıca, allowed_overrides'ın workflow'u da üstü kapatacak şekilde belirtmesi gerekebilir.
Bu, temelde Atlantis sunucusunda bu repo'ya erişebilen herhangi bir kullanıcıya RCE verecektir.
Conftest Politika Kontrolü
Atlantis, plan çıktısına karşı sunucu tarafında conftest politikalarının çalıştırılmasını destekler. Bu adımı kullanmanın yaygın kullanım senaryoları şunlardır:
Bir modül listesinin kullanımını reddetmek
Bir kaynağın oluşturulma zamanındaki niteliklerini doğrulamak
İstemeden kaynak silmelerini yakalamak
Güvenlik risklerini önlemek (yani, güvenli portları halka açmak)
Bunu nasıl yapılandıracağınızı belgelere bakarak kontrol edebilirsiniz.
Belgelere bakarak Atlantis'i çalıştırmak için kullanabileceğiniz seçenekleri bulabilirsiniz:
Eğer istismar sırasında bu hata ile karşılaşırsanız: Error: Error acquiring the state lock
Bunu çalıştırarak düzeltebilirsiniz:
Bir depoya yazma erişiminiz varsa, üzerinde yeni bir dal oluşturabilir ve bir PR oluşturabilirsiniz. Eğer atlantis plan komutunu çalıştırabiliyorsanız (ya da belki otomatik olarak çalıştırılıyorsa), Atlantis sunucusunda RCE yapabilirsiniz.
Bunu, Atlantis'in harici bir veri kaynağını yüklemesini sağlayarak yapabilirsiniz. main.tf dosyasına aşağıdaki gibi bir yük yerleştirin:
Gizli Saldırı
Bu saldırıyı daha gizli bir şekilde gerçekleştirebilirsiniz, bu önerileri takip ederek:
Rev shell'i doğrudan terraform dosyasına eklemek yerine, rev shell içeren harici bir kaynağı yükleyebilirsiniz:
You can find the rev shell code in https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules
Dış kaynakta, ref özelliğini kullanarak repo içindeki bir dalda terraform rev shell kodunu gizleyin, şöyle bir şey: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b
Atlantis'i tetiklemek için master'a bir PR oluşturmak yerine, 2 dal oluşturun (test1 ve test2) ve birinden diğerine bir PR oluşturun. Saldırıyı tamamladıktan sonra, sadece PR'yi ve dalları kaldırın.
Terraform tarafından kullanılan gizli anahtarları dökebilirsiniz atlantis plan (terraform plan) çalıştırarak, terraform dosyasına şöyle bir şey koyarak:
Eğer bir depoya yazma erişiminiz varsa, üzerinde yeni bir dal oluşturabilir ve bir PR oluşturabilirsiniz. Eğer atlantis apply komutunu çalıştırabiliyorsanız, Atlantis sunucusunda RCE gerçekleştirebilirsiniz.
Ancak genellikle bazı korumaları aşmanız gerekecektir:
Birleştirilebilir: Eğer bu koruma Atlantis'te ayarlanmışsa, yalnızca PR birleştirilebilir olduğunda atlantis apply çalıştırabilirsiniz (bu, dal korumasının aşılması gerektiği anlamına gelir).
Potansiyel dal koruma aşmaları kontrol edin.
Onaylı: Eğer bu koruma Atlantis'te ayarlanmışsa, atlantis apply komutunu çalıştırmadan önce başka bir kullanıcının PR'yi onaylaması gerekir.
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 çalıştırmak için local-exec.
Sadece main.tf dosyasının sonunda aşağıdaki gibi bir yükün bulunduğundan emin olmalısınız:
Önceki teknikten önerileri takip ederek bu saldırıyı daha gizli bir şekilde gerçekleştirin.
atlantis plan veya atlantis apply çalıştırıldığında terraform altında çalıştırılmaktadır, atlantis'ten terraform'a komutlar geçirebilirsiniz, şöyle bir yorum yaparak:
Bir şey geçirebileceğiniz env değişkenleri, bazı korumaları aşmanıza yardımcı olabilir. Terraform env değişkenlerini kontrol edin https://www.terraform.io/cli/config/environment-variables
Bir atlantis.yaml dosyasında belirtilen kötü niyetli özel derleme komutlarını çalıştırmak. Atlantis, pull request dalından atlantis.yaml dosyasını kullanır, master'dan değil.
Bu olasılık daha önceki bir bölümde belirtilmiştir:
Eğer sunucu tarafı yapılandırma bayrağı allow_custom_workflows True olarak ayarlandıysa, iş akışları her repo için atlantis.yaml dosyasında belirtilmiş olabilir. Ayrıca, kullanılacak iş akışını geçersiz kılmak için allowed_overrides'ın da workflow'u belirtmesi gerekebilir.
Bu, temelde o repoya erişebilen herhangi bir kullanıcıya Atlantis sunucusunda RCE verecektir.
Eğer sunucu tarafı yapılandırma bayrağı allowed_overrides için apply_requirements yapılandırılmışsa, bir repo plan/apply korumalarını değiştirebilir ve bunları atlatabilir.
Eğer biri atlantis plan/apply yorumları gönderirse geçerli pull request'lerinize, bu terraform'un istemediğiniz bir zamanda çalışmasına neden olur.
Ayrıca, eğer branch protection ayarlarında yeni bir commit gönderildiğinde her PR'nin yeniden değerlendirilmesini istemiyorsanız, biri terraform konfigürasyonuna kötü niyetli konfigürasyonlar yazabilir (önceki senaryolara bakın), atlantis plan/apply çalıştırabilir ve RCE elde edebilir.
Bu, Github branch koruma ayarındaki ayardır:
Eğer kullanılan webhook secret'ını çalmayı başarırsanız veya hiçbir webhook secret'ı kullanılmıyorsa, Atlantis webhook'unu çağırabilir ve atlantis komutlarını doğrudan çalıştırabilirsiniz.
Bitbucket Cloud webhook secret'larını desteklememektedir. Bu, saldırganların Bitbucket'tan gelen istekleri taklit etmesine olanak tanıyabilir. Sadece Bitbucket IP'lerine izin verdiğinizden emin olun.
Bu, bir saldırganın Atlantis'e Bitbucket'tan geliyormuş gibi görünen sahte istekler yapabileceği anlamına gelir.
Eğer --repo-allowlist belirtiyorsanız, yalnızca o reposuna ait sahte istekler yapabilirler, bu nedenle verebilecekleri en büyük zarar, kendi reposunuzda plan/apply yapmak olacaktır.
Bunu önlemek için Bitbucket'ın IP adreslerini beyaz listeye alın (Çıkış IPv4 adreslerine bakın).
Eğer sunucuya erişim sağladıysanız veya en azından bir LFI elde ettiyseniz, okumanız gereken bazı ilginç şeyler var:
/home/atlantis/.git-credentials VCS erişim kimlik bilgilerini içerir
/atlantis-data/atlantis.db Daha fazla bilgi ile 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 Çevre değişkenleri
/proc/[2-20]/cmdline atlantis server komut satırı (hassas veriler içerebilir)
Herkesin kamuya açık pull request'lere yorum yapabileceği için, mevcut tüm güvenlik önlemleriyle bile, Atlantis'i kamuya açık reposlarda uygun güvenlik ayarları olmadan çalıştırmak hala tehlikelidir.
--allow-fork-prsEğer kamuya açık bir repoda çalışıyorsanız (bu önerilmez, yukarıya bakın) --allow-fork-prs ayarını yapmamalısınız (varsayılan olarak false) çünkü herkes kendi fork'undan sizin repoya bir pull request açabilir.
--repo-allowlistAtlantis, --repo-allowlist bayrağı aracılığıyla kabul edeceği repoların bir beyaz listesini belirtmenizi gerektirir. Örneğin:
Belirli repolar: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
Tüm organizasyonunuz: --repo-allowlist=github.com/runatlantis/*
GitHub Enterprise kurulumunuzdaki her repo: --repo-allowlist=github.yourcompany.com/*
Tüm repolar: --repo-allowlist=*. Korunan bir ağda olduğunuzda yararlıdır ama bir webhook secret'ı ayarlamadan tehlikelidir.
Bu bayrak, Atlantis kurulumunuzun kontrol etmediğiniz repolarla kullanılmadığından emin olur. Daha fazla bilgi için atlantis server --help komutuna bakın.
Eğer saldırganların kötü niyetli Terraform kodu ile pull request göndermesi tehdit modelinizde varsa, terraform apply onaylarının yeterli olmadığını bilmelisiniz. Kötü niyetli bir kodu terraform plan içinde çalıştırmak mümkündür, external veri kaynağını kullanarak veya kötü niyetli bir sağlayıcı belirterek. Bu kod, kimlik bilgilerinizi dışarı sızdırabilir.
Bunu önlemek için şunları yapabilirsiniz:
Sağlayıcıları Atlantis imajına dahil edin veya barındırın ve üretimde çıkışı reddedin.
Sağlayıcı kayıt protokolünü dahili olarak uygulayın ve kamuya açık çıkışı reddedin, böylece kayıt üzerinde yazma erişimine kimin sahip olduğunu kontrol edersiniz.
Sunucu tarafı repo yapılandırmanızı'nın plan adımını, yasaklı sağlayıcılar veya veri kaynakları veya izin verilmeyen kullanıcılardan gelen PR'ler ile doğrulamak için değiştirin. Bu noktada ek doğrulama da ekleyebilirsiniz, örneğin plan'ın devam etmesine izin vermeden önce PR'da "beğeni" gerektirmek. Conftest burada faydalı olabilir.
Atlantis, $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET ortam değişkenleri aracılığıyla ayarlanmış Webhook secret'ları ile çalıştırılmalıdır. --repo-allowlist bayrağı ayarlı olsa bile, bir webhook secret'ı olmadan, saldırganlar beyaz listede olan bir repo gibi davranarak Atlantis'e istek yapabilirler. Webhook secret'ları, webhook isteklerinin gerçekten VCS sağlayıcınızdan (GitHub veya GitLab) geldiğini garanti eder.
Eğer Azure DevOps kullanıyorsanız, webhook secret'ları yerine temel bir kullanıcı adı ve şifre ekleyin.
Azure DevOps, tüm webhook olaylarında temel kimlik doğrulama başlığı göndermeyi destekler. Bu, webhook konumunuz için HTTPS URL'si kullanmayı gerektirir.
Eğer webhook secret'ları kullanıyorsanız ama trafiğiniz HTTP üzerinden ise, webhook secret'ları çalınabilir. --ssl-cert-file ve --ssl-key-file bayraklarını kullanarak SSL/HTTPS'yi etkinleştirin.
Web hizmetinde kimlik doğrulamayı etkinleştirmek şiddetle önerilir. --web-basic-auth=true kullanarak BasicAuth'u etkinleştirin ve --web-username=yourUsername ve --web-password=yourPassword bayraklarını kullanarak bir kullanıcı adı ve şifre ayarlayın.
Ayrıca bunları ortam değişkenleri olarak da geçebilirsiniz ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=yourUsername ve ATLANTIS_WEB_PASSWORD=yourPassword.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
