IstStatus Servisinin Susturulması ve Güvenlik Anlayışımız

Dün birçok havacılık meraklısı insanın yanısıra otellerin ve havayolu şirketlerinin çeşitli havalimanlarına iniş yapacak olan uçakları görebildikleri, kule ile aralarında olan telsiz konuşmalarını dinleyebildikleri iststatus.com kapatıldı. Kapatılma sebebi ise “güvenlik”. Devlet Hava Meydanları İşletmesi, VIP uçakların içerisindeki yolcuların, uçak kodunun, havadaki pozisyonunun herkes tarafından açık olarak görülmesinin bir güvenlik zaafiyeti oluşturduğunu düşünmüş ve öyle görünüyor ki teröristlerin bir saldırı yaparak uçağı düşürmelerinden korkarak kapatılmasını sağlamış [0]. Bu düşünce tarzının yanlış olduğunu, kafamıza kuma gömmek olduğunu ve doğru olanın ne olduğunu bir şekilde DHMİ’ye anlatmak gerekiyor.

Konuyu daha iyi anlayabilmek için iststatus.com ‘un bu servisi nasıl sağladığına fazla teknik detaya inmeden bir bakalım. Radar sistemlerinin nasıl çalıştığını hepimiz az çok biliyoruz. Bir radar sinyali göndererek objelerden seken sinyali işleyip bu objelerin bize olan uzaklığını hesaplayarak objelerin konumunu belirleyebiliyoruz. Havacılıkta bu radara Birincil Radar (Primary Radar) deniyor ve genel olarak yedek olarak kullanılıyor. Ancak şöyle bir sorun mevcut, uçakların kuleye olan uzaklık bilgisinin yanısıra yerden olan yüksekliği, uçak kodu gibi bilgilerin de bilinmesi gerekiyor. Bunun için birincil radar yetersiz kaldığı için İkincil İzleme Radarı (Secondary surveillance radar) kullanılıyor. Basit olarak her uçak gerekli bilgileri içerisinde barındıran bir alıcı/verici (transponder) taşıyor. İkincil izleme radarı bir sinyal gönderip bilgi istediği zaman uçaklarda bulunan bu alıcı/verici gerekli bilgiyi kodlanmış (şifrelenmiş değil) bir biçimde 1090 MHz‘den yayınlıyor.  DHMİ’nin söylediğinin aksine şunu belirtmek gerekir ki bu bilgi uçağın içerisindeki yolcu bilgilerini kapsamamaktadır.

IstStatus‘un yaptığı şey zaten herkes tarafından görülebilen, şifrelenmemiş ve 1090 MHz’de gönderilen veriyi anlamlı bir veri haline getirip 3 dakika gecikme ile insanlara sunmak. Telsiz konuşmaları da tek bir kanal değil, birden fazla kanal dolaşılarak veriliyor. Bu kanallar, benim bildiğim kadarıyla, yer, yaklaşma, ve kule. Burada konuşulanlar ise tamamiyle havacılıkla ilgili ve anormal bir durum olmadığı sürece “TK 321, yüksekliğini aaa’ya çıkar, hızını bbb’ye düşür, baş kısmını da ccc’ye yönelt” şeklinde ve herhangi bir önemli bilgi içermiyor. Tekrar hatırlatmak gerekiyor ki bu telsizler de herkes tarafından rahatlıkla dinlenebilir.

IstStatus türünün tek örneği değil tabi ki. Dünyanın birçok yerinde, görünüllü insanlar evlerinin çatılarına basit bir telsiz anteni ve az önce bahsettiğim 1090 MHz’de yayınlanan veriyi anlamlı hale getirecek cihazı koyarak (ADS-B Receiver) insanlara havaalanında neler olduğunu sunuyor. Bunun çeşitli yararları mevcut. Birincil olarak havacılıkla ilgilenen çeşitli insanlar kuleyi takip ederek muhabere konusundaki bilgilerini genişletiyorlar. Bu, aynı zamanda kulede ya da uçakta meydana gelen bir olumsuzluk durumunda otokontrol sağlıyor. Bir diğer yararı ise oteller ve misafirlerini havalimanında karşılayacak olan oluşumlar bu sayfayı takip ederek uçağın nerede olduğuna bakarak araçlarını zamanında çıkarıyorlar ve havalimanındaki gereksiz trafik engellenmiş oluyor. Bunu, iststatus kapandığından beri Atatürk Havalimanında yaşanan araç trafiğinden anlayabiliriz.

Herhangi bir terörist eylemi gerçekleştirme planı olan bir insan, 3 dakika gecikme ile aldığı bilgiyi kullanmayacaktır ve daha sofistike düşünmesi gerekir. Elinde yaklaşık olarak 400-500€ maliyeti olan ADS-B alıcısı olan bir insan bu bilgileri zaten görebilecektir. Şu anda alınan karar kafamızı kuma gömmekten başka bir şey olmamakla birlikte otokontrolü ve havacılık meraklılarının çalışmalarını engellemektedir. Öyle görünüyor ki kuledeki insanlar ve DHMİ, bu otokontrolden rahatsız oluyorlar. Dilerim ki havacılık meraklıları, telsiz meraklıları ve bir şekilde iststatus’den yararlanmış insanlar bu konunun peşini bırakmaz.

[0] http://www.airporthaber.com/iststatus-susturuldu–36590h.html

Reklamlar

Şifreli E-posta Gönderirken

Eminim ki birçoğumuz gerektiğinde, kişisel bilgilerinin güvenliği için e-postalarını şifreliyor ve bu yolla tamamiyle güvenli olduğunu düşünüyor. Açık anahtar ile şifreleme yaparken kendimizi güvende hissedebiliriz ancak bu noktada benim son zamanlarda dikkatimi çeken bir durumu paylaşmak ihtiyacı hissettim.

Her ne kadar e-postaların tamamının şifrelendiğini düşünsek de, e-posta başlıkları (header) sunucuya açık bir şekilde iletilmek zorunda. Durum böyle olunca, e-postaların başlıkları da açık bir şekilde gidiyor ve şifrelenmiyor. Eğer denemek isterseniz kendinize şifreli bir e-posta atın ve kullandığınız e-posta istemcisinin “başlıkları göster” özelliğinden faydalanarak size mesajın tam olarak nasıl iletildiğini görün. Genellikle “başlıkları göster” özelliği, e-postanın okunduğu ekranda “h” tuşuna basılarak aktif edilebiliyor. Öncelikli olarak bunu deneyebilirsiniz, eğer işe yaramıyorsa bir fikrim yok maalesef.

Bir dahaki sefere şifreli e-postaların başlığında önemli bir bilgi bulundurmamaya dikkat ediniz. Bilmeyen insanları bilgilendiriniz. Belki bu ileride bir gün hayatınızı kurtarır, kim bilir?

Twitter Hatası ve Türkiye’deki Yayıncılar Üzerine

logo.png (224×55)

Türkiyede yayıncılık gerçekten içler acısı bir halde. Etrafta bulunan teknoloji siteleri kaynak göstermeden habersiz, habercilik etiği nedir bilmeyen insanlardan oluşuyor.

Duymadıysanız, Twitter’da çok basit bir şekilde kullanılabilen bir açık ortaya çıktı. Web üzerinden “accept <username>” yazdığınızda “username” kişisi sizi otomatik olarak takip etmiş oluyor (idi) isteği dışında..

Bu açığı bulan ve paylaşan kişi Bora Kırca ‘dır. İncisözlük’teki şu girdisi ile paylaşmıştır. Girdinin yazıldığı saate bakarsanız 16:28’i görürsünüz. Aklınızda bulunsun bu saat, twitter ile ilgili haberi başka web sayfalarında gördüğünüz zaman saatine dikkat ederek ne kadar doğru olduğunu görebilirsiniz.

Haberi ilk anda ShiftDelete.Net kaynak göstermeden, sanki kendileri bulmuşcasına yayınladı. Haberi yayınlayan kişinin gerçekten etik anlayışını çok merak ediyorum. Orijinal içerik 16:28’de yayınlandı, 17:00’da yaptığınız bu haber için nasıl “İlk kez SDN’de” diyebiliyorsunuz? Gerçekten habercilik anlayışınız ve sunduğunuz magazinsel içerik içler acısı bir halde. Habercilik etiğini ayaklar altına alarak, insanlara magazinsel haber pompalamayı ve bundan kazanç sağlamayı çok iyi biliyorsunuz. Sağolun SDN takımı, iyi ki varsınız! Eminim ki böyle devam edeceksiniz. Gerçekten ülkenin sizin gibi insanlara ihtiyacı var.

Diğer bir içler acısı durum ise Webrazzi. SDN kadar olmasa da, haberlerinde sonradan kaynak gösterdiler. Ancak şu soru akla geliyor ki, sonradan kaynak gösterilecekse, neden haberi yazarken bu aklınıza gelmedi? Birkaç link eklemek ve 1 cümle yazı yazmak gerçekten zor değil. Şu sayfada Webrazzi’nin yayınladığı ingilizce içerik mevcut. Bu içerik ilk olarak kaynaksız yayınlandı ve Avrupa’nın büyük teknoloji sitelerinden bir tanesi olan TechCrunch ‘da yer aldı. TechCrunch makalesine bakarsanız açığı bulan kişi hakkında herhangi bir bilgi bulamazsınız. Sanki her şeyi Webrazzi bulmuş ve yayınlıyor gibi bir izlenim mevcut. İngilizce yayında da düzeltmiş olsalar da, zaten TechCrunch’da ana sayfa haberi olarak yeterince “profit” kazanıldı. Sonradan “eea, biz düzelttik ama” demek çok da mantıklı görünmüyor bana.. Yine de sonradan düzelttikleri için kendilerine teşekkür etmek gerekiyor.

Neyse ki Avrupada’ki yayıncıların bir etik anlayışı var ki, CNET Incisozluk’ten bahsetmeyi ihmal etmemiş. Haber Slashdot ‘a da düşmüş durumda. Yarın yabancı kaynaklı ana haber bültenlerinde “Türkler Twitter’ı hackledi” şeklinde haberler göreceğizdir. Şu günlerde TheRegister, NYTimes, BBC gibi sayfalara gazetelerin internet sayfalarına göz atmayı unutmayın.

Bu arada dünyanın en aptal hatası anketi yapılırsa, bana haber verebilirseniz sevinirim. Oyumu bundan yana kullanacağımdır.

PHP <5.3.1 Denial of Service

Uzun zamandır yazamıyordum, gezegen biraz paslanmış ama bu girdi gezegenin pasını alacak gibi görünüyor :)

Birkaç gün önce PHP 5.3.1 yayınlandı, birçok hatayı ve güvenlik açığını kapatıyor. Güvenlik güncellemeleri şu şekilde:

  • Added “max_file_uploads” INI directive, which can be set to limit the number of file uploads per-request to 20 by default, to prevent possible DOS via temporary file exhaustion.
  • Added missing sanity checks around exif processing.
  • Fixed a safe_mode bypass in tempnam().
  • Fixed a open_basedir bypass in posix_mkfifo().
  • Fixed failing safe_mode_include_dir

İçlerinden en önemlisi kalın olarak belirttiğim “max_file_uploads” seçeneği. PHP 5.3.1 ‘den önceki sürümlerde bu özellik yok ve üzerinde PHP çalıştıran herhangi bir sunucu 1 dakika içerisinde isteklere yanıt veremez hale getirilebiliyor. Upload edilen dosyanın işlenip işlenmemesi önemli değil, sadece boş bir index.php barındırmanız bile yetiyor!

Açık PHP’nin dosya upload sırasında geçici dosya oluşturmasından kaynaklanıyor. Eğer art arda 16.000+ dosya upload isteği gönderirseniz, sunucu geçici dosya yaratma ve silme ile aşırı derecede meşgul olacağı için normal isteklere cevap veremez hale geliyor. Bu süre zarfında %100 ‘e yakın işlemci tüketmesi ve büyük miktarda bellek kullanması da cabası.

Bununla birlikte açığın kullanıldığına dair çok net bir işarete rastlayamıyorsunuz. Sadece log dosyanızda aynı IP adresinden gelen birkaç yüz tane POST isteği görülecek. POST isteklerinin içeriğin görülemediği için, eğer bu açıktan haberdar değilseniz dikkatinizi o yöne değil de başka yerlere vererek sunucunuzun neden erişilmez olduğunu anlayamayacaksınız. Daha da kötüsü, her zaman kolayca kullanılabileceği için sisteminiz büyük risk altında olacak :)

Açık Bogdan Calin tarafından bulundu. Daha ayrıntılı bilgi için [0] adresini okuyabilirsiniz. Kendisi kullandığı scripti vermeyeceğini yazmış ancak biraz araştırma ve deneme ile açığı exploit eden kodu yazdım ve yayınlıyorum. :) Kod [1] adresinde.

Şu anda Türkiye’de PHP içerik sunan sitelerin büyük bir çoğunluğu etkinlenir durumda. Hosting şirketleri bu açığı kapatmadığı sürece de etkilenecek…

[0] http://www.acunetix.com/blog/websecuritynews/php-multipartform-data-denial-of-service/

[1] http://www.exploit-db.com/exploits/10242

Peki nasıl korunacağız?

PHP 5.3.1 ile açık kapanıyor. Eğer güncelleme imkanınız varsa 5.3.1’e güncelleyin. Ancak PHP 5.3.1 ile birçok özellik değişmiş durumda ve PHP 5.2.x ile çalışan pek çok uygulama 5.3.x ile çalışmayacaktır. Bu yüzden büyük ihtimalle PHP 5.2.x kullanıyorsunuz. Eğer tahmin ettiğim gibiyse, 5.2.x yamaları aşağıda. Yamaları uygulayıp PHP’yi tekrar derleyin ve sunucunuzu yeniden başlatın.

http://svn.php.net/…/main/rfc1867.c?r1=272374&r2=289990

http://svn.php.net/…/main/main.c?r1=289214&r2=289990 (NOT: Buradaki 100 değeri sonradan 20 olarak değiştirildi, siz de 20 olarak değiştirip uygulayın)

Güvenli olup olmadığımı nasıl anlarım?

Çok basit. Aşağıdaki adresindeki dosyayı alıp sunucunuz üzerinde dosya uzantısı *.php olacak şekilde çalıştırın. Sizde yamanın olup olmadığını söyleyecektir.

Pardus ne alemde?

Tabi ki açık yayınlandıktan 1 gün sonra yamaları eklendi ve commit [*] edildi. Birkaç gün içerisinde de depoya alındı. Şu anda düzeltilmiş PHP paketi stable depoda. Eğer Pardus kullanıyor ve PHP içerik sunuyorsanız güvenlik açığını kapatmak için PHP paketlerini güncellemeniz yeterli:

sudo pisi ur && sudo pisi up mod_php php-common php-cli

sudo service apache restart

* http://liste.pardus.org.tr/paketler-commits/2009-November/087149.html

Sonra?

Yazdığım bu girdi ve exploit bu tür önemli şeyleri takip etmeyen sistem yöneticilerini uyandıracaktır diye umuyorum. Eğer PHP kullanıyorsanız, lütfen kullandığınız dağıtımın güncellemelerini kontrol edin. Açığın kapanıp kapanmadığına bakın. Hizmet satın alıyorsanız sunucu yöneticinize bu durumu bildirin. Ve lütfen bu girdiyi ulaştırabildiğiniz kadar insana ulaştırın, dağıtın! Böylece insanlar bu konu hakkında bilinçlenecek ve bu açık daha hızlı bir sürede kapanacabilecek..

Önemli Notlar:

Yayınlanan kod ile yapacaklarınız tamamen sizin sorumluluğunuzdadır. Yayınlanan kod sadece eğitim amaçlıdır ve böyle bir şeyin yapılabileceğini göstermek için yazılmıştır.

ClamAV Sohbetleri

Bir güvenlik açığı kapatılmaya çalışılıyordur. Advisory’de yeni sürümünde bu açık giderilecektir yazmaktadır. 3 saat sonra release gelir, ClamAV web sayfasında release için “stable” yazmaktadır ancak denendiğinde API/ABI kırdığı görülür. Bundan dolayı Klamav derlenmez ve çalışmaz. Irc kanallarına gidilir ve bu açık için patch istenir, bir geliştiriciden “bunu şimdi söyleyemem” yanıtı alınır. Ancak gariptir ki 0.93 sürümünde giderildiği belirtilmiştir ve açığı kapatan kod oradadır. Bir başka kişi de yakında SVN’e commit edileceğini söyler ve şöyle bir diyalog gelişir;

[21:11] <Eren> well, I think it’s a common of you that you make changes and release tarball, then commit these changes to svn?
[21:11] <edwi1> Eren: yes
[21:12] <Eren> ?!

Tor kullanmak güvenli mi? Bence değil.

Bildiğiniz gibi Tor, Internet üzerinde gizli olarak gezinebilmenizi sağlayan bir proxy uygulaması. Basitçe tor’u bilgisayarınıza kuruyorsunuz ve bazı ek uygulamalar yardımıyla webde orjinal IP adresinizi gizleyerek dolaşabiliyorsunuz. Ve bunları yaparken kendinizi güvende hissediyorsunuz, ama öyle değil.

David Berlind’in ZDNet’te yazdığı blog girdisini okuduktan ve freenode’da #tor kanalında yaptığım sohbetten sonra Tor’un artık kullanılabilir olduğunu düşünmüyorum.

Olaylar Dan Egerstad’in bazı önemli parolalar halka açıklaması ile farkediliyor. Dan Egerstad, tor exit nodelarından bir tanesini elinde bulunduruyor, ve bunun üzerinden geçen her veriyi izliyor. Hükumet bunu üzerinde soruşturma başlatıyor ve Dan Egerstad yakalanıyor. (The hack of the year)

Peki güvenli bildiğimiz tor neden bir insanın yakalanmasına sebep oldu? Gayet basit.. Eğer exit node’lardan biri iseniz, her tor clientinden gelen veriyi saf olarak aktarırsınız ve içinizde yaramazlık varsa, bunun üzerinden geçen verileri görme dürtünüz sizi alıp götürür, sonuçta da yakalanabilirsiniz.

Tor kullanırken gönderilen bilgilerin görülememesini sağlanabilir mi?

Elbette sağlanabilir. Kullanılan servis (örneğin web siteleri) eğer güvenli erişim protokolü üzerinden iletişim (SSL) sağlıyor ise network üzerinden geçen tüm veriler şifrelenecektir, böylece saf veri görülebilse bile gönderdiğiniz paketler çözülemeyecek, o veriyi gören insanın işine yaramayacak.

Ancak Internet üzerindeki sitelerin %80’i bu güvenli erişim protolünü desteklemediği için bu siteler üzerindeki kullanıcı oturumları rahatlıkla görülebilir. Güvenli erişim sağlanmadığında gönderdiğiniz form biglileri saf halde network üzerinden geçiyor, bu demek oluyor ki eğer exit node yetkilisi geçen tüm veriyi izliyorsa, gönderdiğiniz bu bilgiler rahatlıkla elde edilebilir, o site üzerindeki kullanıcınız ele geçirilebilir.

Ne kadar tehlikeli olabilir ki, kimin benimle uğraşmak ister?

Belki facebook kullanıyorsunuzdur. Facebook’a giriş yaparken ön tanımlı olarak SSL kullanılmıyor. Eğer Tor kullanarak giriş yapacak olursanız ve Internetin diğer ucundaki insan kötü niyetli ise facebook profilinizi ele geçirebilir.

Bu kişi yabancı diyelim, anlamadığı dili konuşan insanlarla işi olmayacaktır büyük ihtimalle, peki David Egerstad’in yerinde bir Türk olabileceğini düşündüğünüz oldu mu?

Bunların yanında yazışmalarımız da tehlikeye girebilir;

IRC; network üzerinde saf halde veri alınıp/gönderiliyor. Takma adınızı kaydederken veya tanıtırken parolalarınız görülebilir. Ayrıca yaptığınız özel konuşmalar da dinlenilebilir.

MSN; oturum açma sırasında parola ve e-post adresini SSL ile göndermesine rağmen başkalarıyla sohbet ederken, kişi listesini alırken ve diğer özellikleri kullanırken saf halde veri gönderilip/alınıyor. Yine msn sohbetleriniz görülebilir, kişi listenizde var olan insanlar görülebilir.

Şunu da hatırlatmakta fayda var. Yukarıda yazdıklarımı sadece tor ile sınırlandırmayın. Eğer herhangi bir yerde şifresiz kablosuz ağ bulduysanız ve kullanıyorsanız, yukarıda yazılanların gerçekleştirilebileceğini aklınızdan çıkarmayın. Etraftaki herhangi biri havada yolculuk eden paketleri toplayabilir ve görebilir.

Tor kullanırken kendinizi fazla güvende hissetmemenizde ve şifresiz kablosuz ağları kullanırken sevinmemenizde yarar var, aleyhinize sonuçlanabilecek olaylar olabilir.

Web Tarayıcıları için Rootkit

     Petko D. Petkovblogunda yayınladığı yazı insanı bu konuda gerçekten düşündürmeye yöneltiyor. Üzgünüm ki metnin tamamını çevirecek kadar vaktim yok, sadece ana hatlarına değineceğim. Eğer ingilizce biliyorsanız kesinlikle dökümanı okumanızı öneririm.

     Yazı, browser rootkitlerinin önemsenmediğini, buna neden olarak da bu tür teknikler ile sistemin tamamının ele geçirilemeyeceği söylüyor. Buraya kadar haklı, ancak günümüzde en önemli hazinenin bilgi olduğu ele alınırsa, bu tekniğin kötü eller tarafından keşfedilmesi halinde ne kadar tehlikeli olabileceğini bir düşünün. Bilgi akışının neredeyse tamamı tarayıcılar aracılığı ile yapılıyor; form bilgileri, parolalar, web mail servisleri ile gönderilen e-postalar ve niceleri. Sisteme kurulan, anti-virüs yazılımları tarafından yakalanma ihtimali şimdilik olmayan tarayıcı eklentileri ve 3. parti yazılımlar ile gönderilen/alınan her bilgi 3. bir kişinin eline rahatlıkla gönderilebilme riski var. Peki bu nasıl olabilir?

     Firefox’u ele alalım. Firefox’un bir çok bölümü Javascript, Python gibi yorumlanan diller ile yazılmış ve XUL, XML, RDF formatlarını destekliyor. Bir anti-virüs uygulamasının bu formatların rootkit olarak kullanıldığını farketmesi için bunların hangi alanda kullanıldığını, ne yaptığını anlayabilmesi gerekir ve henüz bunu yapabilen modern bir anti-virüs uygulaması yok, olması halinde de yakalaması zor olacağa benziyor. Herhangi biri bunları kullanarak Firefox veya Internet Explorer için rootkit yaparsa şu şekilde yayılabileceği öngörülüyor;

  • Dikkat çekmeyen eklentiler: Rootkitin kullanılabileceği en yaygın alan. Rootkit sisteme ve kullanıcıya görünür halde olur ayrıca herhangi bir yol ile kullanıcının bunun önemli bir eklenti olduğuna inanması sağlanır.
  • Gizli eklentiler: Rootkitin görünürlüğü kaldırılır ve gizlenir. Bu Internet Explorer’daki öntanımlı davranıştır. Firefoxta ise eklenti kurulum dosyasındaki bazı değerler değiştirilerek yapılabilir.
  • 3. Parti Rootkitler: Tarayıcılar ile beraber sıkça kullanılan Adobe Flash Player ve Adobe Acrobat Reader kullanılabilir. Adobe Acrobat Reader açısından bakacak olursak rootkit yazarı pdf dosyasına kolayca javascript kodu kopyalayabilir. Kullanıcı bunu ne zaman açarsa etkilenebilir. Flash Player açısından bakarsak; rootkit yazarı, flash player ayarlarını hafifleterek kendi belirlediği sitedeki flash player objesinin yasaklanmış bazı işlemleri yapmasını sağlayabilir.
  • Eklentilerin eklentileri ile yapılan rootkiler: Bir eklenti için yapılan eklenti yardımı ile gerçekleştirilebilir (greasemonkey için kullanıcı scriptleri gibi). Böylece saldırgan XSS proxy yardımı ile tarayıcı kontrol altına alabilir.

İleride çok farklı teknikler ile karşılaşacağız gibi görünüyor, ne dersiniz?