Sahte Loglarla İzleme Sistemlerini Manipüle Etmek

Bir  kuruluşun siber güvenliğini sağlamak için sahip olduğu sistemlerin loglarının toplanması, analiz edilmesi ve bunun sürekli olarak tekrarlanması gerekir. Sürecin sürekliliğini sağlamak amacıyla izleme sistemleri kurulabilir. İçeride olup bitenlerin takip ediliyor olması saldırganların hareket alanını azaltmaktadır. Fakat oluşturulacak sahte loglarla sistemi yanıltmak mümkündür.

Sahte log üretmenin amacı hedefin yanlış veri okumasını, mevcut verilerini okuyamamasını, log toplamasını aksatmak olabilir. 

Başarılı bir sahte log üretme girişimi 2 ana aşamadan oluşmaktadır:

  • Log formatının belirlenmesi
  • Logların oluşturulması

Gereksinimler:

Ağ içerisinde ele geçirilmiş cihaz

Log Formatının Belirlenmesi

Yapılacak saldırıda üretilen sahte logların işe yaraması için hedef sistemin kullandığı formatta gönderilmelidir. Örneğin LEEF log formatını kullanan bir sisteme CEF formatında log göndermek ayrıştırma (parsing) problemine yol açacaktır. Formatı bulmak için kullanılabilecek yöntemler:

Uygulamanın tespit edilmesi

Uygulamanın tespit edilmesinin ardından uygulama hakkında internet araştırması yapılabilir veya uygulamayı yükleyip log akışı izlenebilir

Ağ trafiğinin izlenmesi

Loglar ağ üzerinde şifrelemesiz olarak aktarılıyorsa log formatı belirlenmiş olacaktır

Logların Oluşturulması

Bir önceki aşamada elde edilen bilgi doğrultusunda sahte loglar oluşturulur ve hedef sisteme gönderilir.

Örnek Senaryo

Aşağıdaki basit topolojiye sahip bir hayali kurumu örnek alalım.

Ağ içerisinde istemcilerden logları toplayan bir log sunucusu var, logların toplanması için Splunk ürünü kullanılıyor. Toplanan loglar izleme sunucusuna aktarılıp korelasyonu sağlanıyor ve analistlerin güvenlik tehditlerini inceleyebilmesi için alarmlar oluşturuluyor.

Saldırgan bir şekilde ağa dahil oluyor ve saldırının 1. aşaması olan log formatını bulmak için bilgi toplamaya başlıyor. İlk olarak log sunucusuna port taraması yapıyor.

Taramanın ardından sunucu içerisinde Splunk kurulu olduğunu keşfediyor. Açık olan “514” ve “1234” portlarını log toplama için kullanıldığını düşünerek ağ trafiğini dinlemeye başlıyor. Hemen ardından “1234” portu üzerinden TCP paketleri geçtiğini görüyor.


Paket detaylarına geldiğinde iletişimin şifreli olmadığını görüyor ve içeriğin tamamını okuyarak log formatını öğrenmiş oluyor.

Formatı öğrenen saldırgan 2. aşamaya geçerek sahte logları log sunucusuna göndermeye hazırlanıyor. Bu aşamada sahte logların amaçları değişkenlik gösterebilir. Örneğin çok sayıda log gönderip sunucusunun veri depolama alanını doldurup yeni log alamaz hale getirmek, sahte saldırı logları ile analistin önüne yanıltıcı alarmlar düşürmek, anlık çok yüksek sayıda log gönderip logların işlenmesini geciktirmek amaçlardan biri olabilir.

Saldırgan, gereksiz oluşan alarmlarla analistin dikkatini dağıtmayı düşünerek Web sunucusuna SQL injection denemelerinin yapıldığını gösteren formata uygun sahte log hazırlıyor.

192.168.131.23 – – [19/Apr/2020:11:33:23 -0700] “GET /read.php?id=1%27%20UNION%20ALL%20SELECT%20LOAD_FILE(%27/etc/passwd%27) HTTP/1.1” 404 208 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36”

Yukarıdakine benzer çeşitli loglar hazırlayıp log sunucusunun “1234” portuna gönderiyor.

Splunk arayüzünden arama yapıldığında logun işlendiği görülür.

Alınabilecek Önlemler

  • Whitelist uygulayıp sadece izni olan adreslerin log sunucusuna bağlanabilmesi
  • Anlık log akış değerlerinin izlenip anormal artışlar/azalışlarda uyarı oluşturulması
  • Log transferinin şifrelenmiş bir şekilde yapılması

Tek Yorum

  1. Safa demiş ki:

    Merhabalar,
    Güzel bir yazı olmuş. Her zaman ilk etkisiz hale getirilmek istenen bekçidir. Ancak bilinmelidir ki, bir şekilde geleceğiniz yöntemler analistler ve zafiyet tarama ile korelasyon ya da davranış analizine yansıyacaktır. Diyelim ki geçtiniz, yapmış olduğunuz ilk port taraması korelasyon sonucunda, ilgili birime haber verecektir. SOAR yapısı olan bir mimari otomatik aksiyon alacaktır. SOAR yapısı olmayan mimari ise, Siem üzerinden basit aksiyonlar ile sizi durdurabilecektir. Burada en önemli durum, iç trafiğin ya firewall üzerinden geçirilerek trafik takibi yapılması ya da Flow datasi veren bir switch kullanılmasıdır. Anlık log akışında artım oranları ya da log parse edilememesi durumu uyarı olarak default ayarlanmalidir. Baska bir durum ise parser uymuyorsa loglari silebilirsiniz. Syslog ile gelen loglari direk Siem sistemi üzerinde konumlandırmayabilirsiniz. Sonuç olarak ortamınıza göre Siem sayesinde bir çok yöntem kullanarak önlenebilir bir aksiyordur. Bu durumda başlangıç seviyesinde düşünülmesi gerekmektedir.

    25 Nisan 2020
    Yanıtla

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir