Pazar, Ekim 18, 2009

FBI başkanı

Arkadaşlar merhaba,

Uzun bir sessizlikten sonra, aşağıdaki haberin ilginizi çekebileceğini düşündüm.

FBI başkanına online bankacılık yasak!

Kolay gelsin.

Etiketler: , ,

Devamı

Cuma, Temmuz 31, 2009

Google Chrome kullananlar. Dikkat!!

Arkadaşlar merhaba,

Biraz teknik ama uyarmak istedim.

Aşağıdaki scripti Google Chrome üzerinde tarihçe bölümündeki kutuda
çalıştırıp, sonucunu görebilirsiniz.

Varın gerisini siz tahmin edin. :)
(Scripti editör direk yansıtıyor olabilir, ancak anladınız sanırım)

"'>

Denemedir



veya adres kısmına link olarak

chrome://history/#q=%22'%3E%3Cmarquee%3E%3Ch2%3EDenemedir%3C%2Fh2%3E%3C%2Fmarquee%3E

yazınız.

Hayırlı olsun.....

Bilginize

Oğuzhan ŞEREFLİŞAN

Etiketler: , , , ,

Devamı

Cuma, Nisan 17, 2009

Özgür Yazılımlar ile VOIP Denetimi (Seminer)

Linux şenliğimizin 8.si İstanbul Bilgi Üniversitesi'nde yapılacak. 17 Nisan 2009 Cuma günü (bugün) saat 15:30 itibariyle "Özgür Yazılımlar ile VOIP Denetimi" seminerim ile etkinliğe katkı sağlamaya çalışacağım. Daha önce duyurma imkanım olmadı, ancak şenliğin sitesinde uzunca bir süredir duyuru yer alıyor.

Seminerde VOIP denetiminin nasıl yapılabileceği ve özgür yazılımların denetim sürecindeki rollerini tartışacağız. Sadece araçları tanıtmaktan bir adım öteye giderek VoIP denetim sürecini anlatmayı, araçların ise hangi amaçlarla sürecin içinde yer aldığını anlatmaya çalışacağım. Seminer sunumunu da ilk müsait olduğumda yine burada paylaşacağım.

Fatih Özavcı
IT Security Consultant
Devamı

Çarşamba, Mart 11, 2009

Ubuntu vs Gentoo (Apache Açıkları)

Ubuntu Linux dağıtımı dün "Full Disclosure" listesine bir e-posta gönderdi. "[USN-731-1] Apache vulnerabilities" başlıklı bir güvenlik duyurusu ile Apache paketlerini güncellediğini belirtti ve sistem yöneticilerinin güncelleme yapmasını önerdi.

Biz diyoruz ki (1,2) Microsoft'a ve Oracle'a güvenlik açığı bildirin ve unutun, nasıl olsa onlar da unutacak. Lakin Linux dağıtımlarının durumunun da -maalesef- pek parlak olmadığı ortada. Güvenlik açığı bulunduğunda üretici/geliştirici uyarılır (Yukarıdaki örnekte Apache Vakfı) , güvenlik duyurusu yayınlanması ve açığın kapatılması beklenir. Bu sürecin farklı adımları vardır, daha önce bu konularda da birşeyler (1,2) karalamıştım. Güvenlik açığı bir ortak yazılımda bulunmuş ise o zaman işler karışır, açığın duyurulması sırasında diğer dağıtımların durumu, açığın önceliği ve kapatılma yöntemi gibi çok şey devreye girer (1).

Gelelim konumuza Ubuntu Linux'un gönderdiği e-posta da atıfta bulunduğu açıklar : CVE-2007-6203, CVE-2007-6420, CVE-2008-1678, CVE-2008-2168, CVE-2008-2364, CVE-2008-2939. Apache bir güvenlik duyurusu sayfasına sahip ve orada bu açıklar ile ilgili duyurularını da yayınlamış. Gentoo Linux ise "6 Temmuz 2008"de ilgili açıkları bir güvenlik duyurusu ile duyurup kapatmış. Ubuntu Linux ise 8 ay beklemiş görünüyor -2007 yılının açığına hiç girmiyorum-, bu süre zarfında durumu farkeden kaç sistem yöneticisi Apache dağıtımını elle günceller ki ? Açıkların önem seviyesi, saptanan bileşen ve kurumlara etki türü şu anda konun dışında; çünkü illa ki bu durum birilerini ilgilendiriyor, yoksa niye duyurulsun.

Özetle, Linux sunucu kullanmak ta güvenlik duyurularını takip etmeyi, yama güncelleme kalitesini sorgulamayı ve hatta gerekiyorsa elle güncelleme yapmayı gerektiriyor. Bu konuda dağıtım seçiminin de bir kriter olduğu ve güvenlik önceliklerine uygun dağıtım kullanmanın gerekliliği de, altı çizilmesi gereken önemli bir noktadır.

Fatih Ozavci
IT Security Consultant
Devamı

Microsoft Duyuruları (MS09-00[6-7-8]) ve Teşekkürler

Microsoft dün itibariyle Microsoft DNS sunucusu, WINS sunucusu, SChannel ve GDI bileşenlerini ilgilendiren 3 adet güvenlik duyurusu yayınladı. Tabiki güvenlik duyurularında detaylı açıklama yok, klasik "specially crafted XXX package" veya "specially crafted XXX file" ile istismar edilen açıklar.

Microsoft Duyuruları (10 Mart 2009) :
MS09-006 ? Critical: Vulnerabilities in Windows Kernel Could Allow Remote Code Execution (958690)
MS09-007 - Important: Vulnerability in SChannel Could Allow Spoofing (960225)
MS09-008 ? Important: Vulnerabilities in DNS and WINS Server Could Allow Spoofing (962238)

Duyuruların detayında ayrıntı belirtilmese de 8 adet açığın duyurulduğu ve yamalandığı anlaşılıyor.
MS09-008'de teşekkür edilen kişinin "Kevin Day" olması, önemli bir ayrıntı olarak dikkat çekiyor. "Kevin Day"i geçen haftadan DjbDNS'in DNSCache bileşenine yapılan Tampon Bellek Zehirlemesi saldırısından hatırlayacaksınız diye umuyorum.

Microsoft ne kadar detayını gizlese de, DjbDNS için açıklanan saldırının Microsoft DNS sunucusu için de geçerli olduğu görünüyor. Bu doğrultuda Internet kullanımına açık olan Microsoft DNS sunucularının ivedilikle güncellenmesi gerekmektedir. Güvenlik açığının yaygın bir kullanım yöntemi ortaya çıkmadıkça gerekli yamayı yüklemeyen sistem yöneticilerine duyurulur.

Fatih Özavcı
IT Security Consultant
Devamı

Salı, Mart 10, 2009

Geçen Haftaya Bakış

Geçtiğimiz hafta birçok ilginç gelişme vardı, vaktiyle yazamadım ama kısa kısa notlarımı paylaşmak istedim.

Warvox - Wardialing'in Yeniden Doğuşu
Metasploit'in geliştiricisi HD Moore tarafından Warvox isimli bir araç duyuruldu. Sözkonusu duyuru wardialing yönteminin yeniden doğuşu olarakta yorumlanabilir. Telefon hatları kullanılarak çağrı yapmak suretiyle cevap veren telefon numaraları ve cihazların türlerini saptamak Wardialing olarak bilinmektedir. Geçmişte arka kapı girişlerini saptamak, yönlendiricilerin yönetim arayüzlerine erişimleri saptamak ve uzak erişim sunucularını saptamak için kullanılmaktaydı. Wardialing yazılımları bir veya daha fazla modemi kullanarak aramalar yapmakta, alınan sinyallerin türüne göre cihazları kayıt etmekteydi. Warvox ise Wardialing yöntemini VoIP altyapısını kullanarak yeniden canlandırdı. Warvox, IAX uyumlu VoIP servis sağlayıcıları üzerinden çalışabilmekte ve çağrıların cevaplanması durumunda alınan sinyalleri veritabanından karşılaştırarak analizler üretmektedir. VoIP altyapısını kullandığı için modemlerden çok daha hızlı sonuçlar üretilmesini sağlıyor. VoIP analizlerinde, cihaz yönetiminde ve sistem sızma testlerinde birçok aşamada kullanımı mümkün görünüyor; ancak lisansının gayri-ticari olduğunu belirtmekte fayda var.

DjbDNS'te Güvenlik Açığı
DjbDNS, D.J. Bernstein tarafından geliştirilmiş ve güvenlik garantisi verilmiş olan bir DNS sunucusudur. Güvenlik garantisi nedeniyle çok sayıda sistem yöneticisi tarafından tercih edilmekte ve kullanılmaktadır. Geçtiğimiz hafta DjbDNS'te 2 adet güvenlik açığı bulunduğu, açıkların DNSCache bileşeninden kaynaklandığı ve tampon bellek zehirlemesinin mümkün olduğu duyuruldu. Daha önce Kaminsky tarafından duyurulan zehirleme saldırısından DjbDNS yaklaşık 40-45 saat civarında bir süre sonunda etkileniyor iken yayınlanan güvenlik açığı ile bu süre 2-18 dk. aralığına kadar düşüyor. D.J. Bernstein ve Jeff King tarafından güvenlik açıklarını kapatmak üzere yamalar (1, 2) yayınlandı. D.J. Bernstein 1.000$'lık ödülünü de Matthew Dempsky'nin kazandığını duyurdu, lakin web sitesinde bu konuya ilişkin birşeyler göremedim. Bu noktada DjbDNS'i DNSCache ile beraber kullanan kişilerin yamaları yüklemesi ve güncellemeleri önerilmektedir. Belirtmeden geçmemek lazım, DNS sunucusu kullanılacak ise sunulacak alan kayıtları ile geçici sorguların farklı sunucularda konumlandırılması, görev ayrıştırmasının yapılmasının gerekliliği bir kez daha ortaya çıkıyor. Kişisel hırslar/tatmin neticesinde geliştirilmiş ve desteği olmayan bir yazılım kullanımının, kurumsal güvenlik ile ne kadar örtüştüğü üzerine de birşeyler yazmak gerekiyor; ancak bu ayrı bir yazının konusu olacak kadar geniş bir tartışma.

Dradis - Sistem Sızma Denetmenleri Bilgi Paylaşım Aracı
Dradis ilk sürümüyle çok ilgimi çekmiş ve kendi projelerime nasıl entegre ederim diye uzun uzun düşünmüştüm. Düşünceler sırasında birçok eksiklik görmüş ve eklenmesi gereken şeylerin çokluğu beni bir süre daha adım atmamaya itmişti. Geçtiğimiz hafta Dradis'in de yeni sürümü duyuruldu, tamamen yenilenmiş ve geliştirilmiş bir araç olarak karşımıza çıktı. Konsept korunmasına rağmen ciddi değişiklikler var, bence daha kullanışlı olmuş. Hedef kitle biraz kısıtlı olduğu için inceledikten sonra nerede kullanılacağına karar vermek daha doğru olacaktır.

L0phtCrack'in Dirilişi
L0pthCrack, Windows şifre kırma yazılımlarının ilk gelişmiş aracı ve efsanesiydi. Symantec atStake'i satın alınca L0pthCrack'in fişini çekmişti. Bizler de Ophcrack , RainbowCrack ve Cain&Abel ile yolumuza devam ediyorduk. Unutmadan hatırlatalım RainbowCrack'in de 13 şubatta yeni sürümü duyuruldu. L0pthCrack'in geliştiricilerinin (Mudge ve Weld Pond) aracın haklarını geri aldığı, yeniden geliştirme çalışmalarına başladığı ve "SOURCE Boston" konferansına yetiştireceği duyuruldu. Yeni özellikleri arasında 64 bit mimaride çalışmak ta yer alıyor. Ancak biz zaten bu imkanlara sahip iken yeni ne vaad edeceğini tam olarak anlayamadım, yine de 12 Mart'ta yapacakları sunuma dikkat etmekte fayda var.

PS: Bu yazım Gezegen'e ilk inişim olacak -umarım kalıcı olur-, Oğuz Yarımtepe'ye de şimdiden teşekkürler. Genelde kendimce yazardım, birilerinin okuyacak olması biraz endişe de kattı hayatıma.

Fatih Özavcı
IT Security Consultant
Devamı

Pazar, Şubat 22, 2009

TR-CERT/TR-BOME Hakkında Karalamalar...

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.

TR-BOME için rekabet sıkıntısı, Tübitak'ın rekabet oyuncusu olmasından kaynaklanan sorunlar ve bağımsız kişilerin bu içeriğe destek vermesinin önündeki engelleri başka bir yazımda anlatmıştım. Bu nedenle aynı konuyu tekrar anlatmaya çalışmayacağım. Bu yazıda TR-BOME'nin yaptıklarını ve yapmadıklarını tartışmak istedim.

TR-BOME'nin web sayfasını incelediğimde "Hakkımızda" bölümünün, "Olay Bildirim Formu"nun ve Duyuru/Bildiri bölümlerinin içerik barındırdığını gördüm. Aklıma takılan aşağıdaki soruların cevaplarını site üzerinde bulamadım, yanılıyorsam yorumlarda bağlantı verebilirseniz sevinirim. Sıkça sorulan sorular bölümünde ise hiçbir soru/cevap görünmüyor, dolayısıyla orada da bir cevap bulamadım.

  • TR-BOME'nin hakkımızda bölümünde gönüllülük esasına göre çalıştığı belirtiliyor. TR-BOME'nin kendi ekibinin varlığı, görev dağılımı ve ana görevlerde yer alan personel bilgisi açıklanmamış; kişi isimleri gizli ise sitenin içindeki yazılarda paylaşıldığını hatırlatırım.
  • TR-BOME'nin gönüllülük esasında beklediği katkının ne olduğu ve bu konuda katkı sağlayanlara hangi imkanları sunabileceği belirtilmemiş. Konuların neler olduğu belirtilmeyince insanların nasıl gönüllü olması beklenir ? Konular kısmında ise siteye makale yazmak değil de araştırma yapmak, güvenlik standart belgeleri hazırlamak, etkinliklerde veya organizasyonda aktif katılım aklıma geliyor. Eğer bu konu açığa kavuşturulursa ikinci soru da katılım sağlanacak etkinliklerde yol-konaklama giderlerinin ve diğer masrafların karşılanıp karşılanmayacağıdır, birçok dernek bu tür katkıları sağlayarak gönüllülük esasındaki çalışmalara hız verebiliyor.
  • TR-BOME'nin hakkımızda bölümünde belirttiği eğitim ve danışmanlık hizmetlerinin ücretsiz/ücretli olduğu belirtilmemiş. Sanırım soru sormadan bu konuda da cevap almak pek mümkün değil, kaldı ki kurum yöneticilerinin bu tür bilgilere dayanarak atacakları adımlar olacaktır ve birçoğu sadece sorular ile böyle bir bilgiyi alırken dahi vazgeçeceklerdir. TR-BOME, bilgi güvenliği konusunda hevesli ve çalışmaya hazır, sadece kendilerine rehber bekleyen bir müşteri/hedef kitle bekliyor ise çok yanılıyor. O insanlara birşeyler verebilmek için dahi çok fazla emek sarfetmek gerekir, zamanında çaba sarfettik tecrübe ile söylüyoruz.
  • Eğitim ve danışmanlık hizmetlerinin koşulları, eğitmen/danışman bilgileri ve kurum tarafından sunulacak hizmetlerin ek şartları da belirtilmemiş.
  • TR-BOME "Olay Bildirim Formu" hazırlamış, birçok açıdan çok güzel görünebilir ancak ortada "OLAY" tanımı dahi bulunmuyor. TR-BOME'ye göre "OLAY" tanımı nedir (Evet Incident yerine kullanılmış ama içinde ne var, mesela MSN çalınması kapsamda yer alıyor mu) ? Bildirim sonrasında atılacak adımlar nelerdir, insanlar neden böyle bir bildirimde bulunacaklar ?
  • TR-BOME "OLAY" kavramı içine giren durumların sadece bildirim formu ile gelmesini mi beklemektedir ? Ulusal ve Uluslararası e-posta listeleri, güvenlik siteleri, günlükler ve basın gibi kaynaklarda takip ediliyor ve görev/ihbar kabul ediliyor mu ? Sonrasında atacağı adımlar ve aşamaların neler olduğu listelenmemiş.
  • Kurulma işlemi sonrasında yapılan çalışmalar ile ilgili bir bilgilendirme raporu veya bildiri göremedim. Siteyi incelediğimde gördüğüm ise güvenlik sitelerinde olduğu gibi belge, makale ve klavuz hazırlamakla kısıtlı çalışmalar olduğu. Bazı çalışmaların olduğunu ise üstü kapalı bildirimler ile öğrendim, ancak gördüğüm kadarıyla şeffaflıktan sınıfta kalıyorlar.
  • Olaya müdahale sırasında ve sonrasında elde edilen bilgileri ne tür bir gizlilik ile koruyorlar. Gizlilik prensipleri bölümünde "Bilgiler Güvenlik Politikasına Uygun Korunmaktadır" denmiş, lakin ortada bir güvenlik politikası varmı ? ilgilendiren bölümü paylaşılmış mı ?
  • Tübitak'ın ağ güvenliği hizmeti satan/sunan bölümlerinin TR-BOME verilerine erişim imkanı bulunmaktamıdır ? Gizlilik prensipleri kurum içi gizliliği mi bölüm içi gizliliği mi kastetmektedir ?
Daha pek çok soru aklıma geliyor, eminim sizlerinde aklına çok şeyler gelmiştir. TR-BOME bizim çok şey beklediğimiz bir organizasyondur, bu nedenle yapılan çalışmaların sadece bir güvenlik sitesi açmak olması yeterli değildir. Güvenlik sitesine içerik beklerken dahi "Site yaptık, o zaman yazmamaları onların suçu" yaklaşımı da ayrı saçmadır, davet türü ve beklenen desteğin gelmesinin önündeki sorunların azaltılması gibi konular umursanmamakta mıdır ?

TR-BOME ile ilgili en önemli eleştirim ise devlet koruma kalkanına sahip tüm kurumlar gibi sorgulamaya ve şeffaflığa sonuna kadar kapalı olmalarıdır. Sitede yapılan çalışmalar, projeler veya araştırma raporlarına dair hiçbir şey bulunmuyor. Yukarıda ki sorular konusunda dahi ("Bilgi Edinme" bölümü var oradan girerseniz cevaplarız) yaklaşımını benimsemeleri bu durumun en somut göstergesi. Benzer bir organizasyon "ÖZEL" bir kuruma verilseydi şu ana kadar nasıl bir e-posta bombardımanı, araştırma raporları, çalışmalar ve içerik görürdük hayal edin.

TR-BOME ile ilgili gördüğüm tek basın bağlantısını da aşağıda paylaşıyorum. TR-BOME'nin kurulduğu, araştırmaları ve diğer çalışmalarının değil; sadece bir anti-virüs firmasından farksız olarak Virüs uyarısı göndermesi nasıl karşılanmalıdır ? Sanırım hepimiz bu tür duyuruların kendilerinin görevi olduğu konusunda hem fikiriz, bence garip olan TR-BOME'nin başka bir haberinin olmamasıdır.

TÜBİTAK'tan Virüs Uyarısı
http://www.hurriyet.com.tr/teknoloji/10882829.asp

Fatih Özavcı
IT Security Consultant
Devamı

Cuma, Şubat 06, 2009

TUBITAK, REKABET ve TR/Cert

Ö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.

Gerçekler ;
  • Tübitak, özel şirketlere bilgi güvenliği alanında denetim ve danışmanlık hizmetleri satmaktadır; yani bilgi güvenliği hizmet pazarının "REKABET EDEN BİR OYUNCUSUDUR".
  • Tübitak bir kamu kuruluşudur, kamusal görevleri ve sorumlulukları bulunmaktadır.
  • TR/Cert, Türkiye'nin ihtiyaç duyduğu ve bilgi güvenliği konusunda yaşadığımız birçok eksikliği giderebilecek organizasyondur.
  • TR/Cert bir kamusal görev olarak değerlendirilmiş ve Tübitak bu doğrultuda yetkilendirilmiştir.
  • Tübitak, Türkiye'nin tüm bilgi güvenliği uzmanlarını bünyesinde toplamamıştır; Türkiye'de özel şirketler için çalışan ve Tübitak'ın sahip olduğundan çok daha fazla bilgi güvenliği uzmanı bulunmaktadır.

Kamusal görev olan TR/Cert, bir rekabet unsuru olarak kullanılmasa dahi haksız rekabeti doğuracak bir olgudur. TR/Cert görevleri doğrultusunda kuruluşlara "güvenlik ihlali müdahale", "güvenlik bilinci arttırılması" ve "güvenlik organizasyonu yapılandırılması" konularında bedelsiz/kamusal hizmetler sunacaktır. Söz konusu hizmeti alan kuruluş çalışmalarını devam ettirmek, teknoloji ve hizmet yatırımı yapmak istediğinde ise izleyeceği bir yol olacaktır. Pazar oyuncularını (hizmet sağlayıcıları) davet edecek ve çözüm önerilerini, fiyatı içeren bir teklif dahilinde isteyecektir. TR/Cert'ün de içinde bir bölüm olduğu Tübitak'ın bir başka bölümü ise çalışmalarını ve fiyat teklifini bu kapsamda iletecektir. Bu durum dünyanın neresinde olursa olsun "HAKSIZ REBAKET" olarak değerlendirilir ve cezalandırılır.

Bu durum sadece rekabet rahatsızlığı yaratmayacaktır; TR/Cert'e destek vermek isteyen ve çalışma hayatını belirtilen "RAKİP" kurumlarda çalışan insanların geri adım atmasına neden olacaktır. Pazar rekabeti içinde bulunulan bir kuruma çalışmalarında "ÜCRETSİZ" yardım edilmesini beklemek ve böyle önemli organizasyonların desteklenmesini istemek ise en iyimser ifade ile "SAFLIK" olacaktır. TR/Cert'e belirtilen sebeple yardımcı olamayan/olmayan kişilerin, kar amacı gütmeyen bağımsız dernek ve kuruluşlarda yaptığı çalışmalar ise TR/Cert'e aktarılamayacaktır.

Yukarıda ki tanıma uyan, kamusal görev ve ticari rekabeti beraber devam ettiren çok sayıda kamu kuruluşu bulunmaktadır. Geçtiğimiz yıllarda belirtilen şartlardaki kamu kuruluşlarından bazıları özel şartlarla satılmıştır. Türk Telekom örneği düşündürücü ve çarpıcı örneklerden sadece biridir. Kamu görevleri icra eden, gelir elde eden ve alanında tekel olan Türk Telekom özelleştirildi. Özelleştirme süreci öncesinde PTT ve Türksat şirketlerine belirtilen kurumun görevlerinden bazıları aktarıldı; özelleştirmeye konu olan Internet altyapısı ve İletişim altyapısı halen ilgili kurumun hizmet verdiği alanda tekel olmasını sağlamaktadır. Kamusal görevler arasında yer alan "iletişim güvenliği" konusunda ise Askeri önlemler (özel bir iletişim altyapısı) ve kamusal önlemler geliştirildi.

Anlatılan koşullar çerçevesinde;
  • TR/Cert'e sadece Tübitak (yeni/eski)çalışanlarının veya hizmet alan kurum bünyesindeki kişiler destek verecek; önemli bir danışman/denetmen/eğitmen kitlesi icraat esnasında (sözde olmasa bile) dışlanacaktır.
  • TR/Cert ile Tübitak kendisine "Bilgi Güvenliği" çalışma alanı için "REKABET BOZAN" bir özellik kazandırmıştır.
  • Tübitak'ın tamamen veya kısmen özelleştirilmesi söz konusu olduğunda (böyle birşey hayalidir, hatta kabusidir) ise zaten bozulmuş olan "REKABET", "ULUSAL BİLGİ GÜVENLİĞİ POLİTİKASI", "HİZMETTE ELDE EDİLEN BİLGİLERİN GİZLİLİĞİ" ve birçok prensip rahatsızlık uyandıracaktır.
TR/Cert'ün önemli zarar görmesi, ticari faaliyette bulunan Tübitak'ın geleceği, kamusal hizmet ile ticari faaliyetin karıştırılması dışında zararlarda vardır.

Özel şirketlerin hizmet aldıkları Tübitak; hizmet zararını göze alabilmekte, çalışanlarını farklı bütçeler altında eğitebilmekte ve çok sayıda çalışanı bünyesinde barındırabilmektedir. Bu durum maliyetlerin azalması, hizmet bedellerinin ve kalitenin zamanla düşmesi sonucuna da gidecektir. Belirtilen düşük maliyet ve zarar ise sadece sermayesi güçlü olan kurumlar tarafından kaldırılır; belirtilen örnekteki "BİLGİ GÜVENLİĞİ HİZMET/ÜRÜN PİYASASI" için sermaye rahatlığı içindeki tek kurum TUBITAK'tır. Zaman içinde küçük hizmet şirketleri, özel bir alanda hizmet sunmak için kurulan şirketler veya büyük oyuncular piyasadan silinecektir. Bu durumu görmek için pazar analizi yapılmasına gerek yoktur; oluşan Türkiye Internet altyapısı ve hizmet sunan kurumların durumu da incelenebilir. Müşteriler için başlangıçta "UCUZ" olan hizmet bir süre sonra kalitesiz, otomatize ve yetersiz olacak; zamanla oyuncular silindikçe ve tekel oluştukça "PAHALI" olacaktır. Pazardaki hizmet sunan küçük kurumların yok edilmesi ve hizmet kalitesinin yetersizliği sonrasında ise YABANCI kurumların Türkiye temsilciliklerinden hizmet alınacak; hatta "BU KONUDA ÇALIŞAN BİR TÜRK FİRMASI DAHİ YOK, HEPSİNİN KALİTESİ YERLERDE" denilebilecektir.

Özetle; TR/Cert kanaatimce sorunlu doğmuştur. TR/Cert gibi yıllarca kurulması için çaba gösterdiğimiz kurum, içeriğine sağlanacak katkılara engeller ile oluşturulmuştur. TR/Cert'ün Tübitak tarafından kullanılış tarzına bağlı olarak "REKABET BOZAN" yapısı ileride çok ciddi tehlikeler oluşturacaktır. TR/Cert'ün bünyesinden ayrılması durumunda dahi Tübitak'ın "REKABET İHLALİ" yaptığı noktalar bulunmakta ve kamusal fayda ile uyuşmamaktadır. Türkiye'nin bilgi güvenliği çalışma alanındaki "Araştırma/Geliştirme" yapan özel şirketlerin sayısının azlığı, hizmete (yabancı kökenli ürünlere değil) yatırım yapan hizmet/ürün sunan şirketlerin azlığı ve piyasada bulunan hizmet bedelleri incelendiğinde, gelecekteki tehlike daha net görülebilir. Halen birçok kurum bilgi güvenliği hizmetlerini -daha iyi oldukları gerekçesi ile- çok yüksek meblağlar ile yurtdışı kökenli -bünyesinde türk mühendislerini kullanan- firmalardan almaktadır.

Fatih Özavcı
IT Security Consultant
Devamı

Pazar, Şubat 01, 2009

Etik! Etik! Diyeni Meşe Odunuyla Dövmek

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.

Meslek seçimini yaparken uyulması gereken kuralları veya genel kriterleri de bilmelisiniz. Bilgi güvenliği işi çok hassas dengeler üzerinde yürümektedir, atacağınız adımların güven/etik gibi kavramlar ile sorgulandığını görürsünüz. Bilgi güvenliği, çok sayıda kişinin çalışmak için seçtiği bir alandır ve kendine özel kriterleri vardır. Bu kriterler farklı alanlarda farklı isimler ile anılır; sonuçta sizin yaptığınız tüm hareketler ile beraber yargılandığınızı farkedersiniz. Yazdığınız makaleler,yaptığınız yorumlar, araçlar, dahil olduğunuz gruplar, arkadaşlarınız ve panellerdeki katılımınız başlıca incelenecek işlemlerdir. Böylece müşteriler en hassas bilgilerini size emanet edip etmemeye karar vereceklerdir.

Bilgi güvenliğindeki çalışma alanlarından birinde ise etik doruklarda gezer; sistem sızma denetimleri.Sistem sızma kavramını bilmeyenler için Penetration, Hacking, Ethical Hacking gibi kavramların yerine kullandığımı hatırlatayım. Eğer sistem sızma denetimi yapıyor iseniz ahlaki sorgulamalara daha çok maruz kalırsınız, kaldı ki Ethical Hacking dikkatinizi çekmiştir. Bu sorgulamanın nedeni ise denetmenlerin, hedef sistemde bir güvenlik açığını araştırması ve bu araştırma sonrasında bulguları müşteriye raporlamasıdır. Kötü olasılıklar ise açığın kullanımı ile bundan çıkar elde etmesi, bu açık ile övünmesi veya açığı kullanım içeride bir arka kapı bırakara sonrası için yatırım kararı alması.

Sistem sızma ve genel güvenlik ile ilgili işlerde, müşteriler tarafından yetkinliği algılamak adına sertifika sorgulaması yapılır. CISSP (Certified Information Systems Security Professional) ve CEH (Certified Ethical Hacker) sertifikaları beraberinde yukarıdaki bahsedilen etik kavramını asgari koşulları içinde anarlar. Aşağıda "Code of Ethics"ten yapılmış bir alıntı var.

---- ALINTI-----
Code of Ethics Canons:
  • Protect society, the commonwealth, and the infrastructure.
  • Act honorably, honestly, justly, responsibly, and legally.
  • Provide diligent and competent service to principals.
  • Advance and protect the profession.
---- ALINTI-----

Ülkemizde ise ilgili sertifikalara sahip olduğunu her fırsatta belirtmek isteyen, yazılarının altına ekleyen, hatta eğitmeni olan arkadaşlarımız söz konusu etik konusunda kafamda soru işareti oluşturan çok sayıda hareket yapıyorlar. Bir güvenlik açığını bulmak ve yayınlamak konusunda izlenebilecek yollar vardır; ancak bir kurumun kaynaklarının üzerindeki zaafiyetleri konuşurken -eğer yukarıda yazan gerçeklerin farkındaysanız- uymanız gereken kurallar vardır. İzlenebilecek olan yollar ile uyulması gereken kurallar arasındaki fark "etik zorunluluktur". Beni rahatsız eden hareketler ise tam bu konuda ortaya çıkıyor.


Etik olacağını, yaptığı hareketlerin onurlu olacağını "vaad eden" kişiler, özellikle bir kurumun kaynaklarındaki açığı kamuyla paylaşma lüksüne sahip değildir; açar aldığı sertifikanın referanslarını ve doğru yollardan birini seçerek çözüme kavuşturur. Yani özünde amaç güvenlik açığını barındıran kurumun zarar görmemesini sağlamaktır, ayrıca güvenlik açığının kapattırılması da amaç ise ortası bulunur. Genel kullanımı olan bir ürünün -Örnek Microsoft IIS- açığını tartışmak farklıdır, bir kurumun web sitesindeki sorunu tartışmak - Örnek Microsoft'un web sayfasında halen devam eden SQL sorguları değiştirme açığı- farklıdır. İkisini karıştırıyor iseniz, bir kurumun yüklenmemiş yamalarından bahsetmeye devam eder iseniz, kurumdaki yetkililerin bu konuda sahip oldukları birçok iş kuralı nedeniyle yaşadıkları sorunları görmezden geliyor iseniz; ETİK DEĞİLSİNİZDİR, başka birşeysinizdir. Kurumun ilgili açığı duyurmanızdan veya alenen tartışmanızdan göreceği zarar sizi ilgilendirmiyor yanılgısında olabilirsiniz; ancak yarın güvenliğini sağlamak/denetlemek zorunda kalacağınız kurum size bunların karşılığını sorabilir.

Etik olmak demek bir güvenlik açığını duyurmamak, hasır altı etmek, dünyayı toz pembe saymak değildir; -konuştuğumuz konu sınırlarında- güvenlik açığını kapatmak ve kurumun açığını gidermek noktasında, kurumun ve kamunun zarar görmemesini sağlamaktır. Açığı kapattırmak istiyor iseniz bunun nasıl yapılacağı üzerinde yazılmış çok şey bulunmaktadır; bir çıkış noktası olması adına sadece bir yolu içeren kişisel tecrübemi aşağıda paylaşıyorum. Birçok farklı yol, yöntem ve doğru olabilir; ama hedef kurumların ve kamunun zarar görmesini engellemektir. Bazen kamu ve kurum zararı çakışabilir, böyle bir durumda orta yolu bulmakta o kişinin asli görevlerinden biridir; kimse size bu işin kolay olduğunu söylemedi.


Bir Güvenlik Açığını Yayınlamak
http://www.bilgiguvenligi.org/2007/05/bir-gvenlik-yaynlamak.html

Fatih Ozavci
IT Security Consultant
Devamı

Perşembe, Ocak 29, 2009

Servis Engellemenin Reddi Ritueli

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.
Programlamadan kaynaklanan servis engelleme saldirilari sadece yukaridakilerden ibaret degildir. Servis engelleme saldirilari sadece programlamadan degil yapilandirma, tasarim ve ag yerlesimi gibi sorunlardan da olusabilir. Hedefe bagli olarak (kablosuz ag, web uygulamasi, VoIP, ag altyapisi vb.) cok daha farkli ornekler ile karsilasmak mumkundur.

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.
Eger bir alt surecin istismari soz konusu ise deneme/yanilma yontemini dikkatle kullanmak mumkundur; neticede olen surecin yerine yenisi gelmis veya gelecektir. Ancak ana surecin okudugu bir verinin degisimi; hatta ana surecin dogrudan istismari soz konusu ise servisin sonlanmasi soz konusudur. Haliyle servis duracak, bir komut calistirma acigi servis engellem etkisi doguracaktir.

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
IT Security Consultant
Devamı

ISO 27001 Bilgi Güvenliği Sertifikasyonları