Aradan çok zaman geçmiş, ama birçok şeyin aynı kalmış olduğunu görünce, bit pazarına nur yağabilir diye düşündüm. Bu nedenle geçtiğimiz yıllarda Bilgi Güvenliği Grubu (www.bilgiguvenligi.org) günlüğünde yazmış olduğum yazıları bir araya getirmeye karar verdim. Yazılardan sadece bugün de anlam ifade edebilecek olanları ayıklamaya çalıştım, belki okuyanların işini görür.
Bu günlüğü açtım diye burada düzenli yazacağım fikrine kapılmamak gerek, tembelliğimle ünlüyümdür. Arada uğrarım, belki birşeyler karalarım ama güncellendiğini mutlaka Twitter hesabımdan (@fozavci) duyururum. Esen kalın.
3 Eylül 2012 Pazartesi
TR-CERT/TR-BOME Hakkında Karalamalar...
Tarih : 22 Şubat 2009
Tübitak bir süre önce TR-CERT / TR-BOME (Bilgisayar Olaylarına Müdahale Ekibi) oluşturulması konusunda yetkilendirildi ve TR-BOME kuruldu. Kurulma aşamasında ve hemen sonrasında www.bilgiguvenligi.gov.tr adresinden Bilgi Güvenliği Kapısı yaşama geçirildi. Kurulma aşaması ile beraber TR-BOME için Bilgi Güvenliği Kapısı altında bir bölüm (Türkçe, İngilizce) açıldı ve bazı bilgileri paylaşıldı.
TR-BOME kurulduğu andan itibaren üretilen içerik olarak sadece www.bilgiguvenligi.gov.tr'den haberdarım, yazının bundan sonraki kısmını da ilgili site üzerinden ve e-posta listelerine gönderilen e-postalardan yola çıkarak hazırlıyorum. Yani bir başka kaynak var ise benim bilgim dahilinde değildir, dolayısıyla bilmeden yazmışımdır ve bu durum benim araştırma yapmamaktan kaynaklanan hatamdır.
TUBITAK, REKABET ve TR/Cert
Tarih : 6 Şubat 2009
Önceki hafta "Bilgi Güvenliği" posta listesine attığım bir e-posta ve sonrasında gelişen yazışmalar sonucu Tübitak konusunda birçok tartışma oldu. Tübitak konusunda ve TR/Cert'ün yerleşimi konusunda duyduğum çok sayıda rahatsızlığı ilgili e-postada belirtmiştim. Bu rahatsızlıkları paylaşmak ve Tübitak'ın davranışları hakkındaki endişelerimin neler olduğunu net olarak ifade etmek istedim. Daha sonra bir başka yazı da TR/Cert ile ilgili düşünce, öneri ve endişelerim için yazacağım.
Tübitak'ın Bilgi Güvenliği alanındaki çalışmaları konusunda birçok rahatsız olduğum nokta var; ancak bu durum Tübitak'ın yaptığı diğer olumlu işleri (Geliştirilen ulusal kriptolama altyapısı, araştırma/geliştirme çalışmaları, kamusal bilgi güvenliği çalışmaları, diğer projeler {pardus vb.}) beğenmediğim anlamına gelmiyor. Şu unutulmamalı; bir kurumu/davranışı eleştirirken tarafın güzel/beğenilen hareketlerini de listelemek gereksiz ve yersizdir. Evet güzel çalışmalar yapmış olabilir, bir kısmını takdir de etmekteyim; ama bu durum benim rahatsız olduğum noktalar ile ilintili değildir.
Etik! Etik! Diyeni Meşe Odunuyla Dövmek
Tarih : 1 Şubat 2009
Bir su tesisatçısının etik olması söz konusu mudur ? Gelir, musluğu değiştirir ve gider. Musluğun bozuk olması, damlatması veya montajı sorunlu ise işini doğru yapmıyordur. Ama genel olarak muslukçuyu etik olmamakla suçlayamazsınız; sadece parasını verdiğiniz işi yapıp yapmaması ile yargılarsınız. Başka yerlerde muslukların veriminden, yeni modellerden ve kendisinin tercihlerinden bahsettiğinde "etik olarak yanlış, bir daha bu adama musluklarımı değiştirmeyeceğim" denmez, diyenini görmedim. Oysa doktorun yazdığı ilaçlar, seçtiği tedavi yöntemi, dene(k/y)leri ve ötanaziye bakışı önemlidir; kendinizi ona göre emanet edersiniz. Sadece muslukçu yoktur; tamirci, lastikçi, kapıcı ve manav vardır. Doktor da yanlız değildir, avukat, polis ve hatta çilingir de aynı kategoriye girebilir.
Servis Engellemenin Reddi Ritueli
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.
Bir Acigin Dogru Anlatimi ve Sonuclari
Bu özet kullanılabilir değil. Yayını görüntülemek için lütfen
burayı tıklayın.
Bir Yama Ne Kadar Sürede Geliştirilir ?
Tarih : 13 Temmuz 2007
Daha önce bulmuş olduğumuz saldırı tespit ve önleme sistemlerinin atlatılmasına imkan veren güvenlik açığı hakkında "Bir Güvenlik Açığının Yayınlanması" başlıklı bir makale yazmıştım. Yama geliştirme sürecinin zorluklarına da biraz değinmiş ve halen açığımızın bazı ürünler için yamalanmamış olduğuna dikkat çekmiştim.
Bugün 3Com TippingPoint IPS üzerinde bulunan ve yamalanan 2 güvenlik açığı hakkında bir blog girdisi okudum. Securiteam blog'u üyelerinden Juha-Matti tarafından yazılmış "Patching an IPS - 16 months !" başlıklı yazıda, yayınlanan açıkların yama geliştirme bilgileri incelendiğinde 3Com TippingPoint IPS için bulunan açığın 16 ayda yamalandığına dikkat çekmiş. Yaklaşık 30 gün sonra açığın teknik detayları yayınlanacak bilgisini de eklemiş.
Bana yazmış olduğum birkaç yazıyı hatırlattı, sanırım söylediklerimde epeyce haksızlık ettiğim nokta varmış. Açığın teknik detaylarını gördüğümüzde, 3Com'un yavaşlığından dolayı mı, açığın türünden dolayı mı gecikme olduğu anlaşılacak. Tüm TCP/IP altyapısı ve paket normalleştirme motorunu değiştirmeyi gerektirebilecek açıklar bulunduğu zaman, üreticilerin ne kadar çaresiz duruma düşebileceğini gösteren güzel bir örnek oldu.
İlgili Şikayet ve Söylenmelerim :
Sıfır Gün Açıkları Kimin Umrunda ? ( Bölüm 1 , Bölüm 2 )
Fatih Özavcı
Bilgi Güvenliği Danışmanı
Daha önce bulmuş olduğumuz saldırı tespit ve önleme sistemlerinin atlatılmasına imkan veren güvenlik açığı hakkında "Bir Güvenlik Açığının Yayınlanması" başlıklı bir makale yazmıştım. Yama geliştirme sürecinin zorluklarına da biraz değinmiş ve halen açığımızın bazı ürünler için yamalanmamış olduğuna dikkat çekmiştim.
Bugün 3Com TippingPoint IPS üzerinde bulunan ve yamalanan 2 güvenlik açığı hakkında bir blog girdisi okudum. Securiteam blog'u üyelerinden Juha-Matti tarafından yazılmış "Patching an IPS - 16 months !" başlıklı yazıda, yayınlanan açıkların yama geliştirme bilgileri incelendiğinde 3Com TippingPoint IPS için bulunan açığın 16 ayda yamalandığına dikkat çekmiş. Yaklaşık 30 gün sonra açığın teknik detayları yayınlanacak bilgisini de eklemiş.
Bana yazmış olduğum birkaç yazıyı hatırlattı, sanırım söylediklerimde epeyce haksızlık ettiğim nokta varmış. Açığın teknik detaylarını gördüğümüzde, 3Com'un yavaşlığından dolayı mı, açığın türünden dolayı mı gecikme olduğu anlaşılacak. Tüm TCP/IP altyapısı ve paket normalleştirme motorunu değiştirmeyi gerektirebilecek açıklar bulunduğu zaman, üreticilerin ne kadar çaresiz duruma düşebileceğini gösteren güzel bir örnek oldu.
İlgili Şikayet ve Söylenmelerim :
Sıfır Gün Açıkları Kimin Umrunda ? ( Bölüm 1 , Bölüm 2 )
Fatih Özavcı
Bilgi Güvenliği Danışmanı
Bir Güvenlik Açığını Yayınlamak
Tarih : 25 Mayıs 2007
Geçtiğimiz aylarda çalışma arkadaşım Çağlar Çakıcı ile beraber çok sayıda saldırı tespit ve önleme sisteminde önemli bir güvenlik açığı saptadık. Ancak bu güvenlik açığını üreticilere kabul ettirmek ve yayınlamak düşündüğümüz kadar kolay olmadı. Sevgili dostum Deniz Tuncalp'in de Bilgi Güvenliği - Tartışma Listesi'nde yaptığı öneriyle beraber bunların bazılarını kaleme almanın doğru olduğunu düşündüm. Umuyorum yazdıklarım, bizler gibi güvenlik açıklarını saptayan uzmanların, yayınlama aşamasında işine yarar ve onlara bir nebze yardımcı olur.
Geçtiğimiz aylarda çalışma arkadaşım Çağlar Çakıcı ile beraber çok sayıda saldırı tespit ve önleme sisteminde önemli bir güvenlik açığı saptadık. Ancak bu güvenlik açığını üreticilere kabul ettirmek ve yayınlamak düşündüğümüz kadar kolay olmadı. Sevgili dostum Deniz Tuncalp'in de Bilgi Güvenliği - Tartışma Listesi'nde yaptığı öneriyle beraber bunların bazılarını kaleme almanın doğru olduğunu düşündüm. Umuyorum yazdıklarım, bizler gibi güvenlik açıklarını saptayan uzmanların, yayınlama aşamasında işine yarar ve onlara bir nebze yardımcı olur.
Ortak [Kütüphane, Zaafiyet, Çekirdek, Yaklaşım] Nereye Kadar ?
Tarih : 2 Ekim 2006
Ağ veya sistem güvenliği şirketleri de dahil olmak üzere çok sayıda yazılım şirketi, yazılım geliştirme sürecinde, çoğu açık kaynak kodlu ve BSD yada eşdeğer lisanslı ortak programlama kütüphanelerinden faydalanmaktadır. Amaç dünyayı yeniden keşfetmek yerine, rekabetin yaygınlaştığı dünyada verimli ve güvenli sistemleri hızlıca üretmektir. Aslında oldukça doğru ve faydalı görünen bu yöntem, yazılım geliştirici kurumların güvenlik yaklaşımı neticesinde tehlikeli bir noktaya gitmektedir. Çok sayıda kurum, programlama kütüphanelerini kullanırken kendi kodlarının içine dahil etmekte ve güncellemelerini kendi kodları üzerinden yapmaktadır.
Bahsi geçen kütüphanelerde ortaya çıkan güvenlik açıkları, kütüphane geliştiricisi ekip tarafından hızlıca düzeltilip yazılım yamaları yayınlanmaktadır. Oysa birçok yazılım geliştirici kurum söz konusu yamaları yapmış oldukları değişimlerden ötürü kendi koduna uyarlayamamakta, umursamamakta veya farklı bir platforma taşımış olduğu uygulamada ilgili zaafiyetin bulunmadığını düşünmektedir.
Ağ veya sistem güvenliği şirketleri de dahil olmak üzere çok sayıda yazılım şirketi, yazılım geliştirme sürecinde, çoğu açık kaynak kodlu ve BSD yada eşdeğer lisanslı ortak programlama kütüphanelerinden faydalanmaktadır. Amaç dünyayı yeniden keşfetmek yerine, rekabetin yaygınlaştığı dünyada verimli ve güvenli sistemleri hızlıca üretmektir. Aslında oldukça doğru ve faydalı görünen bu yöntem, yazılım geliştirici kurumların güvenlik yaklaşımı neticesinde tehlikeli bir noktaya gitmektedir. Çok sayıda kurum, programlama kütüphanelerini kullanırken kendi kodlarının içine dahil etmekte ve güncellemelerini kendi kodları üzerinden yapmaktadır.
Bahsi geçen kütüphanelerde ortaya çıkan güvenlik açıkları, kütüphane geliştiricisi ekip tarafından hızlıca düzeltilip yazılım yamaları yayınlanmaktadır. Oysa birçok yazılım geliştirici kurum söz konusu yamaları yapmış oldukları değişimlerden ötürü kendi koduna uyarlayamamakta, umursamamakta veya farklı bir platforma taşımış olduğu uygulamada ilgili zaafiyetin bulunmadığını düşünmektedir.
Sıfır Gün Aciklari Kimin Umrunda ? (Bolum 2)
Tarih : 2 Mayıs 2006
Daha önce yine burada bahsetmistik, buyuk yazilim firmalari, yama yonetimi ve guvenlik aciklarinin kapatilmasi konusunda ciddi sikintilar yasiyorlar. Yazilim firmalari guvenlik aciginin kendilerine bildirilmesini takiben calismalara basliyorlar ve aylarca acigi kapatmaya calisiyorlar. Sonuc ise genellikle husran oluyor ve guvenlik aciginin kaynagini kapatmak yerine gecici cozumler uretiyorlar, daha sonra ise bu gecici lafi kalici oluyor ancak cozume ait bir gelisme yapilmiyor. Bizler de sanal guvenlik hissi beraberinde geceleri rahatca uyuyoruz.
Sikinti nerede olabilir ? Belki yama gelistirme surecinde, belki guvenlik acigina verilen onemde, belki de guvenlik aciginin duyurulmasina verilen onem de gizli. Tamam bu soruya cevap arayabiliriz, ancak unutmayalim ki sadece buyuk firmalar bu sorunu net olarak cozebilirler (cunku sorun onlarin), biz sadece durum saptamasi yapabiliriz ve cozume katki da bulunabiliriz. Yazinin amaci da budur aslinda, buyuk firmalarin yama gelistirme surecine elestirel bir bakis ortaya koymak.
Daha önce yine burada bahsetmistik, buyuk yazilim firmalari, yama yonetimi ve guvenlik aciklarinin kapatilmasi konusunda ciddi sikintilar yasiyorlar. Yazilim firmalari guvenlik aciginin kendilerine bildirilmesini takiben calismalara basliyorlar ve aylarca acigi kapatmaya calisiyorlar. Sonuc ise genellikle husran oluyor ve guvenlik aciginin kaynagini kapatmak yerine gecici cozumler uretiyorlar, daha sonra ise bu gecici lafi kalici oluyor ancak cozume ait bir gelisme yapilmiyor. Bizler de sanal guvenlik hissi beraberinde geceleri rahatca uyuyoruz.
Sikinti nerede olabilir ? Belki yama gelistirme surecinde, belki guvenlik acigina verilen onemde, belki de guvenlik aciginin duyurulmasina verilen onem de gizli. Tamam bu soruya cevap arayabiliriz, ancak unutmayalim ki sadece buyuk firmalar bu sorunu net olarak cozebilirler (cunku sorun onlarin), biz sadece durum saptamasi yapabiliriz ve cozume katki da bulunabiliriz. Yazinin amaci da budur aslinda, buyuk firmalarin yama gelistirme surecine elestirel bir bakis ortaya koymak.
Sıfır Gün Aciklari Kimin Umrunda ? (Bolum 1)
Tarih : 30 Mart 2006
Birkac gundur yine Microsoft Internet Explorer'da saptanan ve "createTextRang"/"checkbox" vulnerability (ref 1) olarak anilan bir aciktan etkileniyoruz. Acik 0 (yaziyla sifir ! - burasi cok onemli, anladiginizdan emin olun) gün acigi, yani ortada sozkonusu bir yama yok ama herkesin elinde bir exploit (ref 2) gununu gun ediyor. Hatta Microsoft ile iyi gecinen kurumlardan Eeye Digital bile durumla ilgili unofficial bir cozum onerdi (ref 3).
Haber bu mudur ? bence degil, cunku sifir gun aciklari ile daha once de ugrasmistik, elbette herkesin kendince cozum onerileri bulunuyor. Esas nokta ,ki bence cok daha onemli, buyuk yazilim firmalarinin (Temsilen taslarimizi Microsoft'a atacagiz) guvenlik acigina karsi yama gelistirme sureci olmali diye dusunuyorum.
Birkac gundur yine Microsoft Internet Explorer'da saptanan ve "createTextRang"/"checkbox" vulnerability (ref 1) olarak anilan bir aciktan etkileniyoruz. Acik 0 (yaziyla sifir ! - burasi cok onemli, anladiginizdan emin olun) gün acigi, yani ortada sozkonusu bir yama yok ama herkesin elinde bir exploit (ref 2) gununu gun ediyor. Hatta Microsoft ile iyi gecinen kurumlardan Eeye Digital bile durumla ilgili unofficial bir cozum onerdi (ref 3).
Haber bu mudur ? bence degil, cunku sifir gun aciklari ile daha once de ugrasmistik, elbette herkesin kendince cozum onerileri bulunuyor. Esas nokta ,ki bence cok daha onemli, buyuk yazilim firmalarinin (Temsilen taslarimizi Microsoft'a atacagiz) guvenlik acigina karsi yama gelistirme sureci olmali diye dusunuyorum.
Kaydol:
Yorumlar (Atom)