← Back to list

Docker Bir Kale Değildir: Konteynır Güvenliğinde “Mount” Tehdidi ve Bir CTF Analizi

Siber güvenlik dünyasında genel bir yanılgı var: “Uygulamayı Docker içine aldık, sistemden izole ettik, artık güvendeyiz.” Ancak son…

Erdem Ceylan · 2026-04-16 19:39 · 0 claps · 1.7 min read
#docker #hacker #hackviser #datadome #xxe
Open on Medium ↗
Wiki topics: ☁️ · DevOps & Cloud

Docker Bir Kale Değildir: Konteynır Güvenliğinde “Mount” Tehdidi ve Bir CTF Analizi

Siber güvenlik dünyasında genel bir yanılgı var: “Uygulamayı Docker içine aldık, sistemden izole ettik, artık güvendeyiz.” Ancak son çözdüğüm Data Dome CTF senaryosu, en güvenli sanılan yapıların bile tek bir konfigürasyon hatasıyla nasıl yerle bir olabileceğini kanıtlar nitelikteydi. Bu yazıda, bir XXE zafiyetiyle başlayan ve Docker’dan host makineye sıçrayışla (Docker Breakout) biten o kritik süreci ve Docker güvenliğindeki o büyük boşluğu inceleyeceğiz.

1. İlk Giriş: Basit Bir XML Hatası

Her şey masum görünen bir /api/data uç noktasındaki XXE (XML External Entity) zafiyetiyle başladı. Uygulama, dışarıdan gelen XML verisini kontrolsüzce işliyordu. Bu açıklık sayesinde sistemdeki dosyaları okumakla kalmadık, PHP'nin expect modülü sayesinde içeride komut yürütebilir (RCE) hale geldik.

Ancak asıl hikaye, sistemde root yetkisine ulaştığımızda başladı.

2. İllüzyon: “Root Oldum Ama Neredeyim?”

Sistemde getcap komutuyla php5 üzerindeki yetki tanımlarını sömürerek root yetkisini aldım. Fakat bir gariplik vardı; ls -la /root yaptığımda dosya sistemi bomboş görünüyordu.

İşte o an fark ettim: Docker konteynırının içindeydim. Çoğu saldırgan için bu bir “duvar” gibi görünebilir. Evet, içeride root yetkimiz vardı ama bu yetki sadece sanal, izole bir dünya içindeydi. Host makinenin dosyalarına, kullanıcılarına ve gerçek verilere hâlâ uzaktık. Ta ki o ölümcül yapılandırma hatasını bulana dek.

3. Büyük Hata: /dev/sda1'in Paylaşılması

Docker güvenliğinde en büyük risklerden biri, host makineye ait kaynakların konteynıra “gereğinden fazla” veya “bilinçsizce” sunulmasıdır. Senaryoda yaptığım incelemede, host makinenin fiziksel disk bölümünün (/dev/sda1) konteynır içinden erişilebilir olduğunu gördüm.

Bu, bir hapishane hücresindeyken gardiyanın anahtarını masanın üzerinde unutması gibi bir şeydi.

Bash

mkdir -p /mnt/host_root
mount /dev/sda1 /mnt/host_root

Sadece bu iki satırlık komutla Docker’ın o meşhur “izolasyon” duvarı yıkıldı. Host makinenin tüm dosya sistemi /mnt/host_root altına serildi. Artık sadece bir konteynır kullanıcısı değil, ana makinenin tüm sırlarına (SMTP şifreleri, kurban listeleri, config dosyaları) sahip olan kişiydim.

4. Docker Gerçekten Güvenli mi?

Bu senaryodan çıkarmamız gereken ders şu: Docker bir güvenlik aracı değil, bir paketleme ve dağıtım aracıdır. Eğer:

  • Konteynıra gereksiz ayrıcalıklar (--privileged) verirseniz,
  • Host makinenin disklerini veya kritik soketlerini (docker.sock gibi) içeriye mount ederseniz,
  • Sistemdeki capabilities ayarlarını doğru yapılandırmazsanız,

Konteynırınız sadece saldırganın işini biraz yavaşlatan bir kağıttan kaplan olur.

Son Söz

Data Dome senaryosunda da gördüğümüz gibi; XXE ile içeri giren bir saldırgan, eğer sisteminizde yanlış bir “mount” işlemi varsa dakikalar içinde tüm sunucuyu ele geçirebilir. Docker kullanmak sizi otomatik olarak güvenli kılmaz; güvenliği sağlayan şey, izolasyonun sınırlarını ne kadar dar tuttuğunuzdur.

URL: https://github.com/Erdemcey/CTF_rapor/blob/main/Data%20Dome/Write_Up.md


메타데이터
post_id
6d09125699a4
slug
docker-bir-kale-değildir-konteynır-güvenliğinde-mount-tehdidi-ve-bir-ctf-analizi-6d09125699a4
url
https://medium.com/@e.erdem.e25/docker-bir-kale-de%C4%9Fildir-konteyn%C4%B1r-g%C3%BCvenli%C4%9Finde-mount-tehdidi-ve-bir-ctf-analizi-6d09125699a4
canonical_url
https://medium.com/@e.erdem.e25/docker-bir-kale-de%C4%9Fildir-konteyn%C4%B1r-g%C3%BCvenli%C4%9Finde-mount-tehdidi-ve-bir-ctf-analizi-6d09125699a4
author_url
https://medium.com/@e.erdem.e25
status
ok
fetched_at
2026-06-14 11:28:49