Metasploit Framework ile Guvenlik Denetimi Semineri

11-14 Mayis 2006 tarihinde yapilan Linux ve Ozgur Yazilim Senligi'nde "Metasploit Framework ile Guvenlik Denetimi" seminerini sundum. Seminerde Exploit gelistirme gereksinimleri ve surecleri ile Metasploit Framework uzerindeki uygulamalarini anlattim. Ayrica Metasploit'i diger framework'lerden ayiran farklar ve gelistirmis olduklari yeni teknolojileri inceledik ve canli uygulamalar ile kullanimini gosterdik. Seminerin sunum dosyasi asagida yer almaktadir.


Sunum : Devamı

posted by Fatih Ozavci @ 10:30 AM Yorumlar: 1  

Sox uyumluluğunun astarı yüzünden pahalı mı?

Sarbanes-Oxley Act (SOX) 2000'li yıllardan bu yana kopan finansal skandalların tekrarlanmaması için gün geçtikçe daha da sıkılaştırılan kontroller uygulamakta. NASDAQ'a kote firmalar başta olmak üzere şimdiden birçok yerde zorunluluk halini almış durumda.

Peki bu tür çalışmalar gerçekten de beklenen faydayı getiriyor mu? Bazılarına göre hayır. GE Başkan Yardımcısı Philip Ameen'e göre, finansal konularla ilgili iç kontrolleri zorunlu kılan SoX Section 404'ün 2004'de 40,000, 2005'de ise 38,000 kontrolünün uygulanması yaklaşık $33,000,000'a malolmuş.

Peki sizce güvenlik tarafında durum ne? BGYS projeleri gerçekten yararlı olsun diye mi, yoksa yasak savmak için mi uygulanıyor ve getirileri maliyetlerini haklı çıkartıyor mu? Yoksa hala bu işlerin kıymetinin anlaşılması için erken mi? Devamı

posted by kivilcimh @ 10:04 AM Yorumlar: 1  

Exploit Gelistirme Altyapilari Sunumu

Sacis Expo etkingilinde sunmus oldugum, exploit gereksinimi, gelistirme sureci, gelistirme ihtiyaclari ve exploit gelistirme ortamlarinin karsilastirmalarinin aktarildigi "Exploit Gelistirme Altyapilari" seminerinin sunum dosyasi asagida yer almaktadir.

Sunum : Devamı

posted by Fatih Ozavci @ 11:02 AM Yorumlar: 0  

Laptop ile yirmi dakikada araba çalmak!

Klasik film sahnesidir, bir elektronik kart okuyucuya, bir ucunda laptopa bağlı bir ribbon kablo olan bir kart sokulur ve bunun üstünden şifre kırma işlemi başlar, filmin çok küçük bir süresi içinde de işlem tamamlanır. Benzer bir örnek T2'de vardı. Fakat bu tür sahneler genelde InfoSec uzmanlarının yüzünde bir tebessüm oluşturmakla, habersiz kişilerin de "Allah allah bu kadar kolay mıymış?" diye şaşırmasından öteye bir anlam içermez genelde.

Görünen o ki, bu türden üst düzey teknik hırsızlıkları, özellikle de lüks arabaların anahtarsız hale gelmesi sayesinde daha sık görüyor olacağız. Bu haberde bir laptop eşliğinde birçok elektronik kilit sisteminin yirmi dakika gibi bir süre içinde bertaraf edilebildiği ve bu türden birçok araba çalma olaylarının gerçekleştiği anlatılmakta.

Ross Anderson'ın meşhur kitabı Security Engineering de bu kadar ileri bir teknik  olmasa da anahtarla elektronik olarak alarm kapatma ve kapıyı açma zayıflıkları üzerine çok güzel bir bölüm var, tavsiye ederim.
Devamı

posted by kivilcimh @ 11:17 AM Yorumlar: 0  

Oracle ve Yama Gelistirme Sureci Hk.da

Sifir gun aciklari makalelerimizde yama gelistirme sureci ile ilgili olarak bazi seyler yazmistik, benzer seyler dun David Litchfield tarafindan da dile getirildi ve tartismaya acildi. Buyuk firmalarin yazilim gelistirme sureclerinden acikcasi cogu kimse memnun degil, acikca elestiriler getiriliyor. Ancak genel anlamda elestiriler olgunlassa bile nadiren ciddiye aliniyor. Asagidaki elestirileri de ozellikle okumanizi istedim, umarim buyuk firmalar gecmiste oldugu gibi bugunde kulak tikamazlar.

Oracle, where are the patches??? David Litchfield
http://www.seclists.org/lists/bugtraq/2006/May/0039.html

RE: Oracle, where are the patches??? Kornbrust, Alexander
http://www.seclists.org/lists/bugtraq/2006/May/0045.html

Devamı

posted by Fatih Ozavci @ 10:37 AM Yorumlar: 0  

Sıfır Gün Aciklari Kimin Umrunda ? (Bolum 2)

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.

Onceki yazimizda bahsettigimiz gibi Microsoft guvenlik aciklarina yama gelistirmek icin aylarca bekleyebiliyordu, ancak guvenlik acigi duyurulmus ise bu surec birden kisaliyordu. Benzer seyler Oracle, Apple ve IBM gibi diger dunya devleri icinde gecerli, onlar da guvenlik acigina yama gelistirirken onceligi farkli seylere -biz ne oldugunu bilmiyoruz- veriyorlar.

Bu konuya el attigimizdan bu yana daha dikkatli izliyorum olaylari, misal Oracle gectigimiz gunlerde yeni yamasinda bazi sorunlar yasadi ve artik sorun oldukca ciddi boyutlara ulasti. Ayni seyler Microsoft'un basindan gecti ve artik guvenlik acigini bulan Microsoft'a bildirmek yerine acikca tartisiyor ve cozum istiyor. Dolayisiyla insanlar sistemlerinde bulunan guvenlik aciklari hakkinda bilgi sahibi olmak ve cozum onerisinin suratle gelistirilmesini istiyorlar.

Oracle'in yasadigi problemi biraz detaylandiralim (bu yazimizda temsili taslarimiz Oracle'a gidecek) , yuksek oncelikli bir guvenlik acigi bulunur - David Litchfield tarafindan- (Ocak 2005), sonrasinda guvenlik acigi Oracle'a bildirilir (Subat 2005), Oracle tarafindan Subat 2005 - Nisan 2006 arasinda 4 adet yama seti hazirlanir ve sonuc guvenlik acigi halen devam etmektedir. Ayrica guvenlik acigina ait exploit artik herkes tarafindan kullanilabilir hale gelmistir. Ayni guvenlik acigi bircok guvenlik acigi gelistiricisi tarafindan saptanmistir ve bunlar e-posta listelerinde konusulmaktadir.

Ancak Oracle'in en cok elestirildigi konu (ki bizim ustunde israrla durdugumuz) guvenlik acigi ile ilgili yamanin hazirlanirken sadece kendisine bildirilen bolumlerdeki aciklari kapatmasi, ancak bu fonksiyonu veya sureci kullanan diger bolumlerde ayni acigin kapatilmamasi.

Geldigimiz nokta ayni, "Buyuk yazilim/donanim firmalari guvenlik aciklarina sadece kucuk bir hata gozuyle bakiyor ve zorunluluktan dolayi duzeltiyor." Pazarlama amacli "Unbreakable" veya "Security Research Team" benzeri kavramlar ortaya atiyorlar ve yollarina devam ediyorlar. Oysa bizler, yani bu yazilimlarin kullanicilari soz konusu aciklar ile beraber yasayarak ve uretilen yetersiz yamalar ile rahatlamis olarak sicak yataklarimizda uyuyoruz.

Buyuk firmalarin cozum sureci konusunda caba gostermesi gerekiyor, ancak bizim de onlari zorlamamiz gerektigi ortada. Neden gosterdikleri cabanin yetersiz oldugu tartisilmali, yeni guvenlik acigi saptama ve yamalama yontemleri gelistirilmeli. Daha onemlisi yazilim gelistirilirken ve tasarlanirken guvenligin de bir parcasi oldugu onlara hissettirilmelidir.

Sizler Checkpoint/ISS/Symantec gibi firmalarin urunlerini alirken nelere dikkat ediyorsunuz ? Guvenlik aciklarinin olup olmadigi, tasarimlarinda guvenlik sikintilari bulunup bulunmadigi veya sizin guvenlik halkanizi guclendirip guclendirmedigi sizin icin bir kriter degil mi ? O zaman aginizin veya sisteminizin bir parcasi olan, ancak guvenlik teknolojisi olmayan urunlerden de ayni seyleri beklemek hata mi olur ? Sadece guvenlik aciginin duyurulmasi durumunda harekete gecen, hazirladigi yamalarin yetersiz oldugunu kabul etmek yerine pazardaki hakim durumuna guvenen firmalar ile ilgili olarak secim kriterlerimizi gozden gecirmemiz gerekmiyor mu ?

Ezcumle, bizler ne zaman kervan yolda duzelir zihniyetinden kurtulup, sahip oldugumuz seyleri koruma onlemleriyle desteklemek yerine, onlarin guvenli olmasini secim kriteri yaparsak o zaman firmalar guvenlik surecinde adim adim da olsa ilerlemeye baslayacaklardir. Bizlerde ancak o zaman guvenlik urunlerimizin bildigi ve yazilimlarimizin onlem olarak yamalandigi guvenlik aciklarindan hala korkuyor olmayiz.

Fatih Ozavci
IT Security Consultant
fatih.ozavci at gamasec.net


Oracle 10g 10.2.0.2.0 DBA exploit
http://www.securityfocus.com/archive/1/431353

RE: Recent Oracle exploit is _actually_ an 0day with no patch
http://www.securityfocus.com/archive/1/432399/30/30/threaded
http://www.securityfocus.com/archive/1/432393/30/30/threaded
http://www.securityfocus.com/archive/1/432354/30/30/threaded
http://www.securityfocus.com/archive/1/432355/30/30/threaded

Oracle Critical Patch Update - April 2006
http://www.oracle.com/technology/deploy/security/pdf/cpuapr2006.html

Critical Patch Update - January 2006
http://www.oracle.com/technology/deploy/security/alerts.htm

Critical Patch Update - October 2005
http://www.oracle.com/technology/deploy/security/pdf/cpuoct2005.html

Critical Patch Update - April 2005
http://www.oracle.com/technology/deploy/security/pdf/cpuapr2005.pdf

Critical Patch Update - January 2005
http://www.oracle.com/technology/deploy/security/pdf/cpu-jan-2005_advisory.pdf Devamı

posted by Fatih Ozavci @ 11:15 AM Yorumlar: 0