Tarih : 29 Ocak 2009
Sistem sizma denetimlerinde hep uzun istekler listesi goruruz, istenmeyen listesi ise tek bir maddeden olusur, servis engelleme saldirilari. Bu yazi servis engelleme saldirilarinin istenmemesi ve yan etkilerini tartismak icin hazirlanmistir. Normal bir denetim asamasinda dahi bu karara ne kadar bagli kalinabildigi ve kararin etkilerine olabildigince deginmeye calistim. Servis engelleme denetimleri uzerine yaptigim bazi calismalar, denetim asamalari ve ozellikle servis engelleme yapilmasi gereken durumlari -vakit buldukca- daha sonraki yazilarda aktarmaya calisacagim.
Bir sistem, ag veya uygulamanin, gecici veya kalici olarak devre disi kalmasini saglayan saldiri cesitleri servis engelleme saldirilari (DOS) olarak anilmaktadir. Servis engelleme saldirilari cok sayida sistem tarafindan yapiliyorsa -genellikle otomatize olarak ele gecirilmis sistemler- dagitik servis engelleme saldirilari (DDOS) olarak anilmaktadir.
Sistem sizma denetimi surecinde servis engelleme belki de en hassas konulardan biridir. Denetim sonucunda buldugunuz veya bulamadiginiz guvenlik aciklari, durmasina sebep oldugunuz bir servis kadar dikkat cekmeyecektir. Soz konusu dikkat cekme islemi -sozlesmede yer alan maddelere bagli olarak- maddi kayiplari veya yukumlulukleri de beraberinde getirebilir.
Denetim surecinin talep ve kabul asamalarinda gelen ilk talep genellikle "kesinlikle servis engelleme saldirilari istemiyoruz" olmaktadir. Denetmen olarak otomatize bir cevabinizda her zaman vardir, "talebiniz uzerine bilerek servis engelleme saldirilari duzenlenmeyecektir; ancak bircok guvenlik acigi bu tur bir etkiye sahiptir, bu nedenle bilmeyerek boyle bir durumun olusmasina neden olabilir". Karsi tarafta "bilerek olmasin, bilmeyerek oluyorsa da karsilikli haberlesir ve sorunu cozeriz" der. Boylece belirtilen ifadeler sozlesmeye eklenir, cezai sartlar belirtilir ve "servis engellemenin reddi ritueli"ni tamamlariz.
Servis engelleme saldirilarinin gerceklenmesi, ozellikle kritik sistemlerde istenmemektedir. Sifir devre dışı kalma toleransi ile calisan sistemlerin, bir denetim surecinde devre disi kalmasi cok hos karsilanmayacaktir. Bu nedenle otomatize araclarda "DOS" kategorisi isaretlenmez, hesap kilitleme ozellikleri kapatilir, port tarama esnasinda zaman limitleri eklenir ve arkaya yaslanarak denetim surecinin guvenle bitmesi beklenir. Ic buhranlar, karari sorgulamalar ve acabalar dipsiz kuyuya atilir.
Eger sistem sizma denetimi yapiyorsaniz ve bu isi hakkiyla yapmak isterseniz su ana kadar anlatilan seylerden bir veya daha fazlasindan rahatsizsinizdir. Otomatize yazilim, servis engellemenin istenmemesi, sorgulama olmamasi gibi kavramlar genellikle karsi oldugunuz seylerdir. Siz bir guvenlik acigini dogrulamadan raporlamanin hatali oldugunu dusunurken, sizden acigin denenmesinin dahi istenmemesi kabul edilebilir gorunmemektedir. Ancak durumun bu kadar basit parametreler ile dusunulmesi ve degerlendirilmesinin de yan etkileri vardir.
Detay 1, Servis Engelleme Neden Olusur :
Servis engelleme durumu, programlama sorunlari soz konusu ise birkac belirgin kosulda olusur ;
- Servis yazilimi kendisine ait olmayan bir tampon bellek alanina yazmak isterse,
- Servis yazilimi kendisine ait olmayan bir sistem kaynagina erismek isterse,
- Isletim sisteminin ana bilesenlerinden biri bellek veya islemci gibi temel kaynaklari dengesiz bicimde kullanirsa,
- Servis yaziliminin planlanan istek/sorgu/islem sayisi gercek hayatta kaldiramamasi ve erisilen bilesenlerin (alt surec, bellek vb.) yeterli olmamasi,
- Yazilim tarafindan gerceklenmesi uzun sureli islemlerin, es zamanli ve cok kez tekrarlanmasi.
Bir saldirinin kontrolüne ornek vermek adina yukarida listelenen durumlar simdilik yeterli gorunuyor, daha sonraki gonderimlerimde servis engelleme sureci ve denetimi ile ilgili hazirladigim bazi calismalari da paylasmayi planliyorum. Bu konuda bazi planlar, araclar ve ek kontroller olusturma; bir kismini da hayata gecirme imkani buldum. Dogru bicimde yonetilirse faydali bir surec olduguna inaniyorum.
Detay 2, Is Karari Olarak Servis Engellemenin Reddi :
Is sureklilik yukumlulukleri olan sistemlerin anlik durmalari dahi kabul edilebilir olmamaktadir. Bu nedenle kumeleme yontemleri, yuk dagiticilar, sistem ikizleme veya istek yonetimi gibi yollar tercih edilir. Sistemin kritikligi dogrultusunda denetimler yapilmasi istenir. Ancak bircok sistem yoneticisi hangi sistemlerin tam olarak kritik olduguna karar vermek ve devre disi kalabilmesi olasiligini belirli bir kontrolde gerceklemek yerine kolay yolu secer, servis engelleme yapilmamasi. Bu secim, Gizlilik/Butunluk/Erisilebilirlik kavramlarindan olusan bilgi guvenligi felsefesinin Erisilebilirlik kismini goz ardi etmek demektir. Gizli bir bilginin ifsa edilmesi veya kritik bilgilerin ele gecirilmesi telafi edilebilir olmayacaktir, sistem surekliliginin aksamasi ise olusabilecek bir istisna olarak yorumlanabilir. Her kurum icin Gizlilik/Butunluk/Erisilebilirlik es deger onemde degildir, sonucta bu bir is karari olarak karsimiza cikar. Is karari olmasi bir sistem yoneticisinin de bu karara uymasini gerektirir.
Detay 3, Denetimde Servis Engelleme Etkisi :
Servis engelleme istenmiyor ise denetiminizi de bu dogrultuda degistirmeniz gerekecektir. Bilerek ve bilmeyerek bu durumun olusabileceginden bahsetmistik, kavramlari acalim ;
Bilerek -> sadece servis engelleme sonucu doguran aciklari test edilmeyecektir
Bilmeyerek -> servis engelleme sonucu dogurmayan, komut calistirma veya bilgi sizmasi etkileri doguran aciklar test edilecektir.
Peki servis engellemesi ve komut calistirma cok farkli aciklar midir ? Genellikle komut calistirabilmek icin cesitli turlerde tampon bellek tasmasi aciklari (Buffer/Integer/Heap/Stack Overflow) veya karakter sekli (Format String) kullanilir. Uygulamanin kullanicidan gelen girdileri kisitlama veya kontrol olmaksizin bellege kopyalamasindan kaynaklanan bu aciklar; tampon bellege izinsiz yazmak ve yazilan kodu cagirarak calistirmak suretiyle istismar edilir. Eger bu tampon bellek hesaplamalari bir seferde dogru bicimde yapilirsa sikinti yoktur, ancak bu her zaman mumkun olmayacaktir.
En az sorunla komut calistirabilmek icin asagidaki unsurlara -aklima ilk gelenler- dikkat etmek gerekmektedir ;
- Uygulamanin kullandigi ve yazilmasi mumkun olan bellek alaninin BASI, SONU, KULLANILMAMASI GEREKEN KARAKTERLER
- Uygulamanin her kosulda cagirdigi bir ifadenin/karakterin/cagrinin ustune yazmamak
- Komut calistirilan alt surec veya ana surecten cikisa neden olabilecek sonlandirma yapilmamasir
- Eger dahili bir saldiri onleme sistemi varsa, tetiklemek ve yan etkileri
- Kullanilacak bir encoder var ise (Shikata Ga Nai, XOR vb.) uygunlugu ve uyumlulugu
- Isletim sisteminin dahili komut calistirma veya bellek yazma korumalarinin varligi
- Islemci turu (Little Endian vs Big Endian)
- Isletim sistemi yama seviyesi, dil secimi vb.
Komut calistirma aciginin, servis engelleme etkisi dogurmasi nadir rastlanan bir durum degildir; aksine siklikla rastlanan bir durumdur. Ozellikle Microsoft DCE/RPC aciklarinin birkac kez art arta istismari RPC servisi bilesenlerinde sorunlara yol aciyor. Bu durum haliyle Netbios/Cifs icin temel bircok ozelligin calisamamasi anlamina geliyor. Netbios/Cifs'in sorunlu hale gelmesi ise ozellikle Active Directory ortaminda farkedilmesi zor ama etkileri cok buyuk sorunlar doguracaktir; oturum acamama veya zaman asimlari en onde gelen etkilerdir.
Exploit, yani acigin kullanim yontemi, her zaman detayli bicimde aciklanmayabilir veya sadece bir kisinin cok ustune dusmeden hazirlamis oldugu "calisabilirligi gosterme ve ispat" amacli olabilir. Boyle bir kullanimi urun ortaminda denemek ise servisi gercekten durduracaktir. En guvenli yol ise guvenilirligi arttirilmis ve cok sayida sistemde denenerek kararliligi test edilmis exploit'lerin tercih edilmesi veya yazilmasidir.
Acigin farkedilmesi icin otomatize yazilimlarin farkli davranislari ortaya cikar ; bazilari sadece servisin surumunu yeterli gorur iken (ki yanilticiligi ortadadir, baslik bilgisi farkli/gizli ise acik yoktur) bazilari dogrudan acigin istismarini (komut calistirma) tercih eder. Guvenilir sonuclara onem veriyor iseniz sizin acigi arastirmaniz gerekmektedir, hatali bir kullanim sonucu servisin olmesi en istenmeyen durumdur. Kaldi ki komutun basari ile calismasi da her zaman servisin ayakta kalmasina isaret etmeyecektir.
Acik test edilecek ise servisin devre disi kalmasi soz konusudur, test edilemeyen acigin varligindan soz edilemez. Kontrolu gereken acik sayisi binlerle ifade edilebilir, bu nedenle her acigin dogrudan kullanim ile testi mumkun degildir.
Iste boyle bir noktada servis engellemenin istenmedigi gelir akliniza, testin kritik olarak degerlendirilecek bircok bolumu elle kontrol edilir. Tek tek ve bolca sure harcanarak, dikkatsizlik sonucu bir acik kacar veya hatali bir kabuk kodu secimi sonucu servis sonlanir. Active Directory sunucusunun RPC sorunu nedeniyle yeniden baslatilmasi kulaga cekici gelebiliyor mu ?
Sonucta Ne Olacak ?
"Servis engellemenin reddi ritueli" demek iste bu durumun ozetidir. Acik ve ozet hali ise ; "Bir acigi istismar edeceksen habersiz ve kontrolsuz yapma, sadece servis engelleme sonucu doguran aciklari kontrol etme, otomatize bir yazilim kullanacaksan iki kere dusun".
Aslinda red yoktur, az inisiyatif vardir.
"Bak ama dokunma, dokun ama tatma, tat ama yutma. Sen bu kurallarla sasirmisken, o seni izleyip guler"
Fatih Ozavci
Bilgi Güvenliği Danışmanı
