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.
Güvenlik açığını
bir web uygulamasını denetler iken keşfettik, uygulama farklı kodlama
yöntemleri kullandığımızda normal dışı tepkiler üretmekte ve kullanmakta
olduğu güvenlik özelliklerini başarılı biçimde uygulayamamaktaydı.
Ancak denetim esnasında farkettiğimiz bir diğer durum, uygulamayı
koruyan bir web uygulama güvenlik duvarı olduğu, bilinen türde
saldırılar yaptığımızda engellediği; ancak bahsettiğimiz farklı dil
kodlamasını kullandığımızda engelleme uygulayamamasıydı. Daha sonra aynı
web güvenlik duvarının bulunduğu bir başka müşterimize de yaptığımız
denetim esnasında söz konusu açığı kullandık ve başarılı oldu. Bu
noktada ki en büyük şansımız iki denetimin neredeyse eş zamanlı
yürümesiydi, böylece iki ayrı yapılandırmaya sahip aynı türde sistemi
denetleyebildik. Sonuç olarak atlatma türündeki güvenlik açığının ilgili
web güvenlik duvarında olduğunu saptadık. Kısa süre içinde gelen bir
diğer denetimde, farklı bir saldırı önleme sistemi olduğunu gördük ve
aynı yöntemi denedik, sonuç atlatmanın başarıyla sonuçlanmasıydı. Özetle
güvenlik pazarının lider firmalarına ait iki ayrı türde web güvenlik
duvarı ve saldırı önleme sisteminde bu güvenlik açığının bulunduğunu
gördük.
Açıkçası ilk bulduğumuz güvenlik açığı olmaması ve
denetimin doğası gereği bu duruma pek şaşırmadık. Ancak söz konusu
atlatma yönteminin evrensel bir yöntem olduğu ve çok sayıda saldırı
tespit/önleme sisteminde işleyebileceğini görünce yayınlamaya karar
verdik. Yayınlama süreci oldukça basit görünebilen, bazı yeraltı
sitelerine, SecurityFocus - Bugtraq
gibi e-posta listelerine veya güvenlik duyurularının detaylı olmasını
isteyen grupların listelerine bir e-posta atılmasının yeterli olduğu
düşünülen bir süreçtir. Çok sayıda üretici ve tabi etkilenen çok sayıda
müşteri kurum söz konusu olduğunda güvenlik açığını doğrudan ve kullanım
yöntemiyle açıklamak pek mantıklı gelmedi. Sonrasında firmalar ile
haberleşme sürecimiz başladı.
Bu noktada detaya girmeden kabaca bir güvenlik duyurusunun nasıl yayınlanabileceğini listelersek ;
1
- Sadece siz ve yakın olduğunuz bazı kişiler bilirsiniz (Pek doğru
görünmüyor, zaten adı da yayınlama değil kendine saklama olmalı)
2 -
Yeraltı gruplar olarak nitelenen gruplara ait forum/posta listesi/sohbet
veya toplantılarda açıklayabilir, ün kazanabilirsiniz (Doğru
görünmediği gibi kullanım yönteminin yeterince kötü niyete sahip
kişilere ulaşmasının doğrudan ve en kolay yoludur)
3 - Üreticilere kısıtlı bir zaman verip, güvenlik açığını ne olursa olsun verdiğiniz tarihte duyurursunuz
3a - Duyuruda kullanım yönteminin detaylı olarak açıklayabilirsiniz
3b - Kullanım yönteminden bahsetmez olabildiğinde muğlak ifadeler kullanabilirsiniz
3c - Doğrudan kullanım yöntemini vermeseniz de yakınlarında dolaşır, ehil kişilerin durumu farketmelerini sağlarsınız
4
- Üreticiden bir tebrik almak adına açığı onlara bildirir, üreticinin
yamayı yayınlamayı planladığı çok uzun süreli tarihi beklersiniz.
Güvenlik duyurusunda ise 3b maddesi gibi muğlak ifadeler kullanıp açığın
kullanımından bahsetmessiniz.
Liste zorlanırsa uzayıp gidebilir
ancak belli başlı yayınlama biçimleri bunlardır. 3 ve 4 ile alt
maddeleri gri alanlarda kalmaktadır, bazı kişilere göre biri bazılarına
göre tümü haklıdır.
Sorun şu ki bizim durumumuza yukarıdaki
şıkların hiçbiri uygun değildi. Söz konusu olan bir üretici olunca
tepkileri ölçmek, yama hazırlama süreçleri hakkında fikir sahibi olmak
veya etkilenen müşterilerin boyutunu hesaplamak mümkün görünüyor. Çok
sayıda üretici ise açıkçası birçok sıkıntıyı beraberinde getiriyor, bu
yüzden bizim geçtiğimiz yola geri dönüp özetlemek, belki benzer açıkları
bulanlara kolaylık sağlayabilir.
Bizim durumumuzda açığın sadece
iki üreticinin ürünlerinde olduğunu doğrulayabildik; ancak çok sayıda
saldırı tespit/önleme sisteminin de durumdan etkilendiği oldukça açıktı.
Ya tüm üreticilerin ürünlerini aynı testlerden geçirecektik ( Yaklaşık
100 üretici x 4 ürün x 1 saat test süresi x 4 saat test ortamı kurulumu)
yada başka bir yol uygulayacaktık.
Öncelikle doğruladığımız
kurumlar ile irtibata geçtik, olumlu karşıladılar ve çok yardımcı
oldular. Açık konuşmak gerekirse oldukça büyük bir veritabanı
üreticisinin bana benzer bir durum için vermiş olduğu cevap beni uzun
süre "bulduğun sende kalsa daha iyi" düşüncelerine sevk etmişti. Ancak
bu kadar yardımcı olmalarını beklemediğim için ben de duruma oldukça
istekli yaklaştım ve elimizdeki her türlü kaynağı onlara sağlamaya
çalıştım. Gecenin bir saati uluslararası görüşmeler, telefonda durumu
açıklamanın zorlukları ve yama geliştirme süreci tahminlerinin
yanıltıcılığı hesaba katılınca zor birkaç gün geçirdik.
2
üretici ile görüşmemizde öncelikle basit birkaç konuyu halletmeye
çalıştık; açık gerçekten açık mı ? , üreticiler bunu nasıl yamalar ? ,
tahmini yama geliştirme süresi ne kadar ? ve son olarak biz güvenlik
duyurularında nerede olacağız ? (Öyle demeyin çok önemli, açığın
öneminden geçtim kaç gece uykusuz telefonlardaydık :) Diğer
üreticilerin de durumdan nasıl etkilendikleri, bahsi geçen sorulara
cevapları önemliydi. Her durumda onları haberdar etmek için sebebe
ihtiyacımız vardı; fakat ürünlerini deneyemiyorduk (kabul ediyorum bu
zor yola başta girmeye çalıştık ama 2-3 üreticiyi test için ancak ikna
edince vazgeçtik). Sonuçta bu noktada US CERT imdadımıza yetişti,
IBM/ISS'ten Peter'ın önerisi ile konuyu onlara anlattık ve çok yardımcı
oldular. Güvenlik açığının net kullanımı ve etkilerini kendilerine izah
ettikten sonra tüm şüphelenilen üreticilere bildirimde bulundular, bizim
işimizde epey kolaylaştı. Hazır yazıyor iken bu süreçte bizlere
kolaylık sağlayıp bu sürecin az sancılı geçmesini sağlayan ve teşekkürü
hakeden üç kişiyi de unutmak olmaz, Jeff Gennari (US CERT), Michael
Kapelevich (Checkpoint) ve Peter Allor (IBM/ISS XForce).
Üretici ile temas kurma ve açığı yayınlama aşamasında altın birkaç kuralı hatırlatmakta fayda var;
1- Doğru kişi/kurum/ekip ve e-posta adresini bulmalısınız, tercihen önce Internet'i biraz araştırın.
2- Asla seçtiğiniz kişiye güvenlik açığını anlatan bir e-postayı kriptosuz göndermeyin, bu adımın son adım olduğunu unutmayın.
3-
Seçtiğiniz kişinin doğru kişi olduğu, güvenlik açığını doğru
yetkililere ilettiği, ciddiye alınabilecek biri olduğu ve iyi niyetli
olduğu varsayımlarını tekrar gözden geçirin; tercihen araştırıp emin
olun.
4- Öncelikle bir güvenlik açığı bulduğunuzu belirtin,
kendisinin bu konuda yetkili olup olmadığı ve tartışmayı PGP veya S/MIME
ile sürdürüp sürdüremeyeceğinizi sorun. Birçok kurumun web sitesinde
önemli yazışmalar ve ekiplerin e-posta adresleri için PGP açık
anahtarları yer almaktadır.
5- Doğru ve güvenilir bir kişi ise
kendisine KRIPTOLU olarak güvenlik açığının açıklamasını, etkisini, risk
seviyesini, kullanma yöntemini ve varsa çözüm önerinizi iletin.
6- Üreticiden açığı doğrulamasını isteyin; akabinde tahmini yama geliştirme sürelerini isteyin.
7-
Eğer açık doğrulanır, tahmini yama/duyuru yayınlama süresi de size
uygun ise sizleri duyuruda nasıl konumlandırmalarını istediğinizi
belirtin.
8- Yama süresi size pek mantıklı gelmiyor ise (Bkz. Sıfır Gün Aciklari Kimin Umrunda ? [Bolum 1] [Bolum 2]) yayınlama adımındaki 3. maddenin alt maddelerinden uygun olanlarını araştırın.
9-
Üretici ile beraber veya farklı zamanlardaki duyurular için güvenlik
duyurunuzu hazırlayın. Güvenlik duyurunuzun, kalıcı bir web adresi,
tarih, sürüm numarası, güvenlik açığının açıklamaları, etkilenen
sistemler, etki türü, risk seviyesi, çözüm önerileri, sizin bilgileriniz
ve referansları içerdiğine emin olun. Açığın kullanım yöntemi ise
seçimliktir, seçtiğiniz yönteme uygun şekilde davranabilirsiniz. Risk
seviyesi konusunda ise sizin verdiğiniz önemi üreticiler ürünlerini
korumak adına vermeyecektir; çok umursamamanızda fayda var. Özellikle
çok sayıda üretici olduğunda bu durum çok eğlenceli olabiliyor, örneğin
bizim açığımız için yüksek/orta/düşük ibarelerinin tamamı farklı
kaynaklarda kullanıldı.
10- Güvenlik duyurunuzu öncelikle kendi
sayfanızda yayınlayın ve ilgili kurumun duyurusuna bağlantı verin.
SecurityFocus'un Bugtraq e-posta listesine ve diğer güvenlik listelerine
duyurunuzu iletin. Tek tek güvenlik açığı veritabanı, güvenlik sitesi
ve açık numarası atama siteleri bu duyuruyu takiben gerekli süreçleri
başlatacaklardır. Herbiri için tek tek bilgilendirme yapmanıza gerek
yok, yaparsanız da birşey kaybetmezsiniz.
11- Güvenlik duyurunuzu
aralıklı olarak güncelleyin, etkilenen sistemlerin, yayınlanan yamalara
verilecek bağlantıların, CVE/Bugtraq/XForce numaralarının duyurunuzda
yer almasını sağlayın.
Bizim karşılaştığımız bir diğer problem
ise her üreticinin farklı yama geliştirme süreleri olmasıydı. Bir
üretici diğerine göre daha erken haberdar edilmişti ve daha hızlı yama
hazırladı; ancak birçoğu güvenlik açığı için verdiğimiz tarihe maalesef
yetişemedi. Sonuçta güvenlik duyuru tarihini birkaç kez erteledikten
sonra sabitledik ve üreticilerin bu tarihe yetişmelerini talep ettik.
Toplam süremiz 2 ayı buldu ve birçok üretici yama hazırladı. Yazının
yazıldığı an itibariyle sadece 4 üretici ürünleri için yama hazırlamış
ve yayınlamış durumdaydı, bu duruma rağmen ilgili güvenlik duyurusunu
yayınladık.
Açığının kullanımının yayınlanması noktası ise bizim
için biraz karmaşıktı; bir yanda her açığın detaylı açıklamasının olması
ve çözümün tartışılması durur iken diğer yanda ehil eller sendromu
vardı. Özellikle çok sayıda üretici/müşteri söz konusu ise etki düzeyi
de korkutucu olabilirdi. Orta nokta ise basitçe kopyala/yapıştır
yapılamayacak ancak ehil bir kişinin kolayca farkedebileceği şekilde
açığının kullanımının yayınlanması oldu.
Sonuç olarak yorucu bir
süreçti ama aldığımız olumlu tepkilerden başarı ile bu işi
tamamladığımızı düşünüyorum. Çok sayıda kurumu etkileyen bir güvenlik
açığından bahsetmez iken durum kolay iken aksi durumda ne kadar
zorlaşabileceğini bir nebze olsun anlatmak istedim. Şunu da belirtmeden
geçmemek lazım, bu güvenlik açığı ne ilkti, ne de son olacaktır. Birçok
yerli/yabancı kurum veya kişi bu yoldan geçmiştir/geçecektir, her bir
kurum bir diğerinin tecrübesinden de bu yolda faydalanacaktır. Bizlerde
bu güvenlik açığını keşfederken veya denetimlerimizde kullandığımız
yöntemleri geliştirirken birçok kişinin tecrübesinden faydalandık. Hatta
saptadığımız güvenlik açığı, farklı kaynaklarda problem olabileceği
uzun süre önce öngörülen bir durumdu. Ancak şu unutulmamalı ki her
öngörülen durumun gerçeklemesi farklıdır ve her olayda değişim
göstermektedir. Bir açığın çok önceden öngörülmüş olması yazılımların bu
açığı barındırmayacağı anlamına gelmemektedir. Buffer Overflow açıkları
197x'lerde öngörülüyordu, buna rağmen hergün aynı türde yeni açıklar
yayınlanmaktadır. Bu noktada önemli olan ise öngörüyü geliştirmek,
gerçek hayattaki kullanımlarını araştırmak ve tecrübenizi kullanıp
farklılıklar yaratmaktır. Umuyorum bu döküman bir açığın bulunması
anlamında olmasa da (ki hedeflenen bu değildi) yayınlanması aşamasında
size ışık tutacaktır. Bağlantılar arasında farklı güvenlik açığı
yayınlama süreçleri ve yaklaşımlarına ait bağlantılarda bulunuyor,
ilgilenen arkadaşlar daha detaylı araştırmalar yapabilirler.
Fatih Ozavci
Bilg Güvenliği Danışmanı
Bağlantılar :
GS07-01 Tam/Yarım Genişlikteki Evrensel Dil Kodlaması ile Saldırı Tespit ve Önleme Sistemlerinin Aşılması
http://www.gamasec.net/gs07-01.html
US-CERT Vulnerability Note VU#739224
http://www.kb.cert.org/vuls/id/739224
Security Focus - IDS Evasion with Unicode
http://www.securityfocus.com/infocus/1232
ISS XForce - Serious flaw in Microsoft IIS Unicode translation
http://xforce.iss.net/xforce/alerts/id/advise68
OIS Guidelines for Security Vulnerability Reporting and Response, V2.0
http://www.oisafety.org/guidelines/secresp.html
RFP - Full Disclosure Policy (RFPolicy) v2.0
http://www.wiretrip.net/rfp/policy.html
Schneier: Full Disclosure of Security Vulnerabilities a 'Damned Good Idea'
http://www2.csoonline.com/exclusives/column.html?CID=28073
Microsoft: Responsible Vulnerability Disclosure Protects Users
http://www2.csoonline.com/exclusives/column.html?CID=28071
