Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 58

Zafiyet Varyant Tespiti ve Doğrulaması

Recommended resources

Merhaba! Bir önceki dersimizde, tek bir zafiyet bulgusundan yola çıkarak onun temel nedenini soyutlamayı ve "varyant analizi" kavramını öğrendik. Bir hatayı değil, bir hata sınıfını hedeflemenin, uzman bir denetçinin zihniyetini nasıl şekillendirdiğini gördük. Artık "ne bulduğumuzdan" çok, "neden bulduğumuza" odaklanıyoruz.

Bu derste ise soyutladığımız bu zafiyet desenlerini alıp onları birer av haritası gibi kullanacağız. Bugünkü amacımız, soyutlanmış zafiyet desenini kullanarak kod tabanındaki tüm potansiyel varyantları bulmak ve doğrulamaktır. Yani, teoriden pratiğe geçerek, bir kök nedenin tüm yansımalarını kod tabanında sistematik olarak nasıl avlayacağımızı ve bulunan her potansiyel adayın gerçekten bir zafiyet olup olmadığını nasıl doğrulayacağımızı öğreneceğiz.

Avcının Araç Seti: Sistematik Varyant Arama

Soyut bir zafiyet desenini elinize aldığınızda, göreviniz bu desene uyan tüm kod parçacıklarını bulmaktır. Bu, rastgele gezinmekten çok daha fazlasını gerektiren sistematik bir süreçtir. İşte kullanabileceğiniz temel yöntemler:

  1. Anahtar Kelime ve Metin Tabanlı Arama (Grepping): En basit ve en hızlı yöntemdir. grep, ack gibi komut satırı araçları veya IDE'nizin metin arama fonksiyonu ile çalışır. Önemli olan doğru anahtar kelimeleri seçmektir:

    • Tehlikeli Fonksiyon İsimleri: unserialize(), eval(), system(), dangerouslySetInnerHTML, pickle.loads().
    • Savunmasız Desenler: SELECT ... WHERE id=' gibi metin parçaları.
    • İlgili API Çağrıları: save_config, render_template_string, Class.forName.

  2. IDE Destekli Analiz: Modern IDE'ler (VSCode, IntelliJ, PyCharm vb.) metin aramasından çok daha fazlasını sunar.

    • "Find Usages" / "Kullanımları Bul": Belirli bir fonksiyonun (sanitize_string gibi) kod tabanında nerelerde çağrıldığını anında listeler. Bu, basit bir metin aramasından daha güvenilirdir çünkü fonksiyonun gerçekten çağrıldığı yerleri bulur.
    • "Call Hierarchy" / "Çağrı Hiyerarşisi": Belirli bir fonksiyona hangi fonksiyonların yol açtığını (yukarı doğru) veya bu fonksiyonun hangi diğer fonksiyonları çağırdığını (aşağı doğru) gösteren bir ağaç yapısı sunar. Bu, bir zafiyetin kaynağını veya etkisini izlemek için paha biçilmezdir.

  3. Manuel Veri ve Kontrol Akışı Analizi: Bu, "uzman gözünü" en çok kullandığınız yerdir. Bir giriş noktasından (entry point) tehlikeli bir hedefe (sink) giden veri akışını veya belirli bir kod bloğunu tetikleyen kontrol akışını manuel olarak takip edersiniz.

Önceki derste incelediğimiz Schlix CMS örneğinde, araştırmacının bu "geniş ağ atma" tekniğini nasıl kullandığını hatırlayalım.

Schlix CMS Kaynak Kod Analizi ve 0day Zafiyet Araştırmacılığı

Bu video, geniş kapsamlı bir varyant avının nasıl başlatıldığını pratik olarak gösteriyor. Konuşmacı, belirli anahtar kelimelerle tüm kod tabanını tarayarak potansiyel zafiyet noktalarını hızlıca listeliyor.

Lütfen videoda bu bölümü izleyin. Konuşmacının select kelimesini aratarak kod tabanında 223 tane "native" SQL sorgusu bulduğuna dikkat edin. Bu, "SQL enjeksiyonuna neden olabilecek tüm ham sorguları bul" desenini uygulamanın en basit yoludur. Ardından burada yaptığı gibi unserialize anahtar kelimesini arayarak potansiyel "güvensiz deserialization" giriş noktalarını nasıl avladığını gözlemleyin.

Gördüğünüz gibi, select veya unserialize gibi genel ama tehlikeli anahtar kelimelerle yapılan basit bir arama bile, analizinizi odaklayacağınız onlarca veya yüzlerce potansiyel hedefi anında önünüze serebilir. Bu, avın ilk adımıdır.

Doğrulama Adımı: Her Desen Bir Zafiyet Değildir

Bir desene uyan bir kod parçası bulmak, bir zafiyet bulmakla aynı şey değildir. Bu sadece bir adaydır. Uzmanlığınız, bu adayın gerçekten istismar edilebilir olup olmadığını doğrulama sürecinde ortaya çıkar. Doğrulama, bağlamı, kısıtlamaları ve karşı önlemleri analiz etmektir.

Önceki dersteki SQL enjeksiyonu desenini hatırlayalım: "sanitize_string fonksiyonu, dizi (array) parametresi aldığında etkisiz kalıyor."

  • Av: sanitize_string fonksiyonuna yapılan tüm çağrıları bul.
  • Doğrulama:
    1. Bu çağrıya gelen veri kullanıcı kontrolünde mi?
    2. Kullanıcının dizi göndermesine izin veren bir HTTP parametre yapısı var mı (param[]=... gibi)?
    3. Araya giren ve saldırıyı bozan bir mekanizma var mı?

Videoda, username[]=... saldırısının, daha sonra çağrılan bir trim() fonksiyonu yüzünden PHP hatasına neden olduğunu ve exploit'i engellediğini görmüştük. trim() fonksiyonu bir dizi beklememektedir ve bu bir kısıtlama (constraint) görevi görür. İşte bu, doğrulama adımının kritik önemini gösterir. Aday bulundu, ancak doğrulanamadı. Bu, zafiyet olmadığı anlamına gelmez; sadece o yoldan istismar edilemediği anlamına gelir. Belki trim fonksiyonunun çağrılmadığı başka bir kod yolu aynı zafiyeti istismar edilebilir kılabilir.

Vaka Çalışması: Desenleri Birleştirerek Varyant Avı (Python)

Şimdi, daha karmaşık ve sizin uzmanlık alanınız olan Python'u içeren bir örneğe bakalım. Bu vaka, tek bir zafiyet deseninin varyantlarını bulmaktan bir adım öteye geçerek, iki farklı zafiyet desenini birleştirerek bir istismar zinciri oluşturma sürecini de içeriyor.

Aşağıdaki video, Sonarsource'un düzenlediği bir CTF (Capture The Flag) yarışmasındaki bir sorunun çözümünü içeriyor. Odak noktamız, araştırmacının zafiyetleri nasıl adım adım bulduğu, soyutladığı ve birleştirdiği olacak.

Round #3 - Ofansif Kaynak Kod Analizi ! Sonarsource Challenge 2022

Bu video, Python/Flask tabanlı bir uygulamada Dizin Geçişi (Directory Traversal) ve Sunucu Taraflı Şablon Enjeksiyonu (SSTI) zafiyetlerinin nasıl bulunduğunu ve bir RCE (Uzaktan Kod Çalıştırma) elde etmek için nasıl birleştirildiğini detaylı bir şekilde gösteriyor.

Lütfen videoda bu bölümü izleyin. Konuşmacının analiz sürecini adım adım takip edin: Desen 1 (Dizin Geçişi): Bu kısımda, username parametresi üzerinde hiçbir doğrulama olmadığını ve dosya yolu oluşturmak için kullanıldığını fark ediyor. ../../ gibi karakterler kullanarak dosya sisteminde gezinebileceği desenini soyutluyor. Kısıtlama Analizi: Burada, kodun uygulama dizininin dışına çıkmayı engelleyen bir is_relative_to kontrolü içerdiğini görüyor. Bu, dizin geçişinin sınırlı olduğunu, ancak uygulama içindeki dosyalara hala erişilebileceğini gösteriyor. Desen 2 (Şablon Enjeksiyonu): Bu bölümde, kullanıcıdan alınan note verisinin bir dosyaya yazıldığını fark ediyor. Zinciri Kurma (Varyant Avı): Konuşmacı şimdi şu soruyu soruyor: "Dizin geçişi zafiyetini kullanarak, içeriğini kontrol edebildiğim bir note verisini, uygulamanın daha sonra şablon olarak işleyeceği bir dosyaya yazabilir miyim?" İstismar: Bu son kısımda, tüm parçaları birleştiriyor. username olarak ../templates/error.html gibi bir değer vererek error.html şablon dosyasının üzerine yazmayı hedefliyor. Ardından note parametresiyle SSTI payload'unu bu dosyaya yazıyor. Son olarak, sistemin error.html dosyasını render etmesini tetikleyerek kodunu çalıştırıyor.

Bu vaka, varyant analizinin ve doğrulamanın ne kadar dinamik bir süreç olduğunu gösteriyor:

  • Soyutlama: "Kullanıcı girdisi dosya yolu oluşturuyor" (Dizin Geçişi) ve "Kullanıcı girdisi şablon olarak yorumlanabilecek bir yere yazılıyor" (Potansiyel SSTI).
  • Av: Dizin geçişi desenini kullanarak hangi "ilginç" dosyaların üzerine yazabilirim? Cevap: Şablon dosyaları.
  • Doğrulama ve Kısıtlama Analizi: is_relative_to kontrolü tam bir dizin geçişini engellese de, uygulama içindeki kritik dosyaların üzerine yazmayı engellemiyor. Bu kısıtlama, saldırının yönünü değiştiriyor ama onu imkansız kılmıyor.

İstismar Zincirlerini Görselleştirmek

Yaptığımız bu işlem, yani birden fazla bulguyu (varyantı) bir araya getirerek daha büyük bir etki yaratma süreci, "İstismar Zinciri" (Exploit Chain) olarak adlandırılır. Siber güvenlik olay raporlarında gördüğünüz karmaşık saldırı akış şemaları, tam olarak bu tür manuel kod analizi ve mantık yürütme süreçlerinin bir sonucudur.

Bu diyagram, bir React uygulamasındaki tek bir RCE zafiyetinin (Exploitation), farklı saldırgan grupları tarafından nasıl çeşitli istismar sonrası faaliyetler (Post-Exploitation Activities) için bir başlangıç noktası olarak kullanıldığını gösteriyor. Her bir "campaign" (nuts, C3Ploit vb.), bulunan ilk varyantın farklı bir şekilde istismar edilmesidir.
Bu görsel ise 8 aşamalı bir saldırı zincirini özetliyor. Başlangıçtaki yürütmeden (Initial execution) komuta-kontrol sunucusuyla iletişime (C&C server) kadar her adım, bir önceki adımın başarısı üzerine kuruludur. Kod denetiminde bulduğumuz her küçük "gadget" veya "primitive", bu zincirin potansiyel bir halkası olabilir.

Bu görseller, kod seviyesinde yaptığımız varyant avcılığının, gerçek dünyadaki büyük siber saldırıların temelini nasıl oluşturduğunu göstermektedir.

Sonuç

Bugünkü dersimizde, bir önceki derste öğrendiğimiz soyutlama becerisini pratiğe döktük. Artık bir zafiyet desenini sadece tanımlamakla kalmıyor, aynı zamanda bu deseni kod tabanında sistematik olarak avlayıp, bulduğumuz adayları titizlikle doğrulayabiliyoruz.

Anahtar Çıkarımlar:

  • Sistematik Av: Varyant arama, grep gibi basit araçlardan IDE'nin gelişmiş özelliklerine kadar farklı teknikler gerektiren disiplinli bir süreçtir.
  • Doğrulama Kritiktir: Bir desene uyan her kod parçası zafiyet değildir. Bağlamı, kısıtlamaları ve araya giren kontrolleri analiz etmek, yanlış pozitifleri elemek için zorunludur.
  • Zincirleme Mantığı: Bazen bir zafiyetin gerçek potansiyeli, başka bir zafiyetle birleştirildiğinde ortaya çıkar. Farklı desenleri bir araya getirerek istismar zincirleri kurmak, ileri seviye bir yetkinliktir.

Bu modülün sonuna yaklaşırken, bulguları birleştirme yeteneğinizi daha da ileri taşıyacağız. Bir sonraki ve son dersimizde, bu istismar zincirlerini oluşturmanın yapı taşları olan "gadget" ve "primitive" kavramlarını resmileştireceğiz. Düşük etkili gibi görünen bilgi sızıntılarını veya kısmi kontrol sağlayan açıkları nasıl tespit edip, bunları birleştirerek tam teşekküllü bir istismar senaryosu ve ikna edici bir Kavram Kanıtı (PoC) anlatısı oluşturacağımızı ele alacağız.