Merhaba, önceki dersimizde karmaşık sistemler için gelişmiş Veri Akış Diyagramları (DFD) oluşturarak bir saldırganın gözünden sistemin haritasını çıkarmayı öğrendik. Artık elimizde veri akışlarını, süreçleri ve veri depolarını gösteren detaylı bir harita var. Bu derste, bu harita üzerindeki en kritik coğrafi özellikleri, yani güven sınırlarını (trust boundaries) analiz etmeye odaklanacağız. Bu sınırlar, bir sistemin farklı güven seviyelerine sahip parçalarını ayıran çizgilerdir ve bir hata avcısı için en verimli avlanma sahalarını oluştururlar.
Güvenli mimari tasarımı konusundaki derin tecrübeniz, güven sınırlarının ne kadar temel bir konsept olduğunu size zaten göstermiştir. Ancak biz bu derste, bu sınırlara bir savunmacının değil, bir saldırganın gözüyle bakacağız. Amacımız sadece sınırları çizmek değil, bu sınırlardaki örtük, zayıf veya tamamen bozuk güven varsayımlarını tespit ederek yüksek değerli saldırı yüzeylerini ortaya çıkarmaktır. Verinin bir güven sınırını aştığı her nokta, bir "gümrük kontrolü" olarak düşünülebilir. Bizim görevimiz ise bu kontroldeki her türlü zaafiyeti bulmaktır.
Güven Sınırlarını Anlamak
Önceki derste oluşturduğumuz DFD'ler, sistemin bileşenleri arasındaki veri hareketlerini gösterir. Güven sınırı ise bu DFD üzerinde, verinin geçtiği anda güven seviyesinin değiştiği bir çizgidir. Bir verinin bir bileşenden diğerine geçtiği her yerde, alıcı bileşen, gönderen bileşene ve gönderdiği veriye belirli bir düzeyde güvenir. İşte bu güvenin seviyesindeki her değişim, bir güven sınırını işaret eder.
Prabh Nair'in "Practical Threat Modeling" videosunda bu konsept görsel olarak çok güzel açıklanıyor. Videoyu izleyerek güven sınırlarının DFD üzerinde nasıl gösterildiğini ve temel mantığını tekrar hatırlayalım.
Practical Threat Modeling Master Class: STRIDE-Powered
Bu video, DFD'ler üzerinde güven sınırlarının nasıl çizildiğini ve farklı ağ bölgeleri (Internet, DMZ, Internal) arasındaki güven ilişkilerinin nasıl modellendiğini basit bir örnekle gösteriyor.
Lütfen videonun trust boundaries bölümünü izleyin. Konuşmacının "Internet Boundary", "DMZ Boundary" ve "Internal Network" gibi sınırları nasıl tanımladığına ve bu sınırların, farklı güven seviyelerindeki bileşenleri (örneğin, herkese açık bir web sunucusu ile dahili bir veritabanı) birbirinden nasıl ayırdığına dikkat edin.
Bir saldırgan için güven sınırı, zayıf noktaların yoğunlaştığı bir fay hattı gibidir. Bir veri akışı ne zaman bir sınırı geçerse, STRIDE tehditlerinin her biri için potansiyel bir zafiyet ortaya çıkar:
- Spoofing: Sınırın diğer tarafındaki bileşenin kimliğini taklit edebilir miyim?
- Tampering: Sınırdan geçen veriyi değiştirebilir miyim?
- Repudiation: Sınırı geçen bir işlemi gerçekleştirdiğimi inkar edebilir miyim?
- Information Disclosure: Sınırı geçen veride hassas bilgi sızdırılıyor mu?
- Denial of Service: Sınırı geçen trafiği kullanarak diğer taraftaki hizmeti erişilmez kılabilir miyim?
- Elevation of Privilege: Düşük güvenli bir bölgeden, yüksek güvenli bir bölgedeki ayrıcalıklı bir işlemi tetikleyebilir miyim?
Modern Mimarilerde Güven Sınırlarını Belirlemek
Basit bir "İnternet -> DMZ -> İç Ağ" modellemesi, günümüzün karmaşık mimarilerini analiz etmek için yetersiz kalır. Saldırı yüzeyini doğru bir şekilde haritalamak için çok daha granüler düşünmeliyiz.
Mikroservis Mimarileri
Mikroservisler, saldırı yüzeyini ve dolayısıyla güven sınırlarının sayısını katlanarak artırır. "Dahili ağdaki her şey güvenlidir" varsayımı, bu mimarilerdeki en tehlikeli yanılgılardan biridir.
Her bir servisler arası (service-to-service) iletişim, bir güven sınırının geçilmesi anlamına gelir. Bu iletişim genellikle REST API'ler veya gRPC üzerinden gerçekleşir ve şu soruları sormamızı gerektirir:
- Servisler birbirlerini nasıl doğruluyor? (mTLS, JWT, API anahtarları?)
- Bir servisten diğerine giden isteklerdeki yetkilendirme nasıl kontrol ediliyor?
- Bir servisin çökmesi veya ele geçirilmesi, diğer servisleri nasıl etkiler?
Aşağıdaki makale, mikroservis mimarilerinde API'lere odaklanarak tehdit modellemesinin neden bu kadar kritik olduğunu ve güven sınırlarının bu analizdeki merkezi rolünü vurgulamaktadır.
Threat Modeling for APIs in microservices architectures
Bu makale, mikroservislerdeki API'lerin geleneksel monolitik sistemlerden nasıl farklılaştığını ve bunun güvenlik için ne anlama geldiğini açıklıyor. Özellikle güven varsayımlarının (trust assumptions) önemine dikkat çekiyor.
Lütfen makaledeki API'ye özgü tehdit modellemesi ihtiyacı bölümünü okuyun. Yazarların "Her API uç noktasının kendi kimlik doğrulama şeması, veri modeli ve güven varsayımları olabilir" ifadesine odaklanın. Ardından, DFD oluşturma bölümünü inceleyin. Burada, DFD'lerin "güven sınırlarını vurgularken" verinin akışını nasıl yakaladığını ve bu sınırların kesişim noktalarının (unauthenticated API calls, misconfigured TLS vb.) zafiyetleri nasıl ortaya çıkardığını göreceksiniz. Son olarak, STRIDE analizi bölümü, bu tehditlerin sınırlarda nasıl uygulanabileceğine dair (örneğin, servisler arası iletişimde mTLS kullanılmıyorsa Spoofing) somut örnekler sunar.
IoT (Nesnelerin İnterneti) Mimarileri
IoT sistemleri, fiziksel cihazlardan bulut servislerine uzanan çok katmanlı ve dağıtık bir yapıya sahiptir. Bu da çok sayıda belirgin güven sınırı yaratır.
Bu tür bir mimarideki her sınır geçişi, kendine özgü riskler barındırır:
- Device <-> Field Gateway: Cihazların kimliği doğrulanıyor mu? Fiziksel olarak ele geçirilebilirler mi? İletişim şifreli mi?
- Field Gateway <-> Cloud Gateway: Ağ geçidi, binlerce cihazdan gelen veriyi toplar. Bu geçidin kendisi bir saldırı hedefidir.
- Cloud Gateway <-> Services Zone: Bulut altyapısı, arka uç servisleri ve veritabanları arasındaki iletişim. Yanlış yapılandırılmış IAM rolleri veya ağ kuralları burada kritik zafiyetlere yol açabilir.
Pratik Bir Örnek: Mikroservislerde STRIDE Analizi
Güven sınırlarını belirledikten sonra, bu sınırlardan geçen her veri akışına STRIDE uygulamak, tehditleri sistematik olarak ortaya çıkarmanın en etkili yoludur. Aşağıdaki çalışma, açık kaynaklı bir e-ticaret uygulaması üzerinde bu süreci adım adım göstermektedir.
[PDF] Application of the STRIDE framework in a microservice application ...
Bu makale, gerçek bir mikroservis uygulaması için DFD oluşturma, güven sınırlarını tanımlama ve Microsoft Threat Modeling Tool kullanarak STRIDE analizi yapma sürecini baştan sona belgeliyor. Sonuçlar, hangi servislerin hangi tehditlere karşı en savunmasız olduğunu gösteren bir matris ile özetleniyor.
Lütfen "METHODOLOGY" başlığı altındaki metodoloji adımlarını gözden geçirin. Ardından "Visual representation of the application architecture" başlığı altındaki Figure 2 ve Figure 3'ü dikkatlice inceleyin. Figure 3'te, tüm iç mikroservisleri ve veritabanını çevreleyen tek bir büyük güven sınırı (trust boundary) nasıl çizildiğini ve dış varlıkların (kullanıcı, ödeme sistemi vb.) bu sınırın dışında nasıl konumlandırıldığını göreceksiniz. Bu sınırlara ilişkin açıklama paragrafını okuyun. Son olarak, "RESULTS" başlığı altındaki Table 1: STRIDE threat exposure matrix per microservice tablosunu analiz edin. Bu tablo, her bir mikroservisin hangi STRIDE kategorilerindeki tehditlere maruz kaldığını özetleyerek, analizimizin nihai hedefini, yani yüksek riskli bileşenleri ve saldırı vektörlerini belirlemeyi somutlaştırır.
Sınır İhlalleri: Gerçek Dünya Örnekleri
Teoriyi bir kenara bırakıp bu sınır ihlallerinin gerçek dünyada nasıl göründüğüne bakalım. DEF CON'da sunulan aşağıdaki "savaş hikayeleri", bozuk veya gözden kaçan güven varsayımlarının nasıl kritik zafiyetlere yol açtığını mükemmel bir şekilde göstermektedir. Bu örnekler, bir hata avcısının düşünce yapısını anlamak için paha biçilmezdir.
DEF CON 32 - Top War Stories from a TryHard Bug Bounty Hunter -Justin Rhynorater Gardner
Bu sunum, deneyimli bir hata avcısı olan Justin Gardner'ın karşılaştığı en yaratıcı ve etkili zafiyetlerden bazılarını anlatıyor. Her bir vaka, farklı bir güven sınırı ihlali türünü sergiliyor.
Aşağıdaki bölümleri dikkatle izleyin ve her bir vakada hangi güven sınırının ve hangi örtük güven varsayımının ihlal edildiğini düşünün: Nginx 403 Bypass: Bu örnekte, bir Nginx reverse proxy ile arkasındaki backend sunucusu arasında bir güven sınırı vardır. Proxy'nin belirli bir URL yolunu engellemesi gerekiyordu. Bozuk güven varsayımı şuydu: Backend sunucusu, kendisine ulaşan tüm isteklerin proxy tarafından zaten filtrelendiğini varsayıyordu. Saldırgan, URL kodlama hilesiyle proxy filtresini atlayarak bu varsayımı yıktı ve hassas verilere ulaştı. Arbitrary Account Takeover via Docs: Bu vakada, bir OTP (tek kullanımlık şifre) tabanlı uygulamada, dökümantasyonda unutulmuş şifre tabanlı bir API uç noktası keşfediliyor. Bozuk güven varsayımı: Bu "dahili" API'nin kullandığı kimlik bilgilerinin (credentials) güvenli olduğu ve sadece meşru istemciler tarafından bilindiği varsayılıyordu. Ancak bu bilgiler JS dosyalarında bulunuyordu ve bu sayede herhangi bir kullanıcının hesabı, parola ne olursa olsun ele geçirilebiliyordu. Perforce to RCE: Bir masaüstü oyun geliştirme uygulaması, versiyon kontrolü için Perforce protokolünü kullanıyor. Güven sınırı, uygulama (istemci) ile Perforce sunucusu arasındadır. Bozuk güven varsayımı: İstemci, sunucudan gelen komutlara körü körüne güveniyordu. Saldırgan, sahte bir sunucu kurarak istemciye "şu dosyayı şu yola yaz" komutunu gönderdi. Path traversal ile birleştirildiğinde, bu komut sistemdeki herhangi bir yürütülebilir dosyanın üzerine yazarak RCE'ye yol açtı. Bu, protokol seviyesinde bir güven ihlalinin klasik bir örneğidir. IoT Router RCE: Bu örnek, birden çok güven sınırını aşan bir saldırı zincirini gösteriyor: Cloud Provider <-> Router <-> gRPC Service <-> dhcpd Config. Bozuk güven varsayımı: dhcpd yapılandırma dosyasını oluşturan betik, gRPC servisinden gelen girdinin güvenli olduğunu ve "escape" edilmesi gerekmediğini varsayıyordu. Bu varsayımın ihlali, bir "configuration file injection" zafiyetine ve sonuç olarak RCE'ye neden oldu.
Sonuç ve Sonraki Adımlar
Bu derste, DFD haritalarımız üzerinde en değerli saldırı yüzeylerinin bulunduğu yerler olan güven sınırlarını analiz etmeyi öğrendik. Temel çıkarımlarımız şunlardır:
- Sınırlar Saldırı Yüzeyidir: Bir sistemdeki en kritik zafiyetler, genellikle farklı güven seviyelerine sahip bileşenler arasındaki kesişim noktalarında, yani güven sınırlarında bulunur.
- Varsayımları Sorgula: Bir hata avcısı olarak işimiz, bileşenler arasındaki örtük veya açık güven varsayımlarını bulmak ve bunları yıkmaya çalışmaktır. "Bu servis dahili ağda, o yüzden güvenli" veya "Bu veri zaten ön katmanda doğrulandı" gibi varsayımlar, en büyük zafiyetlerin habercisidir.
- Sistematik Analiz: DFD üzerindeki her bir sınır geçişi için STRIDE metodolojisini uygulamak, potansiyel tehditleri kapsamlı bir şekilde belirlemenin en etkili yoludur.
- Gerçek Dünya İlhamı: En yaratıcı saldırılar, genellikle protokollerin, mimarilerin ve bileşenlerin birbirine nasıl güvendiğine dair derin bir anlayıştan doğar.
Artık bir sistemin veri akış haritasını (DFD) nasıl çıkaracağımızı ve bu harita üzerindeki en kritik noktaları (güven sınırları) nasıl analiz edeceğimizi biliyoruz. Bir sonraki dersimizde, bu analizimizi daha da derinleştireceğiz. STRIDE kategorilerinin her birini, ileri düzey ve incelikli istismar senaryolarıyla ilişkilendirerek, her bir tehdit türü için spesifik ve yaratıcı zafiyet sınıflarını nasıl avlayacağımızı öğreneceğiz.