Mert SARICA
Patch Tuesday yani her ayın 2. Salı günü, Microsoft firması tarafından ürünlerine ait güvenlik yamaları yayınlanır. Kimileri için bu yamalardan bazıları bilgisayarın yeniden başlatılmasını gerektirdiği için can sıkan gereksiz güncellemelerken, kimileri için test edilmesi ve daha sonra istemci işletim sistemlerine kurulması gereken çileli bir iş yükü demektir. Fakat kimileri içinse bu gün kazanç kapısını aralamak anlamına gelir.
İstemci taraflı uygulamalardaki (örnek: winzip, adobe reader, winrar vb.), işletim sistemlerindeki güvenlik zafiyetlerini istismar etmeye yarayan istismar paketlerini (örnek: MPack, CRiMEPack vb.) geliştiren art niyetli kişilerin amaçları yayınlanan güvenlik zafiyetini istismar eden kodu derlemek ve paketlerini güncellemektir. Güncellenen her paket yeraltı dünyasındaki müşterilerine pazarlayacakları yeni bir sürüm olduğu için 2. Salı günü yayınlanan yamalar üzerinde hummalı bir çalışma başlar.
Bu çalışma için öncelikle bu kişilerin bu yama ile güncellenen paketi tespit etmeleri gerekmektedir. Microsoft Destek sayfası bu bilgiyi edinmek için en kolay ve zahmetsiz yoldur. Örneğin bu sayfada MS10-005 anahtar kelimesini aratacak olursanız karşınıza çıkan sonuçlarda yer alan sayfalarda bu yama ile hangi dosyanın (yazılımın kendisi olur veya ilgili DLL dosyası olur) güncellendiği bilgisine kolayca erişebildiğinizi göreceksiniz.
Paketi tespit ettiler peki ya sonra ? Daha sonra yapmaları gereken ise programın (mspaint.exe) güncellenen sürümü ile eski sürümünü assembly seviyesinde karılaştırmak ve farkları ortaya çıkarmak olacaktır. Yama geçilmiş bir Windows işletim sistemi üzerinde yazılımın eski sürümünü elde etmek için ilgili yamayı denetim masasındaki program ekle/kaldır menüsünden kaldırarak elde edebilirsiniz. Tabii yamayı kaldırmadan önce güncel yazılımın bir kopyasını almayı unutmayın.
Yamayı kaldırdıktan sonra eski sürüm ile yeni sürümü kıyaslamak için yaygın olarak kullanılan ücretli ve ücretsiz 3 programdan faydalanmaktalar. Bunlar sırasıyla, Zynamic’in BinDiff (ücretli), eEye’in DarunGrim, Tenable’ın PatchDiff programlarıdır. Bu üç programda IDA Pro yazılımının eklentisi olarak çalıştıkları için IDA PRO’nun mutlaka işletim sistemi üzerinde kurulu olması gerekmektedir. 3 programında çalışma mantığı birbiri ile hemen hemen aynı fakat DarunGrim yazılımının daha anlaşılır olduğunu not olarak belirtmek isterim.
Hangi programı kullanırlarsa kullansınlar bu programlar sayesinde yama ile hangi fonksiyonda değişiklik yapıldığını tespit etmeleri çok uzun sürmez. Bunun için yapmaları gereken DarunGrim yazılımında File menüsünden New Diffing from IDA’yı seçmek ve Source için eski sürümü, Target için yeni sürümü ve Output için ise herhangi bir klasörü belirtmek yeterli olacak ve DarunGrim gerisini halledecektir. Analiz tamamlandıktan sonra DarunGrim size eski sürüm ile yeni sürümde yer alan her bir fonksiyon için eşleşme değerini (Match Rate) gösterecektir. %100 eşleşen bir fonksiyonun değişmediğini daha az yüzdeler ise fonksiyonda değişiklik olduğunu işaret etmektedir. Kontrol akışı izlendiğinde sarı renk bir eski sürüm ile güncel sürüm arasında bu bloğun değiştiğini, kırmızı ise yeni bir blok eklendiğini belirtmektedir.
Son olarak assembly kodunu dikkatlice inceleyerek hatalı, zafiyet barındıran kodu tespit eden bu kişiler istismar aracını geliştirdikten sonra derleyerek paketlerine eklerler. Yamasını geçmeye üşenen kişiler/kurumlar ise gün geçmeden art niyetli kişilerin hedefi olurlar. Siz siz olun her ayın 2. Salı günü zamanla yarışan art niyetli kişilerin hedefi olmamak için işinizi gücünüzü bir kenara bırakarak güvenlik yamalarını geçmeye bakın…
Mert SARICA
24 comments
Şimdiden teşekkür ederim. Zaman sorun değil. Önümde uzun bir askerlik dönemi var. blue_screen_of_death_07 [at] hotmail [dot] com’dan ulaşabilirsiniz. Yazdığınız bir blog/site vs. var mı?
Haziradigim raporlar sureclere degil sonuclara yonelik oldugundan internette arastirip bulabileceginiz vulnerability analysis report’larindan cok bir farki olmayacaktir. Zaman buldugumda analizin nasil yapildigi ve surec ile ilgili de ayrintili bir dokuman hazirlayabilirim. Zamanlama ile ilgili su asamada bir tahhutte bulunamiyorum, ancak madem bahsi de gecti MS09-043/ CVE-2009-1534 hedef patch olabilir. Dokuman tamalandginda yayimlanmasinin nasil olacagi ile ilgili (en basitiden ilgili dokumani hangi adrese e-mail atayim?) detaylari paylasirsaniz sevinirim.
Onlemleri by-pass etmek cogu zaman mumkun, ancak hangi onlem(ler)in alindigini (ozellikle vulnerability’nin bulundugu yerde) ve karsilik olarak nasil bir yol izelenecegini bulmak gerekli. Yani, her bi durum icin kendine has kisa bir calisma yapmak gerekli. Mesela, Adobe Reader icin halen kotu niyetli pdf dokumanlarinda siklikla kullanilan collab.getIcon() ile ilgili CVE-2009-0927 kodlu vulnerability’de esas sorun stack overflow olmasina ragmen secure stacj mekanizmalari kullanildigindan EIP’i istediginiz gibi degistiremezsiniz. Yani sadece stack’deki retrun address’i re-write etmek ise yaramiyor. Bunun yerine stack’te biraz daha fazla veri yazarak aktif SEH handler’i overwrite edebilirsiniz, daha da fazla veri yazarak (stack icin ayrilmis memory page’i doldurup) istediginiz adreste olusturdugunuz exception’i handle edebilirsiniz.
Ancak bu case’de yeni yazilacak SEH handler’in adresi basarili kod calistirma icin anahtar noktalardan birisidir. Memory yerlesimi kullanilan O/S, Adobe Reader versiyonu vs. gibi etkenlerle degistiginden, heap spray yaparak Adobe Reader’in siklikla kullandigi adreslere istediginiz veriyi yazabilir, bu verinin adresin SEH handler olarak re-write edebilirsiniz.
Yukaridaki case her durumun kendi ozel sartlari icerisinde ele alinmasi acisindan iyi bir ornek. Internet uzerinde halen aktif olarak dolasan cok cok cok daha karmasik durumlar bulmak mumkun. Onlemlerin karsiliklari olan heap-spray, seh overwriting, return-to-libc vs. gibi yontemler oldukca iyi dokumante edilmis durumdalar. Onemli olanin hangi yontem(ler)in ne zaman ne sekilde kullanilacagi oldugu kanisindayim.
Basarilar,
Dokümanı hazırladıktan sonra bana iletebilirseniz (mert [nokta] sarica [at] gmail.com) seve seve yayınlayabilirim.
Yüksek profilli olarak değerlendirdiğiniz uygulamalardan her hangi biri hakkında konumuzla ilgili ayrıntılı görseller de içeren bir raporunuz varsa incelemek istiyorum, eğer sizin için sorun olmazsa.
Vulnerable fix bulunduysa son zamanların en güzel tekniği head-spray..aslr, dep vs..gibi korumaları aşabilen exploit örnekleride yayınlanmıştı galiba…
Bypass için kullanılan yöntemin adı ROP (return oriented programming)
Yuksek profilli uygulamalarda genellikle birden fazla fix tek bir patch altina topaniyor.
Ayrica compiler optimizasyonlari ve ureticinin source repository’sinin degismesi nedeniyle
aslinda sadece fazladan bir karsilastirma (if len>100 return gibi ) yapan kodun eklenmesi
sonuc olarak cikan binary file’da yuzlerce degisiklige neden olabiliyor. Patch’ler assembly
level uretilse eminim islerimiz cok kolaylasirdi. Ancak genel olarak daha ust duzey programlama
dilleri ve karmasik optimizasyonlar sonucu uretilmis binary’ler ile karsilasiyorsunuz.
Execution path’in bulunmasi konusu da ayri bir zorluk.Eger calistiginiz binary uzerine hakimiyetiniz azsa,
patch edilen yere program isletimini (execution) getirmek oldukca sorun oluyor. Mesela, CVE-2009-1534 uzerinde
calistigimda local bir degiskenin sabit uzuluklu olarak tanimlandigi ve kullanicinin besledigi verinin ilgili
degiskene kontrolsuz olarak kopyalandigi bir durum soz konusuydu. Ancak bu durum, IE uzerinden msowc component’ine
verilen HTML formatinda kaydedilmis bir excel dosyasinda HYPERLINK olarak tanimlanmis bir cell’in referans goserdigi
URL adresinin manipule edilmesi ile trigger edilebiliyordu. Bu kosullari sadece patch-diff
(30-40 degisen sub routine’den sadece birisi aslinda vulnerability fix’ti ve 30-40 genel anlamda az sayilir.
Flash Player icin bu rakam 100’leri genelde geciyor.) ile tesbit etmek ve execution’i binary’nin degisen noktasina
getirebilmek oldukca onemli bir nokta ve analiz edilen binary’nin ne kadar tanindigi ile ilgili ve yukaridaki durum
kisisel tecrubelerime gore de karmasik sayilabilecek hallerden birisi de degil :)
Sonuc olarak, degisen sub-routine’lerden hangisi vulnerability fix, ve execution’i oraya nasil getirebilirsiniz,
o fix olmadigi durumda (patchlenmemis binary) nasil suistimal edebilirsiniz? (SafeSEH, ASLR, stackguard gibi durumlar
bir exploit’e engel mi?). Bu asamalarda da en anahtar konumda olan is tahmin edebileceginiz gibi execution’i
istediginiz noktaya getirmek. Hangi diff’in vulnerability fix oldugunu kisa sureler icinde 3-5 aday farka indirebilirsiniz
ancak execution’i o noktalara getirmek icin reverse ettiginiz binary’i gercekten tanimaniz gerekiyor.
Elbette Ida’dan bagimsiz olarak da patch-diffing yapilabilir, hatta IDA+diff tool+WinDif gibi tool-set’ler kullanarak
cok rahat etigini soyleyen analistler de var. Ama ben inceledigim binary’lere o kadar hakim olmadigimdan olsa gerek,
bu isi hala “goz atmak” ve “fikir edinmek” acisindan cok karmasik buluyorum.
Kolay Gelsin,
Anladığım kadarı ile siz bu işle prof. olarak ilgileniyorsunuz, ekmek yiyorsunuz, işiniz bu..ama ben bir inşaat mühendisiyim ve bahsettiğimiz konu ile hobi olarak ilgilendiğim için arada fark var. Benim ki eğlencelik, birşeyler öğrenmek maksatlı.
Test ağınızda, patchlenmiş ve patchlenmemiş uygulamalalrı debug modda çalıştıran makinalara capture edilmiş paketleri yeniden oluşturarak/gönderilerek programlar izlenebilir…
Elinizde patchlenmiş ve patchlenmemiş uygulamalar varken execution-path bulmak neden bu kadar sorun anlamadım. Isterse 500 tane subroutine olsun…
Kastettiğiniz IDA’dan bağımsız çalışan minik bir araç ile bu analizin yapılmasının olanaksız olduğu ise bence yanılıyorsunuz. Asm ile hiç program yazınız mı bilmiyorum ama crasha neden olan hatalar çok basit oluyor genelde ve patchide çok basit oluyor. Patch yazacak kapasite varsa zaten subroutinler arasında kaybolan execution-patchi bulmanız bakarak bile mümkün olabiliyor. Bu yüzden IDA’dan bağımsız, grafiksel bile değil text bazlı bir difing toolun eksikliğini hissettim ki, bahsetme ihtiyacı uydum.
Sizin ihtiyacınız olmayabilir…
Elbette patch’in kapattigi zaafiyeti suistimal eden bir exploit varsa isler biraz daha farkli olabilir.
Kisisel olarak patch-diffing’te genel hedefim patch ile kapatilan acigi susitimal edebilecek PoC exploit’ler
olusturmak. Sadece exploit-code’u incelemek bana nispeten daha yalin bir ugras gibi geliyor.
Is shell-code, payload analizlerine geldiginde de insanlar kendi tecrubeleri isiginda kendi yontemlerini
gelistiriyorlar. Nihayetinde elinizde calistiabildiginiz bir exploit-code varsa, cesitli yontemlerle
(INT 3’e degistirme vs. gibi…) coverage, execution-flow vs. ile ugrasmadan nokta atisi yapabilirsiniz.
Elinizde sadece expolit-code’u barindiran capture edilmis network paket’leri varsa biraz daha zor bir
isiniz var demektir…
Iyi calismalar,
Amaç zaten sonuca gitmek değil ki. Günlük kullandığınız makinada, analiz yapacağınız makinaya geçmeden önce bir göz atmak. Esas analizlerinizi yaptığınız, alet edavatlarınızın bulunduğu makina evdedir mesela, mesai bitimi eve gitmeden önce merak gidermek istersiniz belki ve ofisteki makinada IDA yoktur. Yanınızda, flash diskinizde portable minik basit bir tool. Grafiksel de değil text bazında diff yapıyor direk binaryden..Hoş olurdu yani.
Patch ile ilgili exploit kodunu biraz moifiye edip shell çalıştımadan payloadı trace edebilirsiniz. Subrutinlerle uğraşmadan kolayca bulunur patch adresi (eip).
Çok ufak bir binary ise ve değişiklik tek bir subroutine’den ibaretse evet böyle bir program değişiklik konusunda fikir verme adına faydalı olabilir. Fakat gerçekten complex binarylere öğle yemeği molasında bir göz atmakla farkları ve execution pathi anlamak pek kolay olmaz gibi :)
Kendi deneyimlerimden yola cikarak, patch-diffing islemi
(ozellikle yuksek profilli Word, Excel, Flash Player gibi yazilimlarda)
oldukca karmasik olabiliyor. Coverage’i saglamak neler oldugu nerelerde
duzeltme yapildigi gibi konularda en hayati konu fikrimce. Elbette uzerinde
uzun sure calisilip her fonksiyonu ve execution-path’i belirlenmis binary’ler
uzerinde analizler oldukca hizli yapilabilecektir.
Ayrica yuksek profilli bir yazilimin diff’ini aldiginizda genel olarak 30-40’dan
az olmayan subroutine’de farklilik buluyorsunuz ve genellikle de sadece bunlardan
birisi gercekten ureticinin patch’i oluyor.
Uzun lafin kisasi, patch-diffing’de “goz atmak” ve “fikir sahibi olmak” kisisel
tecrubelerimden hareketle sonuca dogru yol almaya yardimci olmadigi kanaatindeyim.
Ancak sizin patch-diffing konusunda ilgili degisikligi hizlica belirlemek icin
gelistirdiginiz bir yontem varsa ve paylasabilirseniz cok sevinirim.
Basarilar,
.yturhan Nasıl bir örnek versem bilemedim ama şöyle düşün, sisteminde bilinmeyen bir zararlı var ve önce bunu tespit etmek istersin sanırım..ki daha sonra kapsamlıca analizini yapıp temizleyebilesin.
Demek istediğim; PEID’in imza gösterdiği gibi, uzun uzun analiz gerektirmeyen, öyle bir bakıyordum der gibi, hex compare gibi saniyesinde diffing yapan basit, küçük bir uygulama..IDA gibi her türlü işlemci komut setinide tanıması gerekmiyor. x86 uyumlu olsun yeter.
Amaç pratiklik, analize başlamadan önce yorum yapabilmek için bir ön tespit vs..Analiz yaptığın sistem başkadır, günlük kullandığın sistem farklı olabilir..Analiz yaptığın sistemi aç, IDA aç, db’leri oluştur, diffing yap uzun iş yani..
Bu arada kullandığın sistem yüzünden sanırım, yorumlarında font sorunu var..Türkçe karakterlerde…
Aslında patch-diffing programları bir şekilde disassembler modüllerine muhtaçtırlar.
Düşünürsek, programın giriş verisi olan şey aslında disassemble edilmiş programlar.
Bu verilerin çeşitli şekillerde (fonksiyon ismine göre basic block sayısı, xref’ler vs)
benzeşimleri ve/veya farkları da bu tip programların hedef çıktısı. Hedef çıktılar
düzgün bir şekilde analistlere sunulmadıkça da bu tip programların yararı da oldukça sınırlı olacaktır.PEiD’nin disassembly modülünü kapsamlı bir analiz için kullanan birileri var mı?
Elbette diffing yapan programın içerisinde kendine has disassembler modülü de bulunabilir
ancak doğru düzgün ve kullanılabilir bir disassembler modülü / programı yazmak patch-diffing
programı yazmaktan çok daha karlı bir iş olmalı.
Aynı şekilde IdaPro sektör içerisinde de-facto standart disassembler tool’u olduktan sonra,
pulg-in /add-on konusunda da en çok tercih edilen platform olmaya devam etmesi benim açımdan süpriz olmayacaktır.
ğ°yi çalışmalar,
Kolay yol değilde pratiklik açısından..IDA ile çalışmıyorken rapor filan vermeden çok basitçe ve hızlı bir şekilde sadece o an için sonuç veren ve hatta explorer ile senkronize; sağ tık menüsünden dosya seçebilen ve hedef belirleyebilen basit bir araç daha kullanışlı olabilir kanaatimce. PEID gibi…
Yok ben üreticileri kastetmiştim. Hazır IDA işlerin büyük bir kısmını yapabilirken onu temel almak daha kolaylarına gitmiş.
IDA’dan tamamen bağımsız diffing yapan bir uygulama yok galiba..
Herkes kolay yolu seçmiş gibi görünüyor :)
Bindiff, bu iş için bana göre biçilmiş kaftan..ancak dediğiniz gibi büyük dosyalarla çalışmak neredeyse imkansız..Bu noktada patchdiff devreye giriyor.
DarunGrim hiç kullanmamıştım. IDA’dan tamamen bağımsız çalışabiliyor mu? Yani db’leri IDA kapalıyken bile analiz edebiliyor mu?
Yarı bağımlı diyelim çünkü analiz etmek için IDA veritabanı dosyalarına ihtiyaç duyuyor ve oluştururken IDA’yı kullanıyor fakat bu dosyalar mevcut ise IDA olmadan farkları analiz etmenize imkan tanıyor. Detaylı bilgi için buraya bakabilirsiniz.
BinDiff ücretli ve bayada pahalı diye biliyorum mert ücretsiz yazmışsın ama ya da ben bilmiyo olabilirim ücretsiz versiyonu varsa
Pardon ücretli yazacaktım, düzelttim :)
Kisisel olarak patchdiff’i DarunGrim2 ye gore yeni bir process context’inde ve
kendi window’lari ile bagimsiz olarak degil IDAPro ile tamamen butunlesik calismasi nedeniyle,
BinDiff’e gore buyuk IDA Database’leri ile calisabilmesi ve performansi nedeniyle daha ustun ve
tercih edilesi bulmaktayim. Ancak sektorde genel olarak BinDiff’in tercih ediligini de belirtmek lazim. Bu konudaki kariyer olanaklari bir sekilde pach-diffing yapmis olmayi yeterli gorse de sanirim bir kac yil icerisinde BinDiff ile patch-diffing yapmis olmak on sartlardan birisi olacak.
Gunun sonunda esas olarak tum bu tool’larin yaptiklari isler, sonuclari ve olgunluklari acisindan
birbirlerine oldukca benzerler. Bibirlerine karsi ozellikle bulunan farklarin anlamlandirilmasi ve
code reorganization gibi programin isletimi acisindan fark sayilmamasi gereken durumlari basariyla
algilayabilmek gibi bir takim ustunlukleri / zayifliklari mevcut. x86 mimarisinde cok fazla
etkilenmesekte diger mimarilerde ozellikle code re-organization konusu analist’lere buyuk
sorunlar cikartabiliyor.
Basarilar,
Merhaba,
Aslında sektör içerisinde bu duruma çözüm bulmak için çalışmalar bir süredir devam etmekte. Bu konuda iyi bir örnek: Jeongwook O / Blackhat 09’daki Fight against 1-day exploits: Diffing Binaries vs Anti-diffing Binaries (http://www.blackhat.com/presentations/bh-usa-09/OH/BHUSA09-Oh-DiffingBinaries-PAPER.pdf)
DarunGrim 2. sürümünde oldukça yeterli gözükürken benim tercihim genellikle patchdiff yönündedir.
DarunGrim’in ayrık kullanıcı arabirimi ve BinDiff’in büyük dosya / çok değişiklik olan durumlarda performans problemleri bence kullanım sorunları çıkartmakta.
Ayrıca turbodiff isimli open source patchdiffing tool’u da oldukça gelecek vaad eden bir çalışma..
Yama analizi aslında sadece saldırganlar tarafından kullanılan bir yöntem değil. Kurumsal firmaların çeşitli haklı sebeplerle kullandıkları patch management prosedürleri yüzünden güncellemeleri ağır / yavaş şekilde yapmak zorundalar. Bu tip firmalar genellikle patch’lerden oluşturulan IDS sistemleri ve onların update edilen signature’ları ile güvenliklerini sağlamaya çalışmaktadır. Yani analiz edilen patch’lerden kapatılan açık hakkında attack vector’leri oluşturulmakta daha sonrada IDS signature’u olarak satılmaktadır. Mesela Fransadan eski K-otik yeni vupen bu piyasada prestijli bir yere sahiptir.
Başarılar,
Neden patchdiff diye soralım o zaman :) Ek bilgi için teşekkürler.